IBM Cloud Docs
팟 (Pod) 간 네트워크 연결 디버깅

팟 (Pod) 간 네트워크 연결 디버깅

팟 (Pod) 간의 연결 문제를 디버깅하기 위한 옵션 및 전략을 검토하십시오.

클러스터 컴포넌트 및 네트워킹 팟 (Pod) 의 상태 확인

컴포넌트의 상태를 확인하려면 다음 단계를 수행하십시오. 클러스터 컴포넌트가 최신 상태가 아니거나 정상 상태가 아닌 경우 네트워킹 문제가 발생할 수 있습니다.

  1. 클러스터 마스터 및 작업자 노드가 지원되는 버전에서 실행되고 정상 상태인지 확인하십시오. 클러스터 마스터 또는 작업자가 지원되는 버전을 실행하지 않는 경우 지원되는 버전을 실행하도록 필요한 업데이트를 작성 하십시오. 구성 요소의 상태가 Normal 또는 Ready 이 아닌 경우 클러스터 마스터 상태, 클러스터 상태 를 검토하세요, 워커 노드 상태 또는 문제 해결 단계 Critical 또는 NotReady 워커 노드 에서 자세한 내용을 확인하세요. 계속하기 전에 관련 문제가 해결되었는지 확인하십시오.

    클러스터 마스터 버전 및 상태를 확인하려면 다음을 수행하십시오.

    ibmcloud ks cluster get -c <cluster-id>
    

    작업자 노드 버전 및 상태를 확인하려면 다음을 수행하십시오.

    ibmcloud ks workers -c <cluster-id>
    
  2. 각 작업자 노드에 대해 Calico 및 클러스터 DNS팟 (Pod) 이 존재하고 정상 상태에서 실행 중인지 확인하십시오.

    1. 명령을 실행하여 클러스터의 파드에 대한 세부 정보를 얻습니다.

       kubectl get pods -A -o wide | grep -e calico -e coredns
      
    2. 출력에서 클러스터에 다음 팟 (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>
      
    3. 나열된 팟 (Pod) 이 없거나 상태가 양호하지 않은 경우에는 이전 단계에 포함된 클러스터 및 작업자 노드 문제점 해결 문서를 검토하십시오. 이동하기 전에 이 단계에서 팟 (Pod) 에 대한 문제가 해결되었는지 확인하십시오.

테스트 팟 (Pod) 으로 디버그

팟 (Pod) 에서 네트워킹 문제의 원인을 판별하기 위해 각 작업자 노드에서 테스트 팟 (Pod) 을 작성할 수 있습니다. 그런 다음 테스트를 실행하고 팟 (Pod) 내에서 네트워킹 활동을 관찰할 수 있으며, 이는 문제점의 소스를 나타낼 수 있습니다.

팟 (Pod) 설정

  1. 테스트 팟 (Pod) 에 대한 새 권한 있는 네임스페이스를 작성하십시오. 새 네임스페이스를 작성하면 기존 네임스페이스의 사용자 정의 정책 또는 구성이 테스트 팟 (Pod) 에 영향을 주지 않습니다. 이 예제에서 새 네임스페이스는 pod-network-test 입니다.

    네임스페이스를 작성하십시오.

    kubectl create ns pod-network-test
    
  2. 다음 데몬셋을 생성하고 적용하여 각 노드에 테스트 파드를 생성합니다.

    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
          ```
    
    
  3. 작업자 노드에 테스트 팟 (Pod) 을 배치하려면 디먼 세트를 적용하십시오.

kubectl apply --namespace pod-network-test -f <daemonset-file>
  1. 네임스페이스에 모든 파드를 나열하여 파드가 성공적으로 시작되었는지 확인합니다.
    kubectl get pods --namespace pod-network-test -o wide
    

팟 (Pod) 내에서 테스트 실행

curl, pingnc 명령을 실행하여 각 팟 (Pod) 의 네트워크 연결을 테스트하고 dig 명령을 실행하여 클러스터 DNS를 테스트하십시오. 각 출력을 검토한 후 문제 식별 을 참조하여 결과의 의미를 찾으십시오.

  1. 테스트 팟 (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>
    
  2. exec 명령을 실행하여 하나의 포드에 로그인합니다.

    kubectl exec -it --namespace pod-network-test <pod_name> -- sh
    
  3. 팟 (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
    
  4. 팟 (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
    
  5. 팟 (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
    
  6. dig 명령을 실행하여 DNS를 테스트하십시오.

    dig +short kubernetes.default.svc.cluster.local
    

    출력 예

    172.21.0.1
    
    dig +short ibm.com
    

    출력 예

    23.50.74.64
    
  7. 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"
    }
    
  8. 포드에서 로그아웃합니다.

    exit
    
  9. 나머지 팟 (Pod) 을 사용하여 이전 단계를 반복하십시오.

문제 식별

이전 섹션의 출력을 검토하여 팟 (Pod) 네트워킹 문제의 원인을 찾으십시오. 이 절에서는 이전 절에서 식별할 수 있는 몇 가지 공통 원인을 나열합니다.

  • 명령이 테스트 팟 (Pod) 에서 정상적으로 작동하지만 여전히 기본 네임스페이스의 애플리케이션 팟 (Pod) 에 네트워킹 문제가 있는 경우 애플리케이션과 특별히 관련된 문제가 있을 수 있습니다.

    • 네트워킹 트래픽을 제한하는 Calico 또는 Kubernetes 네트워크 보안 정책이 있을 수 있습니다. 네트워킹 정책이 팟 (Pod) 에 적용되는 경우 해당 정책에 의해 특별히 허용되지 않는 모든 트래픽이 삭제됩니다. 네트워킹 정책에 대한 자세한 정보는 Kubernetes 문서를 참조하십시오.
    • Istio 또는 Red Hat OpenShift 서비스 메시를 사용하는 경우 팟 (Pod) 간 트래픽을 제거하거나 차단하는 서비스 구성 문제가 있을 수 있습니다. 자세한 정보는 IstioRed Hat OpenShift Service Mesh에 대한 문제점 해결 문서를 참조하십시오.
    • 이 문제는 클러스터가 아닌 애플리케이션의 버그와 관련되어 있을 수 있으며 사용자 고유의 독립적인 문제점 해결이 필요할 수 있습니다.
  • 특정 팟 (Pod) 에 대해 curl, ping 또는 nc 명령이 실패한 경우 해당 팟 (Pod) 이 있는 작업자 노드를 식별하십시오. 일부 작업자 노드에만 문제가 있는 경우 해당 작업자 노드를 대체 하거나 작업자 노드 문제점 해결 에 대한 추가 정보를 참조하십시오.

  • dig 명령에서 DNS 검색에 실패한 경우 클러스터 DNS가 올바르게 구성되었는지 확인하십시오.

여전히 팟 (Pod) 네트워킹 문제를 해결할 수 없는 경우에는 지원 케이스를 열고 문제점에 대한 자세한 설명, 문제점 해결을 시도한 방법, 실행한 테스트 유형, 팟 (Pod) 및 작업자 노드에 대한 관련 로그 를 포함하십시오. 지원 케이스 열기 및 포함할 정보에 대한 자세한 정보는 일반 디버깅 안내서 를 참조하십시오.