Amazon VPC CNI

Amazon EKS는 VPC CNI라고도 하는 Amazon VPC 컨테이너 네트워크 인터페이스 플러그인을 통해 클러스터 네트워킹을 구현합니다. CNI 플러그인을 사용하면 Kubernetes 포드가 VPC 네트워크에서와 동일한 IP 주소를 가질 수 있습니다. 보다 구체적으로 말하자면 포드 내의 모든 컨테이너는 네트워크 네임스페이스를 공유하며 로컬 포트를 사용하여 서로 통신할 수 있습니다.

Amazon VPC CNI에는 두 가지 구성 요소가 있습니다.

• 포드 간 통신을 활성화Pod-to-Pod 네트워크를 설정하는 CNI 바이너리입니다. CNI 바이너리는 노드 루트 파일 시스템에서 실행되며 새 포드가 노드에 추가되거나 기존 포드가 노드에서 제거될 때 kubelet에 의해 호출됩니다.

• 장기 실행 노드-로컬 IP 주소 관리(IPAM) 데몬인 ipamd는 다음을 담당합니다.

  • 노드에서 ENIs 관리

  • 사용 가능한 IP 주소 또는 접두사의 웜 풀 유지 관리

인스턴스가 생성되면 EC2는 기본 서브넷과 연결된 기본 ENI를 생성하고 연결합니다. 기본 서브넷은 퍼블릭 또는 프라이빗일 수 있습니다. hostNetwork 모드에서 실행되는 포드는 노드 기본 ENI에 할당된 기본 IP 주소를 사용하고 호스트와 동일한 네트워크 네임스페이스를 공유합니다.

CNI 플러그인은 노드에서 탄력적 네트워크 인터페이스(ENI)를 관리합니다. 노드가 프로비저닝되면 CNI 플러그인은 노드의 서브넷에서 기본 ENI로 슬롯 풀(IPs 또는 접두사)을 자동으로 할당합니다. 이 풀을 웜 풀이라고 하며, 크기는 노드의 인스턴스 유형에 따라 결정됩니다. CNI 설정에 따라 슬롯은 IP 주소 또는 접두사일 수 있습니다. ENI의 슬롯이 할당되면 CNI는 슬롯의 웜 풀이 있는 추가 ENIs를 노드에 연결할 수 있습니다. 이러한 추가 ENIs 보조 ENIs. 각 ENI는 인스턴스 유형에 따라 특정 수의 슬롯만 지원할 수 있습니다. CNI는 일반적으로 포드 수에 해당하는 필요한 슬롯 수를 기반으로 인스턴스에 더 많은 ENIs를 연결합니다. 이 프로세스는 노드가 더 이상 추가 ENI를 지원할 수 없을 때까지 계속됩니다. 또한 CNI는 더 빠른 포드 시작을 위해 "웜" ENIs 및 슬롯을 사전 할당합니다. 각 인스턴스 유형에는 연결할 수 있는 최대 ENIs 수가 있습니다. 이는 컴퓨팅 리소스 외에도 포드 밀도(노드당 포드 수)에 대한 한 가지 제약 조건입니다.

최대 네트워크 인터페이스 수와 사용할 수 있는 최대 슬롯 수는 EC2 인스턴스 유형에 따라 다릅니다. 각 포드는 슬롯의 IP 주소를 사용하므로 특정 EC2 인스턴스에서 실행할 수 있는 포드 수는 연결할 수 있는 ENIs 수와 각 ENI가 지원하는 슬롯 수에 따라 달라집니다. 인스턴스의 CPU 및 메모리 리소스가 고갈되지 않도록 EKS당 최대 포드 사용 설명서를 설정하는 것이 좋습니다. 를 사용하는 포드hostNetwork는이 계산에서 제외됩니다. 지정된 인스턴스 유형에 대한 EKS의 권장 최대 포드를 계산하기 위해 max-pod-calculator.sh라는 스크립트를 사용하는 것을 고려할 수 있습니다.

개요

보조 IP 모드는 VPC CNI의 기본 모드입니다. 이 가이드에서는 보조 IP 모드가 활성화된 경우 VPC CNI 동작에 대한 일반적인 개요를 제공합니다. ipamd(IP 주소 할당)의 기능은 , Linux용 접두사 모드 포드당 보안 그룹및와 같은 VPC CNI의 구성 설정에 따라 달라질 수 있습니다사용자 지정 네트워킹.

Amazon VPC CNI는 작업자 노드에 aws-node라는 Kubernetes Daemonset으로 배포됩니다. 작업자 노드가 프로비저닝되면 기본 ENI라고 하는 기본 ENI가 노드에 연결됩니다. CNI는 노드의 기본 ENIs에 연결된 서브넷에서 ENI 및 보조 IP 주소의 웜 풀을 할당합니다. 기본적으로 ipamd는 노드에 추가 ENI를 할당하려고 시도합니다. IPAMD는 단일 포드가 예약되고 기본 ENI의 보조 IP 주소가 할당될 때 추가 ENI를 할당합니다. 이 "웜" ENI를 사용하면 더 빠른 포드 네트워킹이 가능합니다. 보조 IP 주소 풀이 부족해지면 CNI는 다른 ENI를 추가하여 더 할당합니다.

풀의 ENIs 및 IP 주소 수는 WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET이라는 환경 변수를 통해 구성됩니다. aws-node Daemonset는 충분한 수의 ENIs가 연결되어 있는지 주기적으로 확인합니다. WARM_ENI_TARGET또는 WARM_IP_TARGET 및 MINIMUM_IP_TARGET 조건이 모두 충족되면 충분한 수의 ENIs가 연결됩니다. ENIs가 충분하지 않은 경우 CNI는 MAX_ENI 한도에 도달할 때까지 EC2에 API를 호출하여 더 많이 연결합니다.

• WARM_ENI_TARGET - 정수, 값이 0보다 크면 요구 사항이 활성화되었음을 나타냅니다.

  • 유지할 웜 ENIs. ENI는 노드에 보조 ENI로 연결되지만 포드에서 사용되지 않는 경우 "웜"입니다. 보다 구체적으로 말하자면, ENI의 IP 주소는 포드와 연결되지 않았습니다.

  • 예: 각 ENIs가 5개의 IP 주소를 지원하는 2개의 ENI가 있는 인스턴스를 가정합니다. WARM_ENI_TARGET은 1로 설정됩니다. 정확히 5개의 IP 주소가 인스턴스와 연결된 경우 CNI는 인스턴스에 연결된 2ENIs를 유지합니다. 첫 번째 ENI가 사용 중이며이 ENI의 가능한 IP 주소 5개가 모두 사용됩니다. 두 번째 ENI는 풀에 5개의 IP 주소가 모두 있는 "웜"입니다. 인스턴스에서 다른 포드가 시작되면 6번째 IP 주소가 필요합니다. CNI는이 6번째 포드에 두 번째 ENI의 IP 주소와 풀의 5개의 IPs 주소를 할당합니다. 이제 두 번째 ENI가 사용 중이며 더 이상 "웜" 상태가 아닙니다. CNI는 3번째 ENI를 할당하여 최소 1개의 웜 ENI를 유지합니다.

참고

웜 ENIs는 여전히 VPC의 CIDR에서 IP 주소를 사용합니다. IP 주소는 포드와 같은 워크로드와 연결될 때까지 "미사용" 또는 "웜"입니다.

• WARM_IP_TARGET, 정수, 값이 0보다 크면 요구 사항이 활성화되었음을 나타냅니다.

  • 유지할 웜 IP 주소 수입니다. 웜 IP는 활발하게 연결된 ENI에서 사용할 수 있지만 포드에 할당되지 않았습니다. 즉, 사용 가능한 웜 IPs 수는 추가 ENI 없이 포드에 할당할 수 있는 IPs 수입니다.

• 예: 각 ENI가 20개의 IP 주소를 지원하는 1개의 ENI가 있는 인스턴스를 가정합니다. WARM_IP_TARGET은 5로 설정됩니다. WARM_ENI_TARGET은 0으로 설정됩니다. 16번째 IP 주소가 필요할 때까지 1개의 ENI만 연결됩니다. 그런 다음 CNI는 서브넷 CIDR에서 가능한 20개의 주소를 사용하여 두 번째 ENI를 연결합니다.

• MINIMUM_IP_TARGET, 정수, 값이 0보다 크면 요구 사항이 활성화되었음을 나타냅니다.

  • 언제든지 할당할 최소 IP 주소 수입니다. 이는 일반적으로 인스턴스 시작 시 여러 ENIs의 할당을 미리 로드하는 데 사용됩니다.

  • 예: 새로 시작된 인스턴스를 고려합니다. ENI는 1개이며 각 ENI는 IP 주소 10개를 지원합니다. MINIMUM_IP_TARGET은 100으로 설정됩니다. ENI는 총 100개의 주소에 대해 9개의 추가 ENIs를 즉시 연결합니다. 이는 WARM_IP_TARGET 또는 WARM_ENI_TARGET 값에 관계없이 발생합니다.

이 프로젝트에는 서브넷 계산기 Excel 문서가 포함되어 있습니다. 이 계산기 문서는 WARM_IP_TARGET 및와 같은 다양한 ENI 구성 옵션에서 지정된 워크로드의 IP 주소 소비를 시뮬레이션합니다WARM_ENI_TARGET.

Kubelet이 포드 추가 요청을 수신하면 CNI 바이너리가 사용 가능한 IP 주소에 대해 ipamd를 쿼리한 다음 ipamd가 포드에 제공합니다. CNI 바이너리가 호스트 및 포드 네트워크를 연결합니다.

노드에 배포된 포드는 기본적으로 기본 ENI와 동일한 보안 그룹에 할당됩니다. 또는 다른 보안 그룹으로 포드를 구성할 수 있습니다.

IP 주소 풀이 고갈되면 플러그 인은 다른 탄력적 네트워크 인터페이스를 인스턴스에 자동으로 연결하고 이 인터페이스에 다른 보조 IP 주소 집합을 할당합니다. 이 프로세스는 노드가 탄력적 네트워크 인터페이스를 추가 지원할 수 없을 때까지 계속됩니다.

포드가 삭제되면 VPC CNI는 포드의 IP 주소를 30초 휴지 캐시에 배치합니다. 휴지 캐시IPs는 새 포드에 할당되지 않습니다. 쿨링 오프 기간이 끝나면 VPC CNI는 포드 IP를 웜 풀로 다시 이동합니다. 쿨링 오프 기간은 포드 IP 주소가 조기에 재활용되는 것을 방지하고 모든 클러스터 노드에서 kube-proxy가 iptables 규칙 업데이트를 완료하도록 허용합니다. IPs 또는 ENIs 수가 웜 풀 설정 수를 초과하면 ipamd 플러그인은 IPs 및 ENIs에 반환합니다.

위에서 보조 IP 모드에서 설명한 대로 각 포드는 인스턴스에 연결된 ENIs 중 하나에서 보조 프라이빗 IP 주소 하나를 받습니다. 각 포드는 IP 주소를 사용하므로 특정 EC2 인스턴스에서 실행할 수 있는 포드 수는 연결할 수 있는 ENIs 수와 지원하는 IP 주소 수에 따라 달라집니다. VPC CNI는 제한 파일을 확인하여 각 인스턴스 유형에 허용되는 ENIs 및 IP 주소 수를 확인합니다.

다음 공식을 사용하여 노드에 배포할 수 있는 최대 포드 수를 결정할 수 있습니다.

(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2

+2는 kube-proxy 및 VPC CNI와 같은 호스트 네트워킹이 필요한 포드를 나타냅니다. Amazon EKS에서는 각 노드에서 kube-proxy 및 VPC CNI를 작동해야 하며 이러한 요구 사항은 최대 포드 값에 반영됩니다. 추가 호스트 네트워킹 포드를 실행하려면 최대 포드 값을 업데이트하는 것이 좋습니다.

+2는 kube-proxy 및 VPC CNI와 같은 호스트 네트워킹을 사용하는 Kubernetes 포드를 나타냅니다. Amazon EKS는 모든 노드에서 kube-proxy 및 VPC CNI를 실행해야 하며 최대 포드에 대해 계산됩니다. 호스트 네트워킹 포드를 더 많이 실행하려는 경우 최대 포드를 업데이트하는 것이 좋습니다. 시작 템플릿에서를 사용자 데이터--kubelet-extra-args "—max-pods=110"로 지정할 수 있습니다.

예를 들어 c5.large 노드가 3개인 클러스터(ENIs당 최대 10IPs)에서 클러스터가 시작되고 CoreDNS 포드가 2개 있는 경우 CNI는 49개의 IP 주소를 사용하고 웜 풀에 유지합니다. 웜 풀을 사용하면 애플리케이션이 배포될 때 더 빠른 포드 시작이 가능합니다.

노드 1(CoreDNS 포드 포함): ENIs, IPs 할당

노드 2(CoreDNS 포드 포함): ENIs, IPs 할당

노드 3(포드 없음): ENI 1개. 10개의 IPs 할당되었습니다.

종종 데몬 세트로 실행되는 인프라 포드는 각각 최대 포드 수에 기여한다는 점에 유의하세요. 여기에는 다음이 포함될 수 있습니다.

• CoreDNS

• Amazon Elastic LoadBalancer

• 지표 서버의 운영 포드

이러한 포드의 용량을 결합하여 인프라를 계획하는 것이 좋습니다. 각 인스턴스 유형에서 지원하는 최대 포드 수 목록은 GitHub의 eni-max-Pods.txt를 참조하세요.

추천

Auto Mode를 사용하여 EKS 클러스터 배포

EKS Auto Mode를 사용하여 클러스터를 생성할 때 AWS는 클러스터의 VPC 컨테이너 네트워크 인터페이스(CNI) 구성을 관리합니다. Amazon EKS Auto Mode를 사용하면 네트워킹 추가 기능을 설치하거나 업그레이드할 필요가 없습니다. 그러나 워크로드가 관리형 VPC CNI 구성과 호환되는지 확인합니다.

VPC CNI 관리형 추가 기능 배포

클러스터를 프로비저닝하면 Amazon EKS가 VPC CNI를 자동으로 설치합니다. 그럼에도 불구하고 Amazon EKS는 클러스터가 컴퓨팅, 스토리지 및 네트워킹과 같은 기본 AWS 리소스와 상호 작용할 수 있도록 하는 관리형 추가 기능을 지원합니다. VPC CNI를 포함한 관리형 추가 기능을 사용하여 클러스터를 배포하는 것이 좋습니다.

Amazon EKS 관리형 추가 기능은 Amazon EKS 클러스터에 VPC CNI 설치 및 관리를 제공합니다. Amazon EKS 추가 기능에는 최신 보안 패치, 버그 수정이 포함되며 AWS에서 Amazon EKS와 함께 작동하도록 검증했습니다. VPC CNI 추가 기능을 사용하면 Amazon EKS 클러스터의 보안 및 안정성을 지속적으로 보장하고 추가 기능을 설치, 구성 및 업데이트하는 데 필요한 노력을 줄일 수 있습니다. 또한 Amazon EKS API, AWS Management Console, AWS CLI 및 eksctl을 통해 관리형 추가 기능을 추가, 업데이트 또는 삭제할 수 있습니다.

kubectl get 명령과 함께 --show-managed-fields 플래그를 사용하여 VPC CNI의 관리형 필드를 찾을 수 있습니다.

kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml

관리형 추가 기능은 15분마다 구성을 자동으로 덮어써 구성 드리프트를 방지합니다. 즉, 추가 기능 생성 후 Kubernetes API를 통해 수행된 관리형 추가 기능에 대한 모든 변경 사항은 자동 드리프트 방지 프로세스에 의해 덮어쓰고 추가 기능 업데이트 프로세스 중에 기본값으로 설정됩니다.

EKS에서 관리하는 필드는 관리자가 EKS인 managedFields 아래에 나열됩니다. EKS에서 관리하는 필드에는 서비스 계정, 이미지, 이미지 URL, 생체 프로브, 준비 프로브, 레이블, 볼륨 및 볼륨 마운트가 포함됩니다.

참고

WARM_ENI_TARGET, WARM_IP_TARGET, MINIMUM_IP_TARGET과 같이 가장 자주 사용되는 필드는 관리되지 않으며 조정되지 않습니다. 이러한 필드의 변경 사항은 추가 기능 업데이트 시 유지됩니다.

프로덕션 클러스터를 업데이트하기 전에 비프로덕션 클러스터에서 특정 구성에 대한 추가 기능 동작을 테스트하는 것이 좋습니다. 또한 추가 기능 구성에 대해서는 EKS 사용 설명서의 단계를 따르세요.

관리형 추가 기능으로 마이그레이션

버전 호환성을 관리하고 자체 관리형 VPC CNI의 보안 패치를 업데이트합니다. 자체 관리형 추가 기능을 업데이트하려면 EKS 사용 설명서에 설명된 Kubernetes APIs 및 지침을 사용해야 합니다. 기존 EKS 클러스터의 관리형 추가 기능으로 마이그레이션하는 것이 좋습니다. 마이그레이션하기 전에 현재 CNI 설정의 백업을 생성하는 것이 좋습니다. 관리형 추가 기능을 구성하려면 Amazon EKS API, AWS Management Console 또는 AWS 명령줄 인터페이스를 활용할 수 있습니다.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

필드가 기본 설정으로 관리형으로 나열된 경우 Amazon EKS는 CNI 구성 설정을 대체합니다. 관리형 필드를 수정하지 않도록 주의합니다. 추가 기능은 웜 환경 변수 및 CNI 모드와 같은 구성 필드를 조정하지 않습니다. 관리형 CNI로 마이그레이션하는 동안 포드와 애플리케이션은 계속 실행됩니다.

업데이트 전 백업 CNI 설정

VPC CNI는 고객 데이터 영역(노드)에서 실행되므로 Amazon EKS는 새 버전이 릴리스되거나 클러스터를 새 Kubernetes 마이너 버전으로 업데이트한 후 추가 기능(관리형 및 자체 관리형)을 자동으로 업데이트하지 않습니다. 기존 클러스터의 추가 기능을 업데이트하려면 추가 기능을 위해 update-addon API를 통해 업데이트를 트리거하거나 EKS 콘솔에서 지금 업데이트 링크를 클릭해야 합니다. 자체 관리형 추가 기능을 배포한 경우 자체 관리형 VPC CNI 추가 기능 업데이트에 언급된 단계를 따릅니다.

한 번에 하나의 마이너 버전을 업데이트하는 것이 좋습니다. 예를 들어 현재 버전이 1.9이고 1.11으로 업데이트하려는 경우 먼저 최신 패치 버전 1.10로 업데이트한 다음 최신 패치 버전 1.11으로 업데이트해야 합니다.

Amazon VPC CNI를 업데이트하기 전에 aws-node Daemonset 검사를 수행합니다. 기존 설정을 백업합니다. 관리형 추가 기능을 사용하는 경우 Amazon EKS가 재정의할 수 있는 설정을 업데이트하지 않았는지 확인합니다. 자동화 워크플로에서 사후 업데이트 후크를 사용하거나 추가 기능 업데이트 후 수동 적용 단계를 사용하는 것이 좋습니다.

kubectl apply view-last-applied daemonset aws-node -n kube-system  aws-k8s-cni-old.yaml

자체 관리형 추가 기능의 경우 releases GitHub의와 백업을 비교하여 사용 가능한 버전을 확인하고 업데이트하려는 버전의 변경 사항을 숙지합니다. Helm을 사용하여 자체 관리형 추가 기능을 관리하고 값 파일을 활용하여 설정을 적용하는 것이 좋습니다. Daemonset 삭제와 관련된 업데이트 작업은 애플리케이션 가동 중지를 초래하므로 피해야 합니다.

보안 컨텍스트 이해

VPC CNI를 효율적으로 관리하기 위해 구성된 보안 컨텍스트를 이해하는 것이 좋습니다. Amazon VPC CNI에는 두 가지 구성 요소인 CNI 바이너리와 ipamd(aws-node) Daemonset이 있습니다. CNI는 노드에서 바이너리로 실행되고 노드 루트 파일 시스템에 액세스할 수 있으며 노드 수준에서 iptable을 처리할 때 권한 있는 액세스 권한도 가집니다. 포드가 추가되거나 제거되면 kubelet에서 CNI 바이너리를 호출합니다.

aws-node Daemonset은 노드 수준에서 IP 주소 관리를 담당하는 장기 실행 프로세스입니다. aws-node는 hostNetwork 모드에서 실행되며 루프백 디바이스에 대한 액세스와 동일한 노드에 있는 다른 포드의 네트워크 활동을 허용합니다. aws-node init-container는 권한 있는 모드에서 실행되고 CRI 소켓을 탑재하여 Daemonset이 노드에서 실행되는 포드의 IP 사용량을 모니터링할 수 있도록 합니다. Amazon EKS는 aws-node init 컨테이너의 권한 있는 요구 사항을 제거하기 위해 노력하고 있습니다. 또한 aws-node는 NAT 항목을 업데이트하고 iptables 모듈을 로드해야 하므로 NET_ADMIN 권한으로 실행됩니다.

Amazon EKS는 포드 및 네트워킹 설정에 대한 IP 관리를 위해 aws-node 매니페스트에 정의된 보안 정책을 배포할 것을 권장합니다. 최신 버전의 VPC CNI로 업데이트하는 것이 좋습니다. 또한 특정 보안 요구 사항이 있는 경우 GitHub 문제를 여는 것이 좋습니다.

CNI에 별도의 IAM 역할 사용

AWS VPC CNI에는 AWS Identity and Access Management(IAM) 권한이 필요합니다. IAM 역할을 사용하려면 먼저 CNI 정책을 설정해야 합니다. IPv4 클러스터에 대한 AWS 관리형 정책AmazonEKS_CNI_Policy인를 사용할 수 있습니다. AmazonEKS CNI 관리형 정책에는 IPv4 클러스터에 대한 권한만 있습니다. 여기에 나열된 권한을 사용하여 IPv6 클러스터에 대한 별도의 IAM 정책을 생성해야 합니다.

기본적으로 VPC CNI는 Amazon EKS 노드 IAM 역할(관리형 노드 그룹과 자체 관리형 노드 그룹 모두)을 상속합니다.

Amazon VPC CNI에 대한 관련 정책을 사용하여 별도의 IAM 역할을 구성하는 것이 좋습니다. 그렇지 않은 경우 Amazon VPC CNI의 포드는 노드 IAM 역할에 할당된 권한을 얻고 노드에 할당된 인스턴스 프로파일에 액세스할 수 있습니다.

VPC CNI 플러그인은 aws-node라는 서비스 계정을 생성하고 구성합니다. 기본적으로 서비스 계정은 Amazon EKS CNI 정책이 연결된 Amazon EKS 노드 IAM 역할에 바인딩됩니다. 별도의 IAM 역할을 사용하려면 Amazon EKS CNI 정책이 연결된 새 서비스 계정을 생성하는 것이 좋습니다. 새 서비스 계정을 사용하려면 CNI 포드를 재배포해야 합니다. 새 클러스터를 생성할 때 VPC CNI 관리형 추가 기능에 --service-account-role-arn 대한를 지정하는 것이 좋습니다. Amazon EKS 노드 역할에서 IPv4 및 IPv6 모두에 대한 Amazon EKS CNI 정책을 제거해야 합니다.

보안 위반의 폭발 반경을 최소화하려면 액세스 인스턴스 메타데이터를 차단하는 것이 좋습니다.

Liveness/Readiness 프로브 실패 처리

애플리케이션의 포드가 containerCreating 상태에서 멈출 수 있도록 프로브 실패를 방지하려면 EKS 1.20 이상 클러스터의 수명 및 준비 프로브 제한 시간 값(기본값 timeoutSeconds: 10)을 늘리는 것이 좋습니다. 이 문제는 데이터 집약적 및 배치 처리 클러스터에서 발견되었습니다. CPU 사용량이 높으면 aws-node 프로브 상태가 실패하여 포드 CPU 요청이 채워지지 않습니다. 프로브 제한 시간을 수정하는 것 외에도 aws-node에 대한 CPU 리소스 요청(기본값 CPU: 25m)이 올바르게 구성되었는지 확인합니다. 노드에 문제가 없는 한 설정을 업데이트하지 않는 것이 좋습니다.

Amazon EKS 지원을 받는 동안 노드bash /opt/cni/bin/aws-cni-support.sh에서 sudo를 실행하는 것이 좋습니다. 스크립트는 노드에서 kubelet 로그 및 메모리 사용률을 평가하는 데 도움이 됩니다. 스크립트를 실행하려면 Amazon EKS 작업자 노드에 SSM 에이전트를 설치하는 것이 좋습니다.

비EKS 최적화 AMI 인스턴스에서 IPTables 전달 정책 구성

사용자 지정 AMI를 사용하는 경우 kubelet.service에서 iptables 전달 정책을 ACCEPT로 설정해야 합니다. 많은 시스템에서 iptables 전달 정책을 DROP로 설정합니다. HashiCorp Packer와 AWS GitHub의 Amazon EKS AMI 리포지토리에서 리소스 및 구성 스크립트를 사용하여 빌드 사양을 사용하여 사용자 지정 AMI를 빌드할 수 있습니다. kubelet.service를 업데이트하고 여기에 지정된 지침에 따라 사용자 지정 AMI를 생성할 수 있습니다.

CNI 버전을 정기적으로 업그레이드

VPC CNI는 이전 버전과 호환됩니다. 최신 버전은 Amazon EKS가 지원하는 모든 Kubernetes 버전에서 작동합니다. 또한 VPC CNI는 EKS 추가 기능으로 제공됩니다(위의 "VPC CNI 관리형 추가 기능 배포" 참조). EKS 추가 기능은 추가 기능의 업그레이드를 오케스트레이션하지만 데이터 영역에서 실행되므로 CNI와 같은 추가 기능을 자동으로 업그레이드하지 않습니다. 관리형 및 자체 관리형 작업자 노드 업그레이드 후 VPC CNI 추가 기능을 업그레이드하는 것은 사용자의 책임입니다.