들어가며
대규모 분산 시스템을 구축하려는 팀원들과 Terraform을 이용한 IaC를 구축하기 전에 페어 프로그래밍으로 직접 웹 콘솔에서 쿠버네티스 환경을 구성해보기로 했다.
AWS의 어떤 서비스라도 Console에서 구성하게 될 때 상세 옵션을 선택해야하는 경우가 많은데 자세히 읽어보지 않고 선택한 후 넘어가게 된다면 추후에 여러 서비스를 결합하고 고도화하는 과정에서 문제가 생기더라도 찾기 어려운 경우가 많다.
따라서 기본적인 구성은 넘어가고 중요하게 생각했던 구성을 볼 것인데 여기만 집중한다면 클러스터에서 문제는 생기지 않을 것이라고 생각한다.
EKS 클러스터 아키텍처는 전체 내용의 기반이니
사용자 VPC가 아닌 AWS 관리 VPC 내 EKS Control Plane이 존재하고 ENI만 사용자 VPC에 존재한다는 사실과 네트워킹 모드에 대한 이해 이 두 가지를 반드시 이해해야된다고 생각한다.
아래 블로그를 정독하기를 추천한다.
EKS 정의
Amazon Elastic Kubernetes Service(Amazon EKS)는 Amazon Web Services(AWS)에서 자체 Kubernetes 제어 평면을 설치, 운영 및 유지 관리할 필요성을 없애는 관리형 서비스이다.
컨테이너화된 애플리케이션의 관리, 확장 및 배포를 자동화하는 오픈 소스 시스템이다.
이러한 소개에서 EKS는 자체 Control Plane을 관리하는 것에 집중하고 있다는 것을 알 수 있다.
What is Amazon EKS? - Amazon EKS
Thanks for letting us know this page needs work. We're sorry we let you down. If you've got a moment, please tell us how we can make the documentation better.
docs.aws.amazon.com
EKS 클러스터 아키텍처
EKS 클러스터는 두 개의 VPC로 구성된다. 하나는 AWS에서 관리하고 Kubernetes 제어 평면을 호스팅하는 VPC이고, 다른 하나는 고객이 관리하고 컨테이너가 실행되는 Kubernetes 워커 노드(EC2 인스턴스)와 클러스터에서 사용하는 다른 AWS 인프라(예: 로드 밸런서)를 호스팅하는 사용자 관리 VPC이다. 모든 워커 노드는 관리되는 API 서버 엔드포인트에 연결할 수 있어야 합니다. 이 연결을 통해 워커 노드는 Kubernetes 제어 평면에 등록하고 애플리케이션 Pod를 실행하기 위한 요청을 수신할 수 있습니다.
워커 노드는 퍼블릭 엔드포인트에 연결하거나 클러스터를 생성할 때 제공하는 서브넷에 배치된 EKS 관리형 탄력적 네트워크 인터페이스(ENI)를 통해 연결한다. 워커 노드가 연결하는 경로는 클러스터에 대한 개인 엔드포인트를 활성화했는지 비활성화했는지에 따라 결정된다.
De-mystifying cluster networking for Amazon EKS worker nodes | Amazon Web Services
Running Kubernetes on AWS requires an understanding of both AWS networking configuration and Kubernetes networking requirements. When you use the default Amazon Elastic Kubernetes Service (Amazon EKS) AWS CloudFormation templates to deploy your Amazon Vir
aws.amazon.com
EKS Cluster Architecture
Console로 EKS 구성
Get started with Amazon EKS – AWS Management Console and AWS CLI - Amazon EKS
The system creates and deploys two nodes based on the Fargate profile label you added. You won't see anything listed in Node groups because they aren't applicable for Fargate nodes, but you will see the new nodes listed in the Overview tab.
docs.aws.amazon.com
EKS Docs
클러스터 구성
EKS 대시보드에서 클러스터 추가를 선택한다.
클러스터 구성에선 Control Plane에게 부여할 Policy가 연결될 Role이 필요한데
간단하게 아래처럼 선택만 하면 기본적인 Role을 생성할 수 있다고 공식 문서에서 알려준다.
다음에 Data Plane의 Worker Node에 제공할 Role도 나오므로 이 Role은 Control Plane이 가져간다는 것을 기억하도록 한다.
이 부분에 대해서도 누구나 멈칫할 부분이라고 생각한다.
이전 포스트에서 다뤘으니 천천히 보면 EKS API가 필요한 이유를 알 수 있을 것이다.
네트워킹 지정
역시 네트워킹 지정이 안나올 수가 없는데 인프라 엔지니어라면 가장 잘 알아야하는 중요한 부분이라고 생각한다.
VPC 설정
VPC는 서비스의 특성에따라 CIDR 범위를 잘 고려해서 EKS에 할당할 수 있도록 하나 만들어두면 될 것이다.
그렇다고 CIDR에 대한 고민을 제대로 하지 않을 시
범위가 너무 크다면 Transit Gateway 등으로 여러 VPC와 통신할 시 IP 대역이 겹치게 되는 문제가 발생할 것이고
범위가 너무 작다면 쿠버네티스에서 파드가 생성될 IP가 부족할 수도 있다.
인프콘 2024 무신사 SRE 엔지니어 정주리님의 강연을 들어보신다면 CIDR가 정말로 서비스에 영향을 준다는 것을 알 수 있다.
서브넷(Control Plane의 ENI 위치) 지정
View Amazon EKS networking requirements for VPC and subnets - Amazon EKS
1 The endpoint is dual stack with both IPv4 and IPv6 addresses. Your applications outside of AWS, your nodes for the cluster, and your pods inside the cluster can reach this endpoint by either IPv4 or IPv6. 2 You choose between an IPv4 cluster and IPv6 clu
docs.aws.amazon.com
EKS Cluster Subnet(Control Plane ENI) Docs
AWS에선 클러스터와의 원활한 통신을 위해 Control Plane이 탄력적 네트워크 인터페이스(ENI)를 배치할 수 있는 서브넷을 VPC 내에서 선택할 수 있다고 설명한다.
공식 문서에 따르면 서브넷은 퍼블릭 또는 프라이빗일 수 있지만 가능하면 프라이빗 서브넷을 지정하는 것이 좋다. 프라이빗 서브넷은 인터넷 게이트웨이로의 경로를 포함하지 않는 경로 테이블이 있는 서브넷이다.
사실 이 부분이 가장 낯설었는데 공식 문서와 여러 블로그들을 읽고 흥미로웠던 부분이다.
이 아키텍처를 다시보면 EKS Control Plane와 Worker Nodes의 통신은 ENI를 통해 전달되므로 인터넷 구간과 연결되어있지 않아도 가능하다.
따라서 Public Subnet 또는 인터넷에저 접근이 가능한 Private Subnet이 아니라도 가능하다는 것이다.
그러니 AWS에서는 서로 다른 둘 이상 가용 영역을 요구하므로 보안상 인터넷 연결이 없는 ENI를 배치할 Private Subnet을 작은 CIDR로 지정해서 설정하면 좋을 것이다.
CIDR에 대한 요구사항으로는 최소 16개의 IP 주소를 권장한다고 한다.
Worker Node Group에 대한 서브넷 요구 사항
지금 설정할 것은 아니지만 미리 다뤄보자면
만약 워커노드 그룹의 잔여 IP가 부족해서 서브넷을 추가해야하는 상황인데
정확히 이해하고 있지 않으면 서브넷(Control Plane의 ENI 위치)를 다시 지정해야한다고 생각하여 클러스터를 재생성하는 방법밖에 없다고 생각할 수 있지만 전혀 그렇지 않다.
클러스터를 생성할 때 지정한 것과 동일한 서브넷에 노드와 Kubernetes 리소스를 배포할 수 있다. 그러나 이는 반드시 필요한 것은 아니다. 이는 클러스터를 생성할 때 지정하지 않은 서브넷에도 노드와 Kubernetes 리소스를 배포할 수 있기 때문이다. 노드를 다른 서브넷에 배포하는 경우 Amazon EKS는 해당 서브넷에 클러스터 네트워크 인터페이스를 생성하지 않는다.
천천히 생각해보면 우리는 단지 EKS 클러스터의 전체적인 환경을 구축하는 것이고 워커 노드 그룹은 추후에 따로 만들게 된다.
여기서 지정하는 서브넷은 ENI가 위치할 서브넷이므로 워커노드가 위치할 서브넷과는 다르다.
보안그룹 지정
Amazon EKS 보안 그룹 요구 사항 및 고려 사항 - Amazon EKS
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
AWS EKS Security Group Docs
AWS에 따르면 기본적으로 클러스터가 생성될 시에 EKS에선 위와 같은 보안 그룹을 생성한다고 한다.
이를 클러스터 보안 그룹이라고 하고 우리가 지정하는 보안 그룹은 클러스터 추가 보안 그룹이라고 보면 된다.
각 서비스에 따라 적합한 클러스터 추가 보안 그룹을 생성해서 지정하면 될 거 같다.
위의 아웃바운드 규칙을 제거하고
최소한의 규칙의 아웃바운드로 교체해도 된다고 한다.
따라서 결론은 기본 최소 규칙은 EKS 클러스터 생성 시에 적용된다는 것이니 우리는 추가 보안 그룹이라는 개념을 잘 기억하도록 한다.
[AWS EKS] 클러스터 보안그룹 vs 추가 보안그룹 (Cluster SG vs Additional SG)
# 결론클러스터 보안그룹과 추가 보안그룹은 다르다.클러스터 보안그룹 (EKS 생성 시 자동 생성되며, self rule도 자동으로 생성되어 있음) 은 eks api로 만든 컴퓨팅 리소스 (fargate, managed ec2 node group)
honglab.tistory.com
추천 블로그
Fargate에서 사용할 시 트러블 슈팅한 블로그를 보고나서 EKS에서의 보안 그룹의 의미를 잘 알 수 있었다.
보안 그룹에 대한 이해가 필요할 때 천천히 다시 읽어보면 도움이 많이 될 것이다.
클러스터 엔드포인트 액세스(네트워킹 모드) 지정
쿠버네티스 아키텍처를 잘 이해하고 있다면 Kubernetes API 서버가 Control Plane에 존재한다는 것을 알 수 있을텐데
클러스터 구축을 마치고 작업자의 PC에서 Control Plane과 통신하려면 아래처럼 kubeconfig 파일을 업데이트해야한다.
퍼블릭 클라이언트 엔드포인트 액세스를 선택한다면
이는 새로운 Amazon EKS 클러스터의 기본 동작이다. 클러스터의 퍼블릭 엔드포인트만 활성화된 경우 클러스터의 VPC 내부에서 발생하는 Kubernetes API 요청(예: 워커 노드에서 제어 평면 통신)은 VPC를 떠나지만 Amazon 네트워크는 떠나지 않습니다. 노드가 제어 평면에 연결하려면 퍼블릭 IP 주소와 인터넷 게이트웨이로 가는 경로 또는 NAT 게이트웨이의 퍼블릭 IP 주소를 사용할 수 있는 NAT 게이트웨이로 가는 경로가 있어야 한다.
프라이빗 클라이언트 엔드포인트 액세스를 선택한다면
개인 엔드포인트만 활성화된 경우 클러스터 API 서버로의 모든 트래픽은 클러스터의 VPC 또는 연결된 네트워크에서 나와야 한다. 인터넷에서 API 서버에 대한 공개 액세스는 없다. 모든 kubectl 명령은 VPC 또는 연결된 네트워크에서 나와야 한다. 이는 일반적으로 AWS VPN또는 AWS DirectConnect를 VPC에 사용하여 달성된다.
퍼블릭과 프라이빗 클라이언트 엔드포인트 액세스를 선택한다면
퍼블릭 및 프라이빗 엔드포인트가 모두 활성화되면 VPC 내부의 Kubernetes API 요청은 VPC 내부의 EKS 관리 ENI를 통해 제어 플레인과 통신한다. 클러스터 API 서버는 인터넷에서 액세스할 수 있다.
따라서 보안을 철저히 한다면 프라이빗을 선택하겠지만 현재는 학습 단계이므로 퍼블릭 및 프라이빗을 선택한다.
추가 기능 선택, 선택한 추가 기능 설정 구성, 검토 및 생성
다음은 Default로 진행 후 생성을 완료해도 된다.
다만 옵션들에서 예로 Prometheus 지표 설정 등 AWS 관리 서비스를 사용하길 원한다면 비용이 상당할 수 있으니 반드시 예상 비용을 확인해보고 도입하면 좋을 것 같다.