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

VPC 및 서브넷 고려 사항

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

를 설계VPC하거나 기존 에 클러스터를 배포하기 전에 EKS 제어 영역 통신 메커니즘을 이해하는 것이 좋습니다VPCs.

에 사용할 VPC 및 서브넷을 설계할 때 클러스터 VPC 고려 사항 및 Amazon EKS 보안 그룹 고려 사항을 참조하세요EKS.

개요

EKS 클러스터 아키텍처

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

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

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

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

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

EKS 제어 평면 통신

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

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

퍼블릭 엔드포인트

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

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

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

프라이빗 엔드포인트

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

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

VPC 구성

Amazon은 IPv4 및 IPv6 주소 지정을 VPC 지원합니다. Amazon은 기본적으로 IPv4를 EKS 지원합니다. 에는 연결된 IPv4 CIDR 블록이 VPC 있어야 합니다. 선택적으로 여러 IPv4 클래스리스 도메인 간 라우팅(CIDR) 블록과 여러 IPv6 CIDR 블록을 에 연결할 수 있습니다VPC. 를 생성할 때는 RFC1918VPC년에 지정된 대로 프라이빗 IPv4 주소 범위에서 에 대한 IPv4 CIDR 블록을 지정VPC해야 합니다. 허용되는 블록 크기는 /16 접두사(65,536 IP 주소)와 /28 접두사(16 IP 주소) 사이입니다.

새 를 생성할 때 단일 IPv6 CIDR 블록을 연결할 VPC수 있으며 기존 를 변경할 때는 최대 5개까지 연결할 수 있습니다VPC. 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은 지정한 서브넷ENIs에 최대 4개의 크로스 계정(x-계정 또는 x-ENIs)을 EKS 생성합니다. x-ENIs는 항상 배포되며 로그 전송, exec 및 프록시와 같은 클러스터 관리 트래픽에 사용됩니다. 전체 VPC 및 서브넷 요구 사항 세부 정보는 EKS 사용 설명서를 참조하세요.

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

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

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

전 IPv6 세계에서 모든 주소는 인터넷 라우팅이 가능합니다. 노드 및 포드와 연결된 IPv6 주소는 퍼블릭입니다. 프라이빗 서브넷은 에서 송신 전용 인터넷 게이트웨이(EIGW)를 구현하여 모든 수신 트래픽을 차단하면서 아웃바운드 트래픽을 VPC허용함으로써 지원됩니다. 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 및 의 링크-로컬 주소 공간에서 작동하여 IPv4 주소가 중복될 수 있는 서비스 간에 연결을 IPv6제공합니다. 운영 효율성을 위해 중복되지 않는 IP 범위에 EKS 클러스터와 노드를 배포하는 것이 좋습니다. 인프라에 중복 IP 범위가 VPCs 포함된 경우 그에 따라 네트워크를 설계해야 합니다. 라우팅 가능한 RFC1918 IP 주소를 보존하면서 중복되는 CIDR 문제를 해결하기 위해 전송 게이트웨이와 함께 Private NAT Gateway 또는 VPC CNI 사용자 지정 네트워킹 모드에서 워크로드EKS를 에 통합하는 것이 좋습니다.

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

여러 계정VPC에서 공유

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

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

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

보안 그룹

보안 그룹은 연결된 리소스에 도달하고 나갈 수 있는 트래픽을 제어합니다. AmazonEKS은 보안 그룹을 사용하여 제어 영역과 노드 간의 통신을 관리합니다. 클러스터를 생성할 때 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 스케줄러는 Pod를 배치하여 예상 가용성을 높일 수 있으므로 상관관계가 있는 장애가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있습니다. 노드 선택기 및 AZ 스프레드 제약 조건에 대한 예제를 보려면 노드를 포드에 할당을 참조하세요.

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

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

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

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

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

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

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

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

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

보안 그룹 신중 구성

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

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

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

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

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

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

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

📝 에서 이 페이지 편집 GitHub