AWS EKS – 기타 리소스

AWS EKS 기타 리소스에 대해 알아봅니다.

AWS EKS 컨테이너를 동작시키기 위한 기타 리소스

노드 각각에 반드시 파드 하나를 동작시키는 데몬셋

  • 로그 수집용 에이전트를 노드 각각에 배포해야 하는 상황
  • 애플리케이션 모니터링, 로그 수집용으로 데몬셋 이용
  • 애플리케이션 개발에 사용하기 위한 것으로 컨테이너를 동작시키기 위한 리소스는 아님.

영구 데이터를 다루기 위한 스테이트풀셋

  • 파드가 재시작되더라도 쿠버네티스에서 파드 외부의 볼륨 형태로 데이타를 저장하기 때문에 그 때까지 사용했던 볼륨을 계속 사용할 수 있는 구조로 되어 있음.
  • 모든 파드가 같은 상태를 갖는 것 ‘Stateless’ : 스테이트리스
  • 데이터베이스처럼 파드별로 고유의 상태를 갖는 것 ‘스테이트풀 ‘Stateful’
  • 쿠버네티스에서 스테이트풀 애플리케이션을 동작시키는 것은 운영 측면에서 비추천 → 쿠버네티스 클러스터 외부에서 구성하는 것이 무난함.

네임스페이스

  • 아마존 EKS 컨테이너가 동작하는 클러스터를 논리적으로 사용하기 위한 리소스

쿠버네티스 표준으로 생성되는 네임스페이스

  • default
  • kube-system
  • kube-public

예제 애플리케이션에서 사용한 네임스페이스

  • eks-work : 디플로이먼트와 크론잡을 비롯한 리소스를 이 네임스페이스에 생성함.

네임스페이스를 이용한 클러스터 리소스 제한

  • 리소스 쿼터
  • 네트워크 정책
  • RBAC(Roll-Based Access Control)

네임스페이스를 정의할 매니페스트 파일

  • 디플로이먼트 업데이트와 롤백 – ep.168
    • 디플로이먼트 설정 변경
    • 설정 변경 롤백
# Check revision
kubectl rollout history deployment nginx

# Checl Version 
kubectl rollout history deployment nginx --revision=1

# RollBack
kubectl rollout undo deployment nginx --to-revision=1

컨테이너를 외부로 공개하기 위한 리소스

서비스 리소스 타입

  • ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName

컨테이너를 외부로 공개하는 또 하나의 방법

  • 위 방법의 단점
    • 서비스 단위로 ELB가 생성되므로 효율이 좋지 않음(비용 증가)
    • HTTP/HTTPS 로드밸런서로 더 많은 기능이 있는 ALB(Application Load Balancer) 사용불가.
  • 인그레스(Ingress)
    • 쿠버네티스 클러스터로 접근하는 입구를 만들기 위한 리소스
    • AWS ALB 인그레스 컨트롤러 : 설정방법은 깃허브 문서에 있음.
  • 로드밸런서로 HTTPS 지원
    • AWS Certificate Manager를 이용한 인증서 생성
    • 서비스 리소스의 매니페스트 수정
    • 애너테이션 내용
    • EC2 페이지에서 ELB 상태 확인
    • DNS 등록과 동작

설정 정보 등을 안전하게 저장하는 구조

  • 목표 : 동적으로 설정하고 싶은 항목이 있을 경우
    • 도커 컨테이이너 이미지에 애플리케이션과 그 실행 환경이 같이 포함되어 있어 도커 엔진만 설치되어 있다면 애플리케이션 동작은 보장됨.
    • 동적 정보 : 데이터베이스 접속 정보, 사용자 이름, 비밀번호

환경 변숫값 전달

  • 애플리케이션 설정 정보는 환경 변수에 저장한다.
  • 설정 정보 변경으로 재빌드하는 일이 없도록 하기 위함.

시크릿을 이용한 비밀 정보 전달

  • 시크릿 : 보안이 필요한 정보(사용자 이름, 비밀번호 등)를 안전한 정보에 저장해 참조할 수 있도록 하는 서비스 리소스
  • 쿠버네티스의 시크릿에 등록하는 정보 예
    • backend-app이 사용하는 데이터베이스 접속 문자열, 사용자 이름, 비밀번호
    • batch-app이 사용하는 AWS CLI 액세스 키 ID, 비밀 액세스 키 정보
  • 파드의 매니페스트에서 해당 시크릿에서 값을 읽어 들여 파드 내부의 환경 변수에 설정하도록 정의함
  • 설정 파일
    • Opaque : 환경 변수 이름과 해당 값을 저장할 때 사용하는 키-값 형식
  • 자세한 내용
// 동작 중인 예제 애플리케이션 파드 확인 
kubectl get pod 

// 파드 내부의 환경 변수 확인 
kubectl exec backend-app-xxxxxx -it -- env | grep DB

시크릿을 사용할 때 주의할 점

  • base64로 인코딩된 정보도 해독이 가능하므로 주의
  • 깃허브에 공개되지 않도록 주의.
  • jq : JSON 형식 변환, 추출 등을 실행하는 명령어

컨피그맵을 이용한 설정 정보 전달

  • 보안이 필요없는 정보 전달 시 ConfigMap 사용
// 등록한 컨피그맵 확인
kubectl describe configmap batch-app-config

파드에 불륨을 마운트한다!?

  • Persistent Voulume : 데이타를 저장할 수 있는 스토리지 리소스
  • Persistent VolumeClaim : 파드에서 영구 볼륨을 참조 가능하게 하는 리소스
  • AWS EBS(Elastic Block Store) : 디스크 서비스
    • 단점 : 다른 파드와 동시에 참조, 쓰기가 불가능하여 파드의 라이프사이클에 의존하는 형태임.
    • 대안
      • S3를 참조하거나 데이터베이스에 저장하고 클러스터 내부는 스테이트리스 상태로 유지
      • 파일 단위로 파드 여러 개와 데이타를 공유해야 하는 경우는 파드 사이 공유, 참조, 쓰기가 가능한 타입의 스토리지 NFS 사용을 권함.
  • configmap

Amazon Elastic Block Store(EBS)

블록 스토리지 | Elastic Block Store | Amazon Web Services

Back to top