VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구사항 보기

VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구사항 보기 (View Amazon EKS networking requirements for VPC and subnets)

클러스터를 만들 때 다른 가용 영역(AZ)에 있는 VPC와 최소 두 개의 서브넷을 지정해요. 이 주제는 클러스터와 함께 사용하는 VPC 및 서브넷에 대한 Amazon EKS 고유의 요구사항과 고려 사항을 개괄적으로 설명해요. Amazon EKS와 함께 사용할 VPC가 없다면 Amazon EKS 클러스터용 Amazon VPC 생성하기를 참고하세요. AWS Outposts에 로컬 또는 확장 클러스터를 만든다면 이 주제 대신 AWS Outposts의 Amazon EKS 클러스터용 VPC 및 서브넷 생성하기를 참고하세요. 이 주제의 내용은 하이브리드 노드가 있는 Amazon EKS 클러스터에도 적용돼요. 하이브리드 노드의 추가 네트워킹 요구사항은 하이브리드 노드용 네트워킹 준비하기를 참고하세요.

출처: 문서

본문

VPC 요구사항 및 고려 사항 (VPC requirements and considerations)

클러스터를 만들 때 지정하는 VPC는 다음 요구사항과 고려 사항을 충족해야 해요.

  • VPC에는 클러스터, 모든 노드, 만들려는 다른 Kubernetes 리소스에 충분한 IP 주소가 있어야 해요. 사용하려는 VPC에 IP 주소가 충분하지 않다면 사용 가능한 IP 주소 수를 늘려 보세요.

  • 클러스터 구성을 업데이트해 클러스터가 사용하는 서브넷과 보안 그룹을 변경하면 IP 주소 수를 늘릴 수 있어요. AWS Management Console, 최신 AWS CLI, AWS CloudFormation, eksctl 버전 v0.164.0-rc.0 이상에서 업데이트할 수 있어요. 클러스터 버전을 성공적으로 업그레이드하려면 더 많은 사용 가능한 IP 주소를 가진 서브넷을 제공해야 할 수도 있어요.

    중요

    추가하는 모든 서브넷은 클러스터 생성 시 원래 제공된 것과 동일한 AZ 집합에 있어야 해요. 새 서브넷은 충분한 IP 주소를 보유해야 하는 것 같은 다른 모든 요구사항을 충족해야 해요.

  • 예를 들어 클러스터를 만들고 4개의 서브넷을 지정했다고 가정해요. 지정한 순서에 따라 첫 번째 서브넷은 us-west-2a 가용 영역, 두 번째와 세 번째 서브넷은 us-west-2b 가용 영역, 네 번째 서브넷은 us-west-2c 가용 영역에 있어요. 서브넷을 변경하려면 세 가용 영역 각각에 최소 하나의 서브넷을 제공해야 하며, 서브넷은 원래 서브넷과 같은 VPC에 있어야 해요.

  • VPC의 CIDR 블록이 가진 것보다 더 많은 IP 주소가 필요하다면 VPC에 추가 CIDR(classless inter-domain routing) 블록을 연결해 추가할 수 있어요. 클러스터를 만들기 전이나 후에 프라이빗(RFC 1918) 및 공용(비-RFC 1918) CIDR 블록을 VPC에 연결할 수 있어요.

  • 새 CIDR 블록을 추가한 직후에 새 CIDR 블록을 사용하는 노드를 추가할 수 있어요. 하지만 컨트롤 플레인은 조정(reconciliation)이 완료된 후에만 새 CIDR 블록을 인식하므로, VPC에 연결한 CIDR 블록이 인식되는 데 클러스터에 따라 최대 1시간이 걸릴 수 있어요. 그런 다음 새 CIDR 블록의 노드와 Pod에 대해 kubectl attach, kubectl cp, kubectl exec, kubectl logs, kubectl port-forward 명령(이 명령들은 kubelet API를 사용함)을 실행할 수 있어요. 또한 웹훅 백엔드로 작동하는 Pod가 있다면 컨트롤 플레인 조정이 완료될 때까지 기다려야 해요.

  • Transit Gateway, VPC 피어링 또는 다른 네트워킹 구성으로 EKS 클러스터를 다른 VPC에 연결할 때 IP 주소 범위가 겹치지 않도록 하세요. EKS 클러스터의 서비스 CIDR이 연결된 VPC의 CIDR과 겹치면 CIDR 충돌이 발생해요. 이러한 시나리오에서 서비스 IP 주소는 같은 IP 주소를 가진 연결된 VPC의 리소스보다 우선하지만, 트래픽 라우팅이 예측 불가능해지고 애플리케이션이 의도한 리소스에 연결하지 못할 수 있어요.

  • CIDR 충돌을 피하려면 EKS 서비스 CIDR이 연결된 VPC CIDR과 겹치지 않도록 하고 모든 CIDR 할당의 중앙 기록을 유지하세요. CIDR이 겹치면 공유 서비스 VPC와 함께 transit gateway를 사용할 수 있어요. 자세한 내용은 하이브리드 네트워크의 공유 서비스가 있는 격리된 VPC 및 Amazon EKS VPC 라우팅 가능 IP 주소 보존 패턴을 참고하세요. 또한 EKS 모범 사례 가이드의 VPC 및 서브넷 고려 사항 페이지에서 Communication across VPCs(VPC 간 통신) 섹션을 참고하세요.

  • Kubernetes가 Pod와 서비스에 IPv6 주소를 할당하도록 하려면 VPC에 IPv6 CIDR 블록을 연결하세요. 자세한 내용은 Amazon VPC 사용 설명서의 VPC에 IPv6 CIDR 블록 연결하기를 참고하세요. 하이브리드 노드에서 실행되는 Pod 및 서비스에는 IPv6 주소를 사용할 수 없으며, IPv6 IP 주소 패밀리로 구성된 클러스터에는 하이브리드 노드를 사용할 수 없어요.

  • VPC에는 DNS 호스트 이름 및 DNS 해석 지원이 있어야 해요. 그렇지 않으면 노드가 클러스터에 등록할 수 없어요. 자세한 내용은 Amazon VPC 사용 설명서의 VPC용 DNS 속성을 참고하세요.

  • VPC는 AWS PrivateLink를 사용하는 VPC 엔드포인트가 필요할 수 있어요. 자세한 내용은 서브넷 요구사항 및 고려 사항을 참고하세요.

  • 클러스터가 고객 라우팅 컨트롤 플레인 이그레스(controlPlaneEgressMode=CUSTOMER_ROUTED)를 사용한다면 클러스터가 사용하는 서브넷은 컨트롤 플레인이 호출하는 모든 엔드포인트(예: admission webhook 서버와 OIDC 프로바이더)로 라우팅할 수 있어야 해요. 이는 이그레스 경로(예: NAT 게이트웨이, NAT 인스턴스, 방화벽, 또는 중앙 이그레스 VPC로 가는 transit gateway)와 트래픽을 허용하는 라우팅 테이블, 보안 그룹, 네트워크 ACL 규칙이 필요해요. 자세한 내용은 컨트롤 플레인 이그레스 라우팅 구성하기를 참고하세요.

  • Kubernetes 1.14 이하로 클러스터를 만들었다면 Amazon EKS가 VPC에 다음 태그를 추가했어요.

    키 값
    kubernetes.io/cluster/my-cluster owned

    이 태그는 Amazon EKS만 사용했어요. 서비스에 영향을 주지 않고 태그를 제거할 수 있어요. 버전 1.15 이상의 클러스터에서는 사용되지 않아요.

서브넷 요구사항 및 고려 사항 (Subnet requirements and considerations)

클러스터를 만들 때 Amazon EKS는 지정한 서브넷에 2~4개의 탄력적 네트워크 인터페이스를 만들어요. 이 네트워크 인터페이스는 클러스터와 VPC 사이의 통신을 활성화해요. 또한 kubelet API를 사용하는 Kubernetes 기능도 활성화해요. kubelet API에 대한 연결은 kubectl attach, kubectl cp, kubectl exec, kubectl logs, kubectl port-forward 명령에 사용돼요. Amazon EKS가 만든 각 네트워크 인터페이스의 설명에는 Amazon EKS cluster-name 텍스트가 있어요.

이러한 requester-managed 네트워크 인터페이스는 컨트롤 플레인과 워커 노드 사이의 데이터 플레인 트래픽도 전달해요. Amazon EKS는 이 네트워크 인터페이스의 컨트롤 플레인 쪽 데이터 전송 비용을 흡수해요. 고객 쪽 트래픽(구체적으로 컨트롤 플레인에서 워커 노드로의 인그레스와 워커 노드에서 컨트롤 플레인으로의 이그레스)에는 표준 AWS 데이터 전송 요율이 청구돼요. 자세한 내용은 Amazon EKS 가격 책정을 참고하세요.

Amazon EKS는 클러스터를 만들 때 지정한 모든 서브넷에 네트워크 인터페이스를 만들 수 있어요. 클러스터를 만든 후 Amazon EKS가 네트워크 인터페이스를 만드는 서브넷을 변경할 수 있어요. 클러스터의 Kubernetes 버전을 업데이트하면 Amazon EKS가 원래 만든 네트워크 인터페이스를 삭제하고 새 네트워크 인터페이스를 만들어요. 이 네트워크 인터페이스는 원래 네트워크 인터페이스와 같은 서브넷이나 다른 서브넷에 만들어질 수 있어요. 네트워크 인터페이스가 만들어지는 서브넷을 제어하려면 클러스터를 만들 때 지정하는 서브넷 수를 두 개로만 제한하거나, 클러스터를 만든 후 서브넷을 업데이트할 수 있어요.

클러스터에 대한 서브넷 요구사항

클러스터를 만들거나 업데이트할 때 지정하는 서브넷은 다음 요구사항을 충족해야 해요.

  • 각 서브넷에는 Amazon EKS가 사용할 IP 주소가 최소 6개 있어야 해요. 하지만 최소 16개 IP 주소를 권장해요.

  • 서브넷은 최소 두 개의 서로 다른 가용 영역에 있어야 해요.

  • 서브넷은 AWS Outposts나 AWS Wavelength에 있을 수 없어요. 하지만 VPC에 있다면 이러한 유형의 서브넷에 자체 관리형 노드와 Kubernetes 리소스를 배포할 수 있어요. 자체 관리형 노드에 대한 자세한 내용은 자체 관리형 노드로 노드를 직접 유지하기를 참고하세요.

  • 서브넷은 공용 또는 프라이빗일 수 있어요. 하지만 가능하면 프라이빗 서브넷을 지정하는 것을 권장해요. 공용 서브넷은 인터넷 게이트웨이로 가는 경로가 포함된 라우팅 테이블을 가진 서브넷인 반면, 프라이빗 서브넷은 인터넷 게이트웨이로 가는 경로가 포함되지 않은 라우팅 테이블을 가진 서브넷이에요.

  • 서브넷은 다음 가용 영역에 있을 수 없어요.

    AWS 리전 리전 이름 허용되지 않는 가용 영역 ID
    us-east-1 미국 동부(버지니아 북부) use1-az3
    us-west-1 미국 서부(캘리포니아 북부) usw1-az2
    ca-central-1 캐나다(중부) cac1-az3

컴포넌트별 IP 주소 패밀리 사용 (IP address family usage by component)

다음 표는 Amazon EKS의 각 컴포넌트가 사용하는 IP 주소 패밀리를 포함해요. NAT(네트워크 주소 변환) 또는 다른 호환성 시스템을 사용해 표 항목에 "No" 값이 있는 패밀리의 소스 IP 주소에서 이러한 컴포넌트에 연결할 수 있어요.

기능은 클러스터의 IP 패밀리(ipFamily) 설정에 따라 달라질 수 있어요. 이 설정은 Kubernetes가 Service에 할당하는 CIDR 블록에 사용되는 IP 주소 유형을 변경해요. 설정 값이 IPv4인 클러스터를 IPv4 클러스터, 설정 값이 IPv6인 클러스터를 IPv6 클러스터라고 해요.

컴포넌트 IPv4 주소 IPv6 주소 Dual stack 주소
EKS API 공용 엔드포인트 Yes1,3 Yes1,3 Yes1,3
EKS API VPC 엔드포인트 Yes No No
EKS Auth API 공용 엔드포인트(EKS Pod Identity) Yes1 Yes1 Yes1
EKS Auth API VPC 엔드포인트(EKS Pod Identity) Yes1 Yes1 Yes1
IPv4 Kubernetes 클러스터 공용 엔드포인트2 Yes No No
IPv4 Kubernetes 클러스터 프라이빗 엔드포인트2 Yes No No
IPv6 Kubernetes 클러스터 공용 엔드포인트2 Yes1,4 Yes1,4 Yes4
IPv6 Kubernetes 클러스터 프라이빗 엔드포인트2 Yes1,4 Yes1,4 Yes4
Kubernetes 클러스터 서브넷 Yes2 No Yes2
노드 기본 IP 주소 Yes2 No Yes2
서비스 IP 주소용 클러스터 CIDR 범위 Yes2 Yes2 No
VPC CNI의 Pod IP 주소 Yes2 Yes2 No
IRSA OIDC 발급자 URL Yes1,3 Yes1,3 Yes1,3

참고

  1. 엔드포인트는 IPv4 및 IPv6 주소가 모두 있는 듀얼 스택이에요. AWS 외부의 애플리케이션, 클러스터의 노드, 클러스터 내부의 Pod는 IPv4 또는 IPv6로 이 엔드포인트에 도달할 수 있어요.
  2. 클러스터를 만들 때 클러스터의 IP 패밀리(ipFamily) 설정에서 IPv4 클러스터와 IPv6 클러스터 중 하나를 선택하며, 이는 변경할 수 없어요. 대신 다른 클러스터를 만들 때 다른 설정을 선택하고 워크로드를 마이그레이션해야 해요.
  3. 듀얼 스택 엔드포인트는 2024년 8월에 도입됐어요. AWS CLI에서 듀얼 스택 엔드포인트를 사용하려면 AWS SDKs and Tools Reference Guide의 Dual-stack and FIPS endpoints 구성을 참고하세요. 다음은 새 엔드포인트 목록이에요.
    • EKS API 공용 엔드포인트: eks.region.api.aws
    • IRSA OIDC 발급자 URL: oidc-eks.region.api.aws
  4. 듀얼 스택 클러스터 엔드포인트는 2024년 10월에 도입됐어요. EKS는 이 날짜 이후에 만들어지고 클러스터의 IP 패밀리(ipFamily) 설정에서 IPv6를 선택한 새 클러스터에 대해 다음 엔드포인트를 만들어요.
    • EKS 클러스터 공용/프라이빗 엔드포인트: eks-cluster.region.api.aws

노드에 대한 서브넷 요구사항 (Subnet requirements for nodes)

클러스터를 만들 때 지정한 동일한 서브넷에 노드와 Kubernetes 리소스를 배포할 수 있어요. 하지만 이는 필수가 아니에요. 클러스터를 만들 때 지정하지 않은 서브넷에도 노드와 Kubernetes 리소스를 배포할 수 있기 때문이에요. 노드를 다른 서브넷에 배포하면 Amazon EKS는 해당 서브넷에 클러스터 네트워크 인터페이스를 만들지 않아요. 노드와 Kubernetes 리소스를 배포하는 모든 서브넷은 다음 요구사항을 충족해야 해요.

  • 서브넷에는 모든 노드와 Kubernetes 리소스를 배포할 수 있을 만큼 충분한 사용 가능한 IP 주소가 있어야 해요.

  • Kubernetes가 Pod와 서비스에 IPv6 주소를 할당하도록 하려면 서브넷에 연결된 IPv6 CIDR 블록과 IPv4 CIDR 블록이 하나씩 있어야 해요. 자세한 내용은 Amazon VPC 사용 설명서의 서브넷에 IPv6 CIDR 블록 연결하기를 참고하세요. 서브넷과 연결된 라우팅 테이블에는 IPv4 및 IPv6 주소에 대한 경로가 포함되어야 해요. 자세한 내용은 Amazon VPC 사용 설명서의 라우트를 참고하세요. Pod에는 IPv6 주소만 할당돼요. 하지만 Amazon EKS가 클러스터와 노드에 대해 만드는 네트워크 인터페이스에는 IPv4 및 IPv6 주소가 모두 할당돼요.

  • 인터넷에서 Pod로의 인바운드 접근이 필요하다면 로드 밸런서와 인그레스를 배포할 충분한 사용 가능한 IP 주소가 있는 공용 서브넷이 최소 하나 있어야 해요. 로드 밸런서를 공용 서브넷에 배포할 수 있어요. 로드 밸런서는 프라이빗 또는 공용 서브넷의 Pod로 로드 밸런싱할 수 있어요. 가능하면 노드를 프라이빗 서브넷에 배포하는 것을 권장해요.

  • 노드를 공용 서브넷에 배포할 계획이라면 서브넷이 IPv4 공용 주소 또는 IPv6 주소를 자동 할당해야 해요. 연결된 IPv6 CIDR 블록이 있는 프라이빗 서브넷에 노드를 배포한다면 프라이빗 서브넷도 IPv6 주소를 자동 할당해야 해요. 2020년 3월 26일 이후 Amazon EKS가 제공한 AWS CloudFormation 템플릿으로 VPC를 배포했다면 이 설정이 활성화돼 있어요. 이 날짜 이전에 템플릿으로 VPC를 배포했거나 자체 VPC를 사용한다면 이 설정을 수동으로 활성화해야 해요. 템플릿은 Amazon EKS 클러스터용 Amazon VPC 생성하기를, 자세한 내용은 Amazon VPC 사용 설명서의 서브넷의 공용 IPv4 주소 지정 속성 수정하기 및 서브넷의 IPv6 주소 지정 속성 수정하기를 참고하세요.

  • 노드를 배포하는 서브넷이 프라이빗 서브넷이고 그 라우팅 테이블에 NAT 장치(IPv4) 또는 egress-only 게이트웨이(IPv6)로 가는 경로가 없다면 AWS PrivateLink를 사용하는 VPC 엔드포인트를 VPC에 추가하세요. 노드와 Pod는 통신하는 모든 AWS 서비스에 대해 VPC 엔드포인트가 필요해요. 예로는 Amazon ECR, Elastic Load Balancing, Amazon CloudWatch, AWS Security Token Service, Amazon S3(Simple Storage Service)가 있어요. 서비스 계정용 IAM 역할(IRSA)을 사용한다면 com.amazonaws.region-code.oidc-eks 엔드포인트로 클러스터 OIDC discovery/JWKS 엔드포인트에 프라이빗으로 접근할 수도 있어요. 자세한 내용은 AWS PrivateLink로 클러스터 OIDC 엔드포인트 접근하기를 참고하세요. 모든 AWS 서비스가 VPC 엔드포인트를 지원하는 것은 아니에요. 자세한 내용은 AWS PrivateLink란 무엇인가요? 및 AWS PrivateLink와 통합되는 AWS 서비스를 참고하세요. 더 많은 Amazon EKS 요구사항 목록은 제한된 인터넷 접근으로 프라이빗 클러스터 배포하기를 참고하세요.

  • 서브넷에 로드 밸런서를 배포하려면 서브넷에 다음 태그가 있어야 해요.

    프라이빗 서브넷: | 키 | 값 | |---|---| | kubernetes.io/role/internal-elb | 1 |

    공용 서브넷: | 키 | 값 | |---|---| | kubernetes.io/role/elb | 1 |

  • 버전 1.18 이하의 Kubernetes 클러스터를 만들었을 때 Amazon EKS는 지정된 모든 서브넷에 다음 태그를 추가했어요.

    키 값
    kubernetes.io/cluster/my-cluster shared

    지금 새 Kubernetes 클러스터를 만들면 Amazon EKS는 서브넷에 태그를 추가하지 않아요. 이전에 1.19보다 이전 버전이었던 클러스터가 사용했던 서브넷에 태그가 있었다면 클러스터가 더 새로운 버전으로 업데이트될 때 태그가 서브넷에서 자동으로 제거되지는 않았어요. AWS Load Balancer Controller 버전 2.1.1 이하는 이 태그가 필요해요. 더 새로운 버전의 Load Balancer Controller를 사용한다면 서비스에 영향을 주지 않고 태그를 제거할 수 있어요. 컨트롤러에 대한 자세한 내용은 AWS Load Balancer Controller로 인터넷 트래픽 라우팅하기를 참고하세요.

  • eksctl 또는 Amazon EKS AWS CloudFormation VPC 템플릿 중 하나로 VPC를 배포했다면 다음이 적용돼요.

    • 2020년 3월 26일 이후 – 공용 서브넷에 배포된 새 노드에는 공용 서브넷이 공용 IPv4 주소를 자동 할당해요.
    • 2020년 3월 26일 이전 – 공용 서브넷에 배포된 새 노드에는 공용 서브넷이 공용 IPv4 주소를 자동 할당하지 않아요.

  • 이 변경은 공용 서브넷에 배포된 새 노드 그룹에 다음과 같은 방식으로 영향을 미쳐요.

    • 관리형 노드 그룹 – 노드 그룹이 2020년 4월 22일 이후에 공용 서브넷에 배포된 경우 공용 서브넷에 대한 공용 IP 주소 자동 할당이 활성화되어야 해요. 자세한 내용은 서브넷의 공용 IPv4 주소 지정 속성 수정하기를 참고하세요.
    • Linux, Windows 또는 Arm 자체 관리형 노드 그룹 – 노드 그룹이 2020년 3월 26일 이후에 공용 서브넷에 배포된 경우 공용 서브넷에 대한 공용 IP 주소 자동 할당이 활성화되어야 해요. 그렇지 않으면 노드를 공용 IP 주소로 시작해야 해요. 자세한 내용은 서브넷의 공용 IPv4 주소 지정 속성 수정하기 또는 인스턴스 시작 중 공용 IPv4 주소 할당하기를 참고하세요.

공유 서브넷 요구사항 및 고려 사항 (Shared subnet requirements and considerations)

VPC 공유를 사용해 같은 AWS Organizations 내의 다른 AWS 계정과 서브넷을 공유할 수 있어요. 다음 고려 사항과 함께 공유 서브넷에서 Amazon EKS 클러스터를 만들 수 있어요.

  • VPC 서브넷의 소유자는 참여 계정이 서브넷에서 Amazon EKS 클러스터를 만들기 전에 해당 계정과 서브넷을 공유해야 해요.
  • VPC의 기본 보안 그룹은 소유자 소유이므로 이를 사용해 리소스를 시작할 수 없어요. 또한 참여자는 다른 참여자나 소유자가 소유한 보안 그룹을 사용해 리소스를 시작할 수 없어요.
  • 공유 서브넷에서 참여자와 소유자는 각각의 계정 내 보안 그룹을 별도로 제어해요. 서브넷 소유자는 참여자가 만든 보안 그룹을 볼 수 있지만 이에 대한 작업을 수행할 수 없어요. 서브넷 소유자가 이러한 보안 그룹을 제거하거나 수정하려면 보안 그룹을 만든 참여자가 작업을 수행해야 해요.
  • 참여자가 클러스터를 만들면 다음 고려 사항이 적용돼요.
    • 클러스터 IAM 역할과 노드 IAM 역할은 해당 계정에서 만들어야 해요. 자세한 내용은 Amazon EKS 클러스터 IAM 역할 및 Amazon EKS 노드 IAM 역할을 참고하세요.
    • 관리형 노드 그룹을 포함해 모든 노드는 같은 참여자가 만들어야 해요.
    • 공유 VPC 소유자는 참여자가 공유 서브넷에 만든 클러스터를 보거나 업데이트하거나 삭제할 수 없어요. 이는 각 계정이 다른 접근 권한을 가진 VPC 리소스에 추가되는 사항이에요. 자세한 내용은 Amazon VPC 사용 설명서의 소유자 및 참여자에 대한 책임과 권한을 참고하세요.
    • Kubernetes용 Amazon VPC CNI 플러그인의 커스텀 네트워킹 기능을 사용한다면 각 ENIConfig를 만들 때 소유자 계정에 나열된 가용 영역 ID 매핑을 사용해야 해요. 자세한 내용은 커스텀 네트워킹으로 대체 서브넷에 Pod 배포하기를 참고하세요.

VPC 서브넷 공유에 대한 자세한 내용은 Amazon VPC 사용 설명서의 VPC를 다른 계정과 공유하기를 참고하세요.

더 알아보기 (Learn more)