[레포트] Amazon EKS 마이그레이션 요점정리

2022년 5월 10일~11일 AWS Summit Online Korea 가 개최되었습니다.
다양한 분야에서 AWS 서비스가 어떻게 이용되고 있는지 그리고 AWS에서 어떤 새로운 기능을 제공하고 있는지 알 수 있었습니다.
그 중 제가 보았던 세션에 대해 메모 겸 리뷰를 작성했습니다.
(본 레포트에 사용된 이미지는 별도의 설명이 없다면 해당 세션의 이미지임을 알립니다.)

개요

온프레미스나 다른 클라우드 서비스에서 운영 중인 쿠버네티스 클러스트를 Amazon EKS 서비스로 마이그레이션할 때 고려해야 할 EKS 특징이 있습니다. 네트워크, 보안, 컴퓨트 옵션 등 ESK 특징들을 살펴보며, 더 효과적으로 마이그레이션하는 방법을 알아봅니다. 더 나아가 이런 특징을 활용해 비용 효율적이면서도 안전하고 견고한 쿠버네티스 클러스트 서비스를 구축하는 방법도 소개합니다.

• 강연자
  • 강인호 솔루션즈 아키텍트, AWS
• 난이도
  • 중급 난이도

본 세션에서는 온프레미스나 클라우드 환경에서 사용중인 쿠버네티스를 AWS EKS로 마이그레이션 할 때 핵심적인 중요 사항에 대해 설명합니다.
마이그레이션 접근 방법을 알아본 후 각 고려 사항에 대해 핵심적인 내용을 알아봅니다.

Amazon EKS 마이그레이션 접근방법

쿠버네티스는 Chasm¹을 넘어 주류 시장으로 가고 있다고 합니다.
공인된 hosted 플랫폼을 사용하는 고객들 중 많은 수가 Amazon EKS를 사용 중 입니다.

AWS는 마이그레이션을 돕기 위한 3단계로 구성된 방법론을 제공하고 있습니다.

이 방법론은 쿠버네티스를 마이그레이션 할 때도 동일하게 적용할 수 있습니다.

평가 및 진단

진단 평가 단계에서는 운영 중인 환경을 조사하고 어플리케이션과 관련된 빌드나 배포 환경, 모니터링이나 로깅 환경을 파악합니다.
그리고 이전할 클라우드 플랫폼에 대한 배포 방안을 수립하고 쿠버네티스 리스소와 퍼시스턴트 볼륨에 대한 복제 방안과 도구를 테스트합니다.

전환 계획 수립

위의 단계에서 수집된 정보를 바탕으로 전환 계획을 수립 단계에서 클라우드 환경에서의 보안과 운영, 거버넌스를 제공하는 렌딩존을 구성합니다.
그리고 EKS의 컨트롤 플레인과 데이터 플레인의 아키텍쳐를 정의합니다. 그리고 운영 관리를 위한 IaC, HA 구성 등을 정의합니다.

전환 수행 및 최적화

수립한 계획을 바탕으로 마이그레이션을 진행하고 이후 최적화를 진행합니다.
컨테이너 이미지에 대한 마이그레이션 작업을 통해서 Private Container Registry를 구축하고 정의한 복제방안을 이용해서 쿠버네티스 리소스나 퍼시스턴트 볼륨²을 복제합니다.
그리고 CI/CD 파이프라인을 이용해서 애플리케이션을 배포하고 테스트 과정을 거쳐 컷 오프를 진행한 이후에 운영을 하며 운영 및 비용 최적화 단계를 거칩니다.

EKS의 특징

마이그레이션을 진행하며 많이 헷갈려하는 EKS만의 특징들이 있습니다.
몇 가지 주요 특징들로 우선 EKS는 업스트림 쿠버네티스 소스를 변형 없이 그대로 사용합니다. 4개의 마이너 버전을 14개월간 지원하기 때문에 버전 업그레이드에 대한 시간을 확보할 수 있습니다.
다음으로는 EKS는 보안이나 안정성, 운영성 테스트를 거쳤기 때문에 고객이 신뢰하고 안전하게 이용할 수 있는 쿠버네티스 환경을 제공합니다.
마지막으로 AWS의 다른 서비스들과 완벽하게 통합되어 있어서 다른 AWS 서비스들을 좀 더 쉽게 활용할 수 있게 합니다.

이어서 컨트롤 플레인³과 데이터 플레인⁴에 대해 알아보도록 하겠습니다.

컨트롤 플레인

EKS에서는 컨트롤 플레인을 AWS에서 관리하고 있습니다. 새로은 EKS 클러스터를 생성하면 AWS가 관리하는 VPC에 고가용성을 고려하여 3개 이상의 가용 영역을 사용하며 2개 이상의 API 서비스를 오토스케일링 그룹으로 구성하고 로드밸런서를 통해 서비스합니다.

API 서버와 별개로 ETCD⁵ Cluster를 위해서 가용영역 별로 ETCD 서버를 구성하고 별도의 오토스케일링 그룹이 생성됩니다.

이렇게 생성된 컨트롤 플레인의 성능과 운영에 대한 부분은 AWS가 책임을 집니다. 따라서 사용자는 쿠버네티스 클러스터 운영 업무에 대한 부담을 줄이고 비즈니스나 어플리케이션에 더 집중할 수 있게 됩니다.

데이터 플레인

고객의 워크로드가 올라가는 데이터 플레인은 고객 소유의 계정에서 생성하는 VPC에 생성됩니다.
그리고 설정한 인스턴스 타입에 따라서 EC2 노드(Node)를 생성하고 그 위에 파드(Pod)가 실행됩니다.
워커노드와 API 서버 간의 통신은 EKS가 각 가용영역에 생성하는 네트워크 인터페이스를 통해서 TLS로 안전하게 통신하게 됩니다.

그리고 워커노드들의 관리를 좀 더 쉽게 할 수 있도록 관리형 노트 그룹을 제공합니다.
이 관리형 노드 그룹은 EC2의 오토스케일링 기능을 활용해서 노드의 생성과 업데이트를 자동으로 해주는 기능입니다.

EKS의 데이터 플레인은 고객과 AWS가 함께 책임을 지는 영역입니다.

EKS API 접근제어

EKS API 서버에 접근할 수 있는 Endpoint를 EKS Cluster Endpoint라고 하며 필요에 따라 이 Endpoint를 퍼블릭이나 프라이빗하게 설정할 수 있습니다.

퍼블릭 환경
퍼블릭 IP를 가진 Endpoint에 인터넷 게이트웨이를 통하여 외부 환경에서 쿠버네티스로 접근이 가능해집니다. 사용자의 VPC에서도 해당 Endpoint를 DNS look up 하여 인터넷 게이트웨이를 통하여 통신하게 됩니다.

퍼블릭 및 프라이빗 환경
퍼블릭 IP를 가진 Endpoint에 인터넷 게이트웨이를 통하여 외부 환경에서 쿠버네티스로 접근이 가능해집니다. 사용자의 VPC 내부에는 Route53 프라이빗 호스팅 영역이 생성되어 EKS Cluster Endpoint 를 look up 하면 ENI의 IP로 향하게 됩니다. 따라서 사용자의 VPC 에서는 인터넷 게이트웨이를 향하지 않고 내부적으로 통신하게 됩니다.

프라이빗 환경
외부에서의 API 접근은 불가능하며 오직 EKS가 생성한 ENI로만 통신하게 됩니다. 따라서 외부 환경에서 접근하기 위해서는 배스천 호스트와 같은 운영 서버를 통한 접근만이 가능해집니다. 이때 주의 사항으로 Private Cluster 내부에서 AWS의 다른 서비스에 접근하기 위해서는 VPC Endpoint가 필요하게 됩니다.

EKS의 데이터 플레인 옵션

EKS 데이터 플레인을 구성하는 방법에는 3가지가 있습니다.

Self-Managed 노드 그룹은 사용자가 Custom AMI를 이용하여 Autoscailng Group 등을 직접 구성하고 관리합니다. OS에 대한 구성과 패치 적용을 사용자가 책임지게 됩니다.
Managed 노드 그룹은 EKS 최적화 AMI를 사용한 배포와 라이프사이클의 자동화를 AWS가 관리하는 모델입니다.
AWS Fargate는 별도의 EC2 인스턴스를 관리할 필요 없이 MicroVM 기반의 서버리스 환경인 Fargate를 이용하여 파드별로 VM을 할당하게 됩니다.

EKS의 Auto Scaling

온프레미스와 다르게 클라우드는 워크로드 증가나 축소에 따른 워크로드 증가 및 축소가 가능한 Cluster Auto Scaler를 적용할 수 있습니다. 각 노드의 Kublet에서 수집한 파드의 메트릭을 메트릭 서버가 수집하고 HPA(Horizontal Pod Autoscaling) 컨트롤러가 정의한 메트릭에 따라 ReplicaSet의 Replica 수를 변경하여 새로운 파드를 생성하거나 삭제하게 됩니다.
이렇게 추가된 파드가 노드의 리소스 부족으로 스케줄링 되지 못하고 Pending되면 Cluster Auto Scaler가 Auto Scaling Group의 Desired 값을 변경하여 새로운 노드를 생성하고 Pending 되던 파드가 신규 노드에 스케줄링되어 가동되게 됩니다.

Cluster AutoScaler를 Private Cluster에서 구성할 때는 리전마다 가용한 인스턴스 리스트를 호출하는 외부 API Call이 Default로 설정되어 있습니다. 따라서 외부 호출 없이 미리 정의된 인스턴스 리스트에서 찾도록 하는 옵션을 설정해야 합니다.

보안

쿠버네티스의 인증 인가

API 서버는 하나 이상의 인증 플러그인을 구성할 수 있고 이 플러그인 중에서 인증 요청을 처리하면 나머지 플러그인의 호출을 뛰어넘어서 인가 단계로 진행하게 됩니다.
EKS는 Webhook Token Authentication과 OIDC Token, Service Account Token을 지원합니다.

인가 단계에서는 RBAC 플러그인 등을 거치면서 해당 요청이 특정 리소스에 대해서 허용되었는지를 검사하고 Admission Control을 통해서 분산저장소인 ETCD에 저장되게 됩니다.

쿠버네티스는 RBAC(역할 기반 액세스 제어) 으로 권한을 인증 및 인가 합니다.
유저나 서비스 어카운트를 수행할 수 있는 액션이 정의된 Role 이나 Clusterrole과 Role Binding 이나 Clusterrole Binding으로 연결해서 권한 인가 체계를 구성하게 됩니다.

파드별 IAM 할당 (IRSA)

하나의 노드에는 여러 개의 파드가 실행될 수 있고 각 파드별로 사용하는 AWS 서비스가 다를 수 있습니다. 이때 권장하는 방법이 오른쪽 그림과 같이 파드별로 Service Account에 IAM Role을 binding해서 서로 다른 IAM Role을 갖도록 하는 기능인 IRSA(IAM Role for Service Account)입니다.

네트워크

쿠버네티스의 네트워크

쿠버네티스 네트워크에서는 워커 노드의 IP 대역과 별개로 각 파드가 클러스터 네트워크라고 하는 별도의 IP 대역을 가지고 있습니다.
노드 내부의 파드 간 통신은 노드 내부의 브릿지를 통해서 통신하지만 노드를 넘어선 파드 간의 통신은 Overlay 네트워크를 이용해서 내부 패킷을 캡슐화해서 최종 목적지를 찾아가는 구조입니다.

쿠버네티스에서 파드 간의 통신을 확장하는 규약을 CNI(Container Network Interface) 라고 하며 관련 플러그인이 제공되고 있습니다.

Amazon EKS VPC CNI 네트워킹

AWS에서는 VPC 네트워킹과 통합된 Amazon VPC CNI를 제공하고 있으며 VPC가 제공하는 기능들을 이용할 수 있습니다.
Amazon EKS 를 설치하시게 되면 VPC CNI가 함께 설치되며 각 워커 노드마다 AWS-node라는 데몬셋이 실행되고 새로운 파드에 할당할 IP Address pool을 관리하는 Local IP Address Management라고 하는 데몬이 실행돼서 파드에 IP를 할당하게 됩니다.
VPC CNI는 ENI마다 Primary IP 와 Secondary IP 가 할당되고 IP pool을 관리하는 데몬에 의해서 이 Secondary IP가 파드에 할당됩니다.

VPC CNI에서는 노드의 파드 간 통신은 동일하게 네트워크 브릿지를 통해서 통신하지만 노드를 넘어서는 파드 간 통신은 파드가 VPC와 동일한 IP 주소를 사용하며 일반 VPC 통신을 통해서 통신하게됩니다.
따라서 Overlay 네트워크에서 발생하는 패킷의 캡슐화가 불필요하기 때문에 오버헤드가 줄어들며 낮은 지연시간과 높은 throughput을 제공하게 됩니다.

VPC CNI에 대한 고려사항

우선 EC2는 인스턴스 유형에 따라 할당할 수 있는 IP 개수가 정해져 있기 때문에 노드당 할당할 수 있는 파드의 개수가 제한될 수 있습니다.
예를 들어 m5.large 유형은 최대 29개의 파드를 생성할 수 있습니다.

AWS는 21년 7월에 인스턴스당 더 많은 IP Address를 할당할 수 있는 접두사 위임 기능을 공개하였습니다.
(Amazon EC2 네트워크 인터페이스에 접두사 할당 - 공식 문서)
동일한 m5.large 유형의 경우 접두사 위임을 적용하면 각 ENI 마다 하나의 ENI용 IP와 24의 cidr 블록을 위임할 수 있는 9개의 delegation 을 생성할 수 있습니다.
따라서 노드당 가용 IP 주소를 충분하게 증가시킬 수 있습니다. 하지만 해당 기능은 Nitro 계열의 인스턴스만 제공하고 있습니다.
가질 수 있는 IP Address 의 총 개수는 432개 입니다만 30vCPU 미만은 110개로 제한하고 있고 이외 모든 인스턴스는 250개 까지만 가질 수 있도록 제한되어 있습니다.

따라서 IP Address 의 제약이 문제라면 굳이 더 큰 인스턴스 유형을 고르지 않고 적당한 스펙의 Nitro 계열의 유형을 선택한다면 작은 인스턴스에서도 더 많은 파드를 실행할 수 있습니다.

또 다른 고려 사항으로 보안 그룹이 있습니다. VPC CNI에서도 보안 그룹을 이용할 수 있기 때문에 네트워크 트래픽을 격리할 수 있습니다. 별도의 설정을 하지 않는다면 ENI 단위로 보안 그룹이 설정되고 ENI를 공유하는 파드가 동일한 보안 그룹을 공유하게 됩니다.
따라서 파드별로 ENI를 가지도록 설정한다면 ENI를 Trunk ENI와 Branch ENI를 만들어서 각각의 파드가 Branch ENI를 가지도록 합니다. 그래서 각각의 파드별로 보안 그룹을 설정하면 파드별로 네트워크 트래픽을 제어할 수 있게 됩니다.

로드 밸런서도 하나의 고려 사항입니다. 쿠버네티스에서는 ingress와 Service를 이용해서 실행 중인 파드를 외부에 노출하게 됩니다.
AWS Load Balancer Controller는 Layer 7 로드 밸런싱을 제공하는 ABL이 생성되고 Service를 생성하면 Layer 4 NLB가 생성되어 프로비저닝됩니다.

로드 밸런서를 생성할 때 설정 값에 대해 설명하자면 다음과 같습니다. NLB를 생성할 때 설정하는 Service manifest yaml 파일을 보시면 type 을 LoadBalancer로 설정합니다.
우선 load-balancer-type 설정 값에서 "external"로 설정하시면 EKS Control Plane 외부에 있는 파드로 실행되는 AWS Load Balancer Controller가 NLB를 생성하도록 한다는 의미가 됩니다. 따라서 해당 파드가 쿠버네티스 서비스 목록을 검색한다거나 AWS API를 호출할 수 있도록 하는 적절한 권한 설정이 필요하게 됩니다.
반대로 "internal"로 설정하면 Control Plane에 있는 Cloud Controller Manager가 해당 NLB를 생성하게 됩니다. load-balancer-target-type을 "instance"로 설정하면 NLB의 Target Group이 NodePort을 가리키게 됩니다. 이때 트래픽은 Primary ENI가 받아서 kube proxy를 통해 파드에 전달됩니다.
반대로 "ip"로 설정하면 타겟 그룹이 해당 파드가 실행 중인 IP를 가리키게 되며 kube proxy의 개입 없이 트래픽이 다이렉트로 파드에 전달됩니다. 마지막으로 load-balancer-scheme를 internet-facing으로 설정하면 퍼블릭 서브넷에 생성되어 외부와 통신할 수 있게 되고 설정하지 않거나 "internal"로 설정하면 프라이빗 서브넷에 생성됩니다.

쿠버네티스의 ingress를 생성하면 AWS Load Balancer Controller 가 ALB를 생성합니다.
쿠버네티스 1.19 이전 버전에서는 annotation을 이용해서 ingressClassName을 alb-ingress-class로 지정해야 했지만 1.19 이후 부터는 spec에 포함되어 사용할 ingress용 controller를 정의하고 별도의 설정을 추가할 수 있습니다.
ingress를 정의할 때 ingress마다 별도의 ALB를 생성하는 경우가 있는데 groupname을 설정하면 controller가 여러 ingress를 취합해서 하나의 ALB를 생성하고 각각의 ingress rule 마다 타겟 그룹을 생성합니다.
NLB와 마찬가지로 ingress를 추가하면 controller가 ALB를 생성하고 리스너와 하나의 타겟 그룹이 생성됩니다.
group name을 이용해서 여러 개의 ingress rule 을 생성하면 서비스마다 하나의 타겟 그룹이 생성됩니다.

스토리지 옵션과 비용

AWS는 Stateful 애플리케이션을 마이그레이션 할 때 사용할 수 있는 다양한 스토리지 서비스를 CSI(Container Storage Interface) Plugin으로 제공하고 있습니다. Block Storage를 위한 Amazon EBS CSI는 EBS 볼륨의 생성과 삭제에 대한 라이프사이클을 관리하는 플러그인으로 Driver로 직접 설치하거나 콘솔에서 애드온으로 추가할 수 있습니다.
File Storage를 위해서는 Amazon EFS CSI가 있고 고성능 스토리지를 위해서는 FSx for Lustre가 있습니다.

EKS로 마이그레이션하면 비용 효율적인 클러스터를 만들 수 있습니다. 가동 시간에 민감한 서비스가 아니라면 온 디맨드 인스턴스가 아닌 스팟 인스턴스⁶를 이용하여 비용을 절약할 수 있습니다.

마무리

이번 세션을 요약하자면 다음과 같습니다

• AWS가 관리하는 컨트롤 플레인과 책임을 공유하는 데이터 플레인
• AWS IAM과 통합된 인증과 권한
• Amazon VPC 와 통합된 VPC CNI로 한 차원 높은 성능과 보안
• 다양한 사용 살예에 맞는 다양한 스토리지 클래스 CSI
• 스팟 인스턴스를 활용한 비용 효율적인 클러스터 운영

개인적으로는 마이그레이션 뿐만 아니라 EKS와 쿠버네티스에 대한 전체적인 이미지를 더 확실시 할 수 있었어서 많은 도움이 된 세션이었습니다.
EKS에 대해 좀 더 알아보고 다시 보면 더 많은 것을 얻어 갈 수 있을 것 같습니다!

긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 언제나 환영합니다. must01940 지메일로 연락 주세요!

본 블로그 게시글을 보시고 문의 사항이 있으신 분들은
클래스메소드코리아 (info@classmethod.kr)로 연락 주시면 빠른 시일 내 담당자가 회신 드릴 수 있도록 하겠습니다 !