Windows 네트워킹

Windows 네트워킹 (Networking on Windows)

쿠버네티스는 Linux 또는 Windows에서 노드를 실행하는 것을 지원해요. 단일 클러스터에서 두 종류의 노드를 모두 섞을 수 있어요. 이 페이지는 Windows 운영체제에 특화된 네트워킹 개요를 제공해요.

출처: 문서

본문

Windows의 컨테이너 네트워킹 (Container networking on Windows)

Windows 컨테이너의 네트워킹은 CNI 플러그인을 통해 노출돼요. Windows 컨테이너는 네트워킹 측면에서 가상 머신과 비슷하게 동작해요. 각 컨테이너는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)를 가져요. Host Networking Service(HNS)와 Host Compute Service(HCS)는 함께 작동해 컨테이너를 만들고 컨테이너 vNIC를 네트워크에 연결해요. HCS는 컨테이너 관리를 담당하고, HNS는 다음과 같은 네트워킹 리소스 관리를 담당해요.

가상 네트워크(vSwitch 생성 포함)
엔드포인트 / vNIC
네임스페이스
패킷 캡슐화, 로드밸런싱 규칙, ACL, NAT 규칙을 포함한 정책

Windows HNS와 vSwitch는 네임스페이싱을 구현하고 파드나 컨테이너에 필요에 따라 가상 NIC를 만들 수 있어요. 하지만 DNS, 라우트, 메트릭 같은 많은 구성은 Linux가 그 구성을 저장하는 방식인 /etc 안의 파일이 아니라 Windows 레지스트리 데이터베이스에 저장돼요. 컨테이너의 Windows 레지스트리는 호스트의 것과 분리돼 있어서, 호스트의 /etc/resolv.conf를 컨테이너에 매핑하는 것 같은 개념은 Linux에서와 같은 효과를 내지 않아요. 이들은 그 컨테이너의 컨텍스트에서 실행되는 Windows API로 구성해야 해요. 그래서 CNI 구현은 네트워크 세부 정보를 파드나 컨테이너에 전달하기 위해 파일 매핑에 의존하는 대신 HNS를 호출해야 해요.

네트워크 모드 (Network modes)

Windows는 5가지 네트워킹 드라이버/모드를 지원해요: L2bridge, L2tunnel, Overlay(Beta), Transparent, NAT. Windows와 Linux 워커 노드가 있는 이기종(heterogeneous) 클러스터에서는 Windows와 Linux에서 모두 호환되는 네트워킹 솔루션을 선택해야 해요. 다음 표는 Windows에서 지원되는 out-of-tree 플러그인과 각 CNI를 언제 사용할지에 대한 권장 사항을 나열해요.

네트워크 드라이버	설명	컨테이너 패킷 변형	네트워크 플러그인	네트워크 플러그인 특성
L2bridge	컨테이너가 외부 vSwitch에 연결된다. 컨테이너가 underlay 네트워크에 연결되지만, MAC이 인그레스/이그레스에서 재작성되므로 물리 네트워크가 컨테이너 MAC을 학습할 필요가 없다.	MAC이 호스트 MAC으로 재작성되고, HNS OutboundNAT 정책을 사용해 IP가 호스트 IP로 재작성될 수 있다.	win-bridge, Azure-CNI, Flannel host-gateway는 win-bridge를 사용	win-bridge는 L2bridge 네트워크 모드를 사용해 컨테이너를 호스트의 underlay에 연결하며, 최상의 성능을 제공한다. 노드 간 연결에는 사용자 정의 라우트(UDR)가 필요하다.
L2Tunnel	l2bridge의 특수한 경우이며 Azure에서만 사용된다. 모든 패킷은 SDN 정책이 적용되는 가상화 호스트로 보내진다.	MAC 재작성, IP는 underlay 네트워크에서 보임	Azure-CNI	Azure-CNI는 컨테이너를 Azure vNET과 통합하고 Azure Virtual Network가 제공하는 일련의 기능을 활용할 수 있게 한다. 예를 들어 Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용할 수 있다. 예시는 azure-cni 참고
Overlay	컨테이너에 외부 vSwitch에 연결된 vNIC가 주어진다. 각 overlay 네트워크는 커스텀 IP 접두사로 정의된 자체 IP 서브넷을 가진다. overlay 네트워크 드라이버는 VXLAN 캡슐화를 사용한다.	외부 헤더로 캡슐화된다.	win-overlay, Flannel VXLAN(win-overlay 사용)	win-overlay는 가상 컨테이너 네트워크가 호스트의 underlay로부터 격리되길 원할 때(예: 보안상 이유) 사용해야 한다. 데이터센터에서 IP가 제한된 경우 서로 다른 overlay 네트워크(다른 VNID 태그를 가진)에 IP를 재사용할 수 있게 한다. 이 옵션은 Windows Server 2019에 KB4489899가 필요하다.
Transparent (ovn-kubernetes의 특수 사용 사례)	외부 vSwitch가 필요하다. 컨테이너가 외부 vSwitch에 연결되며, 논리 네트워크(논리 스위치와 라우터)를 통해 파드 내 통신을 가능하게 한다.	패킷은 같은 호스트에 없는 파드에 도달하기 위해 GENEVE 또는 STT 터널링으로 캡슐화된다. 패킷은 ovn 네트워크 컨트롤러가 제공한 터널 메타데이터 정보로 전달되거나 폐기된다. NAT는 north-south 통신을 위해 수행된다.	ovn-kubernetes	ansible로 배포한다. 분산 ACL을 쿠버네티스 정책으로 적용할 수 있다. IPAM 지원. kube-proxy 없이 로드밸런싱 달성 가능. iptables/netsh 없이 NAT 수행.
NAT (쿠버네티스에서 사용 안 함)	컨테이너에 내부 vSwitch에 연결된 vNIC가 주어진다. DNS/DHCP는 WinNAT이라는 내부 컴포넌트로 제공된다.	MAC과 IP가 호스트 MAC/IP로 재작성된다.	nat	완전성을 위해 여기 포함됨

위에서 설명한 대로 Flannel CNI 플러그인도 Windows에서 VXLAN 네트워크 백엔드(Beta 지원; win-overlay에 위임)와 host-gateway 네트워크 백엔드(안정 지원; win-bridge에 위임)를 통해 지원돼요.

이 플러그인은 참조 CNI 플러그인(win-overlay, win-bridge) 중 하나에 위임해 Windows의 Flannel 데몬(Flanneld)과 함께 작동하여 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 지원해요. 이 플러그인은 자체 구성 파일(cni.conf)을 읽고 FlannelD가 생성한 subnet.env 파일의 환경 변수와 결합해요. 그런 다음 네트워크 플러밍을 위해 참조 CNI 플러그인 중 하나에 위임하고, 노드가 할당받은 서브넷을 포함하는 올바른 구성을 IPAM 플러그인(예: host-local)에 보내요.

Node, Pod, Service 객체에 대해 TCP/UDP 트래픽에서 다음 네트워크 흐름이 지원돼요.

Pod → Pod (IP)
Pod → Pod (Name)
Pod → Service (Cluster IP)
Pod → Service (PQDN, 마침표 "."가 없는 경우에만)
Pod → Service (FQDN)
Pod → external (IP)
Pod → external (DNS)
Node → Pod
Pod → Node

IP 주소 관리 (IPAM, IP address management)

Windows에서 지원되는 IPAM 옵션은 다음과 같아요.

host-local
azure-vnet-ipam (azure-cni 전용)
Windows Server IPAM (IPAM이 설정되지 않은 경우의 폴백 옵션)

Direct Server Return (DSR)

기능 상태: Kubernetes v1.34부터 Stable. 이것은 쿠버네티스의 안정적인 기능이며 v1.34부터 그랬어요. 처음에는 v1.14 릴리스에서 사용할 수 있었어요. 더 이상 이 기능이나 동작을 비활성화하거나 거부할 수 없어요(잠겨 있음). 관련 기능 게이트인 WinDSR에 값을 명시적으로 설정하면 쿠버네티스는 이를 무시하지만 오류는 보고하지 않아요.

IP 주소 수정과 LBNAT이 컨테이너 vSwitch 포트에서 직접 발생하는 로드밸런싱 모드예요. 서비스 트래픽은 출발지 IP가 원래 파드 IP로 설정된 채 도착해요. 이는 반환 트래픽이 로드밸런서를 우회해 클라이언트에 직접 응답할 수 있게 함으로써 성능 최적화를 제공해요. 로드밸런서의 부하를 줄이고 전체 대기 시간도 줄여요. 자세한 내용은 Direct Server Return (DSR) in a nutshell을 읽어 보세요.

로드밸런싱과 Services (Load balancing and Services)

쿠버네티스 Service는 논리적 Pod 집합과 네트워크를 통해 접근하는 방법을 정의하는 추상화예요. Windows 노드를 포함하는 클러스터에서 다음 유형의 Service를 사용할 수 있어요.

NodePort
ClusterIP
LoadBalancer
ExternalName

Windows 컨테이너 네트워킹은 Linux 네트워킹과 몇 가지 중요한 방식에서 달라요. Microsoft의 Windows Container Networking 문서가 추가 세부 정보와 배경을 제공해요.

Windows에서는 다음 설정을 사용해 Services와 로드밸런싱 동작을 구성할 수 있어요.

기능	설명	최소 지원 Windows OS 빌드	활성화 방법
세션 어피니티(Session affinity)	특정 클라이언트의 연결이 매번 같은 Pod로 전달되도록 보장한다.	Windows Server 2022	"ClientIP"로 설정
Direct Server Return (DSR)	위 DSR 참고 사항 참고.	Windows Server 2019	명령줄 인자 설정(버전 1.37 기준)
Preserve-Destination	서비스 트래픽의 DNAT를 건너뛰어 백엔드 Pod에 도달하는 패킷에서 대상 서비스의 가상 IP를 보존한다. 노드-노드 포워딩도 비활성화한다.	Windows Server, 버전 1903	서비스 어노테이션에 설정하고 kube-proxy에서 DSR 활성화
IPv4/IPv6 이중 스택 네트워킹	클러스터로/에서/내부에서 네이티브 IPv4-to-IPv4가 IPv6-to-IPv6 통신과 병렬로 지원	Windows Server 2019	IPv4/IPv6 이중 스택 참고
클라이언트 IP 보존(Client IP preservation)	들어오는 인그레스 트래픽의 소스 IP가 보존되도록 보장한다. 노드-노드 포워딩도 비활성화한다.	Windows Server 2019	"Local"로 설정하고 kube-proxy에서 DSR 활성화

제한 사항 (Limitations)

Windows 노드에서는 다음 네트워킹 기능이 지원되지 않아요.

호스트 네트워킹 모드
노드 자체에서의 로컬 NodePort 접근(다른 노드나 외부 클라이언트에서는 동작)
단일 Service에 대한 64개 이상의 백엔드 파드(또는 고유 대상 주소)
overlay 네트워크에 연결된 Windows 파드 간 IPv6 통신
비-DSR 모드에서의 Local Traffic Policy
win-overlay, win-bridge 또는 Azure-CNI 플러그인을 사용한 ICMP 프로토콜의 아웃바운드 통신. 특히 Windows 데이터 플레인(VFP)은 ICMP 패킷 변환을 지원하지 않아서, 다음을 의미해요.
- 같은 네트워크 내 대상으로 향하는 ICMP 패킷(예: ping을 통한 파드 간 통신)은 예상대로 동작
- TCP/UDP 패킷은 예상대로 동작
- 원격 네트워크를 통과하는 ICMP 패킷(예: ping을 통한 파드 대 외부 인터넷 통신)은 변환될 수 없어 출발지로 다시 라우팅되지 않음
- TCP/UDP 패킷은 여전히 변환될 수 있으므로, 외부 세계와의 연결성을 디버깅할 때 ping <destination> 대신 curl <destination>을 사용할 수 있음

기타 제한 사항:

Windows 참조 네트워크 플러그인 win-bridge와 win-overlay는 CNI spec v0.4.0을 구현하지 않아요. CHECK 구현이 없기 때문이에요.
Flannel VXLAN CNI 플러그인은 Windows에서 다음 제한 사항이 있어요.
- Flannel v0.12.0(또는 그 이상)에서만 로컬 파드에 대한 노드-파드 연결이 가능해요.
- Flannel은 VNI 4096과 UDP 포트 4789만 사용하도록 제한돼요. 이 매개변수에 대한 자세한 내용은 공식 Flannel VXLAN 백엔드 문서를 참고하세요.

Windows 네트워킹