Amazon EKS에서 IPv6로의 여정 : Foundation (Part 1)

이 글은 AWS Containers Blog에 게시된 The Journey to IPv6 on Amazon EKS: Foundation (Part 1) by Srinivas Jasti 를 한국어번역 및 편집하였습니다.

서론

디지털 환경이 지속적으로 발전함에 따라, 서비스의 성장과 미래에 보장할 수 있는 인프라를 대비하기 위해서는 Kubernetes 네트워킹을 확장하는 것이 핵심입니다. 각 Pod 마다 고유 IP 주소를 필요로 하는 것은 제한된 IPv4 주소의 고갈 문제와 직면합니다. 사용 가능한 IPv4 주소의 한정된 풀로 인해 Kubernetes 클러스터 관리자는 NAT(Network Address Translation) 또는 오버레이 네트워킹과 같은 대안을 마련해야 하는 경우가 많습니다. 이러한 방안은 종종 성능 병목 현상을 일으키고 관리 오버헤드를 증가시킵니다. IPv6 주소 공간을 사용하는 것은 대규모 Kubernetes 클러스터를 관리하는 보다 우아한 방법입니다. IPv6는 클러스터 관리자들이 IPv4 고갈 문제를 해결하는 데 노력을 들이지 않고도 애플리케이션을 확장할 수 있도록 훨씬 더 큰 IP 주소 전체 공간을 제공합니다.

점점 더 많은 조직이 워크로드를 컨테이너화함에 따라 IPv6 채택을 고려하고 있습니다. 이는 Public IPv4 주소 고갈 이 주요 원인으로 인식되는 경우가 많습니다만, 실제 고객 중 일부와 대화해 본 결과 제한된 IPv4 Private IP 공간(즉, RFC1918)이 주요 동인이라는 것을 알게 되었습니다.

도전

IPv6를 채택하면 네트워크 구성을 간소화하고 대규모로 운영할 수 있습니다. 그러나 많은 EKS를 사용하는 고객분들은 여전히 IPv6 도입까지의 여정을 복잡하게 보고 있습니다. 그들 중 일부와 인터뷰를 진행하면서 우리는 두 가지 주요 우려 사항에 대해 알게 되었습니다.

AWS 네트워킹 서비스에 대한 IPv6 지원
Amazon Elastic Kubernetes Service (Amazon EKS) IPv6 및 IPv4 상호운용 (하이브리드 모드)

이번 블로그에서는 고객이 Amazon EKS 클러스터를 IPv6 주소 패밀리로 마이그레이션하는 데 도움이 되는 아키텍처를 참조하여 주요 우려 사항을 명확하게 설명하고 지침을 제공하려고 합니다. 이 시리즈에서는 AWS의 IPv6 에 대해 깊이 다루지 않기 때문에, AWS의 IPv6에 대한 전체적인 관점(예: 계획, 아키텍처, AWS 서비스)을 보고 싶으시다면 이 백서를 읽어보시기 바랍니다: IPv6 on AWS. 이번 Part 1에서는IPv6 기반으로 구축된 Amazon EKS에 대해 중점적으로 살펴보겠습니다.

Kubernetes와 IPv6

업스트림 Kubernetes의 IPv6 접근 방식은 Pod 및 Service에 대한 듀얼 스택 네트워킹입니다.
기본적으로, 각 Pod와 Service에 라우팅 가능한 IPv4 및 IPv6 주소를 모두 할당받을 수 있습니다. 이를 듀얼 스택 Pod 및 Service라고 합니다.

이 접근 방식의 주요 이점은 NAT64 또는 DNS64와 같은 구성에 대한 종속성이나, 호환을 위한 추가 레이어를 거칠 필요 없이 Pod가 IPv4 또는 IPv6 엔드포인트에 연결할 수 있다는 것입니다.

결과적으로, 이 듀얼 스택 접근 방식은 각 Pod가 듀얼 스택 서브넷 아래에 있는 연관된 Amazon Virtual Private Cloud(Amazon VPC) 에서 유효한 IPv6 및 Private IPv4 주소를 사용한다는 것을 의미합니다.
본질적으로, 이는 우리가 다시 제자리로 돌아가 Private IPv4 고갈 및 네트워크 중첩 문제에 직면하게 됨을 의미합니다.

Amazon EKS는 IPv6를 지원하기 위해 다른 접근 방식을 취했으며 아직 업스트림 Kubernetes 듀얼 스택 접근 방식을 지원하지 않습니다.

Amazon EKS와 IPv6

Amazon EKS 팀은 고객의 요구 사항을 바탕으로 다음 5가지 원칙을 준수하는 Amazon EKS IPv6 기반 클러스터를 지원하는 독창적인 메커니즘을 구축했습니다.

클러스터 내 Pod에서 Pod/Service로의 IPv6 네이티브 통신을 허용합니다.
IPv6 Pod가 NAT64/DNS64의 오버헤드 없이 IPv4 엔드포인트(교차 클러스터/VPC, 인터넷, VPC 내부, 리전 내부)에 원활하게 연결할 수 있도록 합니다.
IPv6 Pod가 IPv4 엔드포인트에 연결할 때, 기본 VPC 서브넷에서 라우팅 가능한 Private IPv4 주소를 소비하지 않아, Private IPv4 주소 공간 고갈 문제를 완화합니다.
IPv4 Amazon EKS 클러스터가 Amazon EKS IPv6 클러스터와 공존할 수 있도록 합니다. 따라서 IPv4 Amazon EKS 클러스터의 Pod는 IPv4 – IPv6 외부 구성 없이도 IPv6 Amazon EKS 클러스터의 Pod에 원활하게 연결할 수 있습니다.
IPv4 및 IPv6 엔드포인트가 로드 밸런스된 Amazon EKS IPv6 Pod에 연결할 수 있도록 하여, IPv4에서 IPv6으로의 원활한 수신을 가능하게 합니다.

위의 원칙들은 Amazon VPC 듀얼 스택 기반과 긴밀하게 통합되는 Amazon VPC CNI 플러그인을 사용하여, IPv6 모드에서 EKS 클러스터를 배포함으로써 구현됩니다. 수신 연결의 경우(예. 원칙 5), Amazon EKS 로드 밸런서 컨트롤러(LBC)가 사용되어 서비스/수신 관련 주석을 사용하며, 이로 인해 듀얼 스택 Network Load Balancer(NLB) 또는 Application Load Balancer(ALB)가 생성됩니다.

이제 그 원칙에 기반한 실제 아키텍처를 자세히 살펴보겠습니다.

솔루션 개요

1단계 : 기초

AWS에는 Elastic network interfaces (ENI)가 작동할 수 있는 세 가지 알려진 네트워킹 IP 모드가 있습니다: IPv4 전용, IPv6 전용 및 듀얼 스택. 먼저 듀얼 스택 VPC를 생성해야 합니다. 듀얼 스택 모드에서는 리소스가 IPv4와 IPv6 모두를 통해 통신할 수 있습니다. 별도의 상호 운용성 레이어가 필요하지 않습니다.

IPv6 기반 Amazon EKS 클러스터는 듀얼 스택 VPC 기반만 지원합니다. 듀얼 스택 VPC 모드에서 VPC-CNI는 상호 운용성 레이어입니다.

다음 다이어그램은 듀얼 스택 VPC 기반을 보여줍니다.

그림 1: Amazon EKS IPv6 기반 클러스터의 필수 기반인 듀얼 스택 VPC 기반

듀얼 스택 VPC는 서브넷 내에서 CIDRs(클래스 없는 도메인 간 라우팅)로 알려진 IPv4 및 IPv6 주소 범위를 모두 지원합니다. 서브넷은 할당된 IPv4와 IPv6 범위와 일치하는 관련 CIDR 블록으로 생성되어, 자원이 동일한 VPC 인프라 내에서 두 주소 유형을 사용하여 통신할 수 있도록 합니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 듀얼 스택 서브넷에 배포되면 Amazon EC2 ENI는 하나의 IPv4 주소와 하나의 IPv6 주소를 소비하는데, 이것은 본질적으로 듀얼 스택 Amazon EC2 인스턴스라고 불립니다.

2단계 : Amazon EKS IPv6 기반 클러스터

그림 1에서 설명한 대로 1단계가 배포되면 (즉, VPC 기반) Amazon EKS IPv6 클러스터를 배포할 수 있습니다. 그렇다면 이 Amazon EKS IPv6 모드는 무엇을 의미할까요?

Amazon EKS IPv6 모드는 단순히 다음을 의미합니다:

Amazon EKS 컨트롤 플레인은 --ip-family ipv6 API 옵션으로 생성됩니다. Amazon EKS 컨트롤 플레인 외에도 Amazon EKS 서비스의 일반적인 부트스트랩 작업은 변경할 수 없는 고유 로컬 IPv6 유니캐스트 주소(ULA) 를 할당합니다. 이 IPv6 범위는 공개적으로 라우팅할 수 없으며, Kubernetes(즉, ClusterIP) 기반 서비스에 IPv6 주소를 할당하는 데 사용됩니다. 이 서비스들은 IPv6 전용입니다(그림 2의 ①)
Amazon EKS 워커 노드가 Amazon EKS 데이터 플레인의 일부로 듀얼 스택 서브넷(그림 2의 ②)에 부트스트랩될 때, 기본적으로 Amazon VPC CNI는 /80 접두사를 할당하고 연결하려고 시도합니다. 이는 Pod에 대해 약 10^14개의 IPv6 주소를 제공할 수 있습니다 — IP 고갈 문제 해결!

이 듀얼 스택 Amazon EC2 워커 노드에 도착하는 모든 Pod는 /80 prefix에서 할당된 IPv6 주소를 받게 됩니다. (그림 2의 왼쪽 A에서 C까지의 단계를 참조).

여기서는 Amazon EC2 보안 그룹, 라우팅 테이블, 네트워크 액세스 제어 목록 (NACLs) 과 같은 다른 모든 Amazon EC2 및 VPC 구성이 IPv6를 지원한다는 점에 유의하는 것이 중요합니다. Amazon EC2 보안 그룹을 사용하여 IPv6 Pod와의 인바운드 및 아웃바운드 네트워크 트래픽을 직접 허용하는 규칙을 정의할 수 있습니다.

또한, 인터넷으로의 IPv6 송신 설정과 관련하여 주요 고려사항이 있습니다. IPv6 주소는 공개적으로 라우팅 가능합니다. 따라서 IPv6 Pod가 인터넷을 송신하려면 EIGW(Egress-Only-Internet-Gateway)를 생성하고 이를 듀얼 스택 VPC에 연결한 다음 서브넷 라우팅 테이블에서 적절한 IPv6 기본 경로를 구성하는 것이 좋습니다(그림 1). NAT 게이트웨이는 여전히 Private IPv4 엔드포인트가 인터넷에 연결하도록 공개적으로 허용하는 데 사용됩니다.

1단계와 2단계가 완료되고 IPv6 기반 Amazon EKS 클러스터가 구성되면, 이제 원칙들이 실제로 작동합니다. EKS Terraform 기반 EKS/IPv6 블루프린트를 사용해 Amazon EKS 클러스터를 배포해 보십시오.

결론

이 게시물에서는 Amazon EKS IPv6 클러스터의 기본 측면에 대한 개요를 다루고, Amazon EKS가 고객이 IPv6를 사용하여 확장 가능한 클러스터를 구축하여 제한된 IPv4 주소 공간 문제를 해결하는 데 어떻게 도움이 되는지 설명하였습니다.
IPv6의 Amazon EKS는 운영 오버헤드를 줄여 처음부터 부당한 상호 운용성 계층의 필요성을 완화하고 모든 IPv4 엔드포인트 및 IPv6를 지원하는 AWS 서비스와의 통신을 허용합니다. 전체 조직의 IPv6 마이그레이션이 구체화될 때까지 기다리기보다는 지금 Amazon EKS/IPv6 채택을 시작하는 것이 좋습니다.
다음 두 게시물에서는 일반적인 구현 패턴 과 마이그레이션 전략 에 대해 자세히 살펴보겠습니다.

AWS 기술 블로그