Kubernetes 문제 해결

  • 아티클

이 페이지에서는 Kubernetes 설정, 네트워킹 및 배포와 관련된 몇 가지 일반적인 문제를 안내합니다.

팁

설명서 리포지토리에 PR 을 올려 FAQ 항목을 제안합니다.

이 페이지는 다음 범주로 세분화됩니다.

  1. 일반적인 질문
  2. 일반적인 네트워킹 오류
  3. 일반적인 Windows 오류
  4. 일반적인 Kubernetes 마스터 오류

일반적인 질문

Windows의 Kubernetes가 성공적으로 완료되었는지 어떻게 할까요? 알고 있나요?

kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행되는 flanneld 호스트 에이전트 프로세스가 표시됩니다. 이 외에도 Windows 노드는 Kubernetes 클러스터에 "준비됨"으로 나열되어야 합니다.

이 모든 것을 백그라운드에서 실행하도록 구성할 수 있나요?

Kubernetes 버전 1.11부터 kubelet 및 kube-proxy를 네이티브 Windows 서비스로 실행할 수 있습니다. nssm.exe와 같은 대체 서비스 관리자를 항상 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet 및 kube-proxy)를 항상 실행할 수도 있습니다.

일반적인 네트워킹 오류

부하 분산 장치는 클러스터 노드 간에 일관되지 않게 배관됩니다.

Windows에서 kube-proxy는 클러스터의 모든 Kubernetes 서비스에 대한 HNS 부하 분산 장치를 만듭니다. (기본값) kube-proxy 구성에서 많은(일반적으로 100개 이상) 부하 분산 장치가 포함된 클러스터의 노드는 사용 가능한 임시 TCP 포트(즉, 기본적으로 포트 49152~65535를 포함하는 동적 포트 범위)가 부족할 수 있습니다. 이는 모든(비 DSR) 부하 분산 장치에 대해 각 노드에 예약된 포트 수가 많기 때문입니다. 이 문제는 다음과 같은 kube 프록시의 오류를 통해 나타날 수 있습니다.

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

사용자는 CollectLogs.ps1 스크립트를 실행하고 파일을 참조하여 이 문제를 식별할 *portrange.txt 수 있습니다.

CollectLogs.ps1 또한 HNS 할당 논리를 모방하여 임시 TCP 포트 범위에서 포트 풀 할당 가용성을 테스트하고 성공/실패를 reservedports.txt보고합니다. 스크립트는 64TCP 임시 포트의 10개 범위를 예약하고(HNS 동작을 에뮬레이트하기 위해), 예약 성공 및 실패 수를 계산한 다음 할당된 포트 범위를 해제합니다. 성공 번호가 10보다 작을 경우 임시 풀에 사용 가능한 공간이 부족합니다. 약 사용 가능한 64블록 포트 예약 수에 대한 휴리 요약도 생성 reservedports.txt됩니다.

이 문제를 해결하려면 몇 가지 단계를 수행할 수 있습니다.

  1. 영구 솔루션의 경우 kube-proxy 부하 분산을 DSR 모드로 설정해야 합니다. DSR 모드는 완전히 구현되며 최신 Windows Server 참가자 빌드 18945 이상에서만 사용할 수 있습니다.
  2. 해결 방법으로 사용자는 다음과 같은 netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>명령을 사용하여 사용 가능한 임시 포트의 기본 Windows 구성을 늘릴 수도 있습니다. 경고: 기본 동적 포트 범위를 재정의하면 임시 범위가 아닌 범위에서 사용 가능한 TCP 포트를 사용하는 호스트의 다른 프로세스/서비스에 영향을 줄 수 있으므로 이 범위를 신중하게 선택해야 합니다.
  3. 누적 업데이트 KB4551853(및 모든 최신 누적 업데이트)에 포함된 지능형 포트 풀 공유를 사용하여 비 DSR 모드 부하 분산 장치에 대한 확장성이 향상되었습니다.

HostPort 게시가 작동하지 않음

HostPort 기능을 사용하려면 CNI 플러그 인이 v0.8.6 릴리스 이상이고 CNI 구성 파일에 portMappings 다음 기능이 설정되어 있는지 확인하세요.

"capabilities": {
    "portMappings":  true
}

"Win32에서 hnsCall 실패: 잘못된 디스켓이 드라이브에 있습니다."와 같은 오류가 표시됩니다.

이 오류는 HNS 개체를 사용자 지정 수정하거나 이전 HNS 개체를 삭제하지 않고 HNS를 변경하는 새 Windows 업데이트 설치할 때 발생할 수 있습니다. 업데이트 전에 이전에 만든 HNS 개체가 현재 설치된 HNS 버전과 호환되지 않음을 나타냅니다.

Windows Server 2019 및 이전 버전에서 사용자는 HNS.data 파일을 삭제하여 HNS 개체를 삭제할 수 있습니다.

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

사용자는 호환되지 않는 모든 HNS 엔드포인트 또는 네트워크를 직접 삭제할 수 있어야 합니다.

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Windows Server 버전 1903의 사용자는 다음 레지스트리 위치로 이동하여 네트워크 이름(예: 또는cbr0)으로 시작하는 모든 NIC를 삭제할 수 있습니다. vxlan0

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Azure에서 Flannel host-gw 배포의 컨테이너가 인터넷에 연결할 수 없음

Azure에서 host-gw 모드로 Flannel을 배포하는 경우 패킷은 Azure 물리적 호스트 vSwitch를 통과해야 합니다. 사용자는 노드에 할당된 각 서브넷에 대해 "가상 어플라이언스" 형식의 사용자 정의 경로를 프로그래밍해야 합니다. 이 작업은 Azure Portal(여기서 예제 참조) 또는 Azure CLI를 통해 az 수행할 수 있습니다. 다음은 IP 10.0.0.4 및 해당 Pod 서브넷 10.244.0.0/24가 있는 노드에 az 명령을 사용하는 이름이 "MyRoute"인 UDR 예제입니다.

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

팁

Azure 또는 다른 클라우드 공급자의 IaaS VM에 Kubernetes를 직접 배포하는 경우 대신 사용할 overlay networking 수도 있습니다.

내 Windows Pod에서 외부 리소스를 ping할 수 없음

Windows Pod에는 현재 ICMP 프로토콜에 대해 프로그래밍된 아웃바운드 규칙이 없습니다. 그러나 TCP/UDP는 지원됩니다. 클러스터 외부의 리소스에 대한 연결을 보여 주려는 경우 해당 curl <IP> 명령으로 대체 ping <IP> 하세요.

여전히 문제가 있는 경우 cni.conf의 네트워크 구성에 주의해야 할 가능성이 높습니다. 언제든지 이 정적 파일을 편집할 수 있으며 구성은 새로 만든 Kubernetes 리소스에 적용됩니다.

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

"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 서비스에 액세스할 수 없음

노드 자체에서 로컬 NodePort 액세스가 실패할 수 있습니다. 이는 누적 업데이트 KB4571748 이상에서 해결되는 알려진 기능 간격입니다. NodePort 액세스는 다른 노드 또는 외부 클라이언트에서 작동합니다.

Pod를 축소한 후 Windows 노드가 thourgh NodePorts 라우팅을 중지합니다.

디자인 제한으로 인해 NodePort 전달이 작동하려면 Windows 노드에서 실행 중인 Pod가 하나 이상 있어야 합니다.

잠시 후 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제됩니다.

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

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

Flannel(vxlan) 모드에서 노드에 다시 가입한 후 Pod에 연결 문제가 발생합니다.

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

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

Kubernetes를 시작한 후 Flanneld는 "네트워크가 생성되기를 기다리는 중"에 갇혀 있습니다.

이 문제는 Flannel v0.12.0 이상에서 해결해야 합니다. 이전 버전의 Flanneld를 사용하는 경우 플란넬 네트워크의 관리 IP가 설정되지 않도록 발생할 수 있는 알려진 경합 상태가 있습니다. 해결 방법은 FlannelD를 수동으로 다시 시작하기 위한 것입니다.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> 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를 시작할 수 없습니다.

이는 Flannel이 제대로 시작되지 않았음을 나타냅니다. flanneld.exe를 다시 시작하거나 Kubernetes 마스터 C:\run\flannel\subnet.env 에서 /run/flannel/subnet.env Windows 작업자 노드로 수동으로 파일을 복사하고 할당된 서브넷으로 행을 수정 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

더 자주는 아니지만 먼저 조사해야 하는 이 오류를 일으킬 수 있는 또 다른 문제가 있습니다. 이 파일을 생성할 수 있도록 flanneld.exe 하는 것이 좋습니다.

vSphere에서 실행되는 Kubernetes 클러스터에서 호스트 간의 Pod 간 연결이 끊어짐

vSphere와 Flannel은 모두 오버레이 네트워킹을 위해 포트 4789(기본 VXLAN 포트)를 예약하므로 패킷이 가로챌 수 있습니다. vSphere가 오버레이 네트워킹에 사용되는 경우 4789를 확보하려면 다른 포트를 사용하도록 구성해야 합니다.

내 엔드포인트/IP가 누출되고 있습니다.

엔드포인트가 누출될 수 있는 현재 알려진 두 가지 문제가 있습니다.

  1. 첫 번째 알려진 문제는 Kubernetes 버전 1.11의 문제입니다. Kubernetes 버전 1.11.0 - 1.11.2를 사용하지 마십시오.
  2. 엔드포인트가 누출될 수 있는 알려진 두 번째 문제는 엔드포인트 스토리지의 동시성 문제입니다. 수정 사항을 받으려면 Docker EE 18.09 이상을 사용해야 합니다.

"네트워크: 범위에 할당하지 못했습니다." 오류로 인해 Pod를 시작할 수 없습니다.

노드의 IP 주소 공간이 사용됨을 나타냅니다. 유출된 엔드포인트를 클린 영향을 받은 노드에서 리소스를 마이그레이션하고 다음 명령을 실행하세요.

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

내 Windows 노드가 서비스 IP를 사용하여 내 서비스에 액세스할 수 없음

이는 Windows의 현재 네트워킹 스택에 대한 알려진 제한 사항입니다. 그러나 Windows Pod는 서비스 IP에 액세스할 수 있습니다.

Kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없음

Windows 네트워킹 스택에는 Kubernetes 네트워킹이 작동하려면 가상 어댑터가 필요합니다. 다음 명령이 결과(관리 셸에서)를 반환하지 않으면 Kubelet이 작동하는 데 필요한 필수 조건인 HNS 네트워크 생성이 실패했습니다.

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

호스트의 네트워크 어댑터가 "이더넷"이 아닌 경우 start.ps1 스크립트의 InterfaceName 매개 변수를 수정하는 것이 좋습니다. 그렇지 않으면 가상 네트워크를 만드는 동안 오류가 있는지 확인하려면 스크립트의 start-kubelet.ps1 출력을 참조하세요.

나는 아직도 문제를 보고 있다. 어떻게 해야 합니까?

네트워크 또는 호스트에서 노드 간의 특정 유형의 통신을 방지하는 추가 제한 사항이 있을 수 있습니다. 다음 사항을 확인합니다.

  • 선택한 네트워크 토폴로지(l2bridge 또는 overlay)를 올바르게 구성한 경우
  • Pod에서 들어오는 것처럼 보이는 트래픽은 허용됩니다.
  • 웹 서비스를 배포하는 경우 HTTP 트래픽이 허용됩니다.
  • 다른 프로토콜의 패킷(예: ICMP 및 TCP/UDP)이 삭제되지 않습니다.

팁

추가 자가 진단 리소스의 경우 여기에서 사용할 수 있는 Windows 용 Kubernetes 네트워킹 문제 해결 가이드도 있습니다.

일반적인 Windows 오류

내 Kubernetes Pod가 "ContainerCreating"에 고정됨

이 문제에는 많은 원인이 있을 수 있지만 가장 일반적인 것 중 하나는 일시 중지 이미지가 잘못 구성되었다는 것입니다. 이것은 다음 문제의 높은 수준의 증상입니다.

배포할 때 Docker 컨테이너는 계속 다시 시작됩니다.

일시 중지 이미지가 OS 버전과 호환되는지 확인합니다. Kubernetes는 OS와 컨테이너 모두 OS 버전 번호가 일치한다고 가정합니다. 참가자 빌드와 같은 실험적 Windows 빌드를 사용하는 경우 그에 따라 이미지를 조정해야 합니다. 이미지는 Microsoft의 Docker 리포지 토리를 참조하세요.

일반적인 Kubernetes 마스터 오류

Kubernetes 마스터 디버깅은 세 가지 기본 범주로 분류됩니다(가능성 순서).

  • Kubernetes 시스템 컨테이너에 문제가 있습니다.
  • 실행 중인 방식에 kubelet 문제가 있습니다.
  • 시스템에 문제가 있습니다.

Kubernetes에서 생성되는 Pod를 확인하려면 실행 kubectl get pods -n kube-system 합니다. 그러면 어떤 특정 Pod가 충돌하거나 올바르게 시작되지 않는지 파악할 수 있습니다. 그런 다음, 실행 docker ps -a 하여 이러한 Pod를 백업하는 모든 원시 컨테이너를 확인합니다. 마지막으로 문제가 발생한 것으로 의심되는 컨테이너에서 실행 docker logs [ID] 하여 프로세스의 원시 출력을 확인합니다.

에서 API 서버에 연결할 수 없습니다. https://[address]:[port]

이 오류는 인증서 문제를 나타내는 경우가 많습니다. 구성 파일을 올바르게 생성했는지, 구성 파일의 IP 주소가 호스트의 주소와 일치하는지, API 서버에 의해 탑재된 디렉터리에 복사했는지 확인합니다.

이 구성 파일을 찾을 수 있는 좋은 위치는 다음과 같습니다.

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

그렇지 않으면 API 서버의 매니페스트 파일을 참조하여 탑재 지점을 검사.