Examinar a integridade do nó e do pod

Este artigo faz parte de uma série. Comece com a visão geral.

Se as verificações de cluster que você executou na etapa anterior estiverem limpas, verifique a integridade dos nós de trabalho do Serviço Kubernetes do Azure (AKS). Siga as seis etapas neste artigo para verificar a integridade dos nós, determinar o motivo de um nó não íntegro e resolver o problema.

Etapa 1: Verificar a integridade dos nós de trabalho

Vários fatores podem contribuir para nós não íntegros em um cluster AKS. Uma razão comum é a quebra de comunicação entre o plano de controle e os nós. Essa falha de comunicação geralmente é causada por configurações incorretas nas regras de roteamento e firewall.

Ao configurar seu cluster AKS para roteamento definido pelo usuário, você deve configurar caminhos de saída por meio de um dispositivo virtual de rede (NVA) ou um firewall, como um firewall do Azure. Para resolver um problema de configuração incorreta, recomendamos que você configure o firewall para permitir as portas necessárias e os FQDNs (nomes de domínio totalmente qualificados) de acordo com as diretrizes de tráfego de saída do AKS.

Outra razão para nós não íntegros pode ser recursos inadequados de computação, memória ou armazenamento que criam pressões kubelet. Nesses casos, a ampliação dos recursos pode efetivamente resolver o problema.

Em um cluster AKS privado, problemas de resolução do Sistema de Nomes de Domínio (DNS) podem causar problemas de comunicação entre o plano de controle e os nós. Você deve verificar se o nome DNS do servidor de API do Kubernetes é resolvido para o endereço IP privado do servidor de API. A configuração incorreta de um servidor DNS personalizado é uma causa comum de falhas de resolução de DNS. Se você usar servidores DNS personalizados, certifique-se de especificá-los corretamente como servidores DNS na rede virtual onde os nós são provisionados. Confirme também que o servidor de API privado AKS pode ser resolvido através do servidor DNS personalizado.

Depois de resolver esses possíveis problemas relacionados à comunicação do plano de controle e à resolução de DNS, você pode efetivamente abordar e resolver problemas de integridade do nó em seu cluster AKS.

Você pode avaliar a integridade de seus nós usando um dos seguintes métodos.

Vista de estado de funcionamento dos contentores do Azure Monitor

Para exibir a integridade de nós, pods de usuário e pods de sistema em seu cluster AKS, siga estas etapas:

1. No portal do Azure, vá para Azure Monitor.
2. Na seção Informações do painel de navegação, selecione Contêineres.
3. Selecione Clusters monitorados para obter uma lista dos clusters AKS que estão sendo monitorados.
4. Escolha um cluster AKS na lista para visualizar a integridade dos nós, pods de usuário e pods de sistema.

Visualização de nós AKS

Para garantir que todos os nós no cluster AKS estejam no estado pronto, siga estas etapas:

1. No portal do Azure, vá para o cluster AKS.
2. Na seção Configurações do painel de navegação, selecione Pools de nós.
3. Selecione Nós.
4. Verifique se todos os nós estão no estado pronto.

Monitorização em cluster com Prometheus e Grafana

Se você implantou o Prometheus e o Grafana em seu cluster AKS, poderá usar o Painel de Detalhes do Cluster K8 para obter informações. Este painel mostra métricas de cluster Prometheus e apresenta informações vitais, como uso de CPU, uso de memória, atividade de rede e uso do sistema de arquivos. Ele também mostra estatísticas detalhadas para pods individuais, contêineres e serviços systemd .

No painel, selecione Condições do nó para ver as métricas sobre a integridade e o desempenho do cluster. Você pode rastrear nós que possam ter problemas, como problemas com sua programação, a rede, a pressão do disco, a pressão da memória, a pressão da derivada integral proporcional (PID) ou o espaço em disco. Monitore essas métricas, para que você possa identificar e resolver proativamente quaisquer problemas potenciais que afetem a disponibilidade e o desempenho do seu cluster AKS.

Monitorar o serviço gerenciado para Prometheus e Azure Managed Grafana

Você pode usar painéis pré-criados para visualizar e analisar as métricas do Prometheus. Para fazer isso, você deve configurar seu cluster AKS para coletar métricas do Prometheus no serviço gerenciado do Monitor para Prometheus e conectar seu espaço de trabalho do Monitor a um espaço de trabalho do Azure Managed Grafana. Esses painéis fornecem uma visão abrangente do desempenho e da integridade do cluster Kubernetes.

Os painéis são provisionados na instância especificada do Azure Managed Grafana na pasta Managed Prometheus . Alguns painéis incluem:

• Kubernetes / Recursos de computação / Cluster
• Kubernetes / Recursos de computação / Namespace (Pods)
• Kubernetes / Recursos de computação / Nó (pods)
• Kubernetes / Recursos de computação / Pod
• Kubernetes / Recursos de computação / Namespace (cargas de trabalho)
• Kubernetes / Recursos de computação / Carga de trabalho
• Kubernetes / Kubelet
• Exportador de Nó / Método USE / Nó
• Exportador de nós / nós
• Kubernetes / Recursos de computação / Cluster (Windows)
• Kubernetes / Recursos de computação / Namespace (Windows)
• Kubernetes / Recursos de computação / Pod (Windows)
• Kubernetes / Método USE / Cluster (Windows)
• Kubernetes / Método USE / Nó (Windows)

Esses painéis integrados são amplamente utilizados na comunidade de código aberto para monitorar clusters Kubernetes com Prometheus e Grafana. Use esses painéis para ver métricas, como uso de recursos, integridade do pod e atividade de rede. Você também pode criar painéis personalizados que são adaptados às suas necessidades de monitoramento. Os painéis ajudam você a monitorar e analisar efetivamente as métricas do Prometheus em seu cluster AKS, o que permite otimizar o desempenho, solucionar problemas e garantir o bom funcionamento de suas cargas de trabalho do Kubernetes.

Você pode usar o painel Kubernetes / Recursos de computação / Nó (Pods) para ver as métricas dos nós do agente Linux. Você pode visualizar o uso da CPU, a cota da CPU, o uso da memória e a cota de memória para cada pod.

Se o cluster incluir nós de agente do Windows, você poderá usar o painel Kubernetes / Método USE / Nó (Windows) para visualizar as métricas do Prometheus coletadas desses nós. Este painel fornece uma visão abrangente do consumo de recursos e do desempenho para nós do Windows em seu cluster.

Aproveite esses painéis dedicados para que você possa monitorar e analisar facilmente métricas importantes relacionadas à CPU, memória e outros recursos nos nós de agente Linux e Windows. Essa visibilidade permite identificar possíveis gargalos, otimizar a alocação de recursos e garantir uma operação eficiente em todo o cluster AKS.

Etapa 2: Verificar a conectividade do plano de controle e do nó de trabalho

Se os nós de trabalho estiverem íntegros, você deverá examinar a conectividade entre o plano de controle AKS gerenciado e os nós de trabalho do cluster. O AKS permite a comunicação entre o servidor API do Kubernetes e kubelets de nó individuais através de um método de comunicação de túnel seguro. Esses componentes podem se comunicar mesmo se estiverem em redes virtuais diferentes. O túnel é protegido com criptografia mTLS (Mutual Transport Layer Security). O túnel primário que o AKS usa é chamado Konnectivity (anteriormente conhecido como apiserver-network-proxy). Certifique-se de que todas as regras de rede e FQDNs estejam em conformidade com as regras de rede do Azure necessárias.

Para verificar a conectividade entre o plano de controle AKS gerenciado e os nós de trabalho de cluster de um cluster AKS, você pode usar a ferramenta de linha de comando kubectl .

Para garantir que os pods do agente Konnectivity funcionem corretamente, execute o seguinte comando:

kubectl get deploy konnectivity-agent -n kube-system

Certifique-se de que os pods estão em um estado pronto.

Se houver um problema com a conectividade entre o plano de controle e os nós de trabalho, estabeleça a conectividade depois de garantir que as regras de trânsito de saída AKS necessárias sejam permitidas.

Execute o seguinte comando para reiniciar os konnectivity-agent pods:

kubectl rollout restart deploy konnectivity-agent -n kube-system

Se reiniciar os pods não corrigir a conexão, verifique se há anomalias nos logs. Execute o seguinte comando para visualizar os konnectivity-agent logs dos pods:

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

Os logs devem mostrar a seguinte saída:

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

Você também pode pesquisar os logs de contêiner no serviço de registro e monitoramento para recuperar os logs. Para obter um exemplo que procura erros de conectividade aks-link , consulte Logs de consulta de informações de contêiner.

Execute a seguinte consulta para recuperar os logs:

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

Execute a seguinte consulta para pesquisar logs de contêiner para qualquer pod com falha em um namespace específico:

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

Se você não conseguir obter os logs usando consultas ou a ferramenta kubectl, use a autenticação Secure Shell (SSH). Este exemplo localiza o pod de frente de túnel depois de se conectar ao nó via SSH.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

Etapa 3: Validar a resolução de DNS ao restringir a saída

A resolução de DNS é um aspeto crucial do seu cluster AKS. Se a resolução DNS não estiver funcionando corretamente, isso pode causar erros de plano de controle ou falhas de extração de imagem de contêiner. Para garantir que a resolução DNS para o servidor de API do Kubernetes esteja funcionando corretamente, siga estas etapas:

1. Execute o comando kubectl exec para abrir um shell de comando no contêiner que está sendo executado no pod.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. Verifique se as ferramentas nslookup ou dig estão instaladas no contêiner.

3. Se nenhuma das ferramentas estiver instalada no pod, execute o seguinte comando para criar um pod utilitário no mesmo namespace.

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. Você pode recuperar o endereço do servidor de API na página de visão geral do cluster AKS no portal do Azure ou executar o seguinte comando.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. Execute o seguinte comando para tentar resolver o servidor API AKS. Para obter mais informações, consulte Solucionar problemas de falhas de resolução de DNS de dentro do pod, mas não do nó de trabalho.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. Verifique o servidor DNS upstream do pod para determinar se a resolução DNS está funcionando corretamente. Por exemplo, para o DNS do Azure, execute o nslookup comando.

   nslookup microsoft.com 168.63.129.16
   

7. Se as etapas anteriores não fornecerem informações, conecte-se a um dos nós de trabalho e tente a resolução de DNS a partir do nó. Esta etapa ajuda a identificar se o problema está relacionado ao AKS ou à configuração de rede.

8. Se a resolução de DNS for bem-sucedida a partir do nó, mas não do pod, o problema pode estar relacionado ao DNS do Kubernetes. Para conhecer as etapas para depurar a resolução DNS do pod, consulte Solucionar problemas de falhas de resolução de DNS.

   Se a resolução DNS falhar a partir do nó, revise a configuração de rede para garantir que os caminhos e portas de roteamento apropriados estejam abertos para facilitar a resolução DNS.

Etapa 4: Verificar se há erros de kubelet

Verifique a condição do processo kubelet que é executado em cada nó de trabalho e certifique-se de que ele não esteja sob qualquer pressão. A pressão potencial pode pertencer à CPU, memória ou armazenamento. Para verificar o status de kubelets de nó individuais, você pode usar um dos seguintes métodos.

Pasta de trabalho do kubelet do AKS

Para garantir que os kubelets do nó do agente funcionem corretamente, siga estas etapas:

1. Vá para o cluster AKS no portal do Azure.

2. Na seção Monitoramento do painel de navegação, selecione Pastas de trabalho.

3. Selecione a pasta de trabalho do Kubelet .

   

4. Selecione Operações e certifique-se de que as operações para todos os nós de trabalho estão concluídas.

   

Monitorização em cluster com Prometheus e Grafana

Se você implantou o Prometheus e o Grafana em seu cluster AKS, poderá usar o painel do Kubernetes / Kubelet para obter informações sobre a integridade e o desempenho de kubelets de nó individuais.

Monitorar o serviço gerenciado para Prometheus e Azure Managed Grafana

Você pode usar o painel pré-construído do Kubernetes / Kubelet para visualizar e analisar as métricas do Prometheus para os kubelets do nó de trabalho. Para fazer isso, você deve configurar seu cluster AKS para coletar métricas do Prometheus no serviço gerenciado do Monitor para Prometheus e conectar seu espaço de trabalho do Monitor a um espaço de trabalho do Azure Managed Grafana.

A pressão aumenta quando um kubelet reinicia e causa um comportamento esporádico e imprevisível. Certifique-se de que a contagem de erros não aumente continuamente. Um erro ocasional é aceitável, mas um crescimento constante indica um problema subjacente que você deve investigar e resolver.

Etapa 5: Use a ferramenta NPD (detetor de problemas do nó) para verificar a integridade do nó

O NPD é uma ferramenta do Kubernetes que você pode usar para identificar e relatar problemas relacionados ao nó. Ele opera como um serviço systemd em cada nó dentro do cluster. Ele reúne métricas e informações do sistema, como uso da CPU, uso do disco e status da conectividade de rede. Quando um problema é detetado, a ferramenta NPD gera um relatório sobre os eventos e a condição do nó. No AKS, a ferramenta NPD é usada para monitorar e gerenciar nós em um cluster Kubernetes hospedado na nuvem do Azure. Para obter mais informações, consulte NPD em nós AKS.

Etapa 6: Verificar as operações de E/S de disco por segundo (IOPS) quanto à limitação

Para garantir que as IOPS não estejam sendo limitadas e afetando serviços e cargas de trabalho dentro do cluster AKS, você pode usar um dos seguintes métodos.

Pasta de trabalho de E/S do disco do nó AKS

Para monitorar as métricas relacionadas à E/S de disco dos nós de trabalho no cluster AKS, você pode usar a pasta de trabalho de E/S do disco do nó. Siga estas etapas para acessar a pasta de trabalho:

1. Vá para o cluster AKS no portal do Azure.

2. Na seção Monitoramento do painel de navegação, selecione Pastas de trabalho.

3. Selecione a pasta de trabalho E/S do disco do nó.

   

4. Analise as métricas relacionadas a E/S.

   

Monitorização em cluster com Prometheus e Grafana

Se você implantou o Prometheus e o Grafana em seu cluster AKS, poderá usar o painel Método USE / Nó para obter informações sobre a E/S de disco para os nós de trabalho do cluster.

Monitorar o serviço gerenciado para Prometheus e Azure Managed Grafana

Você pode usar o painel pré-criado Exportador /Nós de nós para visualizar e analisar métricas relacionadas a E/S de disco dos nós de trabalho. Para fazer isso, você deve configurar seu cluster AKS para coletar métricas do Prometheus no serviço gerenciado do Monitor para Prometheus e conectar seu espaço de trabalho do Monitor a um espaço de trabalho do Azure Managed Grafana.

IOPS e discos do Azure

Os dispositivos de armazenamento físico têm limitações inerentes em termos de largura de banda e do número máximo de operações de arquivo que podem manipular. Os discos do Azure são usados para armazenar o sistema operacional executado em nós AKS. Os discos estão sujeitos às mesmas restrições de armazenamento físico que o sistema operacional.

Considere o conceito de taxa de transferência. Você pode multiplicar o tamanho médio de E/S pelas IOPS para determinar a taxa de transferência em megabytes por segundo (MBps). Tamanhos de E/S maiores se traduzem em IOPS mais baixas devido à taxa de transferência fixa do disco.

Quando uma carga de trabalho ultrapassa os limites máximos de serviço IOPS atribuídos aos discos do Azure, o cluster pode deixar de responder e entrar em um estado de espera de E/S. Em sistemas baseados em Linux, muitos componentes são tratados como arquivos, como soquetes de rede, CNI, Docker e outros serviços que dependem de E/S de rede. Consequentemente, se o disco não puder ser lido, a falha se estende a todos esses arquivos.

Vários eventos e cenários podem acionar a limitação de IOPS, incluindo:

• Um número substancial de contêineres que são executados em nós, porque a E/S do Docker compartilha o disco do sistema operacional.

• Ferramentas personalizadas ou de terceiros empregadas para segurança, monitoramento e registro, que podem gerar operações de E/S adicionais no disco do sistema operacional.

• Eventos de failover de nó e trabalhos periódicos que intensificam a carga de trabalho ou dimensionam o número de pods. Esse aumento de carga aumenta a probabilidade de ocorrência de limitação, potencialmente fazendo com que todos os nós passem para um estado não pronto até que as operações de E/S sejam concluídas.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal
• Francis Simy Nazareth - Brasil | Especialista Técnico Sénior

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Limites de disco da máquina virtual
• Máquinas virtuais e desempenho de disco

Recursos relacionados