Windows 노드의 제한 사항과 알려진 문제

원문 보기 위키 갱신 2026.10.12

Calico Cloud를 Windows 노드와 함께 쓸 때 알아야 할 기능 제한과 알려진 문제를 정리한 페이지예요. 기능 지원 범위부터 BGP·VXLAN 네트워킹 제한, 네트워크 정책과 플로우 로그 제약까지 담고 있어요. Windows 노드를 클러스터에 넣기 전에 이 목록을 먼저 훑어보세요.

출처: 문서

본문

Calico Cloud feature limitations

기능	이 릴리스에서 지원되지 않음
Platforms	- GKE
Install and upgrade	- 확장용 Typha 컴포넌트 (Linux 기반 기능)
Networking	- BGP 피어링을 사용하는 오버레이 모드 - BGP 라우팅을 사용하는 IP in IP 오버레이 - VXLAN의 크로스 서브넷 지원 및 MTU 설정 - IPv6 및 듀얼 스택 - Dual-ToR - 서비스 광고 - 파드에 여러 네트워크
Policy	- Staged network-policy - 방화벽 통합 - 호스트를 위한 정책 (자동 호스트 엔드포인트를 포함한 호스트 엔드포인트) - 티어드 정책: TKG, GKE, AKS - WAF 통합 - AWS 방화벽 통합 - Fortinet 통합
Visibility and troubleshooting	- 패킷 캡처 - DNS 로그 - iptables 로그 - L7 로그
Threat defense	- 위협 방어 기능은 지원되지 않아요.
Multi-cluster management	- 멀티 클러스터 관리 페더레이션 아이덴티티 엔드포인트 및 서비스 - 페더레이션 엔드포인트 아이덴티티 및 서비스
Compliance and security	- CIS 벤치마크 및 기타 리포트 - pod-to-pod 트래픽과 host-to-host 트래픽의 WireGuard 암호화
Data plane	- eBPF는 Linux 기반 기능이에요

Calico Cloud BGP 네트워킹 제한

Calico Cloud를 BGP와 함께 사용한다면 Windows 관련 현재 제한 사항을 주의하세요.

기능	제한 사항
IP mobility/ borrowing	Calico Cloud IPAM은 애그리게이션을 위해 블록 단위로 호스트에 IP를 할당해요. IP 풀이 가득 차면, 노드는 다른 노드의 블록에서 IP를 "빌려올"(borrow) 수도 있어요. BGP 관점에서 보면 빌려온 쪽이 빌려온 IP에 대해 더 구체적인 "/32" 라우트를 광고하고, 그 IP로 가는 트래픽은 빌려간 호스트로만 라우팅돼요. Windows 노드는 이 빌리기 메커니즘을 지원하지 않아요. IP 풀이 가득 차더라도 IP를 빌려오지 않고, Linux 노드가 자기 블록에서 빌려가지 못하도록 블록을 표시해요.
IPs reserved for Windows	Calico Cloud IPAM은 CIDR 블록 단위로 IP를 할당해요. Windows의 네트워킹 요구사항 때문에, Windows 노드가 소유한 블록마다 4개의 IP를 내부 목적으로 예약해야 해요. 예를 들어 기본 블록 크기가 /26이면 각 블록은 64개의 IP 주소를 담고, 4개는 Windows를 위해 예약되어 60개가 pod networking에 남아요. 이 예약의 영향을 줄이려면 (파드가 만들어지기 전에) IP 풀 범위에서 더 큰 블록 크기를 설정할 수 있어요.
Single IP block per host	Calico Cloud IPAM은 요청이 있을 때 호스트에 IP 블록(기본 크기 /26)을 할당하도록 설계됐어요. Calico Cloud CNI 플러그인도 같은 방식으로 작성되었지만, Windows용 kube-proxy는 현재 호스트당 하나의 IP 블록만 지원해요. 호스트당 /26 하나라는 기본 제한을 우회하는 몇 가지 옵션이 있어요: - Kubernetes 데이터스토어와 함께 Calico Cloud BGP 네트워킹을 사용하세요. 그 모드에서는 Calico Cloud IPAM을 쓰지 않고, 노드의 Pod CIDR과 함께 CNI host-local IPAM 플러그인을 사용해요. (kube-proxy 호환성을 희생하고) 호스트당 여러 IPAM 블록을 허용하려면, Calico Cloud를 설치하기 전에 `cni.conf.template`에서 `windows_use_single_network` 플래그를 `false`로 설정하세요. 파드가 네트워킹된 후에 그 설정을 바꾸는 것은 권장하지 않아요. HNS 엔드포인트가 누출될 수 있어요.
IP-in-IP overlay	Calico Cloud의 IPIP 오버레이 모드는 Windows 노드가 포함된 클러스터에서 사용할 수 없어요. Windows는 IP-in-IP를 지원하지 않기 때문이에요.
NAT-outgoing	Calico Cloud IP 풀은 다음 동작을 갖는 "NAT outgoing" 설정을 지원해요: - Calico Cloud 워크로드 간의 트래픽(모든 IP 풀에서)은 NAT되지 않아요. - 설정된 IP 풀을 벗어나는 트래픽은, 그 워크로드의 IP가 NAT outgoing이 활성화된 IP 풀 안에 있으면 NAT돼요. Calico Cloud는 위 설정을 따르지만, 파드 생성 시점에만 적용돼요. 파드가 만들어진 후에 IP 풀 설정을 업데이트하면, 그 파드의 트래픽은 이전과 같이 NAT되거나(또는 되지 않고) 유지돼요. 새로 네트워킹된 파드의 NAT 정책은 새 설정을 따라요. Calico Cloud는 호스트 자신과 그 서브넷을 NAT 제외 목록에 자동으로 추가해요. 이 동작은 설치 스크립트를 실행하기 전에 `cni.conf.template`에서 `windows_disable_host_subnet_nat_exclusion` 플래그를 `true`로 설정하면 끌 수 있어요.
Service IP advertisement	이 Calico Cloud 기능은 Windows에서 지원되지 않아요.

네트워크 구성 확인하기

레이어 2 도달 가능성이 필요한 네트워킹 타입(예: 패브릭과 피어링하지 않는 BGP 메시를 쓰는 Calico Cloud)을 사용 중이라면, 다음과 같이 네트워크에 레이어 2 도달 가능성이 있는지 확인할 수 있어요.

각 노드에서 pod networking에 사용하려는 네트워크 어댑터의 IP 네트워크를 확인하세요. 예를 들어 Linux에서 네트워크 어댑터가 eth0이라면 다음을 실행할 수 있어요:

$ ip addr show eth0
     2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:0c:29:cb:c8:19 brd ff:ff:ff:ff:ff:ff
    inet 192.168.171.136/24 brd 192.168.171.255 scope

    global eth0
      valid_lft forever preferred_lft forever
      inet6 fe80::20c:29ff:fecb:c819/64 scope
      link

      valid_lft forever preferred_lft
      forever

이 경우 IPv4는 192.168.171.136/24이고, /24 마스크를 적용하면 IP 네트워크는 192.168.171.0/24가 돼요.

마찬가지로 Windows에서는 다음을 실행할 수 있어요

PS C:\> ipconfig

Windows IP Configuration

Ethernet adapter vEthernet (Ethernet 2):

  Connection-specific DNS Suffix . :
  us-west-2.compute.internal Link-local IPv6 Address . . . .
  . : fe80::6d10:ccdd:bfbe:bce2%15 IPv4 Address. . . . . . .
  . . . . : 172.20.41.103 Subnet Mask . . . . . . . . . . .
  : 255.255.224.0 Default Gateway . . . . . . . . . :
  172.20.32.1

이 경우 IPv4 주소는 172.20.41.103이고, 마스크는 CIDR 표기법이 아니라 255.255.224.0이라는 바이트 값으로 표현돼요. 마스크를 적용하면 네트워크 주소는 172.20.32.0/19가 돼요.

Linux 노드의 네트워크는 192.168.171.136/24이고 Windows 노드는 다른 네트워크인 172.20.32.0/19이기 때문에, 같은 레이어 2 네트워크에 있을 가능성은 낮아요.

VXLAN 네트워킹 제한

Linux와 Windows 데이터 플레인 기능 세트의 차이 때문에, 다음 Calico Cloud 기능은 Windows에서 지원되지 않아요.

기능 제한 사항

IPs reserved for Windows Calico Cloud IPAM은 CIDR 블록 단위로 IP를 할당해요. Windows의 네트워킹 요구사항 때문에, Windows 노드가 소유한 블록마다 4개의 IP를 내부 목적으로 예약해야 해요. 예를 들어 기본 블록 크기가 /26이면 각 블록은 64개의 IP 주소를 담고, 4개는 Windows를 위해 예약되어 60개가 pod networking에 남아요. 이 예약의 영향을 줄이려면 (파드가 만들어지기 전에) IP 풀 범위에서 더 큰 블록 크기를 설정할 수 있어요.

Single IP block per host Calico Cloud IPAM은 요청이 있을 때 호스트에 IP 블록(기본 크기 /26)을 할당하도록 설계됐어요. Calico Cloud CNI 플러그인도 같은 방식으로 작성되었지만, kube-proxy는 현재 호스트당 하나의 IP 블록만 지원해요. (kube-proxy 호환성을 희생하고) 호스트당 여러 IPAM 블록을 허용하려면, Calico Cloud를 설치하기 전에 cni.conf.template에서 windows_use_single_network 플래그를 false로 설정하세요. 파드가 네트워킹된 후에 그 설정을 바꾸는 것은 권장하지 않아요. HNS 엔드포인트가 누출될 수 있어요.

기능	제한 사항
IPs reserved for Windows	Calico Cloud IPAM은 CIDR 블록 단위로 IP를 할당해요. Windows의 네트워킹 요구사항 때문에, Windows 노드가 소유한 블록마다 4개의 IP를 내부 목적으로 예약해야 해요. 예를 들어 기본 블록 크기가 /26이면 각 블록은 64개의 IP 주소를 담고, 4개는 Windows를 위해 예약되어 60개가 pod networking에 남아요. 이 예약의 영향을 줄이려면 (파드가 만들어지기 전에) IP 풀 범위에서 더 큰 블록 크기를 설정할 수 있어요.
Single IP block per host	Calico Cloud IPAM은 요청이 있을 때 호스트에 IP 블록(기본 크기 /26)을 할당하도록 설계됐어요. Calico Cloud CNI 플러그인도 같은 방식으로 작성되었지만, kube-proxy는 현재 호스트당 하나의 IP 블록만 지원해요. (kube-proxy 호환성을 희생하고) 호스트당 여러 IPAM 블록을 허용하려면, Calico Cloud를 설치하기 전에 `cni.conf.template`에서 `windows_use_single_network` 플래그를 `false`로 설정하세요. 파드가 네트워킹된 후에 그 설정을 바꾸는 것은 권장하지 않아요. HNS 엔드포인트가 누출될 수 있어요.

클라우드 프로바이더에서 라우트가 사라지는 문제

클라우드 프로바이더(예: AWS)로 Windows 호스트를 만들면, Calico Cloud 설치 시점의 vSwitch 생성이 클라우드 프로바이더의 메타데이터 라우트를 제거할 수 있어요. 애플리케이션이 메타데이터 서비스에 의존한다면, Calico Cloud를 설치하기 전과 후에 라우팅 테이블을 확인해서 잃어버린 라우트를 복구해야 할 수도 있어요.

VXLAN 제한

VXLAN 지원

Windows 1903 build 18317 이상
Windows 1809 build 17763 이상

구성 업데이트

특정 구성 변경은 첫 파드가 네트워킹된 후에는 반영되지 않아요. Windows가 현재 네트워크 생성 후 VXLAN 서브넷 파라미터 업데이트를 지원하지 않기 때문에, 그 파라미터를 업데이트하려면 노드를 drain해야 해요:

한 가지 예는 VXLAN VNI 설정이에요. 이런 파라미터를 바꾸려면:

모든 파드를 노드에서 drain하세요

Calico Cloud HNS 네트워크를 삭제하세요:

Import-Module -DisableNameChecking C:\TigeraCalico\libs\hns\hns.psm1
Get-HNSNetwork | ? Name -EQ "Calico Cloud" | Remove-HNSNetwork

config.ps1에서 설정을 업데이트하고, uninstall-calico.ps1을 실행한 뒤 install-calico.ps1을 실행해서 CNI 설정을 다시 생성하세요.

파드 간 연결이 TCP reset 패킷으로 끊기는 문제

Felix를 재시작하거나 정책 변경(정책이 참조하는 엔드포인트의 변경 포함)이 일어나면, 다음 중 하나에 해당할 때 파드 간 연결이 TCP reset 패킷으로 끊길 수 있어요:

파드에 적용되는 정책이 업데이트될 때
파드에 적용되는 ingress 또는 egress 정책에 셀렉터가 있고, 그 셀렉터가 매칭하는 엔드포인트 집합이 바뀔 때

Felix는 파드에 붙은 HNS ACL 정책을 재프로그래밍해야 해요. 이 재프로그래밍이 TCP reset을 일으킬 수 있어요. Microsoft는 이것이 HNS 문제임을 확인했고, 조사 중이에요.

네트워크 정책의 파드 IP 셀렉터와 호환되지 않는 서비스 ClusterIP

Windows 1809 build 17763.1432 이전

Windows 노드에서 kube-proxy는 로컬 파드에서 서비스 ClusterIP로 가는 트래픽에 무조건 source NAT를 적용해요. 즉 정책이 적용되는 목적지 파드 입장에서는, 트래픽이 소스 파드가 아니라 소스 호스트에서 온 것처럼 보여요. 그 결과 소스 파드와 매칭되는 소스 셀렉터를 가진 network policy가 기대한 트래픽과 매칭되지 않아요.

네트워크 정책과 셀렉터 사용

특정 조건에서는 비교적 단순한 Calico Cloud 정책이 Windows 데이터 플레인 자원을 크게 소모할 수 있어요. 이로 인해 CPU와 메모리 사용량이 커지고, 정책 프로그래밍 지연(latency)이 커질 수 있어요.

소스와 목적지 셀렉터를 모두 포함하는 규칙을 가진 정책은 피하는 것이 좋아요. 다음은 비효율적인 정책의 예제예요. 이 정책은 모든 워크로드에 적용되고, clients 레이블이 붙은 워크로드에서 servers 레이블이 붙은 워크로드로 가는 트래픽만 허용해요:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: calico-dest-selector
spec:
  selector: all()
  order: 500
  ingress:
    - action: Allow
      destination:
        selector: role == "webserver"
      source:
        selector: role == "client"

이 정책은 모든 워크로드에 적용되기 때문에 워크로드마다 한 번씩 렌더링돼요(그 워크로드가 server로 레이블되지 않았더라도). 그다음 셀렉터가 허용된 연결을 잡기 위해 많은 개별 데이터 플레인 규칙으로 확장돼요.

다음은 같은 트래픽을 여전히 허용하면서 훨씬 더 효율적인 정책이에요:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: calico-dest-selector
spec:
  selector: role == "webserver"
  order: 500
  ingress:
    - action: Allow
      source:
        selector: role == "client"

목적지 셀렉터가 정책 셀렉터로 옮겨갔기 때문에, 이 정책은 role: webserver 레이블이 있는 워크로드에만 렌더링돼요. 또한 규칙이 단순해져서 트래픽의 소스만 매칭해요. webserver 파드 수에 따라 다르겠지만, 이 변경으로 데이터 플레인 자원 사용량을 몇 자릿수(order of magnitude) 줄일 수 있어요.

티어가 있는 네트워크 정책

Windows 데이터 플레인이 규칙을 처리하는 방식 때문에, 성능 문제를 피하려면 다음 제한이 필요해요:

티어: 최대 5개
pass 규칙: 티어당 최대 10개
각 티어에 규칙이 많고 pass 규칙이 있다면, 티어 수를 더 줄여야 할 수도 있어요.

플로우 로그 제한

Calico Cloud는 다음 제한 사항과 함께 플로우 로그를 지원해요:

거부된 트래픽에 대한 packet/bytes 통계 없음
VXLAN 네트워킹에서 num_flows_started와 num_flows_completed 통계가 부정확함
DNS 통계 없음
HTTP 통계 없음
티어에 대한 RuleTrace 없음
BGP 로그 없음

DNS Policy 제한

SECONDARY: DNS Policy는 tech preview 기능이에요. tech preview 기능은 GA가 되기 전에 크게 바뀔 수 있어요.

Calico Cloud는 다음 제한 사항과 함께 Windows에서 DNS policy를 지원해요:

DNS 도메인 이름에 대한 연결에서 첫 TCP SYN 패킷이 통과하기까지 최대 5초가 걸릴 수 있어요. DNS 정책이 동적으로 프로그래밍되기 때문이에요. Calico Cloud가 DNS 응답에서 도메인 IP를 감지하고 DNS 정책 규칙을 프로그래밍하기 전까지는 그 트래픽을 허용하는 정책이 없어서, 첫 TCP 패킷이 드롭될 수 있어요. Windows TCPIP 스택은 이전 SYN이 드롭되면 TCP 재전송 타임아웃(RTO) 후에 SYN을 다시 보내요.
일부 런타임 라이브러리는 DNS TTL을 존중하지 않아요. 대신 자체 DNS 캐시를 관리하고, DNS 항목마다 다른 TTL 값을 사용해요. .NET Framework에서 DNS TTL을 제어하는 값은 ServicePointManager.DnsRefreshTimeout이고 기본값은 120초예요 - DNS refresh timeout. Calico Cloud가 애플리케이션이 사용하는 것보다 더 긴 TTL 값을 사용하는 것이 중요해요. 애플리케이션이 outbound 연결을 만들 때 DNS 정책이 이미 적용되고 있어야 하기 때문이에요. "WindowsDNSExtraTTL" 구성 항목은 여러분의 애플리케이션이 사용하는 런타임 라이브러리의 DNS TTL 최대값보다 커야 해요.
Windows 컨테이너 네트워킹의 제한 때문에, 정책 업데이트가 성능에 영향을 줄 수 있어요. DNS 정책 프로그래밍은 정책 업데이트를 더 많이 발생시킬 수 있어요. "WindowsDNSExtraTTL"을 더 큰 값으로 설정하면 성능 영향을 줄일 수 있어요.