기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

VPC 및 서브넷 고려 사항

EKS 클러스터를 운영하려면 Kubernetes 네트워킹 외에도 AWS VPC 네트워킹에 대한 지식이 필요합니다.

VPC를 설계하거나 기존 VPC에 클러스터를 배포하기 전에 EKS 컨트롤 플레VPCs 통신 메커니즘을 이해하는 것이 좋습니다.

EKS와 함께 사용할 VPC 및 서브넷을 설계할 때는 클러스터 VPC 고려 사항 및 Amazon EKS 보안 그룹 고려 사항을 참조하세요. https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html

개요

EKS 클러스터 아키텍처

EKS 클러스터는 두 개의 VPCs로 구성됩니다.

고객 VPC의 노드에는 AWS VPC의 관리형 API 서버 엔드포인트에 연결할 수 있는 기능이 필요합니다. 이렇게 하면 노드가 Kubernetes 컨트롤 플레인에 등록하고 애플리케이션 포드 실행 요청을 수신할 수 있습니다.

노드는 (a) EKS 퍼블릭 엔드포인트 또는 (b) EKS에서 관리하는 교차 계정 탄력적 네트워크 인터페이스(X-ENI)를 통해 EKS 컨트롤 플레인에 연결됩니다. 클러스터를 생성할 때 VPC 서브넷을 두 개 이상 지정해야 합니다. EKS는 클러스터 생성 중에 지정된 각 서브넷(클러스터 서브넷이라고도 함)에 X-ENI를 배치합니다. Kubernetes API 서버는 이러한 교차 계정 ENIs 사용하여 고객 관리형 클러스터 VPC 서브넷에 배포된 노드와 통신합니다.

노드가 시작되면 EKS 부트스트랩 스크립트가 실행되고 Kubernetes 노드 구성 파일이 설치됩니다. 각 인스턴스의 부팅 프로세스의 일부로 컨테이너 런타임 에이전트, kubelet 및 Kubernetes 노드 에이전트가 시작됩니다.

노드를 등록하기 위해 Kubelet은 Kubernetes 클러스터 엔드포인트에 문의합니다. VPC 외부의 퍼블릭 엔드포인트 또는 VPC 내의 프라이빗 엔드포인트와의 연결을 설정합니다. Kubelet은 API 지침을 수신하고 정기적으로 엔드포인트에 상태 업데이트 및 하트비트를 제공합니다.

EKS 제어 플레인 통신

EKS에는 클러스터 엔드포인트에 대한 액세스를 제어하는 두 가지 방법이 있습니다. 엔드포인트 액세스 제어를 사용하면 퍼블릭 인터넷에서 엔드포인트에 연결할 수 있는지 아니면 VPC를 통해서만 엔드포인트에 연결할 수 있는지 선택할 수 있습니다. 퍼블릭 엔드포인트(기본값), 프라이빗 엔드포인트 또는 둘 다를 한 번에 켤 수 있습니다.

클러스터 API 엔드포인트의 구성에 따라 노드가 컨트롤 플레인과 통신하는 데 걸리는 경로가 결정됩니다. 이러한 엔드포인트 설정은 EKS 콘솔 또는 API를 통해 언제든지 변경할 수 있습니다.

퍼블릭 엔드포인트

새 Amazon EKS 클러스터의 기본 동작입니다. 클러스터의 퍼블릭 엔드포인트만 활성화되면 클러스터의 VPC 내에서 시작되는 Kubernetes API 요청(예: 컨트롤 플레인 통신을 위한 작업자 노드)은 VPC를 벗어나지만 Amazon의 네트워크는 나가지 않습니다. 노드가 컨트롤 플레인에 연결되려면 퍼블릭 IP 주소와 인터넷 게이트웨이에 대한 경로 또는 NAT 게이트웨이의 퍼블릭 IP 주소를 사용할 수 있는 NAT 게이트웨이에 대한 경로가 있어야 합니다.

퍼블릭 및 프라이빗 엔드포인트

퍼블릭 엔드포인트와 프라이빗 엔드포인트가 모두 활성화되면 VPC 내 Kubernetes API 요청은 VPC 내 X-ENIs를 통해 제어 플레인과 통신합니다. 인터넷에서 클러스터 API 서버에 액세스할 수 있습니다.

프라이빗 엔드포인트

프라이빗 엔드포인트만 활성화된 경우 인터넷에서 API 서버에 대한 퍼블릭 액세스 권한이 없습니다. 클러스터 API 서버에 대한 모든 트래픽은 클러스터의 VPC 또는 연결된 네트워크 내에서 비롯되어야 합니다. 노드는 VPC 내의 X-ENIs 통해 API 서버와 통신합니다. 클러스터 관리 도구는 프라이빗 엔드포인트에 액세스할 수 있어야 합니다. Amazon VPC 외부에서 프라이빗 Amazon EKS 클러스터 엔드포인트에 연결하는 방법에 대해 자세히 알아봅니다.

클러스터의 API 서버 엔드포인트는 퍼블릭 DNS 서버에서 VPC의 프라이빗 IP 주소로 확인됩니다. 이전에는 VPC 내에서만 엔드포인트를 확인할 수 있었습니다.

VPC 구성

Amazon VPC는 IPv4 및 IPv6 주소 지정을 지원합니다. Amazon EKS는 기본적으로 IPv4를 지원합니다. VPC에는 이와 연결된 IPv4 CIDR 블록이 있어야 합니다. 선택적으로 여러 IPv4 Classless Inter-Domain Routing(CIDR) 블록과 여러 IPv6 CIDR 블록을 VPC에 연결할 수 있습니다. VPC를 생성할 때 RFC 1918에 지정된 대로 프라이빗 IPv4 주소 범위에서 VPC에 대한 IPv4 CIDR 블록을 지정해야 합니다. http://www.faqs.org/rfcs/rfc1918.html 허용되는 블록 크기는 /16 접두사(65,536 IP 주소)와 /28 접두사(16 IP 주소) 사이입니다.

새 VPC를 생성할 때 단일 IPv6 CIDR 블록을 연결하고 기존 VPC를 변경할 때 최대 5개까지 연결할 수 있습니다. IPv6 CIDR 블록 크기의 접두사 길이는 /44에서 /60 사이일 수 있으며 IPv6 서브넷의 경우 /44/에서 /64 사이일 수 있습니다. Amazon에서 유지 관리하는 IPv6 주소 풀에서 IPv6 CIDR 블록을 요청할 수 있습니다. 자세한 내용은 VPC 사용 설명서의 VPC CIDR 블록 섹션을 참조하세요.

Amazon EKS 클러스터는 IPv4와 IPv6를 모두 지원합니다. 기본적으로 EKS 클러스터는 IPv4 IP를 사용합니다. 클러스터 생성 시 IPv6를 지정하면에서 IPv6 클러스터를 사용할 수 있습니다. IPv6 클러스터에는 듀얼 스택 VPCs 및 서브넷이 필요합니다.

Amazon EKS에서는 클러스터 생성 중에 서로 다른 가용 영역에 있는 서브넷을 두 개 이상 사용할 것을 권장합니다. 클러스터 생성 중에 전달하는 서브넷을 클러스터 서브넷이라고 합니다. 클러스터를 생성할 때 Amazon EKS는 지정한 서브넷에 최대 4개의 크로스 계정(x-계정 또는 x-ENIs) ENIs를 생성합니다. x-ENIs는 항상 배포되며 로그 전송, exec 및 프록시와 같은 클러스터 관리 트래픽에 사용됩니다. 전체 VPC 및 서브넷 요구 사항 세부 정보는 EKS 사용 설명서를 참조하세요.

Kubernetes 작업자 노드는 클러스터 서브넷에서 실행할 수 있지만 권장되지 않습니다. 클러스터 업그레이드 중에 Amazon EKS는 클러스터 서브넷에 추가 ENIs를 프로비저닝합니다. 클러스터가 스케일 아웃되면 작업자 노드와 포드가 클러스터 서브넷에서 사용 가능한 IPs를 사용할 수 있습니다. 따라서 사용 가능한 IPs지 확인하기 위해 /28 넷마스크가 있는 전용 클러스터 서브넷 사용을 고려할 수 있습니다.

Kubernetes 작업자 노드는 퍼블릭 또는 프라이빗 서브넷에서 실행할 수 있습니다. 서브넷이 퍼블릭인지 프라이빗인지는 서브넷 내의 트래픽이 인터넷 게이트웨이를 통해 라우팅되는지 여부를 나타냅니다. 퍼블릭 서브넷에는 인터넷 게이트웨이를 통해 인터넷에 대한 라우팅 테이블 항목이 있지만 프라이빗 서브넷에는 없습니다.

다른 곳에서 시작되어 노드에 도달하는 트래픽을 수신이라고 합니다. 노드에서 시작되어 네트워크에서 나가는 트래픽을 송신이라고 합니다. 인터넷 게이트웨이로 구성된 서브넷 내에 퍼블릭 또는 탄력적 IP 주소(EIPs)가 있는 노드는 VPC 외부에서 수신할 수 있습니다. 프라이빗 서브넷에는 일반적으로 NAT 게이트웨이로의 라우팅이 있으며, VPC 외부의 서브넷에 있는 노드로의 수신 트래픽은 허용하지 않지만 노드로부터의 트래픽은 여전히 VPC에서 나갈 수 있습니다(송신).

IPv6 세계에서는 모든 주소가 인터넷 라우팅이 가능합니다. 노드 및 포드와 연결된 IPv6 주소는 퍼블릭입니다. 프라이빗 서브넷은 VPC에 EIGW(송신 전용 인터넷 게이트웨이)를 구현하여 모든 수신 트래픽을 차단하면서 아웃바운드 트래픽을 허용함으로써 지원됩니다. IPv6 서브넷 구현 모범 사례는 VPC 사용 설명서에서 확인할 수 있습니다.

다음과 같은 세 가지 방법으로 VPC와 서브넷을 구성할 수 있습니다.

퍼블릭 서브넷만 사용

동일한 퍼블릭 서브넷에서 노드와 수신 리소스(예: 로드 밸런서)가 모두 생성됩니다. 퍼블릭 서브넷에 태그를 지정kubernetes.io/role/elb하여 인터넷을 향하는 로드 밸런서를 구성합니다. 이 구성에서 클러스터 엔드포인트는 퍼블릭, 프라이빗 또는 둘 다(퍼블릭 및 프라이빗)로 구성할 수 있습니다.

프라이빗 및 퍼블릭 서브넷 사용

노드는 프라이빗 서브넷에서 생성되는 반면 수신 리소스는 퍼블릭 서브넷에서 인스턴스화됩니다. 클러스터 엔드포인트에 대한 퍼블릭, 프라이빗 또는 둘 다(퍼블릭 및 프라이빗) 액세스를 활성화할 수 있습니다. 클러스터 엔드포인트의 구성에 따라 노드 트래픽은 NAT 게이트웨이 또는 ENI를 통해 들어갑니다.

프라이빗 서브넷만 사용

노드와 수신 모두 프라이빗 서브넷에 생성됩니다. kubernetes.io/role/internal-elb 서브넷 태그를 사용하여 내부 로드 밸런서를 구성합니다. 클러스터의 엔드포인트에 액세스하려면 VPN 연결이 필요합니다. EC2 및 모든 Amazon ECR 및 S3 리포지토리에 대해 AWS PrivateLink를 활성화해야 합니다. 클러스터의 프라이빗 엔드포인트만 활성화해야 합니다. 프라이빗 클러스터를 프로비저닝하기 전에 EKS 프라이빗 클러스터 요구 사항을 살펴보는 것이 좋습니다.

VPCs 간 통신

여러 VPCs에 배포된 별도의 EKS 클러스터가 필요한 경우 많은 시나리오VPCs.

Amazon VPC Lattice를 사용하여 여러 VPCs 및 계정에서 서비스를 일관되고 안전하게 연결할 수 있습니다(VPC 피어링, AWS PrivateLink 또는 AWS Transit Gateway와 같은 서비스에서 추가 연결을 제공할 필요 없음). 여기에서 자세히 알아보세요.

Amazon VPC Lattice는 IPv4 및 IPv6의 링크-로컬 주소 공간에서 작동하여 IPv4 주소가 겹칠 수 있는 서비스 간에 연결을 제공합니다. 운영 효율성을 위해 겹치지 않는 IP 범위에 EKS 클러스터와 노드를 배포하는 것이 좋습니다. 인프라에 중복 IP 범위가 있는 VPCs 포함된 경우 그에 따라 네트워크를 설계해야 합니다. 라우팅 가능한 RFC1918 IP 주소를 유지하면서 중복되는 CIDR 문제를 해결하기 위해 EKS의 워크로드를 통합하려면 전송 게이트웨이와 함께 프라이빗 NAT 게이트웨이 또는 사용자 지정 네트워킹 모드의 VPC CNI를 사용하는 것이 좋습니다. RFC1918

서비스 공급자이고 Kubernetes 서비스 및 수신(ALB 또는 NLB)을 별도의 계정의 고객 VPC와 공유하려는 경우 엔드포인트 서비스라고도 하는 AWS PrivateLink를 활용하는 것이 좋습니다.

여러 계정에서 VPC 공유

많은 기업이 네트워크 관리를 간소화하고, 비용을 절감하고, AWS Organization의 여러 AWS 계정에서 보안을 개선하기 위한 수단으로 공유 Amazon VPCs를 채택했습니다. AWS Resource Access Manager(RAM)를 활용하여 지원되는 AWS 리소스를 개별 AWS 계정, 조직 단위(OUs) 또는 전체 AWS Organization과 안전하게 공유합니다.

AWS RAM을 사용하여 다른 AWS 계정의 공유 VPC 서브넷에 Amazon EKS 클러스터, 관리형 노드 그룹 및 기타 지원 AWS 리소스(예: LoadBalancers, 보안 그룹, 엔드포인트 등)를 배포할 수 있습니다. 아래 그림은 상위 수준 아키텍처의 예를 보여줍니다. 이를 통해 중앙 네트워킹 팀은 VPCs, 서브넷 등과 같은 네트워킹 구성을 제어하고 애플리케이션 또는 플랫폼 팀은 해당 AWS 계정에 Amazon EKS 클러스터를 배포할 수 있습니다. 이 시나리오에 대한 전체 연습은이 github 리포지토리에서 확인할 수 있습니다.

공유 서브넷 사용 시 고려 사항

보안 그룹

보안 그룹은 연결된 리소스에 도달하고 나갈 수 있는 트래픽을 제어합니다. Amazon EKS는 보안 그룹을 사용하여 컨트롤 플레인과 노드 간의 통신을 관리합니다. 클러스터를 생성할 때 Amazon EKS에서 eks-cluster-sg-my-cluster-uniqueID라는 보안 그룹을 만듭니다. EKS는 이러한 보안 그룹을 관리형 ENIs 및 노드에 연결합니다. 기본 규칙을 사용하면 클러스터와 노드 간에 모든 트래픽이 자유롭게 흐를 수 있으며 모든 아웃바운드 트래픽은 모든 대상에 대해 허용됩니다.

클러스터를 생성할 때 자체 보안 그룹을 지정할 수 있습니다. 자체 보안 그룹을 지정할 때는 보안 그룹에 대한 권장 사항을 참조하세요.

추천

다중 AZ 배포 고려

AWS 리전은 지연 시간이 짧고 처리량이 높으며 중복성이 높은 네트워킹과 연결된 물리적으로 분리되고 격리된 여러 가용 영역(AZ)을 제공합니다. 가용 영역을 사용하면 중단 없이 가용 영역 간에 자동으로 장애 조치를 수행하는 애플리케이션을 설계하고 운영할 수 있습니다. Amazon EKS는 EKS 클러스터를 여러 가용 영역에 배포할 것을 적극 권장합니다. 클러스터를 생성할 때 두 개 이상의 가용 영역에 서브넷을 지정하는 것이 좋습니다.

노드에서 실행되는 Kubelet은와 같은 노드 객체에 레이블을 자동으로 추가합니다topology.kubernetes.io/region=us-west-2. 포드 토폴로지 분산 제약 조건과 함께 노드 레이블을 사용하여 포드가 영역 간에 분산되는 방식을 제어하는 것이 좋습니다. 이러한 힌트를 통해 Kubernetes 스케줄러는 예상 가용성을 높이기 위해 포드를 배치하여 상관관계가 있는 장애가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있습니다. 노드 선택기 및 AZ 분산 제약 조건의 예를 보려면 포드에 노드 할당을 참조하세요.

노드를 생성할 때 서브넷 또는 가용 영역을 정의할 수 있습니다. 구성된 서브넷이 없는 경우 노드가 클러스터 서브넷에 배치됩니다. 관리형 노드 그룹에 대한 EKS 지원은 가용 용량의 여러 가용 영역에 노드를 자동으로 분산합니다. Karpenter는 워크로드가 토폴로지 분산 한도를 정의하는 경우 노드를 지정된 AZ로 조정하여 AZs 분산 배치를 준수합니다.

AWS Elastic Load Balancer는 Kubernetes 클러스터의 AWS Load Balancer Controller에서 관리합니다. Kubernetes 수신 리소스에 대한 Application Load Balancer(ALB)와 유형의 Kubernetes 서비스에 대한 Network Load Balancer(NLB)를 프로비저닝합니다. Elastic Load Balancer 컨트롤러는 태그를 사용하여 서브넷을 검색합니다. ELB 컨트롤러가 수신 리소스를 성공적으로 프로비저닝하려면 최소 2개의 가용 영역(AZs)이 필요합니다. 지리적 중복성의 안전성 및 신뢰성을 활용하려면 두 개 이상의 AZs에서 서브넷을 설정하는 것이 좋습니다.

프라이빗 서브넷에 노드 배포

프라이빗 서브넷과 퍼블릭 서브넷을 모두 포함하는 VPC는 EKS에 Kubernetes 워크로드를 배포하는 데 이상적인 방법입니다. 두 개의 개별 가용 영역에서 최소 두 개의 퍼블릭 서브넷과 두 개의 프라이빗 서브넷을 설정하는 것이 좋습니다. 퍼블릭 서브넷의 관련 라우팅 테이블에는 인터넷 게이트웨이에 대한 경로가 포함되어 있습니다. 포드는 NAT 게이트웨이를 통해 인터넷과 상호 작용할 수 있습니다. 프라이빗 서브넷은 IPv6 환경(EIGW)의 외부 전용 인터넷 게이트웨이에서 지원됩니다.

프라이빗 서브넷의 노드를 인스턴스화하면 노드에 대한 트래픽을 최대한 제어할 수 있으며 대부분의 Kubernetes 애플리케이션에 효과적입니다. 수신 리소스(예: 로드 밸런서)는 퍼블릭 서브넷에서 인스턴스화되고 프라이빗 서브넷에서 작동하는 포드로 트래픽을 라우팅합니다.

엄격한 보안 및 네트워크 격리가 필요한 경우 프라이빗 전용 모드를 고려하세요. 이 구성에서는 세 개의 프라이빗 서브넷이 AWS 리전의 VPC 내의 개별 가용 영역에 배포됩니다. 서브넷에 배포된 리소스는 인터넷에 액세스할 수 없으며 인터넷도 서브넷의 리소스에 액세스할 수 없습니다. Kubernetes 애플리케이션이 다른 AWS 서비스에 액세스하려면 PrivateLink 인터페이스 및/또는 게이트웨이 엔드포인트를 구성해야 합니다. AWS Load Balancer Controller를 사용하여 트래픽을 포드로 리디렉션하도록 내부 Load Balancer 설정할 수 있습니다. 컨트롤러가 로드 밸런서를 프로비저닝하려면 프라이빗 서브넷에 태그(kubernetes.io/role/internal-elb: 1)를 지정해야 합니다. 노드를 클러스터에 등록하려면 클러스터 엔드포인트를 프라이빗 모드로 설정해야 합니다. 전체 요구 사항 및 고려 사항은 프라이빗 클러스터 가이드를 참조하세요.

클러스터 엔드포인트에 대한 퍼블릭 및 프라이빗 모드 고려

Amazon EKS는 퍼블릭 전용, public-and-private 전용 클러스터 엔드포인트 모드를 제공합니다. 기본 모드는 퍼블릭 전용이지만 퍼블릭 및 프라이빗 모드에서 클러스터 엔드포인트를 구성하는 것이 좋습니다. 이 옵션을 사용하면 클러스터의 VPC 내에서 Kubernetes API 호출(예: node-to-control-plane 통신)이 프라이빗 VPC 엔드포인트 및 트래픽을 활용하여 클러스터의 VPC 내에 유지할 수 있습니다. 반면 클러스터 API 서버는 인터넷에서 연결할 수 있습니다. 그러나 퍼블릭 엔드포인트를 사용할 수 있는 CIDR 블록을 제한하는 것이 좋습니다. CIDR 블록 제한을 포함하여 퍼블릭 및 프라이빗 엔드포인트 액세스를 구성하는 방법을 알아봅니다.

보안 및 네트워크 격리가 필요한 경우 프라이빗 전용 엔드포인트를 사용하는 것이 좋습니다. EKS 사용 설명서에 나열된 옵션 중 하나를 사용하여 API 서버에 비공개로 연결하는 것이 좋습니다.

보안 그룹을 신중하게 구성

Amazon EKS는 사용자 지정 보안 그룹 사용을 지원합니다. 모든 사용자 지정 보안 그룹은 노드와 Kubernetes 컨트롤 플레인 간의 통신을 허용해야 합니다. 조직에서 열린 통신을 허용하지 않는 경우 포트 요구 사항을 확인하고 규칙을 수동으로 구성하십시오.

EKS는 클러스터 생성 중에 제공하는 사용자 지정 보안 그룹을 관리형 인터페이스(X-ENIs)에 적용합니다. 그러나 노드와 즉시 연결되지는 않습니다. 노드 그룹을 생성할 때는 사용자 지정 보안 그룹을 수동으로 연결하는 것이 좋습니다. 노드의 자동 크기 조정 중에 사용자 지정 보안 그룹의 Karpenter 노드 템플릿 검색을 활성화하려면 securityGroupSelectorTerms를 활성화하는 것이 좋습니다.

모든 노드 간 통신 트래픽을 허용하는 보안 그룹을 생성하는 것이 좋습니다. 부트스트랩 프로세스 중에 노드가 클러스터 엔드포인트에 액세스하려면 아웃바운드 인터넷 연결이 필요합니다. 온프레미스 연결 및 컨테이너 레지스트리 액세스와 같은 외부 액세스 요구 사항을 평가하고 규칙을 적절하게 설정합니다. 프로덕션 환경에 변경 사항을 적용하기 전에 개발 환경에서 연결을 주의 깊게 확인하는 것이 좋습니다.

각 가용 영역에 NAT 게이트웨이 배포

프라이빗 서브넷(IPv4 및 IPv6)에 노드를 배포하는 경우 각 가용 영역(AZ)에 NAT 게이트웨이를 생성하여 영역 독립적 아키텍처를 보장하고 교차 AZ 지출을 줄이는 것이 좋습니다. AZ의 각 NAT 게이트웨이는 중복으로 구현됩니다.

Cloud9를 사용하여 프라이빗 클러스터에 액세스

AWS Cloud9는 AWS Systems Manager를 사용하여 수신 액세스 없이 프라이빗 서브넷에서 안전하게 실행할 수 있는 웹 기반 IDE입니다. Cloud9 인스턴스에서 송신을 비활성화할 수도 있습니다. Cloud9를 사용하여 프라이빗 클러스터 및 서브넷에 액세스하는 방법에 대해 자세히 알아봅니다.