TKGS 클러스터 네트워킹 오류 문제를 해결하려면 이 섹션의 팁을 참조하십시오.
노드 네트워킹 확인
각 TKG 클러스터에는 다음과 같은 네트워크 리소스가 있어야 합니다.
| 네트워크 개체 | 네트워크 리소스 | 설명 | 문제 해결 | 명령 |
|---|---|---|---|---|
| VirtualNetwork | Tier-1 라우터 및 연결된 세그먼트 | 클러스터에 대한 노드 네트워크 | SNAT IP가 할당되었는지 확인 | kubectl get virtualnetwork -n NS-NAME |
| VirtualNetworkInterface | 세그먼트의 논리적 포트 | 클러스터 노드에 대한 노드 네트워크 인터페이스 | 각 VirtualMachine에 IP 주소가 있는지 확인 | kubectl get virtualmachines -n NS-NAME NODE-NAME |
제어부에 대한 로드 밸런서 확인
TKG 클러스터 제어부에 대한 로드 밸런서는 Kubernetes API 서버에 대한 액세스를 제공합니다. 이 로드 밸런서는 클러스터 생성 중에 시스템에 의해 자동으로 프로비저닝됩니다. 다음 리소스가 있어야 합니다.
제어부 로드 밸런서의 상태를 확인하면 오류가 발생했을 때 리소스가 준비되었는지 파악하는 데 도움이 될 수 있습니다. 일반적으로 감독자 클러스터에 대해 다음 명령으로 이 로드 밸런서 찾기를 사용하여 이 로드 밸런서를 찾습니다.
kubectl get services -A | grep control-plane-service
| 네트워크 개체 | 네트워크 리소스 | 설명 | 문제 해결 | 명령 |
|---|---|---|---|---|
| VirtualMachineService | 해당 없음 | VirtualMachineService가 생성되고 k8s 서비스로 변환됩니다. | 상태가 업데이트되고 로드 밸런서 VIP(가상 IP)가 포함되어 있는지 확인합니다. | kubectl get virtualmachineservices -n NS-NAME SERVICE-NAME |
| 서비스 | VirtualServer 인스턴스 및 연결된 서버 풀(멤버 풀)이 있는 로드 밸런서 서버 | TKG 클러스터 API 서버에 액세스하기 위해 Load Balancer 유형의 Kubernetes 서비스가 생성됩니다. | 외부 IP가 할당되었는지 확인합니다. LB 서비스의 외부 IP를 통해 TKG 클러스터 API에 액세스할 수 있는지 확인합니다. |
감독자 네임스페이스:
kubectl get services -A | grep control-plane-service
클러스터 네임스페이스:
kubectl get services -n NS-NAME
둘 중 하나의 네임스페이스
curl -k https://EXTERNAL-IP:PORT/healthz |
| 끝점 | 끝점 멤버(TKG 클러스터 제어부 노드)는 멤버 풀에 있어야 합니다. | 모든 TKG 클러스터 제어부 노드를 포함하도록 끝점이 생성됩니다. | kubectl get endpoints -n NS-NAME SERVICE-NAME |
작업자 노드에서 로드 밸런서 서비스 확인
TKG 클러스터 작업자 노드에 대한 로드 밸런서 인스턴스는 LoadBalancer 유형의 Kubernetes 서비스가 생성될 때 사용자가 생성합니다.
첫 번째 단계는 클라우드 제공자가 TKG 클러스터에서 실행되고 있는지 확인하는 것입니다.
kubectl get pods -n vmware-system-cloud-provider
관련 Kubernetes 개체가 생성되었고 올바른 상태에 있는지 확인합니다.
| 네트워크 개체 | 네트워크 리소스 | 설명 | 명령 |
|---|---|---|---|
| 감독자의 VirtualMachineService | 해당 없음 | 감독자에서 VirtualMachineService가 생성되고 감독자에서 Kubernetes 서비스로 변환됨 | kubectl get virtualmachineservice -n NS-NAME SVC-NAME |
| 감독자의 로드 밸런서 서비스 | TKG 클러스터 로드 밸런서의 VirtualServer 및 연결된 멤버 풀. | 이 LB 유형의 서비스에 액세스하기 위해 감독자에서 로드 밸런서 서비스가 생성됨 | kubectl get services -n NS-NAME SVC-NAME |
| 감독자의 끝점 | 끝점 멤버(TKG 클러스터 작업자 노드)는 NSX의 멤버 풀에 있어야 합니다. | 모든 TKG 클러스터 작업자 노드를 포함하도록 끝점이 생성됩니다. | # kubectl get endpoints -n NS-NAME SVC-NAME |
| TKG 클러스터의 로드 밸런서 서비스 | 해당 없음 | 사용자가 배포한 TKG 클러스터의 로드 밸런서 서비스의 상태가 로드 밸런서 IP로 업데이트되어야 합니다. | kubectl get services |
감독자 NSX 네트워킹 스택 확인
컨트롤러 포드에서 실행되는 Kubernetes API 서버, NCP 포드 및 관리자 컨테이너는 인프라 네트워킹 문제를 확인하기 위한 기본 시작점입니다.
다음 오류 메시지는 ESXi 호스트 NIC가 연결되어 있는 물리적 포트 그룹을 포함하여 네트워크 패브릭의 모든 지점에서 라우팅 또는 MTU 문제를 나타낼 수 있습니다.
{"log":"I0126 19:40:15.347154 1 log.go:172] http: TLS handshake error from
100.64.128.1:4102: EOF\n","stream":"stderr","time":"2021-01-26T19:40:15.347256146Z"}
문제를 해결하려면 SSH를 통해 ESXi 호스트에 연결하고 다음 명령을 실행합니다.
esxcli network ip interface ipv4 get
이 명령은 호스트의 모든 vmkernel 인터페이스를 나열합니다. 단일 TEP 인터페이스가 있는 경우 항상 vmk10입니다. 2번째 또는 3번째 TEP 인터페이스가 있는 경우 vmk11 및 vmk12 등이 됩니다. 생성된 TEP 인터페이스의 수량은 업링크 프로파일의 TEP에 할당한 업링크 수에 따라 다릅니다. 업링크 간 TEP에 대해 "로드 공유"를 선택한 경우 업링크별로 TEP 인터페이스가 생성됩니다.
기본 TEP-TEP ping 명령에는 다음과 같은 구문이 있습니다.
vmkping ++netstack=vxlan -s 1572 -d -I vmk10 10.218.60.66
여기서
-s는 패킷 크기입니다.-d는 조각화하지 않음을 의미합니다.-I는 vmk10의 링크를 소스로 지정합니다.IP address는 ping하는 다른 ESXi 호스트 또는 NSX Edge의 TEP 인터페이스입니다.
