Multus 워커 노드 및 파드를 위한 자동화된 IP 주소 관리

이 글은 영문 게시글(Automated IP address management for Multus Workers and Pods by Raghvendra Singh)을 한글 번역, 편집하였습니다.

Telco 5G 및 IMS 컨테이너 기반 워크로드는 트래픽 및 라우팅 분리, 패킷 가속화를 위해 Multus CNI를 활용합니다. Multus 컨테이너 네트워크 인터페이스 플러그인을 사용하면 Kubernetes 파드를 여러 인터페이스 및 네트워크에 연결할 수 있습니다. Multus CNI는 “Meta-plugin”이며, VPC CNI (Amazon Elastic Kubernetes Service (Amazon EKS)의 기본 CNI), IPVLAN CNI 등과 같은 다른 CNI를 호출하여 이를 달성합니다. VPC CNI는 쿠버네티스 파드 기본 인터페이스를 관리하는 반면 IPVLAN CNI는 파드가 워커 노드 Elastic Network interface (ENI)의 동일한 MAC 주소를 사용하는 워커 노드의 보조 인터페이스를 사용하게 합니다. Multus CNI는 또한 host-local, static 및 whereabouts와 같은 IPAM CNI를 호출합니다.

Amazon EKS는 이제 Multus CNI를 지원합니다라는 게시물은 Amazon EKS에서 Multus 워크로드 배포를 하는 데 도움을 줍니다. EKS에 Multus 기반 워크로드를 프로덕션 레벨로 배포하려면 다음 두 주제를 관리할 계획을 세워야 합니다.

Multus 워커 노드 그룹: 각 워커 노드 ENI에는 서브넷의 IP 주소가 필요하기 때문에 워커 노드 서브넷 및 워커 노드의 IP 주소 관리.
Multus 파드 네트워킹: 워커 노드 서브넷을 통한 Multus 파드 IP 관리 및 Amazon Virtual Private Cloud (Amazon VPC)에서의 파드 통신.

이 블로그에서는 표준 Multus 노드 그룹 배포 접근 방식뿐만 아니라 Amazon VPC 내에서 Multus 워크로드와 함께 ipvlan CNI를 사용할 때 위의 주제를 관리하는 데 따르는 어려움과 접근 방식에 대해 살펴보겠습니다.

표준 Multus 노드 그룹 배포 접근 방식

이 다이어그램은 이 블로그에서 참조할 예정인 IPVLAN CNI를 사용한 Multus 워크로드의 샘플 배포 예시입니다. 이 예에는 Amazon EKS 클러스터와 두 개의 워커 노드가 있는 노드 그룹이 있습니다. 두 워커 노드에는 다음과 같이 두 개의 서브넷이 연결되어 있습니다.

eth0 네트워크: 10.10.12.0/24 (VPC CNI, 즉 기본 파드 인터페이스에 사용됨)
eth1 네트워크: 10.10.1.0/24 (Multus ipvlan cni, 즉 파드 보조 인터페이스에 사용됨)

이 샘플 배포 접근 방식의 경우, 배포는 Amazon EKS 클러스터 배포룰 한 다음 Amazon EKS 노드 그룹 배포로 이어집니다. 노드 그룹이 배포되면 여러분의 워크로드를 지원할 수 있는 Multus CNI와 관련된 플러그인을 배포합니다. 플러그인이 배포되면 워크로드를 배포할 수 있습니다.

다음 섹션에서는 Multus Worker Node 그룹 및 IP 관리를 위한 배포 전략에 대해 설명하겠습니다.

Multus 워커 노드 그룹 배포 및 IP 관리

Multus 워커 노드 배포

자체 관리형 Multus 노드 그룹은 오토스케일링 그룹을 사용하여 복원력(최소 워커 노드 수 유지)과 확장성을 제공합니다.오토스케일링 그룹은 시작 템플릿을 활용하여 Amazon Elastic Compute Cloud (Amazon EC2) 워커 노드를 구성합니다. 오토스케일링 그룹은 시작 템플릿과 함께 사용하면 동일한 서브넷에 속하는 단일 또는 다중 인터페이스로 워커 노드를 만들 수 있습니다. 사용자 지정 배포 전략에서는 Amazon EC2 Autoscaling 수명 주기 후크에 Multus 인터페이스를 추가하는 사용자 지정 AWS Lambda를 사용하여 여러 서브넷에 여러 네트워크 인터페이스를 연결할 수 있습니다.

다음 다이어그램에서 볼 수 있듯이 오토스케일링 그룹에서 시작 템플릿을 사용하여 단일 인터페이스(eth0)를 가진 워커 노드를 만드는 것으로 배포가 시작됩니다. 워커 노드가 시작되면 사용자 지정 Lambda가 단일 인터페이스 노드를 종료합니다. 이렇게 스케일인하면 “AutoScaling:EC2\ _INSTANCE\ _TERMINATING” 이벤트가 발생합니다. 이 이벤트는 사용자 지정 Lambda를 트리거한 후 노드를 비우거나 아무 작업도 수행하지 않습니다.

이 이벤트가 완료되면 오토스케일링 그룹이 원하는 용량에 맞춰 스케일아웃되어 "Autoscaling:EC2_INSTANCE_LAUNCHING” 이벤트가 발생합니다. 이 이벤트는 사용자 지정 Lambda 함수를 트리거합니다. 이 함수는 Multus 서브넷에서 태그(key: node.k8s.amazonaws.com/no_manage” value: true)를 사용하여 보조 인터페이스를 추가합니다.

EKS Multus 노드 그룹 생성 흐름

워커 노드 IP 관리 과제

오토스케일링 그룹은 Amazon EKS 워커 노드 그룹에 탄력성과 복원력을 제공하며, 동일한 기능을 지원하기 위해 모든 인터페이스에 대한 DHCP IP 할당을 사용합니다. 반면 Multus 파드의 경우 non-VPC IPAM CNI(host-local, whereabouts 등)는 고정 주소 범위/풀을 사용하여 보조 인터페이스의 IP 할당을 관리합니다. 파드 egress/ingress는 해당 워커 ENI를 통해 이루어지므로 파드 IP 및 워커 ENI IP 주소는 서브넷에서 가져온 것이어야 합니다. 애플리케이션 플래너는 Multus network-attachment-definition 구성 및 annotation을 사용하여 Multus 파드에 고정 IP 범위를 할당합니다.

동일한 서브넷에서 서로 다르며 연결이 끊긴 두 가지 IP 할당 방법(DHCP와 고정)은 워크로드 배포에 있어 흥미로운 문제를 야기합니다. DHCP를 통한 워커 노드 IP 할당은 무작위이며 다른 고정 할당에 대한 지식이 없기 때문에 파드에 대해 계획된 고정 IP 범위에서 아무 IP 주소를 가져올 수 있습니다. Multus IPAM CNI(host-local, whereabouts 등)는 이 할당을 인식하지 못하기 때문에 만약 이 IP가 워커 노드 인터페이스에서 사용되면 애플리케이션 파드에 IP 충돌이 발생하고 IP 할당이 실패하여 예기치 않은 애플리케이션 배포가 발생합니다.

해결책

다음 섹션에서는 워커 노드와 Multus 워크로드의 IP 주소 지정을 충돌 없이 효과적으로 관리할 수 있는 두 가지 접근 방식을 안내해 드리겠습니다.

접근법 1: 사용자 지정 Lambda를 사용하여 작업자 IP를 정적으로 할당

이 솔루션 접근 방식은 워커와 파드 간의 논리적 서브넷 공유 모델에서 작동합니다. 이 접근 방식에서 워커 노드는 서브넷의 시작 부분부터 할당되지 않은 IP를 가져오고 Multus 파드는 서브넷 끝에서 할당되지 않은 IP를 가져옵니다. 이 할당 전략을 사용하면 워커 노드 인터페이스의 IP 주소 할당이 무작위로 이루어지지 않으며 서브넷에서 사용 가능한 첫 번째 IP부터 정적으로 IP 할당이 이루어집니다.

자세한 설명, 샘플 AWS CloudFormation 템플릿 및 지원되는 Lambda 함수는 GitHub 리포지토리 사용자 지정 lambda 기반 솔루션을 통해 워커 노드 IP를 정적으로 할당을 참조하십시오.

접근법 2: 파드의 IP 주소에 VPC 서브넷 CIDR 예약(고정) 사용

이 접근 방식은 VPC 서브넷 CIDR 예약 전략을 사용하여 워커 노드와 Multus 파드 IP 주소 할당을 구분합니다. 이 접근 방식을 사용하면 명시적으로 Multus 파드 IP CIDR 범위를 정적으로 예약하여 Amazon EC2 워커 노드용 DHCP가 이 블록의 워커 노드에 IP 주소를 할당하지 않도록 할 수 있습니다.

이를 달성하려면 명시적(고정) 할당을 위해서만 파드 IP 주소 청크에 대해 하나 이상의 서브넷 CIDR 예약을 생성할 수 있다. 서브넷 CIDR의 예약되지 않은 청크는 오토스케일링 그룹 뒤에 있는 워커 노드에 대한 DHCP(기본값) 할당에 사용될 수 있습니다.

샘플 CloudFormation 템플릿 및 지원되는 Lambda 함수에 대한 자세한 설명은 GitHub 리포지토리 파드 IP 주소에 VPC 서브넷 cidr 예약(정적) 사용을 참조하십시오.

자동화된 Multus 파드 네트워킹

이제 Amazon EKS 클러스터와 Multus 노드 그룹이 이전 접근 방식 중 하나로 배포되었으므로 Multus를 사용하여 Amazon EKS에 워크로드를 배포할 수 있습니다. 다음 단계로, git 리포지토리에서 언급한 대로 Multus CNI를 배포하고 whereabout IPAM CNI를 설치할 수 있습니다. 이 글에서는 whereabouts IPAM CNI를 사용하여 클러스터의 고유한 Multus IP 주소를 관리하려고 합니다.

이제 VPC에서 IP 통신이 어떻게 작동하는지, 라우팅을 활성화하는 접근 방식, 자동화된 방식으로 Multus 파드에 대한 IP 할당에 대해 알아보겠습니다.

Multus 파드 IP 관리 및 라우팅 문제

다음 예시에서는 Multus 파드를 배포할 때 보안 그룹 규칙/NACL이 트래픽을 차단하지 않더라도 서로 다른 워커 노드의 파드 간 통신이 작동하지 않는다는 점에 유의하십시오. 하지만 동일한 워커 노드에 있는 파드 간의 상호 통신은 정상적으로 작동합니다.

여기서 이 동작에 대해 자세히 설명하면 Amazon VPC는 워크로드에 Layer 3 네트워킹을 제공합니다. ENI는 하나 이상의 IP 주소와 해당 MAC 주소를 포함하는 논리적 네트워킹 엔티티입니다. Amazon VPC는 ENI에 할당된 IP 주소를 기반으로 트래픽을 올바른 대상으로 라우팅합니다. Amazon EC2 워커 노드에 연결된 각 ENI에는 원하는 IP 주소가 할당되어 있어야 합니다.

파드의 기본 인터페이스의 경우, Amazon VPC CNI는 DHCP를 사용하여 파드 eth0(VPC CNI 관리형 인터페이스)에 기본 파드 IP 주소(이전 예제의 10.10.12.x)를 할당하고 이러한 IP를 워커 노드 ENI의 보조 IP로 할당합니다. non-VPC IPAM CNI (whereabouts, host-local, static 등)는 Multus 파드에 IP 주소를 할당합니다. 따라서 Amazon VPC는 이 IP 주소 할당을 인식하지 못합니다. 또한 이러한 IP 주소는 각 워커 노드 ENI(이 예에서는 eth1)에 보조 IP로 할당되지 않습니다.

참고로 Amazon EC2 콘솔에서 워커 노드 ENI를 검토하여 동일한 내용을 확인할 수 있습니다: Amazon EC2 콘솔 → 인스턴스 → 인스턴스 선택(워커 노드) → 작업 → 네트워킹 → IP 주소 관리

이 문제는 파드에서 사용하는 IP 주소를 각 워커 노드 ENI에 할당하면 해결됩니다. 이러한 IP가 각 ENI(예: eth1)에 할당되면 Amazon VPC는 할당된 IP를 ENI에 매핑하여 트래픽을 지정된 Multus IP 주소로 라우팅하도록 업데이트합니다.

다음 예시에서는 Multus 파드 IP 주소 10.10.1.80 및 10.10.1.82를 첫 번째 워커 노드의 eth1 ENI에 보조 IP 주소로 할당했습니다. 마찬가지로 보조 IP 주소 10.10.1.81는 두 번째 워커 노드 eth1 ENI에 할당됩니다.

자동화 솔루션

Amazon EC2는 IP 주소 할당/IP 주소 할당 취소 API 호출을 통해 워커 노드 ENI의 IP 할당을 자동화할 수 있습니다. git 리포지토리의 샘플 파이썬 코드와 스크립트는 동일한 결과를 달성하는 데 도움이 될 수 있습니다.

다음에서 설명하는 자동화 접근 방식에서는 애플리케이션 이미지나 소스 코드를 변경할 필요가 없습니다. 이러한 파드의 사용자 지정 “IP 관리” 컨테이너를 활용하여 애플리케이션 컨테이너나 아키텍처에 영향을 주지 않고 각 워커 노드 ENI의 IP 할당을 자동화할 수 있습니다. 이 추가 컨테이너를 사용하여 워크로드 파드/디플로이먼트/스테이트풀셋의 사양을 개선할 수 있습니다.

이 기능을 제공하고 다음 솔루션 옵션 중 하나에 사용할 수 있는 도커 컨테이너 이미지를 빌드하려면 How to build를 참조하십시오.

접근법 1: InitContinaer 기반 IP 관리 솔루션

이 솔루션은 유동 IP와 같은 특수/사용자 지정 처리 없이 대부분의 ipvlan CNI 파드에 사용할 수 있습니다(다음 접근 방식에서 설명). 이 접근 방식은 워커 노드에게 추가 CPU/메모리 요구 사항이라는 제약을 추가하지 않습니다.

이 “IP 관리” 컨테이너는 POD가 init 상태일 때 첫 번째 컨테이너로 실행됩니다. 이 컨테이너는 파드의 IP 주소를 확인하고 파드가 초기화 상태에 있는 동안 IP 주소를 ENI에 할당합니다. Multus IP 주소가 워커 노드 ENI에 성공적으로 할당되면 이 initContainer가 종료되고 파드가 초기화 상태를 벗어나게 된다.

이 솔루션을 사용하려면 initContainer IP 관리 문서 및 배포 절차를 참조하십시오. Amazon EC2 콘솔에서 워커 노드 ENI를 검토하여 이를 확인할 수 있습니다: Amazon EC2 콘솔 → 인스턴스→ 인스턴스 선택(워커 노드) → 작업 → 네트워킹 → IP 주소 관리.

접근법 2: 사이드카 IP 관리 솔루션

이 접근 방식에서는 “IP 관리” 컨테이너가 사이드카 컨테이너로 실행됩니다. 또한 InitContainer와 달리 Multus 인터페이스의 파드 IP 주소를 지속적으로 모니터링하여 새 IP 주소나 변경된 IP 주소가 있는지 확인합니다. 이는 액티브/스탠바이 파드에 대해 사용자 지정 “Floating IP”를 처리하는 파드에 유용하며, 내부 로직에 따라 “Floating IP”는 트래픽 중단 없이 스탠바이 파드로 장애조치됩니다. 이 경우 사이드카가 파드의 IP 주소 변경을 지속적으로 모니터링하므로 Multus 기반 파드별로 이 컨테이너의 CPU/메모리(최소)를 추가로 사용하게 됩니다.

이 솔루션을 사용하려면 사이드카 IP 관리 솔루션 문서 및 절차를 참조하십시오. Amazon EC2 콘솔에서 확인할 수 있습니다: Amazon EC2 콘솔 → 인스턴스 → 인스턴스 선택(워커 노드) → 작업 → 네트워킹 → IP 주소 관리

정리

이 게시물에 배포된 샘플 Multus 워크로드를 정리하려면 GitHub 리포지토리의 Cleanup을 참조하십시오. 또한 향후 요금이 발생하지 않도록 CloudFormation 콘솔에서 Multus 워커 노드 그룹을 삭제하십시오. Amazon EKS 클러스터는 Amazon EKS 콘솔에서 삭제할 수 있습니다.

결론

이 게시물에서는 Amazon VPC 클라우드 내에서 워커 노드와 Multus 파드 IP 주소의 IP 할당, 관리 및 분리 과정에서 고객이 직면하는 문제를 간략하게 설명합니다. 또한 Multus 파드가 Amazon EKS 및 Amazon VPC 범위에서 어떻게 작동하고 VPC에서 트래픽을 라우팅하는지 설명합니다.

또한 이 게시물에서는 소프트웨어/이미지를 변경하지 않고도 Amazon EKS 노드 그룹 및 Multus 파드의 IP 관리 자동화를 위한 샘플 자동화 방법론을 제공합니다.

간단하게 설명하자면, 이 게시물에서는 이전 예제의 IPv4 처리만 시연했습니다만 git 리포지토리의 샘플 코드는 IPv6를 지원합니다. 다양한 애플리케이션 아키텍처 및 사용 사례에 따라 git 리포지토리에서 샘플 소스 코드를 추가로 조정할 수 있습니다.

AWS 기술 블로그