eks 사용시 고려해야할 사항들 정리
📝 Amazon EKS 마이그레이션 접근 방법
1. 평가 및 진단
- 현행 클러스터 환경 조사
- 애플리케이션 구성 파악
- 클라우드 배포 방안 리뷰
- 복제 관련 도구 리뷰
2. 전환 계획 수립
- 클라우드 환경 구성 - 랜딩존 구축
- EKS 아키텍처 정의
- 인프라 구성(Infrastructure As Code)
3. 전환 수행 및 최적화
- 컨테이너 이미지 마이그레이션
- 데이터 복제
- 애플리케이션 배포
- 테스트 및 전환
- 최적화
📝 Amazon EKS 특징
1. Upstream Kubernetes
- k8s의 업스트림 및 인증된 k8s 버전
- 4개의 k8s 마이너 버전 지원
2. Highly available
- 성능, 신뢰성 및 보안 k8s를 위한 관리형 쿠버네티스 환경
- 고객의 다양한 환경을 위한 안정적이고 안전한 환경
3. Integrated
- AWS 서비스들과 통합
- k8s의 실행, 운영 및 관리 작업을 쉽게 단순화
📝 영역별 핵심 고려사항
Amazon EKS 컨트롤 플레인
eks는 컨트롤 플레인은 aws가 관리한다는 특징을 가짐 -> 고객의 부담을 줄임
새로운 EKS 생성 시 AWS가 관리하는 VPC에 고가용성을 고려한 뒤,
3개 이상의 가용 영역을 사용해서 2개 이상의 API 서버를 오토스케일링 그룹으로 구성하고
로드밸런서를 통해 서비스한다.
API 서버와는 별개로 ETCD Cluster를 위해서 가용영역별로 ETCD 서버를 구성하고
별도의 오토스케일링 그룹이 설정된다.
이렇게 생성된 컨트롤 플레인의 성능과 운영에 관한 부분은 AWS가 책임을 지게 된다.
예를 들어 API 서버를 Scale Up 한다거나, ETCD의 데이터를 백업하는 부분은 AWS가 책임지고 운영한다고 생각하면 된다.
(그에 따라 고객은 비즈니스에 더 집중이 가능하다.)
고객의 워크로드가 올라가는 데이터 플레인은 고객 소유의 Account에서 생성하는 VPC에 만들어진다.
그리고 설정한 Instance Type에 따라서 EC2 노드를 생성하고 그 위에 Pod가 실행되게 된다.
워커노드와 API 서버 간의 통신은 EKS가 각 가용영역에 생성하는 Network Interface를 통해서 TLS로 안전하게 통신한다.
또한 워커노드들은 좀 더 쉽게 관리할 수 있는 노드 그룹 기능 또한 제공한다.
이 관리형 노드 그룹은 EC2의 오토스케일링 기능을 활용해서 노드의 생성과 업데이트들을 자동으로 실행하게 해준다.
여기서 EKS 컨트롤 플레인은 AWS가 전적으로 책임을 지며,
데이터 플레인 영역은 고객과 AWS가 함께 책임을 지는 책임 공유 모델 하의 서비스로 제공된다.
📝 EKS API 접근 제어
EKS API 서버에 접근 할 수 있는 Endpoint를 EKS Cluster Endpoint라고 하고
필요에 따라 이 Endpoint를 퍼블릭이나 프라이빗하게 설정이 가능하다.
📌 Amazon EKS Cluster Endpoint - public
퍼블릭하게 Endpoint를 설정 할 경우
Endpoint가 public ip를 가지고 있기 때문에 인터넷 게이트웨이를 통해서 접근이 가능하다.
그리고 고객의 VPC에서 Cluster Endpoint를 DNS look up 하면
Public IP가 리턴되서 Internet gateway를 통해 통신하게 된다.
📌 Amazon EKS Cluster Endpoint - public Private
외부에서 인터넷 게이트웨이를 이용해 접근하는건 동일하나,
고객의 VPC 내부에 Route 53 프라이빗 호스팅 영역이 생성되어
EKS 클러스터 앤드포인트를 LookUp 하면 ENI의 IP를 가리키게 된다.
따라서 고객의 VPC에서 인터넷 영역으로 트래픽을 보낼 필요 없이 내부적 통신이 가능하다.
📌 Amazon EKS Cluster Endpoint - Private
보안을 강화한 private의 경우,
외부 API를 통한 접근이 불가능 하고
오직 EKS가 생성한 ENI로만 통신하게 된다.
따라서 전용선이나 VPN 등으로 고객의 VPC에 접근해서
Baston 호스트와 같은 운영 서버를 통한 접근만 허용하게 된다.
이때 주의할 사항은 Private Cluster 내부에서 AWS 다른 서버를 연계하려면
VPC Endpoint 생성이 필요하다.
예를 들어 S3나 ECR등의 연결을 위해서는 VPC Endpoint를 생성해야 한다.
또한 Public Cluster VPC Endpoint를 이용할 경우에는 접근을 허용하는 IP 대역을 강화하는 등의 방법으로 보안을 강화 할 필요가 있다.
📝 데이터 플레인 구성 방법
📌 self-Managed 노드 그룹
고객이 Custom AMI를 이용해서 Autoscaling Group등의 설정을 직접 구현하고 관리하는 모델로,
OS에 대한 구성과 패치 적용을 고객이 직접 책임진다.
📌 Managed 노드 그룹
EKS 최적화 AMI를 사용한 배포와 라이프사이클의 자동화를 AWS가 처리한다.
📌 AWS Fargate
별도의 EC2 인스턴스를 관리할 필요 없이 MicroVM 기반의 서버리스 환경인 Fargate를 이용해서 pod 별로 VM 할당이 가능하다.
📝 EKS에서의 Auth Scaling
온프레미스와 다르게 클라우드에서는 워크로드 증가와 축소에 따라 워커노드를 추가, 삭제 할 수 있는 클러스터 오토 스케일러를 적용 할 수 있다.
우선, 아래 사진은 Pod의 가용성을 확보하는 Horizontal Pod Auto Scaler의 동작이다.
-
각 노드의 Kubelet에서 수집한 pod의 매트릭을 Metric Server가 수집한다.
-
HPA(Horizontal Pod Autoscaling)가 정의한 메트릭에 따라 ReplicatSet의 Replica 수를 변경해서 새로운 Pod를 생성하거나 삭제한다.
-
여기서, 추가된 Pod가 Node의 리소스 부족으로 스케줄링 되지 못하고 Pending 되면 Cluster Auto Scaler가 Auto Scaling Group의 Desired 값을 변경해서 새로운 Node를 생성한다.
-
Pending되던 Pod가 신규 Node에 스케줄링 되면서 가동하게 된다.
여기서, Cluster Autoscaler를 Private Cluster에서 구성할 때에는 주의가 필요하다.
why? 리전마다 가용한 인스턴스 리스트를 호출하는 외부 API Call이 Default로 설정되어있기 때문
따라서 외부 호출 없이 미리 정의된 인스턴스 리스트에서 찾도록 하는 옵션을 설정하는것이 필요하다..
👀 참고자료
