AEWS 1주차. Amazon EKS 설치 및 기본 사용

Kubernetes(=K8s)는 컨테이너화된 애플리케이션의 배포, 확장 관리를 자동화하기 위한 오픈 소스 시스템으로,

클라우드 네이티브의 핵심으로 급부상하여 현재는 컨테이너 관리의 디팩토(defacto) 스탠다드로 자리잡았습니다.

 

실제로 많은 곳에서 On-premise와 클라우드를 가리지 않고, 다양한 형태의 K8s 기반의 클러스터를 운영하고 있습니다.

그러나, 가용성, 다중화, 성능, 최적화, 확장, 업그레이드, 기술지원, 패치, 네트워크와의 연동 등에 있어

전문적인 기술/운영 인력이 없을 경우 K8s를 활용하는데 많은 어려움을 겪고 있는 것이 현실입니다.

 

AWS에서는 이러한 어려움을 해소하기 위해, 

Amazon EKS(Elastic Kubernetes Services, 이하 EKS), 보통 EKS라 불리는 관리형 K8s 서비스를 제공하고 있습니다.

EKS는 오픈소스 K8s를 그대로 별도의 변형없이 제공하며, 컨트롤플레인의 역할을 AWS가 관리형으로 제공합니다.

관리형 서비스이기 때문에, 사용자는 구성/운영에 대한 고민없이 애플리케이션 관점에서 활용에 집중할 수 있습니다.

당연히, 상용서비스로 검증된 보안이나 뛰어난 안정성, 높은 성능, 운영편의성 등도 제공됩니다.

 

EKS가 오픈소스를 제공한다는 것은, K8s 커뮤니티에서 사용되는 플러그인과 도구들을 모두 사용할 수 있으며,

EKS에서 동작하는 애플리케이션은 표준 K8s 환경에서 실행중인 애플리케이션과 완벽하게 호환을 보장한다는 것입니다.

즉, 오픈소스에서 사용중인 Pod를 EKS 기반으로 옮길수도 있고, 원한다면, EKS Pod를 오픈소스로도 옮길수 있겠지요.

 

EKS는 최신 버전을 기준으로 4개의 K8s 마이너버전을 14개월동안 지원합니다.

오픈소스 K8s가 3개의 마이너버전을 9개월간 지원하는데 반해, 업그레이드를 위한 충분한 시간을 확보할 수 있습니다.

참고로, Amazon EKS의 버전의 경우 오픈소스 K8s와 동일하게 Major.Minor.Patch의 구조로 명명되고 있으며,

23년 4월 기준으로는 v1.22 ~ v1.26의 5개 버전이 지원되고 있습니다.

지원 버전 정보는 지속적으로 변경이 있음으로 필요할 때마다 공식페이지에서 확인하는 것이 좋습니다.

 

또한, EKS는 AWS의 공식 서비스답게, 다양한 AWS의 서비스들과의 연동되어 함께 서비스를 제공합니다.

• 컨테이너 이미지 저장소인 Amazon ECR(Elastic Container Registry)
• 로드 분산을 위한 AWS ELB(Elastic Load Balancing)
• 인증을 위한 AWS IAM
• 격리된 Amazon VPC

 

 

EKS를 배포하게 되면, K8s의 컨트롤플레인은 AWS가 관리하는 VPC에 분산되어 배포되게 되며,

실제 Pod가 돌아가는 Node들은 사용자 VPC에 위치하여 역할별로 나뉘어 관리됩니다.

 

EKS는 컨트롤플레인 구성을 위해,

3개 이상의 AZ에서 2개 이상의 API 서버를 오토스케일링 그룹으로 구성하고 NLB를 통해 서비스합니다.

외부에서 API 서버에 접근이 필요할 경우 NLB를 거쳐서 실제 통신이 이루어지는 구조입니다.

API 서버와는 별개로 etcd의 경우 AZ별 서버를 별도로 구성하고 별도의 오토스케일링 그룹으로 설정하며,

etcd에 통신은 ELB를 통해 로드밸런싱하여 서비스를 제공합니다.

 

EKS는 다른 AWS 서비스와 마찬가지로, EKS 컨트롤플레인은 AWS가 책임지며,

데이터플레인은 AWS와 사용자가 함께 관리 및 책임지는 책임 공유 모델을 기반으로 합니다.

이에 따라 API의 Scale-up이나 etcd의 데이터 백업 같은 성능과 운영에 대한 부분은 AWS가 책임지고 있습니다.

On-premise에서는 직접 구축하고 관리해야 하는 영역이지만, AWS에 의해 관리형이기 때문에 가능한 것으로,

사용자의 운영 부담을 획기적으로 줄여줍니다.

 

관리형 서비스다보니,

일반적인 사용자가 관리하는 K8s에서는 kube-system namespace 안에 컨트롤플레인 내부의 Pod 정보가 확인되지만,

EKS가 관리하는 컨트롤플레인에 위치한 pod 정보(API서버, 컨트롤러, 스케줄러)를 직접 확인할 수는 없습니다.

 

 

EKS의 컨트롤플레인이 배포되고 난후,

실제 사용자가 지정하는 EC2를 기반으로 데이터플레인이 구성되고, 배포되는 EC2 위에 Pod가 위치하게 됩니다.

당연히 EC2에는 API 서버와 통신 및 Node 제어등을 위한 Kubelet과 네트워크 제공을 위한 Kube-proxy가 포함됩니다.

 

AWS는 배포되는 EC2 기반의 Node들의 관리 편리성을 위해 관리형 노드그룹의 형태로 데이터플레인을 관리합니다.

즉, EC2의 오토스케일링 기능을 활용해서 노드의 생성과 업데이트를 지원하게 됩니다.

 

EKS의 API 서버가 데이터플레인의 Node와 통신을 하려할때,

컨트롤플레인은 EKS가 소유한 ENI를 통해 사용자 VPC에 위치한 Node와 직접 연결되게 됩니다.

기본적으로 ENI는 컨트롤플레인이 Node를 제어할 때 사용하는 전용 통로로

API 서버는 항상 EKS가 소유한 ENI를 통해 Kubelet에 TLS 기반으로 관련 사항을 전달합니다.

 

그러나, 사용자 VPC에 위치한 Node에서는 API 서버에 접근할때,

EKS의 EKS cluster endpoint 구성이 Public인지, Private인지, 아니면 둘다인지에 따라 다양한 경로를 이용하게 됩니다.

 

1) Public에 구성시

Endpoint가 public IP를 가지고 있기 때문에, 외부에서 IGW를 통해 접근할 수 있습니다.

이 경우 VPC 내에서 해당 주소를 lookup하면, public IP가 회신되며, Node도 인터넷을 통해 통신해야 합니다.

VPC 외부의 관리자도 IGW를 통해 직접 접근하며, 인터넷에 직접 노출되어 보안이 취약할 수 있습니다.

반드시 접근 IP 대역 제한같은 보안 조치가 권장됩니다.

 

2) Public과 Private 동시 구성시

출발지에 따라 외부와 내부에서 두가지 경로로 접근이 가능합니다.

Endpoint가 public IP를 가지고 있기 때문에, 외부에서는 IGW를 통해 접근할 수 있습니다.

그러나 사용자 VPC 내부에서는 Route53 프라이빗 호스팅 영역이 생성되어

Endpoint를 lookup시 EKS가 소유한 ENI의 IP가 회신되며, 인터넷 구간을 거치지 않고 내부적으로 직접 통신합니다.

 

3) Private으로 구성시

외부에서의 API 서버 접근이 불가능하고, EKS가 생성한 ENI로만 접근해야 합니다.

외부 관리자의 경우 DX나 VPN 등으로 내부 VPC에 먼저 접근한 후 Bastion을 통해 다시 접근해야 합니다.

보안적으로 가장 강력한 구조입니다.

만약, Private Cluster 내부에서 AWS의 다른 서비스와 연결이 필요한 경우 VPC endpoint 지정이 필요합니다.

 

 

데이터플레인을 위해 배포되는 Node들은 기본적으로는 최신 EKS Optimized AMI를 통해 배포됩니다.

EKS Optimized AMI에서는 단순히 Amazon Linux 뿐만 아니라, Ubuntu나 Windows등 다양한 OS를 제공하고 있습니다.

만약 사용자가 원할 경우 Custom AMI를 사용하거나, AWS fargate를 이용하여 Micro VM 형태로 배포 할 수도 있습니다.

다만 관리형의 장점을 살려 AWS에서 제공되는 EKS Optimized AMI를 이용하는 것이

OS에 대한 구성/패치 작업등 관리 영역의 많은 부분에서 수월할 수 있습니다.

 

관련 실습

-----------------------------------------------------------------------------------------------

이 내용은 AEWS(AWS EKS Workshop Study) 1기의 과제로써 작성되었습니다.

AEWS는 '가시다'님이 속한 CloudNet@에서 진행하는 AWS EKS workshop에 대한 스터디입니다.

매주 일요일마다 소중한 정보를 퍼주시는 '가시다'님께 무한 감사 드립니다.

https://gasidaseo.notion.site/23-AWS-EKS-Workshop-07165aec800042b9ac9357aee18fdf17