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

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

네트워킹 모범 사례

클러스터와 애플리케이션을 효율적으로 운영하려면 Kubernetes 네트워킹을 이해하는 것이 중요합니다. 클러스터 네트워킹이라고도 하는 포드 네트워킹은 Kubernetes 네트워킹의 중심입니다. Kubernetes는 클러스터 네트워킹을 위한 컨테이너 네트워크 인터페이스(CNI) 플러그인을 지원합니다.

Amazon EKS는 Kubernetes 포드 네트워킹을 구현하기 위해 Amazon Virtual Private Cloud(VPC) CNI 플러그인을 공식적으로 지원합니다. VPC CNI는 AWS VPC와의 기본 통합을 제공하며 언더레이 모드에서 작동합니다. 언더레이 모드에서 포드와 호스트는 동일한 네트워크 계층에 위치하고 네트워크 네임스페이스를 공유합니다. 포드의 IP 주소는 클러스터 및 VPC 관점에서 일관됩니다.

이 가이드에서는 Kubernetes 클러스터 네트워킹의 맥락에서 Amazon VPC 컨테이너 네트워크 인터페이스(VPC CNI)를 소개합니다. VPC CNI는 EKS에서 지원하는 기본 네트워킹 플러그인이므로 가이드의 핵심입니다. VPC CNI는 다양한 사용 사례를 지원하도록 고도로 구성할 수 있습니다. 이 가이드에는 다양한 VPC CNI 사용 사례, 운영 모드, 하위 구성 요소에 대한 전용 섹션과 권장 사항이 추가로 포함되어 있습니다.

Amazon EKS는 업스트림 Kubernetes를 실행하며 Kubernetes 준수 인증을 받았습니다. 대체 CNI 플러그인을 사용할 수 있지만이 가이드에서는 대체 CNIs를 관리하기 위한 권장 사항을 제공하지 않습니다. 대체 CNI를 효과적으로 관리하기 위한 파트너 및 리소스 목록은 EKS 대체 CNIs 설명서를 참조하십시오.

Kubernetes 네트워킹 모델

Kubernetes는 클러스터 네트워킹에 대해 다음과 같은 요구 사항을 설정합니다.

호환되는 네트워킹 구현에서 Kubernetes가 기대하는 사항에 대한 자세한 내용은 Kubernetes 네트워크 모델을 참조하세요. 다음 그림은 포드 네트워크 네임스페이스와 호스트 네트워크 네임스페이스 간의 관계를 보여줍니다.

컨테이너 네트워킹 인터페이스(CNI)

Kubernetes는 Kubernetes 네트워크 모델을 구현하기 위한 CNI 사양 및 플러그인을 지원합니다. CNI는 지원되는 여러 플러그인과 함께 플러그인을 작성하여 컨테이너의 네트워크 인터페이스를 구성하기 위한 사양(최신 버전 1.0.0) 및 라이브러리로 구성됩니다. CNI는 컨테이너의 네트워크 연결과 컨테이너가 삭제될 때 할당된 리소스 제거에만 관여합니다.

CNI 플러그인은 kubelet에 --network-plugin=cni 명령줄 옵션을 전달하여 활성화됩니다. Kubelet은 --cni-conf-dir (기본 /etc/cni/net.d)에서 파일을 읽고 해당 파일의 CNI 구성을 사용하여 각 포드의 네트워크를 설정합니다. CNI 구성 파일은 CNI 사양(최소 v0.4.0)과 일치해야 하며 구성에서 참조하는 필수 CNI 플러그인이 --cni-bin-dir 디렉터리(기본값 /opt/cni/bin)에 있어야 합니다. 디렉터리에 CNI 구성 파일이 여러 개 있는 경우 kubelet은 이름별로 가장 먼저 어휘 순서로 표시되는 구성 파일을 사용합니다.

Amazon Virtual Private Cloud(VPC) CNI

AWS에서 제공하는 VPC CNI는 EKS 클러스터의 기본 네트워킹 추가 기능입니다. VPC CNI 추가 기능은 EKS 클러스터를 프로비저닝할 때 기본적으로 설치됩니다. VPC CNI는 Kubernetes 작업자 노드에서 실행됩니다. VPC CNI 추가 기능은 CNI 바이너리와 IP 주소 관리(ipamd) 플러그인으로 구성됩니다. CNI는 VPC 네트워크의 IP 주소를 포드에 할당합니다. ipamd는 각 Kubernetes 노드에 대한 AWS 탄력적 네트워킹 인터페이스(ENIs)를 관리하고 IPs의 웜 풀을 유지합니다. VPC CNI는 빠른 포드 시작 시간을 위해 ENIs 및 IP 주소의 사전 할당을 위한 구성 옵션을 제공합니다. 권장 플러그인 관리 모범 사례는 Amazon VPC CNI를 참조하세요.

Amazon EKS에서는 클러스터를 생성할 때 두 개 이상의 가용 영역에 서브넷을 지정하는 것이 좋습니다. Amazon VPC CNI는 노드 서브넷의 포드에 IP 주소를 할당합니다. 서브넷에서 사용 가능한 IP 주소를 확인하는 것이 좋습니다. EKS 클러스터를 배포하기 전에 VPC 및 서브넷 권장 사항을 고려하세요.

Amazon VPC CNI는 노드의 기본 ENIs에 연결된 서브넷에서 ENI 및 보조 IP 주소의 웜 풀을 할당합니다. VPC CNI의이 모드를 보조 IP 모드라고 합니다. IP 주소 수와 따라서 포드 수(Pod 밀도)는 인스턴스 유형에 의해 정의된 ENIs 수와 ENI당 IP 주소(제한)로 정의됩니다. 보조 모드는 기본값이며 인스턴스 유형이 작은 소규모 클러스터에 적합합니다. 포드 밀도 문제가 발생하는 경우 접두사 모드를 사용하는 것이 좋습니다. ENIs.

Amazon VPC CNI는 기본적으로 AWS VPC와 통합되며, 이를 통해 사용자는 Kubernetes 클러스터 구축을 위한 기존 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있습니다. 여기에는 네트워크 트래픽 격리를 위해 VPC 흐름 로그, VPC 라우팅 정책 및 보안 그룹을 사용하는 기능이 포함됩니다. 기본적으로 Amazon VPC CNI는 노드의 기본 ENI와 연결된 보안 그룹을 포드에 적용합니다. 포드에 다른 네트워크 규칙을 할당하려는 경우 포드에 대한 보안 그룹을 활성화하는 것이 좋습니다.

기본적으로 VPC CNI는 노드의 기본 ENI에 할당된 서브넷의 포드에 IP 주소를 할당합니다. 수천 개의 워크로드가 있는 대규모 클러스터를 실행할 때 IPv4 주소가 부족한 것이 일반적입니다. AWS VPC를 사용하면 보조 CIDRs을 할당하여 IPv4 CIDR 블록의 소진을 해결하여 사용 가능한 IPs를 확장할 수 있습니다. AWS VPC CNI를 사용하면 포드에 다른 서브넷 CIDR 범위를 사용할 수 있습니다. VPC CNI의이 기능을 사용자 지정 네트워킹이라고 합니다. 사용자 지정 네트워킹을 사용하여 EKS에서 100.64.0.0/10 및 198.19.0.0/16 CIDRs(CG-NAT)을 사용하는 것을 고려할 수 있습니다. 이렇게 하면 포드가 더 이상 VPC의 RFC1918 IP 주소를 사용하지 않는 환경을 효과적으로 생성할 수 있습니다.

사용자 지정 네트워킹은 IPv4 주소 소진 문제를 해결하는 한 가지 옵션이지만 운영 오버헤드가 필요합니다. 이 문제를 해결하려면 사용자 지정 네트워킹보다 IPv6 클러스터를 사용하는 것이 좋습니다. 특히 VPC에 사용 가능한 IPv4 주소 공간이 모두 소진된 경우 IPvIPv6 클러스터로 마이그레이션하는 것이 좋습니다. IPv6를 지원하려는 조직의 계획을 평가하고 IPv6에 대한 투자가 장기적인 가치가 더 높을 수 있는지 고려합니다.

EKS의 IPv6 지원은 제한된 IPv4 주소 공간으로 인한 IP 소진 문제를 해결하는 데 중점을 둡니다. IPv4 소진과 관련된 고객 문제에 대응하여 EKS는 듀얼 스택 포드보다 IPv6-only 포드의 우선 순위를 지정했습니다. 즉, 포드는 IPv4 리소스에 액세스할 수 있지만 VPC CIDR 범위에서 IPv4 주소가 할당되지 않습니다. VPC CNI는 AWS 관리형 VPC IPv6 CIDR 블록의 포드에 IPv6 주소를 할당합니다.

서브넷 계산기

이 프로젝트에는 서브넷 계산기 Excel 문서가 포함되어 있습니다. 이 계산기 문서는 WARM_IP_TARGET 및와 같은 다양한 ENI 구성 옵션에서 지정된 워크로드의 IP 주소 소비를 시뮬레이션합니다WARM_ENI_TARGET. 문서에는 두 개의 시트가 포함되어 있습니다. 하나는 웜 ENI 모드용이고 다른 하나는 웜 IP 모드용입니다. 이러한 모드에 대한 자세한 내용은 VPC CNI 지침을 검토하세요.

입력:

출력: