사용자 지정 네트워킹

기본적으로 AmazonVPCCNI은 기본 서브넷에서 선택한 IP 주소를 포드에 할당합니다. 기본 서브넷은 기본 서브넷ENI이 연결된 서브넷CIDR으로, 일반적으로 노드/호스트의 서브넷입니다.

서브넷CIDR이 너무 작으면 CNI가 포드에 할당할 충분한 보조 IP 주소를 획득하지 못할 수 있습니다. 이는 EKS IPv4 클러스터의 일반적인 과제입니다.

사용자 지정 네트워킹은 이 문제에 대한 하나의 솔루션입니다.

사용자 지정 네트워킹은 보조 VPC 주소 공간()IPs에서 노드와 포드를 할당하여 IP 소진 문제를 해결합니다CIDR. 사용자 지정 네트워킹 지원은 ENIConfig 사용자 지정 리소스를 지원합니다. 에는 포드가 속할 보안 그룹(들)과 CIDR함께 대체 서브넷 CIDR 범위(보조 VPC 에서 조각)가 ENIConfig 포함됩니다. 사용자 지정 네트워킹이 활성화되면 는 아래에 정의된 서브넷ENIs에 보조 를 VPC CNI 생성합니다ENIConfig. 는 ENIConfig 에 정의된 CIDR 범위의 IP 주소를 포드에 CNI 할당합니다CRD.

기본 ENI 는 사용자 지정 네트워킹에서 사용되지 않으므로 노드에서 실행할 수 있는 최대 포드 수가 더 적습니다. 호스트 네트워크 포드는 기본 에 할당된 IP 주소를 계속 사용합니다ENI. 또한 기본 ENI 는 소스 네트워크 변환을 처리하고 노드 외부로 포드 트래픽을 라우팅하는 데 사용됩니다.

구성의 예제

사용자 지정 네트워킹은 보조 VPC 범위에 유효한 CIDR 범위를 허용하지만 CG-NAT 스페이스에서 CIDRs (/16)을 사용하는 것이 좋습니다. 즉, 100.64.0.0/10 또는 198.19.0.0/16은 다른 RFC1918 범위보다 기업 환경에서 사용할 가능성이 낮기 때문입니다. 와 함께 사용할 수 있는 허용 및 제한된 CIDR 블록 연결에 대한 자세한 내용은 VPC 설명서의 VPC 및 서브넷 크기 조정 단원의 IPv4 CIDR 블록 연결 제한을 VPC참조하세요.

아래 다이어그램과 같이 작업자 노드의 기본 탄력적 네트워크 인터페이스(ENI)는 여전히 기본 VPC CIDR 범위(이 경우 10.0.0.0/16)를 사용하지만 보조 노드는 보조 VPC CIDR 범위(이 경우 100.64.0.0/16)를 ENIs 사용합니다. 이제 포드가 100.64.0.0/16 CIDR 범위를 사용하도록 하려면 사용자 지정 네트워킹을 사용하도록 CNI 플러그인을 구성해야 합니다. 에 설명된 대로 단계를 수행할 수 있습니다.

에서 사용자 지정 네트워킹CNI을 사용하려면 AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG 환경 변수를 로 설정합니다true.

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

이 경우 CNI는 AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true에 정의된 서브넷에서 포드 IP 주소를 할당합니다ENIConfig. ENIConfig 사용자 지정 리소스는 포드를 예약할 서브넷을 정의하는 데 사용됩니다.

apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0dff111a1d11c1c11
  subnet: subnet-011b111c1f11fdf11

ENIconfig 사용자 지정 리소스를 생성하면 새 작업자 노드를 생성하고 기존 노드를 비워야 합니다. 기존 작업자 노드와 포드는 영향을 받지 않습니다.

추천

사용자 지정 네트워킹 사용 시기

IPv4 탈진을 처리하고 IPv6 아직 사용할 수 없는 경우 사용자 지정 네트워킹을 고려하는 것이 좋습니다. Amazon의 RFC6598 공간 EKS 지원을 통해 소진 문제를 RFC1918 해결하는 것 이상으로 포드를 확장할 수 있습니다. 노드의 포드 밀도를 높이려면 사용자 지정 네트워킹과 함께 접두사 위임을 사용하는 것이 좋습니다.

보안 그룹 요구 사항이 다른 네트워크에서 포드를 실행해야 하는 보안 요구 사항이 있는 경우 사용자 지정 네트워킹을 고려할 수 있습니다. 사용자 지정 네트워킹이 활성화되면 포드는 노드의 기본 네트워크 인터페이스ENIConfig와 에 정의된 다른 서브넷 또는 보안 그룹을 사용합니다.

사용자 지정 네트워킹은 실제로 온프레미스 데이터 센터 서비스를 연결하기 위해 여러 EKS 클러스터와 애플리케이션을 배포하는 데 이상적인 옵션입니다. Amazon Elastic Load Balancing 및 NAT-GW와 같은 서비스에 VPC 대해 EKS에서 액세스할 수 있는 프라이빗 주소(RFC1918)의 수를 늘리는 동시에 여러 클러스터의 포드에 라우팅할 수 없는 CG 공간을NAT 사용할 수 있습니다. 전송 게이트웨이 및 공유 서비스VPC(고가용성을 위한 여러 가용 영역의 NAT 게이트웨이 포함)를 사용한 사용자 지정 네트워킹을 통해 확장 가능하고 예측 가능한 트래픽 흐름을 제공할 수 있습니다. 이 블로그 게시물은 사용자 지정 네트워킹을 사용하여 EKS 포드를 데이터 센터 네트워크에 연결하는 가장 권장되는 방법 중 하나인 아키텍처 패턴을 설명합니다.

다음과 같은 경우 사용자 지정 네트워킹 방지

구현 준비 완료 IPv6

사용자 지정 네트워킹은 IP 소진 문제를 완화할 수 있지만 추가 운영 오버헤드가 필요합니다. 현재 듀얼 스택(IPv4/IPv6)을 배포하고 VPC 있거나 플랜에 IPv6 지원이 포함되어 있는 경우 대신 IPv6 클러스터를 구현하는 것이 좋습니다. IPv6 EKS 클러스터를 설정하고 앱을 마이그레이션할 수 있습니다. IPv6 EKS 클러스터에서 Kubernetes와 포드 모두 IPv6 주소를 가져오고 IPv4 및 IPv6 엔드포인트 모두에서 주고 받을 수 있습니다. IPv6 EKS 클러스터 실행 모범 사례를 검토하세요.

소진된 CG-NAT Space

또한 현재 CG-NAT 스페이스CIDRs에서 를 사용하고 있거나 보조 를 클러스터 CIDR와 연결할 수 없는 경우 대체 를 사용하는 등의 다른 옵션을 탐색해야 할 VPC수 있습니다CNI. 패치를 디버깅하고 오픈 소스 CNI 플러그인 프로젝트에 제출하려면 상업적 지원을 받거나 사내 지식을 보유하는 것이 좋습니다. 자세한 내용은 대체 CNI 플러그인 사용 설명서를 참조하세요.

프라이빗 NAT 게이트웨이 사용

Amazon은 VPC 이제 프라이빗 NAT 게이트웨이 기능을 제공합니다. Amazon의 프라이빗 NAT 게이트웨이를 사용하면 프라이빗 서브넷의 인스턴스가 겹치는 를 사용하여 다른 VPCs 및 온프레미스 네트워크에 연결할 수 있습니다CIDRs. 이 블로그 게시물에 설명된 방법을 활용하여 프라이빗 NAT 게이트웨이를 사용하여 클라이언트가 표현한 상당한 불만 CIDRs사항인 중복으로 인한 EKS 워크로드의 통신 문제를 극복하는 것을 고려해 보세요. 사용자 지정 네트워킹은 중복되는 CIDR 문제를 자체적으로 해결할 수 없으며 구성 문제에 추가됩니다.

이 블로그 사후 구현에 사용되는 네트워크 아키텍처는 Amazon VPC 설명서의 중복 네트워크 간 통신 활성화의 권장 사항을 따릅니다. 이 블로그 게시물에서 볼 수 있듯이 RFC6598 주소와 함께 프라이빗 NAT 게이트웨이 사용을 확장하여 고객의 프라이빗 IP 소진 문제를 관리할 수 있습니다. EKS 클러스터, 작업자 노드는 라우팅 불가능한 100.64.0.0/16 VPC 보조 CIDR 범위에 배포되는 반면 프라이빗 NAT 게이트웨이, NAT 게이트웨이는 라우팅 가능한 RFC1918 CIDR 범위에 배포됩니다. 이 블로그는 전송 게이트웨이를 사용하여 겹치는 라우팅 불가능한 CIDR 범위VPCs와 간의 통신을 용이하게 하기 VPCs 위해 연결하는 방법을 설명합니다. 라우팅 VPC불가능한 주소 범위의 EKS 리소스가 주소 범위가 겹치지 VPCs 않는 다른 리소스와 통신해야 하는 사용 사례의 경우 고객은 VPC 피어링을 사용하여 이러한 를 상호 연결할 수 있습니다VPCs. 이제 VPC 피어링 연결을 통해 가용 영역 내에서 모든 데이터를 전송할 수 없으므로 이 방법을 사용하면 비용을 절감할 수 있습니다.

노드 및 포드용 고유 네트워크

보안상의 이유로 노드와 포드를 특정 네트워크에 격리해야 하는 경우 노드와 포드를 더 큰 보조 CIDR 블록(예: 100.64.0.0/8)에서 서브넷에 배포하는 것이 좋습니다. CIDR 에 새 를 설치VPC한 후 보조 노드를 사용하여 다른 노드 그룹을 배포CIDR하고 원래 노드를 드레이닝하여 포드를 새 작업자 노드에 자동으로 재배포할 수 있습니다. 이를 구현하는 방법에 대한 자세한 내용은 이 블로그 게시물을 참조하세요.

사용자 지정 네트워킹은 아래 다이어그램에 표시된 설정에서 사용되지 않습니다. 오히려 Kubernetes 작업자 노드는 100.64.0.0/10과 같은 VPC의 보조 VPC CIDR 범위에서 서브넷에 배포됩니다. EKS 클러스터를 계속 실행할 수 있습니다(컨트롤 플레인은 원래 에 유지됩니다subnet/s), but the nodes and Pods will be moved to a secondary subnet/s. 이는 에서 IP 소진 위험을 완화하는 또 다른 기존 기법은 아니지만, VPC 포드를 새 작업자 노드로 재배포하기 전에 이전 노드를 드레이닝하는 것이 좋습니다.

가용 영역 레이블을 사용한 구성 자동화

Kubernetes가 작업자 노드 가용 영역(AZ)ENIConfig에 해당하는 를 자동으로 적용하도록 활성화할 수 있습니다.

Kubernetes는 topology.kubernetes.io/zone 작업자 노드에 태그를 자동으로 추가합니다. Amazon은 ENI AZ당 보조 서브넷( 대체 CIDR)이 하나만 있는 경우 가용 영역을 구성 이름으로 사용하는 것이 EKS 좋습니다. 태그failure-domain.beta.kubernetes.io/zone는 더 이상 사용되지 않으며 태그 로 대체됩니다topology.kubernetes.io/zone.

name 필드를 의 가용 영역으로 설정합니다VPC.
다음 명령을 사용하여 자동 구성을 활성화합니다.

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

가용 영역당 보조 서브넷이 여러 개 있는 경우 특정 를 생성해야 합니다ENI_CONFIG_LABEL_DEF. k8s.amazonaws.com/eniConfig 및 와 같은 사용자 지정 eniConfig 이름을 사용하여 k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 및 레이블 노드ENI_CONFIG_LABEL_DEF로 구성하는 것을 고려할 수 있습니다k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2.

보조 네트워킹 구성 시 포드 교체

사용자 지정 네트워킹을 활성화해도 기존 노드는 수정되지 않습니다. 사용자 지정 네트워킹은 파괴적인 작업입니다. 사용자 지정 네트워킹을 활성화한 후 클러스터의 모든 작업자 노드를 롤링 교체하는 대신 Lambda 함수를 호출하는 사용자 지정 리소스로 EKS 시작 안내서의 AWS CloudFormation 템플릿을 업데이트하여 작업자 노드가 프로비저닝되기 전에 사용자 지정 네트워킹을 활성화하도록 환경 변수로 aws-node Daemonset을 업데이트하는 것이 좋습니다.

사용자 지정 CNI 네트워킹 기능으로 전환하기 전에 클러스터에 포드가 실행 중인 노드가 있는 경우 노드를 코딩하고 드레이닝하여 포드를 정상적으로 종료한 다음 노드를 종료해야 합니다. ENIConfig 레이블 또는 주석과 일치하는 새 노드만 사용자 지정 네트워킹을 사용하므로 이러한 새 노드에 예약된 포드에 보조 의 IP를 할당할 수 있습니다CIDR.

노드당 최대 포드 계산

노드의 기본 ENI 는 더 이상 포드 IP 주소를 할당하는 데 사용되지 않으므로 지정된 EC2 인스턴스 유형에서 실행할 수 있는 포드 수가 줄어듭니다. 이 제한 사항을 해결하려면 사용자 지정 네트워킹과 함께 접두사 할당을 사용할 수 있습니다. 접두사 할당을 사용하면 각 보조 IP가 보조 의 /28 접두사로 대체됩니다ENIs.

사용자 지정 네트워킹이 있는 m5.large 인스턴스의 최대 포드 수를 고려합니다.

접두사 할당 없이 실행할 수 있는 최대 포드 수는 29개입니다.

3 ENIs - 1) * (10 secondary IPs per ENI - 1 + 2 = 20

접두사 첨부 파일을 활성화하면 포드 수가 290개로 증가합니다.

(3 ENIs - 1) * ((10 secondary IPs per ENI - 1) * 16 + 2 = 290

하지만 인스턴스의 가상 가 다소 적기 때문에 최대 포드를 290이 아닌 110으로 설정하는 것이 좋습니다CPUs. 더 큰 인스턴스의 경우 는 최대 포드 값 250을 EKS 권장합니다. 인스턴스 유형이 작은 접두사 첨부 파일(예: m5.large)을 사용하는 경우 IP 주소보다 훨씬 먼저 인스턴스 CPU 및 메모리 리소스를 소진할 수 있습니다.

참고

CNI 접두사가 /28 접두사를 에 할당ENI하면 IP 주소의 연속 블록이어야 합니다. 접두사가 생성되는 서브넷이 고도로 조각화되면 접두사 연결에 실패할 수 있습니다. 클러스터 VPC 전용 새 를 생성하거나 서브넷에 접두사 첨부 파일 CIDR 전용 세트를 예약하여 이러한 현상을 완화할 수 있습니다. 이 주제에 대한 자세한 내용은 서브넷 CIDR 예약을 참조하세요.

CG-NAT Space의 기존 사용 식별

사용자 지정 네트워킹을 사용하면 IP 소진 문제를 완화할 수 있지만 모든 문제를 해결할 수는 없습니다. 클러스터에 이미 CG 공간을NAT 사용하고 있거나 보조 를 클러스터 CIDR 에 연결할 수 없는 경우 대체 를 사용하거나 IPv6 클러스터로 CNI 이동하는 등의 다른 옵션을 탐색하는 VPC것이 좋습니다.

📝 에서 이 페이지 편집 GitHub

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

IPv6 클러스터 실행

Linux용 접두사 모드