Depurando conexões de rede entre os pods

Revise as opções e estratégias para depurar problemas de conexão entre pods.

Verifique o funcionamento de seus componentes de cluster e pods de rede

Resolva problemas de rede dos pods e de conectividade.

Siga estas etapas para verificar o funcionamento de seus componentes Problemas de rede poderão ocorrer se os componentes do seu cluster não estiverem atualizados ou não estiverem em um estado funcional

Verifique se os nós do cluster mestre e do trabalhador são executados em uma versão suportada e estão em um estado funcional Se o cluster mestre ou os trabalhadores não executam uma versão suportada, faça quaisquer atualizações necessárias para que eles executem uma versão suportada Se o status de algum componente não for Normal ou Ready, revise os estados de integridade do mestre do cluster, estados do cluster, estados do nó de trabalho, ou etapas para solucionar problemas de Critical ou NotReady nós de trabalho para obter mais informações. Assegure-se de que quaisquer problemas relacionados sejam resolvidos antes de continuar.

Para verificar a versão e o funcionamento do cluster principal:.
```
ibmcloud oc cluster get -c CLUSTER-ID
```
Para verificar versões e funcionamento do nó do trabalhador:
```
ibmcloud oc workers -c CLUSTER-ID
```
Para cada nó do trabalhador, verifique se os pods DNS do Calico e do cluster estão presentes e em execução em um estado funcional.
1. Execute o comando para obter os detalhes dos pods do seu cluster.
```
 oc get pods -A -o wide | grep -e calico -e dns-default
```
2. Na saída, assegure-se de que seu cluster inclua os pods a seguir. Certifique-se de que o status de cada pod seja Running e que os pods não tenham muitas reinicializações.
  - Exatamente um pod do calico-node por nó do trabalhador
  - Pelo menos um pod do calico-typha por cluster Clusters maiores podem ter mais de um.
  - Exatamente um pod do calico-kube-controllers por cluster
  - Um dns-default pod por nó. No entanto, alguns nós podem não ter o pod dns-default se tiverem rótulos anexados. Isso é normal e não causa problemas de rede.
  Exemplo de saída
```
NAMESPACE        NAME                               READY   STATUS     RESTARTS    AGE    IP              NODE           NOMINATED     READINESS GATES
calico-system    calico-kube-controllers-1a1a1a1    1/1     Running     0          37m    172.17.61.195   10.245.0.5     <none>        <none>
calico-system    calico-node-1a1a1a1                1/1     Running     0          37m    10.245.0.5      10.245.0.5     <none>        <none>
calico-system    calico-node-1a1a1a1                1/1     Running     0          37m    10.245.0.4      10.245.0.4     <none>        <none>
calico-system    calico-typha-1a1a1a1               1/1     Running     0          37m    10.245.0.5      10.245.0.5     <none>        <none>
openshift-dns    dns-default-1a1a1a1                2/2     Running     0          33m    172.17.36.144   10.245.0.4     <none>        <none>
openshift-dns    dns-default-1a1a1a1                2/2     Running     0          33m    172.17.61.210   10.245.0.5     <none>        <none>
```
3. Se qualquer um dos pods listados não estiver presente ou estiver em um estado inoperante, passe pela documentação de resolução de problemas do cluster e do nó do trabalhador incluída nas etapas anteriores. Certifique-se de que quaisquer problemas com os pods nesta etapa sejam resolvidos antes de continuar.

Depurar com pods de teste

Para determinar a causa de problemas de rede em seus pods, é possível criar um pod de teste em cada um de seus nós do trabalhador Em seguida, é possível executar testes e observar a atividade de rede no pod, que pode revelar a origem do problema.

Configurando os pods.

Crie um novo namespace privilegiado para seus pods de teste.. Criar um novo namespace evita que quaisquer políticas ou configurações customizadas em namespaces existentes afetem seus pods de teste. Neste exemplo, o novo namespace é chamado de pod-network-test

Crie o namespace.
```
oc create ns pod-network-test
```

Adicione rótulos ao novo namespace privilegiado.

oc label namespace pod-network-test --overwrite=true \
            pod-security.kubernetes.io/enforce=privileged \
            pod-security.kubernetes.io/enforce-version=latest \
            pod-security.kubernetes.io/audit=privileged \
            pod-security.kubernetes.io/audit-version=latest \
            pod-security.kubernetes.io/warn=privileged \
            pod-security.kubernetes.io/warn-version=latest \
            security.openshift.io/scc.podSecurityLabelSync="false"

Execute o comando para permitir que o namespace execute pods com um contexto de segurança privilegiado.
```
oc adm policy add-scc-to-group privileged system:serviceaccounts:pod-network-test
```

Crie e aplique o seguinte conjunto de daemons para criar um pod de teste em cada nó.

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

Aplique o conjunto de daemons para implantar um pod de teste em cada nó de trabalho.
```
oc apply --namespace pod-network-test -f <daemonset-file>
```
Verifique se os pods são iniciados com êxito, listando todos os pods no namespace.
```
oc get pods --namespace pod-network-test -o wide
```

Executando testes dentro dos pods

Execute comandos curl, ping e nc para testar a conexão de rede de cada pod e o comando dig para testar o DNS do cluster. Revise cada saída e, em seguida, veja Identificando problemas para localizar o que os resultados podem significar

Liste seus pods de teste e observe o nome e o IP de cada pod.

oc get pods --namespace pod-network-test -o wide

Exemplo de saída

NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
webserver-test-2fv7c   1/1     Running   0          68s   172.17.36.169    10.245.0.4  <none>           <none>
webserver-test-4mktb   1/1     Running   0          68s   172.17.61.240    10.245.0.5  <none>           <none>

Execute o comando exec para fazer login em um pod.

kubectl exec -it --namespace pod-network-test <pod_name> -- sh

Execute o comando curl no pod e observe a saída. Especifique o IP de um pod de teste no qual você não fez login. Isso testa a conexão de rede entre os pods em nós diferentes

curl <pod_ip>:8080

Saída bem-sucedida de exemplo..

Hostname: webserver-test-4mktb
Pod Information:
  node name:	env var NODE_NAME not set
  pod name:	webserver-test-4mktb
  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

Execute o comando ping no pod e observe a saída. Especifique o IP de um pod de teste no qual você não fez login com o comando exec. Isso testa a conexão de rede entre os pods em nós diferentes

ping -c 5 <pod_ip>

Saída bem-sucedida de exemplo..

PING 172.17.61.240 (172.17.61.240) 56(84) bytes of data.
64 bytes from 172.17.61.240: icmp_seq=1 ttl=62 time=0.473 ms
64 bytes from 172.17.61.240: icmp_seq=2 ttl=62 time=0.449 ms
64 bytes from 172.17.61.240: icmp_seq=3 ttl=62 time=0.381 ms
64 bytes from 172.17.61.240: icmp_seq=4 ttl=62 time=0.438 ms
64 bytes from 172.17.61.240: icmp_seq=5 ttl=62 time=0.348 ms
--- 172.17.61.240 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

Execute o comando nc no pod e observe a saída. Especifique o IP de um pod de teste no qual você não fez login com o comando exec. Isso testa a conexão de rede entre os pods em nós diferentes
```
nc -vzw 5 <pod_ip> 8080
```
Saída bem-sucedida de exemplo..
```
nc -vzw 5 172.17.61.240 8080
172.17.61.240 (172.17.61.240:8080) open
```

Execute os comandos do dig para testar o DNS

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

Exemplo de saída

172.21.0.1

dig +short ibm.com

Exemplo de saída

23.50.74.64

Execute os comandos curl para testar uma conexão completa TCP ou HTTPS com o serviço. Este exemplo testa a conexão entre o pod e o cluster mestre recuperando as informações de versão do cluster.. A recuperação com sucesso da versão do cluster indica uma conexão funcional

curl -k https://kubernetes.default.svc.cluster.local/version

Exemplo de saída

"major": "1",
"minor": "34",
"emulationMajor": "1",
"emulationMinor": "34",
"minCompatibilityMajor": "1",
"minCompatibilityMinor": "33",
"gitVersion": "v1.34.7+IKS",
"gitCommit": "67bf12be5abc8e65743a243172693ad1a098a2c4",
"gitTreeState": "clean",
"buildDate": "2026-04-16T04:24:50Z",
"goVersion": "go1.25.9",
"compiler": "gc",
"platform": "linux/amd64"

Saia do pod.
```
exit
```
Repita as etapas anteriores com os pods restantes.

Identificando problemas

Revise as saídas da seção anterior para ajudar a localizar a causa de seus problemas de rede de pod Esta seção lista algumas causas comuns que podem ser identificadas na seção anterior.

Se os comandos funcionaram normalmente nos pods de teste, mas você ainda tem problemas de rede com os pods de aplicativos no namespace padrão, pode haver problemas relacionados especificamente ao seu aplicativo.
- Você pode ter políticas de segurança de rede Calico ou Kubernetes em vigor que restrinjam seu tráfego de rede. Se uma política de rede for aplicada a um pod, todo o tráfego que não é especificamente permitido por essa política será descartado Para obter mais informações sobre políticas de rede, consulte a documentação doKubernetes..
- Se você estiver usando Istio ou Red Hat OpenShift Service Mesh, pode haver problemas de configuração de serviço que derrubam ou bloqueiam o tráfego entre os pods. Para obter mais informações, consulte a documentação de solução de problemas do Istio e Red Hat OpenShift Service Mesh.
- O problema pode estar relacionado a erros no aplicativo em vez de seu cluster e pode requerer sua própria resolução de problemas independente.
Se os comandos curl, ping ou nc falharem para determinados pods, identifique em quais nós do trabalhador esses pods estão.. Se o problema existir em apenas alguns de seus nós do trabalhador, substitua esses nós do trabalhador ou veja informações adicionais sobre resolução de problemas do nó do trabalhador
Se as consultas DNS dos comandos dig falharem, consulte as informações de resolução de problemas do DNS do Red Hat.

Se ainda não for possível resolver seu problema de rede de pod, abra um caso de suporte e inclua uma descrição detalhada do problema, como você tentou resolvê-lo. Quais tipos de testes você executou e logs relevantes para seus pods e nós do trabalhador. Para obter mais informações sobre como abrir um caso de suporte e quais informações incluir, consulte o guia de depuração geral.