Windows 디버깅 팁

Windows 디버깅 팁 (Windows debugging tips)

Windows 노드와 파드의 문제를 해결하기 위한 디버깅 팁을 정리한 페이지예요.

출처: 문서

본문

노드 레벨 문제 해결 (Node-level troubleshooting)

파드가 "Container Creating"에서 멈추거나 계속해서 재시작돼요 (My Pods are stuck at "Container Creating" or restarting over and over)

pause 이미지가 Windows OS 버전과 호환되는지 확인하세요. 최신/권장 pause 이미지를 보거나 더 많은 정보를 얻으려면 Pause container를 참고하세요.

참고: 컨테이너 런타임으로 containerd를 사용한다면 pause 이미지는 config.toml 구성 파일의 plugins.plugins.cri.sandbox_image 필드에 지정돼요.

파드 상태가 `ErrImgPull` 또는 `ImagePullBackOff`로 표시돼요 (My pods show status as `ErrImgPull` or `ImagePullBackOff`)

Pod가 호환되는 Windows 노드에 스케줄링되는지 확인하세요. Pod에 호환 가능한 노드를 지정하는 방법에 대한 자세한 정보는 이 가이드에서 찾을 수 있어요.

네트워크 문제 해결 (Network troubleshooting)

Windows Pod에 네트워크 연결이 없어요 (My Windows Pods do not have network connectivity)

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

Windows Pod가 외부 리소스를 ping할 수 없어요 (My Windows Pods cannot ping external resources)

Windows Pod는 ICMP 프로토콜에 대한 아웃바운드 규칙이 프로그래밍되어 있지 않아요. 그러나 TCP/UDP는 지원돼요. 클러스터 밖의 리소스에 대한 연결을 보여주려 할 때 ping <IP>를 해당 curl <IP> 명령으로 대체하세요.

여전히 문제가 있다면 cni.conf의 네트워크 구성을 좀 더 살펴볼 가치가 있어요. 이 정적 파일을 언제든 편집할 수 있어요. 구성 업데이트는 새 쿠버네티스 리소스에 적용돼요.

쿠버네티스 네트워킹 요구 사항 중 하나(쿠버네티스 모델 참고)는 내부적으로 NAT 없이 클러스터 통신이 발생하는 것이에요. 이 요구 사항을 지키기 위해 아웃바운드 NAT가 발생하지 않기를 원하는 모든 통신에 대해 ExceptionList가 있어요. 그러나 이는 또한 조회하려는 외부 IP를 ExceptionList에서 제외해야 한다는 뜻이에요. 그래야만 Windows pod에서 발생하는 트래픽이 외부 세계로부터 응답을 받도록 올바르게 SNAT될 거예요. 이와 관련해 cni.conf의 ExceptionList는 다음과 같아야 해요.

"ExceptionList": [
                "10.244.0.0/16",  # Cluster subnet
                "10.96.0.0/12",   # Service subnet
                "10.127.130.0/24" # Management (host) subnet
            ]

Windows 노드가 `NodePort` 유형 Service에 접근할 수 없어요 (My Windows node cannot access `NodePort` type Services)

노드 자체에서의 로컬 NodePort 접근은 실패해요. 이는 알려진 제한 사항이에요. NodePort 접근은 다른 노드나 외부 클라이언트에서 작동해요.

컨테이너의 vNIC와 HNS 엔드포인트가 삭제되고 있어요 (vNICs and HNS endpoints of containers are being deleted)

이 문제는 hostname-override 매개변수가 kube-proxy에 전달되지 않을 때 발생할 수 있어요. 해결하려면 사용자가 kube-proxy에 다음과 같이 호스트네임을 전달해야 해요.

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

Windows 노드가 service IP로 내 서비스에 접근할 수 없어요 (My Windows node cannot access my services using the service IP)

이는 Windows의 네트워킹 스택의 알려진 제한 사항이에요. 그러나 Windows Pod는 Service IP에 접근할 수 있어요.

kubelet 시작 시 네트워크 어댑터가 발견되지 않아요 (No network adapter is found when starting the kubelet)

Windows 네트워킹 스택은 쿠버네티스 네트워킹이 작동하려면 가상 어댑터가 필요해요. 다음 명령이 (관리 셸에서) 결과를 반환하지 않는다면, kubelet이 작동하는 데 필요한 전제 조건인 가상 네트워크 생성이 실패한 거예요.

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

호스트의 네트워크 어댑터가 "Ethernet"이 아닌 경우 start.ps1 스크립트의 InterfaceName 매개변수를 수정하는 것이 종종 가치가 있어요. 그렇지 않으면 start-kubelet.ps1 스크립트의 출력을 확인해 가상 네트워크 생성 중 오류가 있는지 확인하세요.

DNS 해석이 제대로 작동하지 않아요 (DNS resolution is not properly working)

이 섹션에서 Windows용 DNS 제한 사항을 확인하세요.

`kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패해요 (`kubectl port-forward` fails with "unable to do port forwarding: wincat not found")

이것은 쿠버네티스 1.15에서 pause 인프라스트럭처 컨테이너 mcr.microsoft.com/oss/kubernetes/pause:3.6에 wincat.exe를 포함시켜 구현됐어요. 지원되는 쿠버네티스 버전을 사용해야 해요. 자체 pause 인프라스트럭처 컨테이너를 빌드하려면 wincat을 포함해야 해요.

Windows Server 노드가 프록시 뒤에 있어 쿠버네티스 설치가 실패해요 (My Kubernetes installation is failing because my Windows Server node is behind a proxy)

프록시 뒤에 있다면 다음 PowerShell 환경 변수가 정의되어야 해요.

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

Flannel 문제 해결 (Flannel troubleshooting)

Flannel 사용 시 노드가 클러스터에 다시 조인한 후 문제가 있어요 (With Flannel, my nodes are having issues after rejoining a cluster)

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

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

Flanneld가 "Waiting for the Network to be created"에 멈춰 있어요 (Flanneld is stuck in "Waiting for the Network to be created")

이 문제에 대한 많은 보고가 있어요. 아마도 flannel 네트워크의 관리 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

`/run/flannel/subnet.env`가 없어 Windows Pod를 실행할 수 없어요 (My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`)

이는 Flannel이 올바르게 실행되지 않았음을 나타내요. flanneld.exe를 재시작하거나 쿠버네티스 마스터의 /run/flannel/subnet.env에서 Windows 워커 노드의 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

추가 조사 (Further investigation)

이 단계로 문제가 해결되지 않으면 다음을 통해 Windows 노드에서 Windows 컨테이너를 실행하는 데 도움을 받을 수 있어요.

StackOverflow Windows Server Container 주제
Kubernetes 공식 포럼 discuss.kubernetes.io
Kubernetes Slack #SIG-Windows 채널

Windows 디버깅 팁