Pular para o conteúdo principal

Troubleshooting de Rede

Plugins de CNI​

Vários plugins podem ser utilizados para criar a rede entre os nodes. No exame a url será dada caso necessário. Para mais documentação https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy

  1. Weave Net: kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

  2. Flannel : kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml 2.1. Não suporta network policies.

  3. Calico : curl https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml -O; kubectl apply -f calico.yaml

Se existirem vários arquivos de configuração de CNI, o kubelet usará o primeiro em ordem alfabética.

DNS in Kubernetes​

Como servidor DNS o Kubernetes utiliza o CoreDNS que é bem flexível e extensível.

Memory and Pods

O uso de memória usado pelo CoreDNS é afetado pelo número de pods e services no cluster, mas somente visível em clusters de larga escala. O tamanho do cache e a taxa de consultas influenciam na utilização da memória também.

Os recursos do CoreDNS são:

Kubernetes resources for coreDNS are:

  • service account: coredns
  • cluster-roles: coredns e kube-dns
  • clusterrolebindings coredns e kube-dns
  • deployment: coredns
  • configmap: coredns
  • service: kube-dns

Analisando o deployment do coreDNS, um configmap é utilizado para as configurações.

    spec:
      volumes:
        - name: config-volume
          configMap:
            name: coredns #<<<<
            items:
              - key: Corefile
                path: Corefile
            defaultMode: 420

Aqui o conteúdo do configmap.

kubectl describe cm -n kube-system coredns
Name:         coredns
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
Corefile:
----
### Porta 53 é usada para a resolução de DNS.
.:53 {
    errors
    health {
       lameduck 5s
    }
    ready
    # Este é o back-end do k8s para cluster.local e domínios reversos.
    kubernetes cluster.local in-addr.arpa ip6.arpa {
       pods insecure
       fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    # Encaminhar domínios de cluster diretamente para o servidor DNS autoritativo correto.
    forward . /etc/resolv.conf {
       max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}


BinaryData
====

Events:  <none>

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

Solução de problemas relacionados ao coreDNS.

  1. Se o CoreDNS estiver em estado de pending, verifique se algum plugin CNI está instalado.

  2. Se os pods do CoreDNS estiverem em estado de CrashLoopBackOff ou Error. Se estiver utilizando nodes que estão rodando o SELinux com uma versão do Docker antiga pode ser que o CoreDNS não inicie. Para resolver esse problema você pode tentar seguir os passos abaixo.

    2.1. Atualizar a versão do container runtime.

    2.2. Desativar SELinux no sistema operacional.

    2.3. Modificar o deployment do CoreDNS e setar allowPrivilegeEscalation para true.

    kubectl -n kube-system get deployment coredns -o yaml | sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | kubectl apply -f -

    2.4. Outra causa para o CoreDNS ter CrashLoopBackOff é quando um Pod CoreDNS deployado no Kubernetes detecta um loop. Há muitas maneiras de contornar esse problema, algumas estão listadas aqui:

    • Adicione o seguinte ao yaml de configuração do kubelet: resolvConf: <path-to-your-real-resolv-conf-file> Este sinalizador diz ao kubelet para passar um resolv.conf alternativo para os pods. Para sistemas que usam o systemd-resolved, /run/systemd/resolve/resolv.conf é normalmente o local do resolv.conf "real", embora possa ser diferente dependendo da sua distribuição.
    • Desative o cache DNS local nos nós do host e restaure /etc/resolv.conf para o original.
    • Uma solução rápida é editar seu Corefile, substituindo forward . /etc/resolv.conf pelo endereço IP do seu DNS upstream, por exemplo forward . 8.8.8.8. Mas isso apenas corrige o problema do CoreDNS, o kubelet continuará encaminhando o resolv.conf inválido para todos os pods dnsPolicy padrão, deixando-os incapazes de resolver o DNS.

  3. Se os pods CoreDNS e o serviço kube-dns estiverem funcionando bem, verifique se o serviço kube-dns tem endpoints válidos. kubectl -n kube-system get ep kube-dns Se não houver endpoints para o service, inspecione-o e certifique-se de que utiliza os seletores e portas corretos.

Kube-Proxy​

kube-proxy é um proxy de rede executado em cada nó do cluster. kube-proxy mantém regras de rede em nós. Essas regras de rede permitem a comunicação de rede com os pods a partir de sessões de rede dentro ou fora do cluster.

Se o cluster foi configurado com o kubeadm, kube-proxy estará rodando como um daemonset.

kube-proxy é responsável por monitorar os services e endpoints associados a cada service. Quando o cliente vai se conectar ao service usando o IP virtual, o kube-proxy é responsável por enviar o tráfego para os pods reais.

Se executar um kubectl description ds -n kube-system kube-proxy poderá ver que o binário kube-proxy é executado com o seguinte comando dentro do contêiner kube-proxy.

kubectl describe ds -n kube-system kube-proxy
Name:           kube-proxy
Selector:       k8s-app=kube-proxy
Node-Selector:  kubernetes.io/os=linux
Labels:         k8s-app=kube-proxy
Annotations:    deprecated.daemonset.template.generation: 1
Desired Number of Nodes Scheduled: 4
Current Number of Nodes Scheduled: 4
Number of Nodes Scheduled with Up-to-date Pods: 4
Number of Nodes Scheduled with Available Pods: 4
Number of Nodes Misscheduled: 0
Pods Status:  4 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:           k8s-app=kube-proxy
  Service Account:  kube-proxy
  Containers:
   kube-proxy:
    Image:      registry.k8s.io/kube-proxy:v1.29.1
    Port:       <none>
    Host Port:  <none>
####################
    Command:
      /usr/local/bin/kube-proxy
      --config=/var/lib/kube-proxy/config.conf
      --hostname-override=$(NODE_NAME)
####################
    Environment:
      NODE_NAME:   (v1:spec.nodeName)
    Mounts:
      /lib/modules from lib-modules (ro)
      /run/xtables.lock from xtables-lock (rw)
      /var/lib/kube-proxy from kube-proxy (rw)
  Volumes:
   kube-proxy:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kube-proxy
    Optional:  false
   xtables-lock:
    Type:          HostPath (bare host directory volume)
    Path:          /run/xtables.lock
    HostPathType:  FileOrCreate
   lib-modules:
    Type:               HostPath (bare host directory volume)
    Path:               /lib/modules
    HostPathType:  
  Priority Class Name:  system-node-critical
Events:                 <none>

Portanto, ele busca a configuração de um arquivo /var/lib/kube-proxy/config.conf e podemos substituir o nome do host pelo nome do nó no qual o pod está sendo executado.

No arquivo de configuração definimos clusterCIDR, modo kubeproxy, ipvs, iptables, bindaddress, kube-config etc.

Como resolver problemas relacionados ao kube-proxy:

  1. Verifique se o pod kube-proxy no namespace kube-system está em execução.

  2. Verifique os logs do proxy kube.

  3. Verifique se o configmap está definido corretamente e se o arquivo de configuração para executar o binário kube-proxy está correto.

  4. kube-config é definido no configmap.

  5. verifique se o kube-proxy está sendo executado dentro do contêiner.

# netstat -plan | grep kube-proxy
tcp        0      0 0.0.0.0:30081           0.0.0.0:*               LISTEN      1/kube-proxy
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      1/kube-proxy
tcp        0      0 172.17.0.12:33706       172.17.0.12:6443        ESTABLISHED 1/kube-proxy
tcp6       0      0 :::10256                :::*                    LISTEN      1/kube-proxy