본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

제한 사항 및 알려진 문제

원문 보기 위키 갱신

제한 사항 및 알려진 문제 (Limitations and known issues)

Windows용 Calico Open Source에는 설치를 계획하기 전에 반드시 확인해야 할 알려진 제한 사항들이 있습니다. 이 문서는 배포 가능한 플랫폼, 네트워킹 기능 제약, 알려진 이슈까지 한눈에 짚어 줍니다. Windows 노드를 클러스터에 넣기 전에 이 목록을 먼저 훑어보세요.

출처: 문서

본문

Windows용 Calico 기능 제한

기능
배포판(Distributions) 지원됨: - EKS - AKS - AWS - GCE - Azure - 온프레미스 Kubernetes - DigitalOcean의 Kubernetes - OpenShift - Rancher RKE 지원 안 됨: - GKE - IKS - OpenStack - K3s 클러스터
설치 및 업그레이드 지원됨: - 오퍼레이터 설치 지원 안 됨: - 비(非)클러스터 호스트 - 확장용 Typha 컴포넌트 (Linux 기반 기능)
네트워킹 지원됨: - Calico VXLAN, 크로스 서브넷 또는 VXLAN MTU 설정 없음, 제한 사항 있음 - BGP 피어링을 사용하는 Calico 논오버레이(non-overlay) 모드, 제한 사항 있음 - IPv4 지원 안 됨: - BGP 피어링을 사용하는 오버레이 모드 - BGP 라우팅을 사용하는 IP in IP 오버레이 - VXLAN의 크로스 서브넷 지원 및 MTU 설정 - IPv6 및 듀얼 스택 - 서비스 광고
보안 지원 안 됨: - Istio용 애플리케이션 계층 정책(ALP) - 호스트를 위한 정책 (자동 호스트 엔드포인트를 포함한 호스트 엔드포인트) - WireGuard를 사용한 암호화
가시성 및 문제 해결 가시성 및 문제 해결
운영(Operations) 지원됨: - Calico 노드 상태
메트릭 지원됨: Prometheus 모니터링
eBPF 지원 안 됨: (Linux 기반 기능)

Calico BGP 네트워킹 제한

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

기능 제한
IP 이동성/빌리기(borrowing) Calico IPAM은 집계를 위해 호스트에 IP를 블록 단위로 할당합니다. IP 풀이 가득 차면 노드는 다른 노드의 블록에서 IP를 "빌릴" 수도 있습니다. BGP 관점에서 보면 IP를 빌려간 쪽은 빌린 IP에 대해 더 구체적인 "/32" 경로를 광고하고, 그 IP로 향하는 트래픽만 빌려간 호스트로 라우팅됩니다. Windows 노드는 이 빌리기 메커니즘을 지원하지 않습니다. IP 풀이 가득 찼더라도 IP를 빌리지 않으며, 자신의 블록에 Linux 노드가 빌려가지 못하도록 표시를 남깁니다.
Windows용으로 예약된 IP Calico IPAM은 CIDR 블록 단위로 IP를 할당합니다. Windows의 네트워킹 요구 사항 때문에 Windows 노드가 소유한 블록마다 네 개의 IP를 내부 용도로 예약해야 합니다. 예를 들어 기본 블록 크기가 /26이면 각 블록은 64개의 IP 주소를 담고, 4개는 Windows용으로 예약되어 파드 네트워킹에 60개가 남습니다. 이 예약의 영향을 줄이려면 (파드를 만들기 전에) IP 풀 범위에서 더 큰 블록 크기를 설정할 수 있습니다.
호스트당 단일 IP 블록 Calico IPAM은 요청 시 호스트에 (기본 크기 /26의) IP 블록을 할당하도록 설계되었습니다. Calico CNI 플러그인도 같은 방식으로 작성되었지만, kube-proxy는 현재 호스트당 단일 IP 블록만 지원합니다. 호스트당 /26 하나라는 기본 제한을 우회하는 몇 가지 옵션이 있습니다. - 블록을 만들기 전에 Calico BGP 네트워킹과 etcd 데이터스토어를 사용한다면, IP 풀에서 사용하는 블록 크기를 단일 Windows 호스트에서 사용할 파드 수의 최댓값을 감당할 수 있도록 바꾸세요. - 쿠버네티스 데이터스토어와 함께 Calico BGP 네트워킹을 사용하세요. 이 모드에서는 Calico IPAM을 사용하지 않고, 노드의 Pod CIDR로 CNI host-local IPAM 플러그인을 사용합니다. 호스트당 여러 IPAM 블록을 허용하려면(kube-proxy 호환성을 희생하면서) Calico 설치 전에 cni.conf.template에서 windows_use_single_network 플래그를 false로 설정하세요. 파드가 이미 네트워킹된 뒤에 이 설정을 바꾸는 것은 HNS 엔드포인트가 누출될 수 있어 권장하지 않습니다.
IP-in-IP 오버레이 Calico의 IPIP 오버레이 모드는 Windows가 IP-in-IP를 지원하지 않기 때문에 Windows 노드가 포함된 클러스터에서는 사용할 수 없습니다.
NATOutgoing Calico IP 풀은 다음 동작을 가진 "NAT outgoing" 설정을 지원합니다. - (어떤 IP 풀에 있든) Calico 워크로드 간 트래픽은 NAT되지 않습니다. - 설정된 IP 풀 밖으로 나가는 트래픽은 워크로드가 NAT outgoing이 활성화된 IP 풀 안의 IP를 가질 때 NAT됩니다. Windows용 Calico도 위 설정을 존중하지만 파드 생성 시점에만 적용됩니다. 파드가 생성된 뒤 IP 풀 설정이 업데이트되면 그 파드의 트래픽은 이전과 같이 (NAT되거나 그렇지 않은 채로) 계속됩니다. 새로 네트워킹되는 파드의 NAT 정책은 새 설정을 따릅니다. Windows용 Calico는 호스트 자신과 그 서브넷을 NAT 제외 목록에 자동으로 추가합니다. 이 동작은 설치 스크립트를 실행하기 전에 cni.conf.template에서 windows_disable_host_subnet_nat_exclusion 플래그를 true로 설정해 비활성화할 수 있습니다.
서비스 IP 광고 이 Calico 기능은 Windows에서 지원되지 않습니다.

네트워크 구성 확인하기

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

각 노드에서 파드 네트워킹에 사용할 네트워크 어댑터의 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 네트워크에 있을 가능성은 낮습니다.

Calico VXLAN 네트워킹 제한

Linux와 Windows 데이터 플레인 기능 집합의 차이 때문에 다음 Calico 기능들은 Windows에서 지원되지 않습니다.

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

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

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

VXLAN 제한

VXLAN 지원

  • Windows 1903 빌드 18317 이상
  • Windows 1809 빌드 17763 이상

설정 업데이트

첫 파드가 네트워킹된 이후에는 특정 설정 변경이 반영되지 않습니다. Windows는 현재 네트워크가 생성된 뒤 VXLAN 서브넷 파라미터 업데이트를 지원하지 않아서, 그 파라미터를 바꾸려면 노드를 드레인해야 합니다.

한 예가 VXLAN VNI 설정입니다. 이런 파라미터를 바꾸려면:

  • 모든 파드를 노드에서 드레인합니다.

  • Calico HNS 네트워크를 삭제합니다.

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

  • config.ps1의 설정을 업데이트하고, uninstall-calico.ps1을 실행한 다음 install-calico.ps1을 실행해 CNI 설정을 다시 생성합니다.

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

Felix를 재시작하거나 정책 변경(정책에서 참조하는 엔드포인트의 변경 포함)이 일어나면, 파드 간 연결이 TCP 리셋 패킷으로 끊길 수 있습니다. 다음 중 하나가 일어나면:

  • 파드에 적용되는 정책이 업데이트됨
  • 파드에 적용되는 ingress 또는 egress 정책이 셀렉터를 포함하고, 그 셀렉터가 매치하는 엔드포인트 집합이 바뀜

Felix는 파드에 붙은 HNS ACL 정책을 다시 프로그래밍해야 합니다. 이 재프로그래밍이 TCP 리셋을 일으킬 수 있습니다. Microsoft는 이것이 HNS 문제임을 확인했고 조사 중입니다.

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

Windows 1809 빌드 17763.1432 이전

Windows 노드에서 kube-proxy는 로컬 파드에서 서비스 ClusterIP로 가는 트래픽에 무조건 소스 NAT를 적용합니다. 즉, 정책이 적용되는 목적지 파드에서 보면 트래픽이 소스 파드가 아니라 소스 호스트에서 온 것처럼 보입니다. 그 결과, 소스 파드에 매치하는 소스 셀렉터를 가진 네트워크 정책은 기대한 트래픽에 매치하지 않습니다.

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

특정 조건에서는 비교적 단순한 Calico 정책이라도 상당한 Windows 데이터 플레인 자원을 요구할 수 있고, 이는 큰 CPU와 메모리 사용량, 그리고 큰 정책 프로그래밍 지연으로 이어질 수 있습니다.

소스와 목적지 셀렉터를 모두 가진 규칙이 포함된 정책은 피하는 것을 권장합니다. 다음은 비효율적일 수 있는 정책의 예입니다. 이 정책은 모든 워크로드에 적용되며, client로 레이블된 워크로드에서 server로 레이블된 워크로드로 가는 트래픽만 허용합니다.

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 파드 수에 따라 이 변경은 데이터 플레인 자원 사용량을 몇 자릿수 줄일 수 있습니다.

다음 단계(Next steps)

더 알아보기 (Learn more)

Windows용 Calico는 Linux와 데이터 플레인 구조가 달라서 지원되지 않는 기능이 상당히 많습니다. 설치 전에 기능 제한 표를 꼼꼼히 확인하고, BGP/VXLAN 제약은 IPAM 블록 설계에 직접 영향을 준다는 점을 기억하세요. 셀렉터를 정책 셀렉터로 올리는 최적화 기법은 Windows에서 특히 효과가 큽니다.