Depurando componentes do Calico

Nuvem Privada Virtual Infraestrutura clássica

Você está com problemas com os componentes do Calico, como, por exemplo, pods que não são implementados ou problemas intermitentes de rede.

Você está com problemas com os componentes do Calico, como, por exemplo, pods que não são implementados ou problemas intermitentes de rede.

O operador “ Calico ” determina o número de pods do “ calico-typha ” com base no número de workers do cluster e não leva em consideração os nós marcados como “tainted”. Se você tiver menos de 3 nós sem marcação (untainted) em seu cluster, ou se tiver um cluster muito grande com um número reduzido de nós sem marcação, é possível que um ou mais pods do tipo “ calico-typha ” fiquem presos no estado “ Pending ”, pois o pod não consegue encontrar um nó sem marcação para ser executado. Normalmente, isso não causa problemas, desde que haja pelo menos um pod calico-typha no estado Running. No entanto, para alta disponibilidade, é recomendável ter pelo menos dois calico-typha pods sempre em execução. Como prática recomendada, certifique-se de que haja nós não contaminados suficientes para executar todos os calico-typha pods criados pelo Calico operador.

Calico Problemas de rede podem ser difíceis de diagnosticar sem registros detalhados. O nível de log padrão para os componentes do Calico está definido como “ info ”, o que fornece informações operacionais básicas, mas pode não incluir detalhes suficientes para solucionar problemas complexos de rede.

Aumente o nível de registro dos componentes do Calico para debug a fim de coletar informações mais detalhadas sobre o problema. O registro de log no nível de depuração fornece uma saída detalhada que pode ajudar a identificar a causa raiz de problemas de rede.

Aumentando o nível de log para os componentes do calico-typha

Conclua as etapas a seguir para aumentar o nível de log para o componente do calico-typha. .

  1. Execute o comando a seguir para editar a implementação do calico-typha.

    Para o 1.29 e versões posteriores:

    kubectl edit deploy calico-typha -n calico-system
    

    Para 1.28 e anterior:

    kubectl edit deploy calico-typha -n kube-system
    
  2. Mude a variável de ambiente TYPHA_LOGSEVERITYSCREEN de info para debug.

          containers:
        - env:
          - name: TYPHA_LOGSEVERITYSCREEN
            value: debug
    
  3. Salve e feche o arquivo para aplicar as mudanças e reinicie a implementação calico-typha.

Aumentando o nível de log para os componentes do calico-cni

Conclua as etapas a seguir para aumentar o nível de log para o componente do calico-cni. .

  1. Execute o comando a seguir para editar o configmap calico-config.

    kubectl edit cm -n kube-system calico-config
    
  2. Mude a variável de ambiente cni_network_config > plugins > log_level para debug.

      cni_network_config: |-
      {
        "name": "k8s-pod-network",
        "cniVersion": "0.3.1",
        "plugins": [
          {
            "type": "calico",
            "log_level": "debug",
    
  3. Salve e feche o arquivo. A mudança não será efetivada até que os pods calico-node sejam reiniciados.

  4. Reinicie os pods calico-node para aplicar as mudanças.

    kubectl rollout restart daemonset/calico-node -n kube-system
    

    Saída de exemplo

    daemonset.apps/calico-node restarted
    

Aumentando o nível de log para os componentes do calico-node

Conclua as etapas a seguir para aumentar o nível de log para o componente do calico-node. .

  1. Execute o comando a seguir:

    Para o 1.29 e versões posteriores:

    kubectl edit ds calico-node -n calico-system
    

    Para 1.28 e anterior:

    kubectl edit ds calico-node -n kube-system
    
  2. Sob o par de nome e valor FELIX_USAGEREPORTINGENABLED (ou após qualquer um dos pares de nome e valor da variável de ambiente FELIX_*), inclua a entrada a seguir.

    - name: FELIX_LOGSEVERITYSCREEN
      value: Debug
    
  3. Salve as mudanças. Após o salvamento das mudanças, todos os pods no daemonset calico-node concluirão uma atualização contínua que aplica mudanças. O calico-cni também aplica quaisquer mudanças nos níveis de criação de log no configmap kube-system/calico-config.

Aumentando o nível de log para os componentes do calico-kube-controllers

Conclua as etapas a seguir para aumentar o nível de log para o componente do calico-kube-controllers. .

  1. Edite a implantação executando o comando a seguir.

    Para o 1.29 e versões posteriores:

    kubectl edit deploy calico-kube-controllers -n calico-system
    

    Para 1.28 e anterior:

    kubectl edit deploy calico-kube-controllers -n kube-system
    
  2. Sob o par de nome e valor DATASTORE_TYPE, inclua a entrada a seguir.

    - name: LOG_LEVEL
      value: debug
    
  3. Salve as mudanças. O pod calico-kube-controllers é reiniciado e aplica as mudanças.

Reunindo logs do Calico

  1. Liste os pods e os nós do seu cluster e anote o nome do pod, o endereço IP do pod e o nó de trabalho que está apresentando o problema.

    kubectl get pods -o wide -n kube-system
    
  2. Obtenha os logs para o pod calico-node no nó do trabalhador onde ocorreu o problema.

    Para o 1.29 e versões posteriores:

    kubectl logs calico-typha-aaa11111a-aaaaa -n calico-system
    

    Para 1.28 e anterior:

    kubectl logs calico-typha-aaa11111a-aaaaa -n kube-system
    
  3. Obter logs para o pod calico-kube-controllers.

    Para o 1.29 e versões posteriores:

    kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n calico-system
    

    Para 1.28 e anterior:

    kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n kube-system
    
  4. Siga as instruções em Depurando usando o kubectl exec para obter /var/log/syslog, containerd.log, kubelet.log e kern.log do nó do trabalhador.