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

Windows 네트워킹

Windows 컨테이너 네트워킹 개요

Windows 컨테이너는 Linux 컨테이너와 근본적으로 다릅니다. Linux 컨테이너는 네임스페이스, 유니온 파일 시스템 및 cgroup과 같은 Linux 구문을 사용합니다. Windows에서는 이러한 구문이 호스트 컴퓨팅 서비스(HCS)에 의해 컨테이너화되어 추상화됩니다. HCS는 Windows에서 컨테이너 구현 위에 있는 API 계층 역할을 합니다. Windows 컨테이너는 노드의 네트워크 토폴로지를 정의하는 호스트 네트워크 서비스(HNS)도 활용합니다.

네트워킹 관점에서 HCS와 HNS를 사용하면 Windows 컨테이너가 가상 머신처럼 작동합니다. 예를 들어 각 컨테이너에는 위의 다이어그램과 같이 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있습니다.

IP 주소 관리

Amazon EKS의 노드는 ENI(Elastic Network Interface)를 사용하여 AWS VPC 네트워크에 연결합니다. 현재 Windows 작업자 노드당 단일 ENI만 지원됩니다. Windows 노드의 IP 주소 관리는 컨트롤 플레인에서 실행되는 VPC 리소스 컨트롤러에서 수행됩니다. Windows 노드의 IP 주소 관리를 위한 워크플로에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

Windows 작업자 노드가 지원할 수 있는 포드 수는 노드의 크기와 사용 가능한 IPv4 주소 수에 따라 결정됩니다. 노드에서 사용할 수 있는 IPv4 주소를 다음과 같이 계산할 수 있습니다.

위의 공식을 사용하여 다음과 같이 m5.large 인스턴스를 기반으로 노드된 Windows 작업자의 최대 포드를 계산할 수 있습니다.

인스턴스 유형이 지원할 수 있는 IP 주소 수에 대한 자세한 내용은 인스턴스 유형별 네트워크 인터페이스당 IP 주소를 참조하세요.

또 다른 주요 고려 사항은 네트워크 트래픽의 흐름입니다. Windows를 사용하면 서비스가 100개 이상인 노드에서 포트가 고갈될 위험이 있습니다. 이 조건이 발생하면 노드에서 다음 메시지와 함께 오류가 발생하기 시작합니다.

“정책 생성 실패: Win32에서 hcnCreateLoadBalancer 실패: 지정된 포트가 이미 있습니다.”

이 문제를 해결하기 위해 DSR(Direct Server Return)을 활용합니다. DSR은 비대칭 네트워크 로드 분산을 구현한 것입니다. 즉, 요청 및 응답 트래픽은 서로 다른 네트워크 경로를 사용합니다. 이 기능은 포드 간 통신 속도를 높이고 포트 소진 위험을 줄입니다. 따라서 Windows 노드에서 DSR을 활성화하는 것이 좋습니다.

DSR은 Windows Server SAC EKS 최적화 AMIs에서 기본적으로 활성화됩니다. Windows Server 2019 LTSC EKS 최적화 AMIs 경우 아래 스크립트를 사용하고 Windows Server 2019 Full 또는 Core를 eksctl nodeGroup의 amiFamily로 사용하여 인스턴스 프로비저닝 중에 활성화해야 합니다. 자세한 내용은 eksctl 사용자 지정 AMI를 참조하세요.

nodeGroups:
- name: windows-ng
  instanceType: c5.xlarge
  minSize: 1
  volumeSize: 50
  amiFamily: WindowsServer2019CoreContainer
  ssh:
    allow: false

Windows Server 2019 이상에서 DSR을 활용하려면 인스턴스 시작 중에 다음 kube-proxy 플래그를 지정해야 합니다. 자체 관리형 노드 그룹 시작 템플릿과 연결된 사용자 데이터 스크립트를 조정하여이 작업을 수행할 수 있습니다.

<powershell>
[string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS"
[string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1'
[string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName"
(Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile
& $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1
</powershell>

DSR 활성화는 Microsoft 네트워킹 블로그 및 AWS Lab의 Windows 컨테이너의 지침에 따라 확인할 수 있습니다.

서브넷에 사용 가능한 IPv4 주소를 보존하고 낭비를 최소화하는 것이 중요한 경우 일반적으로 Windows용 접두사 모드 - 피해야 할 경우에 언급된 대로 접두사 위임 모드를 사용하지 않는 것이 좋습니다. 접두사 위임을 계속 사용하려는 경우 서브넷의 IPv4 주소 사용률을 최적화하는 단계를 수행할 수 있습니다. IPv4 주소 요청 및 할당 프로세스를 미세 조정하는 방법에 대한 자세한 지침은 접두사 위임을 위한 파라미터 구성을 참조하세요. 이러한 구성을 조정하면 IPv4 주소 보존과 접두사 위임의 포드 밀도 이점 간에 균형을 맞출 수 있습니다.

보조 IPv4 주소 할당의 기본 설정을 사용하는 경우 현재 VPC 리소스 컨트롤러가 IPv4 주소를 요청하고 할당하는 방법을 조작하는 데 지원되는 구성이 없습니다. 보다 구체적으로, minimum-ip-target 및 warm-ip-target는 접두사 위임 모드에서만 지원됩니다. 또한 보조 IP 모드에서는 인터페이스에서 사용 가능한 IP 주소에 따라 VPC 리소스 컨트롤러가 일반적으로 노드에 미사용 IPv4 주소 3개를 할당하여 포드 시작 시간을 단축하기 위해 웜 IPs 유지합니다. 사용하지 않는 웜 IP 주소의 IP 낭비를 최소화하려면 ENI의 IP 주소 용량을 최대한 많이 사용하도록 지정된 Windows 노드에서 더 많은 포드를 예약하는 것이 좋습니다. 보다 명시적으로 말하자면, ENI의 모든 IPs 주소가 노드에서 이미 사용 중이고 포드를 실행하는 경우 웜 미사용 IP를 사용하지 않도록 할 수 있습니다. 서브넷의 IP 주소 가용성 제약 조건을 해결하는 데 도움이 되는 또 다른 해결 방법은 서브넷 크기를 늘리거나 Windows 노드를 전용 서브넷으로 분리하는 것입니다.

또한 IPv6는 현재 Windows 노드에서 지원되지 않는다는 점에 유의해야 합니다.

컨테이너 네트워크 인터페이스(CNI) 옵션

AWSVPC CNI는 Windows 및 Linux 작업자 노드용 사실상의 CNI 플러그인입니다. AWSVPC CNI는 많은 고객의 요구 사항을 충족하지만 IP 소진을 방지하기 위해 오버레이 네트워크와 같은 대안을 고려해야 하는 경우가 있을 수 있습니다. 이러한 경우 AWSVPC CNI 대신 Calico CNI를 사용할 수 있습니다. Project Calico는 Tigera에서 개발한 오픈 소스 소프트웨어입니다. 이 소프트웨어에는 EKS와 함께 작동하는 CNI가 포함되어 있습니다. EKS에 Calico CNI를 설치하는 지침은 Project Calico EKS 설치 페이지에서 확인할 수 있습니다.

네트워크 정책

Kubernetes 클러스터의 포드 간 개방형 통신의 기본 모드에서 네트워크 정책에 따라 액세스를 제한하는 것으로 변경하는 것이 모범 사례로 간주됩니다. 오픈 소스 Project Calico는 Linux 및 Windows 노드 모두에서 작동하는 네트워크 정책을 강력하게 지원합니다. 이 기능은 별개이며 Calico CNI 사용에 의존하지 않습니다. 따라서 Calico를 설치하고 네트워크 정책 관리에 사용하는 것이 좋습니다.

EKS에 Calico를 설치하는 지침은 Amazon EKS에 Calico 설치 페이지에서 확인할 수 있습니다.

또한 Amazon EKS 보안 모범 사례 가이드 - 네트워크 섹션에 제공된 조언은 Windows 작업자 노드가 있는 EKS 클러스터에도 동일하게 적용되지만, 현재 Windows에서는 "포드용 보안 그룹"과 같은 일부 기능이 지원되지 않습니다.