AWS EKS 기타 리소스에 대해 알아봅니다.
목차
ToggleAWS 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