윈도우 디버깅 팁

노드-수준 트러블슈팅

1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.

   퍼즈(pause) 이미지가 OS 버전과 호환되는지 확인한다. 퍼즈 컨테이너에서 최신 / 추천 퍼즈 이미지 및 추가 정보를 확인한다.

   참고:

   컨테이너 런타임으로 containerd를 사용하고 있다면, 퍼즈 이미지는 config.toml 환경 설정 파일의 plugins.plugins.cri.sandbox_image 필드에 명시되어 있다.

2. 내 파드의 상태가 ErrImgPull 또는 ImagePullBackOff이다.

   파드가 호환되는 윈도우 노드에 스케줄링되었는지 확인한다.

   각 파드와 호환되는 노드를 찾는 방법에 대한 추가 정보는 이 가이드를 참고한다.

네트워크 트러블슈팅

1. 내 윈도우 파드에 네트워크 연결이 없다.

   가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에 MAC 스푸핑이 활성화되어 있는지 확인한다.

2. 내 윈도우 파드가 외부 리소스를 ping 할 수 없다.

   윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, ping <IP>를 대응되는 curl <IP>명령으로 대체한다.

   여전히 문제가 발생하는 경우, cni.conf의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다.

   쿠버네티스 네트워킹 요구 사항(쿠버네티스 모델 참조) 중 하나는 클러스터 통신이 NAT 없이 내부적으로 발생해야 한다는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 ExceptionList가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 cni.conf의 ExceptionList는 다음과 같아야 한다.

   "ExceptionList": [
                   "10.244.0.0/16",  # 클러스터 서브넷
                   "10.96.0.0/12",   # 서비스 서브넷
                   "10.127.130.0/24" # 관리(호스트) 서브넷
               ]
   

3. 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다.

   노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다.

4. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제된다.

   이 문제는 hostname-override 파라미터가 kube-proxy에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.

   C:\k\kube-proxy.exe --hostname-override=$(hostname)
   

5. 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다.

   이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다.

6. kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다.

   윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. (어드민 셸에서) 다음 명령이 결과를 반환하지 않으면, Kubelet이 작동하는 데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다.

   Get-HnsNetwork | ? Name -ieq "cbr0"
   Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
   

   호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 InterfaceName 파라미터를 수정하는 것이 좋다. 그렇지 않으면 start-kubelet.ps1 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.

7. DNS 해석(resolution)이 제대로 작동하지 않는다.

   이 섹션에서 윈도우에서의 DNS 제한을 확인한다.

8. kubectl port-forward가 "unable to do port forwarding: wincat not found" 에러와 함께 실패한다.

   이 기능은 퍼즈 인프라 컨테이너 mcr.microsoft.com/oss/kubernetes/pause:3.6에 wincat.exe를 포함시킴으로써 쿠버네티스 1.15에서 구현되었다. 지원되는 쿠버네티스 버전을 사용하고 있는지 확인한다. 퍼즈 인프라 컨테이너를 직접 빌드하려면 wincat을 포함시켜야 한다.

9. 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 쿠버네티스 설치에 실패한다.

   프록시 뒤에 있는 경우, 다음 PowerShell 환경 변수를 정의해야 한다.

   [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
   [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
   

플란넬 트러블슈팅

1. 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다.

   이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다.

   Remove-Item C:\k\SourceVip.json
   Remove-Item C:\k\SourceVipRequest.json
   

2. flanneld가 "Waiting for the Network to be created" 상태에서 멈춘다.

   이 이슈에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다.

   [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
   C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
   

3. /run/flannel/subnet.env 누락으로 인해 윈도우 파드를 시작할 수 없다.

   이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 /run/flannel/subnet.env에서 윈도우 워커 노드의 C:\run\flannel\subnet.env로 파일을 수동으로 복사할 수 있고, FLANNEL_SUBNET 행을 다른 숫자로 수정한다. 예를 들어, 노드 서브넷 10.244.4.1/24가 필요한 경우 다음과 같이 설정한다.

   FLANNEL_NETWORK=10.244.0.0/16
   FLANNEL_SUBNET=10.244.4.1/24
   FLANNEL_MTU=1500
   FLANNEL_IPMASQ=true
   

추가 조사

이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는 데 도움을 받을 수 있다.

• 스택오버플로우 윈도우 서버 컨테이너 주제
• 쿠버네티스 공식 포럼 discuss.kubernetes.io
• 쿠버네티스 슬랙 #SIG-Windows Channel