팟 (Pod) 간 네트워크 연결 디버깅
팟 (Pod) 간의 연결 문제를 디버깅하기 위한 옵션 및 전략을 검토하십시오.
클러스터 컴포넌트 및 네트워킹 팟 (Pod) 의 상태 확인
컴포넌트의 상태를 확인하려면 다음 단계를 수행하십시오. 클러스터 컴포넌트가 최신 상태가 아니거나 정상 상태가 아닌 경우 네트워킹 문제가 발생할 수 있습니다.
-
클러스터 마스터 및 작업자 노드가 지원되는 버전에서 실행되고 정상 상태인지 확인하십시오. 클러스터 마스터 또는 작업자가 지원되는 버전을 실행하지 않는 경우 지원되는 버전을 실행하도록 필요한 업데이트를 작성 하십시오. 구성 요소의 상태가
Normal
또는Ready
이 아닌 경우 클러스터 마스터 상태, 클러스터 상태 를 검토하세요, 워커 노드 상태 또는 문제 해결 단계Critical
또는NotReady
워커 노드 에서 자세한 내용을 확인하세요. 계속하기 전에 관련 문제가 해결되었는지 확인하십시오.클러스터 마스터 버전 및 상태를 확인하려면 다음을 수행하십시오.
ibmcloud ks cluster get -c <cluster-id>
작업자 노드 버전 및 상태를 확인하려면 다음을 수행하십시오.
ibmcloud ks workers -c <cluster-id>
-
각 작업자 노드에 대해 Calico 및 클러스터 DNS팟 (Pod) 이 존재하고 정상 상태에서 실행 중인지 확인하십시오.
-
명령을 실행하여 클러스터의 파드에 대한 세부 정보를 얻습니다.
kubectl get pods -A -o wide | grep -e calico -e coredns
-
출력에서 클러스터에 다음 팟 (Pod) 이 포함되어 있는지 확인하십시오. 각 팟 (Pod) 의 상태가
Running
이고 팟 (Pod) 에 너무 많은 다시 시작이 있지 않은지 확인하십시오.- 작업자 노드당 정확히 하나의
calico-node
팟 (Pod). - 클러스터당 하나 이상의
calico-typha
팟 (Pod). 더 큰 클러스터에는 둘 이상의 클러스터가 있을 수 있습니다. - 클러스터당 정확히 하나의
calico-kube-controllers
팟 (Pod). - 클러스터당 하나 이상의
coredns
팟 (Pod). 대부분의 클러스터에는 3개의coredns
파드가 있으며, 규모가 큰 클러스터에는 더 많은 파드가 있을 수 있습니다. - 정확히 하나의
coredns-autoscaler
포드입니다.
출력 예
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED READINESS GATES calico-system calico-kube-controllers-1a1a1a1 1/1 Running 0 16h 172.17.87.11 192.168.0.28 <none> <none> calico-system calico-node-1a1a1a1 1/1 Running 0 16h 192.168.0.28 192.168.0.28 <none> <none> calico-system calico-node-1a1a1a1 1/1 Running 0 16h 192.168.0.27 192.168.0.27 <none> <none> calico-system calico-typha-1a1a1a1 1/1 Running 0 16h 192.168.0.28 192.168.0.28 <none> <none> kube-system coredns-867bfb84df-1a1a1a1 1/1 Running 0 16h 172.17.87.1 192.168.0.28 <none> <none> kube-system coredns-867bfb84df-1a1a1a1 1/1 Running 0 16h 172.17.87.15 192.168.0.28 <none> <none> kube-system coredns-867bfb84df-1a1a1a1 1/1 Running 0 16h 172.17.87.14 192.168.0.28 <none> <none> kube-system coredns-autoscaler-1a1a1a1 1/1 Running 0 16h 172.17.87.2 192.168.0.28 <none> <none>
- 작업자 노드당 정확히 하나의
-
나열된 팟 (Pod) 이 없거나 상태가 양호하지 않은 경우에는 이전 단계에 포함된 클러스터 및 작업자 노드 문제점 해결 문서를 검토하십시오. 이동하기 전에 이 단계에서 팟 (Pod) 에 대한 문제가 해결되었는지 확인하십시오.
-
테스트 팟 (Pod) 으로 디버그
팟 (Pod) 에서 네트워킹 문제의 원인을 판별하기 위해 각 작업자 노드에서 테스트 팟 (Pod) 을 작성할 수 있습니다. 그런 다음 테스트를 실행하고 팟 (Pod) 내에서 네트워킹 활동을 관찰할 수 있으며, 이는 문제점의 소스를 나타낼 수 있습니다.
팟 (Pod) 설정
-
테스트 팟 (Pod) 에 대한 새 권한 있는 네임스페이스를 작성하십시오. 새 네임스페이스를 작성하면 기존 네임스페이스의 사용자 정의 정책 또는 구성이 테스트 팟 (Pod) 에 영향을 주지 않습니다. 이 예제에서 새 네임스페이스는
pod-network-test
입니다.네임스페이스를 작성하십시오.
kubectl create ns pod-network-test
-
다음 데몬셋을 생성하고 적용하여 각 노드에 테스트 파드를 생성합니다.
apiVersion: apps/v1 kind: DaemonSet metadata: labels: name: webserver-test app: webserver-test name: webserver-test spec: selector: matchLabels: name: webserver-test template: metadata: labels: name: webserver-test app: webserver-test spec: tolerations: - operator: "Exists" containers: - name: webserver securityContext: privileged: true image: us.icr.io/armada-master/network-alpine:latest env: - name: ENABLE_ECHO_SERVER value: "true" - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name restartPolicy: Always terminationGracePeriodSeconds: 1 ```
-
작업자 노드에 테스트 팟 (Pod) 을 배치하려면 디먼 세트를 적용하십시오.
kubectl apply --namespace pod-network-test -f <daemonset-file>
- 네임스페이스에 모든 파드를 나열하여 파드가 성공적으로 시작되었는지 확인합니다.
kubectl get pods --namespace pod-network-test -o wide
팟 (Pod) 내에서 테스트 실행
curl
, ping
및 nc
명령을 실행하여 각 팟 (Pod) 의 네트워크 연결을 테스트하고 dig
명령을 실행하여 클러스터 DNS를 테스트하십시오. 각 출력을 검토한 후 문제 식별 을 참조하여 결과의 의미를 찾으십시오.
-
테스트 팟 (Pod) 을 나열하고 각 팟 (Pod) 의 이름 및 IP를 기록하십시오.
kubectl get pods --namespace pod-network-test -o wide
출력 예
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES webserver-test-1a1a1 1/1 Running 0 68s 172.17.36.169 10.245.0.4 <none> <none> webserver-test-1a1a1 1/1 Running 0 68s 172.17.61.240 10.245.0.5 <none> <none>
-
exec
명령을 실행하여 하나의 포드에 로그인합니다.kubectl exec -it --namespace pod-network-test <pod_name> -- sh
-
팟 (Pod) 에서
curl
명령을 실행하고 출력을 참고하십시오. 로그인하지 않은 포드의 IP를 지정하십시오. 이는 서로 다른 노드에 있는 팟 (Pod) 간의 네트워크 연결을 테스트합니다.curl <pod_ip>:8080
성공적인 출력의 예입니다.
Hostname: webserver-test-t546j Pod Information: node name: env var NODE_NAME not set pod name: webserver-test-t546j pod namespace: env var POD_NAMESPACE not set pod IP: env var POD_IP not set Connection Information: remote address: 172.17.36.169 remote port: 56042 local address: 172.17.61.240 local port: 8080
-
팟 (Pod) 에서
ping
명령을 실행하고 출력을 참고하십시오.exec
명령으로 로그인하지 않은 포드의 IP를 지정합니다. 이는 서로 다른 노드에 있는 팟 (Pod) 간의 네트워크 연결을 테스트합니다.ping -c 5 <pod_ip>
성공적인 출력의 예입니다.
PING 172.30.248.201 (172.30.248.201) 56(84) bytes of data. 64 bytes from 172.30.248.201: icmp_seq=1 ttl=62 time=0.473 ms 64 bytes from 172.30.248.201: icmp_seq=2 ttl=62 time=0.449 ms 64 bytes from 172.30.248.201: icmp_seq=3 ttl=62 time=0.381 ms 64 bytes from 172.30.248.201: icmp_seq=4 ttl=62 time=0.438 ms 64 bytes from 172.30.248.201: icmp_seq=5 ttl=62 time=0.348 ms --- 172.30.248.201 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4086ms rtt min/avg/max/mdev = 0.348/0.417/0.473/0.046 ms
-
팟 (Pod) 에서
nc
명령을 실행하고 출력을 참고하십시오.exec
명령으로 로그인하지 않은 포드의 IP를 지정합니다. 이는 서로 다른 노드에 있는 팟 (Pod) 간의 네트워크 연결을 테스트합니다.nc -vzw 5 <pod_ip> 8080
성공적인 출력의 예입니다.
nc -vzw 5 172.17.61.240 8080 172.17.61.240 (172.17.61.240:8080) open
-
dig
명령을 실행하여 DNS를 테스트하십시오.dig +short kubernetes.default.svc.cluster.local
출력 예
172.21.0.1
dig +short ibm.com
출력 예
23.50.74.64
-
curl
명령을 실행하여 서비스에 대한 전체 TCP 또는 HTTPS 연결을 테스트합니다. 이 예제는 클러스터의 버전 정보를 검색하여 팟 (Pod) 과 클러스터 마스터 간의 연결을 테스트합니다. 클러스터 버전을 성공적으로 검색하면 연결 상태가 양호함을 표시합니다.curl -k https://kubernetes.default.svc.cluster.local/version
출력 예
{ "major": "1", "minor": "25", "gitVersion": "v1.25.14+bcb9a60", "gitCommit": "3bdfba0be09da2bfdef3b63e421e6a023bbb08e6", "gitTreeState": "clean", "buildDate": "2023-10-30T21:33:07Z", "goVersion": "go1.19.13 X:strictfipsruntime", "compiler": "gc", "platform": "linux/amd64" }
-
포드에서 로그아웃합니다.
exit
-
나머지 팟 (Pod) 을 사용하여 이전 단계를 반복하십시오.
문제 식별
이전 섹션의 출력을 검토하여 팟 (Pod) 네트워킹 문제의 원인을 찾으십시오. 이 절에서는 이전 절에서 식별할 수 있는 몇 가지 공통 원인을 나열합니다.
-
명령이 테스트 팟 (Pod) 에서 정상적으로 작동하지만 여전히 기본 네임스페이스의 애플리케이션 팟 (Pod) 에 네트워킹 문제가 있는 경우 애플리케이션과 특별히 관련된 문제가 있을 수 있습니다.
- 네트워킹 트래픽을 제한하는 Calico 또는 Kubernetes 네트워크 보안 정책이 있을 수 있습니다. 네트워킹 정책이 팟 (Pod) 에 적용되는 경우 해당 정책에 의해 특별히 허용되지 않는 모든 트래픽이 삭제됩니다. 네트워킹 정책에 대한 자세한 정보는 Kubernetes 문서를 참조하십시오.
- Istio 또는 Red Hat OpenShift 서비스 메시를 사용하는 경우 팟 (Pod) 간 트래픽을 제거하거나 차단하는 서비스 구성 문제가 있을 수 있습니다. 자세한 정보는 Istio 및 Red Hat OpenShift Service Mesh에 대한 문제점 해결 문서를 참조하십시오.
- 이 문제는 클러스터가 아닌 애플리케이션의 버그와 관련되어 있을 수 있으며 사용자 고유의 독립적인 문제점 해결이 필요할 수 있습니다.
-
특정 팟 (Pod) 에 대해
curl
,ping
또는nc
명령이 실패한 경우 해당 팟 (Pod) 이 있는 작업자 노드를 식별하십시오. 일부 작업자 노드에만 문제가 있는 경우 해당 작업자 노드를 대체 하거나 작업자 노드 문제점 해결 에 대한 추가 정보를 참조하십시오. -
dig
명령에서 DNS 검색에 실패한 경우 클러스터 DNS가 올바르게 구성되었는지 확인하십시오.
여전히 팟 (Pod) 네트워킹 문제를 해결할 수 없는 경우에는 지원 케이스를 열고 문제점에 대한 자세한 설명, 문제점 해결을 시도한 방법, 실행한 테스트 유형, 팟 (Pod) 및 작업자 노드에 대한 관련 로그 를 포함하십시오. 지원 케이스 열기 및 포함할 정보에 대한 자세한 정보는 일반 디버깅 안내서 를 참조하십시오.