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. .
-
Execute o comando a seguir para editar a implementação do
calico-typha.Para o
1.29e versões posteriores:kubectl edit deploy calico-typha -n calico-systemPara 1.28 e anterior:
kubectl edit deploy calico-typha -n kube-system -
Mude a variável de ambiente
TYPHA_LOGSEVERITYSCREENdeinfoparadebug.containers: - env: - name: TYPHA_LOGSEVERITYSCREEN value: debug -
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. .
-
Execute o comando a seguir para editar o configmap
calico-config.kubectl edit cm -n kube-system calico-config -
Mude a variável de ambiente
cni_network_config>plugins>log_levelparadebug.cni_network_config: |- { "name": "k8s-pod-network", "cniVersion": "0.3.1", "plugins": [ { "type": "calico", "log_level": "debug", -
Salve e feche o arquivo. A mudança não será efetivada até que os pods
calico-nodesejam reiniciados. -
Reinicie os pods
calico-nodepara aplicar as mudanças.kubectl rollout restart daemonset/calico-node -n kube-systemSaí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. .
-
Execute o comando a seguir:
Para o
1.29e versões posteriores:kubectl edit ds calico-node -n calico-systemPara 1.28 e anterior:
kubectl edit ds calico-node -n kube-system -
Sob o par de nome e valor
FELIX_USAGEREPORTINGENABLED(ou após qualquer um dos pares de nome e valor da variável de ambienteFELIX_*), inclua a entrada a seguir.- name: FELIX_LOGSEVERITYSCREEN value: Debug -
Salve as mudanças. Após o salvamento das mudanças, todos os pods no daemonset
calico-nodeconcluirão uma atualização contínua que aplica mudanças. Ocalico-cnitambém aplica quaisquer mudanças nos níveis de criação de log no configmapkube-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. .
-
Edite a implantação executando o comando a seguir.
Para o
1.29e versões posteriores:kubectl edit deploy calico-kube-controllers -n calico-systemPara 1.28 e anterior:
kubectl edit deploy calico-kube-controllers -n kube-system -
Sob o par de nome e valor
DATASTORE_TYPE, inclua a entrada a seguir.- name: LOG_LEVEL value: debug -
Salve as mudanças. O pod
calico-kube-controllersé reiniciado e aplica as mudanças.
Reunindo logs do Calico
-
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 -
Obtenha os logs para o pod
calico-nodeno nó do trabalhador onde ocorreu o problema.Para o
1.29e versões posteriores:kubectl logs calico-typha-aaa11111a-aaaaa -n calico-systemPara 1.28 e anterior:
kubectl logs calico-typha-aaa11111a-aaaaa -n kube-system -
Obter logs para o pod
calico-kube-controllers.Para o
1.29e versões posteriores:kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n calico-systemPara 1.28 e anterior:
kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n kube-system -
Siga as instruções em Depurando usando o kubectl exec para obter
/var/log/syslog,containerd.log,kubelet.logekern.logdo nó do trabalhador.