Suporte e solução de problemas

Nesta página, falamos sobre os recursos de suporte e resolução de problemas disponíveis para o Kubernetes e o Kubernetes Engine, além de soluções para problemas comuns.

Suporte

Na lista a seguir, você conhecerá os recursos de suporte para o Kubernetes Engine e o Kubernetes:

• Faça perguntas relacionadas a programação e desenvolvimento nas tags Kubernetes e Kubernetes Engine do StackOverflow.
• Interaja com a equipe e os usuários do Kubernetes no canal Kubernetes Slack.
• Faça perguntas e participe de discussões no grupo de e-mail dos usuários do Kubernetes.
• Saiba mais sobre os grupos e eventos de interesse especial na comunidade do Kubernetes.
• Compre um plano de suporte no Suporte do Google Cloud.

Bugs e solicitações de recursos do Kubernetes

Se você encontrar um bug ou quiser solicitar um recurso, registre um problema no GitHub.

Antes de fazer isso, pesquise os problemas existentes para conferir se o seu já foi resolvido.

Para bugs, inclua informações detalhadas de reprodução do problema, como:

• versão do Kubernetes: kubectl;
• provedor de nuvem, distribuição do SO, configuração de rede e versão do Docker;
• etapas para reproduzir o problema.

Solução de problemas

Nas seções a seguir, você verá problemas comuns encontrados no Kubernetes Engine.

Como depurar recursos de Kubernetes

Se você tiver um problema relacionado ao cluster, consulte Como solucionar problemas de clusters (em inglês) na documentação do Kubernetes.

Se você está tendo um problema com o aplicativo, os pods ou o objeto controlador, consulte Como solucionar problemas de aplicativos (em inglês).

Comando do kubectl não encontrado

Em primeiro lugar, instale o binário kubectl. Basta executar o seguinte comando:

sudo gcloud components update kubectl

Responda "sim" quando a modificação da variável de ambiente $PATH for solicitada no instalador. Quando essas variáveis são modificadas, você consegue usar os comandos do kubectl sem digitar o caminho completo do arquivo.

Se preferir, adicione a seguinte linha a ~/.bashrc (ou a ~/.bash_profile em macOS, ou outro local em que as variáveis de ambiente sejam armazenadas no shell):

export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/

Por fim, execute o comando a seguir para carregar o arquivo .bashrc ou .bash_profile atualizado:

source ~/.bashrc

Comandos do kubectl retornam erro de "conexão recusada"

Defina o contexto do cluster com o seguinte comando:

gcloud container clusters get-credentials CLUSTER_NAME

Se não tiver certeza sobre o que inserir em CLUSTER_NAME, use o comando a seguir para listar os clusters:

gcloud container clusters list

Comandos do kubectl retornam erro de "falha ao negociar versão da API"

Verifique se o kubectl tem credenciais de autenticação:

gcloud auth application-default login

Os comandos logs, attach, exec e port-forward do kubectl travam

Esses comandos dependem do mestre do cluster conseguir acessar os nodes no cluster. Porém, como o mestre não está na mesma rede do Compute Engine que os nodes do cluster, dependemos dos túneis SSH para ativar a comunicação segura.

No Kubernetes Engine, um arquivo de chave pública SSH é salvo nos metadados do projeto do Compute Engine. Todas as VMs do Compute Engine que usam as imagens fornecidas pelo Google verificam regularmente os metadados comuns do projeto e os metadados da instância em busca das chaves SSH para adicionar à lista de usuários autorizados da VM. Além disso, o Kubernetes Engine adiciona uma regra de firewall à rede do Compute Engine, o que permite o acesso SSH do endereço IP do mestre a cada node no cluster.

Quando um dos comandos do kubectl acima não são executados, é provável que estejam ocorrendo falhas no mestre para abrir os túneis SSH com os nodes. Verifique as possíveis causas:

1. O cluster não tem nenhum node.

   Se você reduziu o número de nodes no cluster a zero, os túneis SSH não funcionam.

   Para corrigir esse problema, redimensione o cluster para ter pelo menos um node.

2. Os pods no cluster estão paralisados em um estado de encerramento e impedem os nodes que não existem mais de serem removidos do cluster.

   Esse é um problema que afeta somente o Kubernetes versão 1.1, mas ele pode ser causado pelo redimensionamento repetido do cluster.

   Para corrigi-lo, exclua os pods que estão no estado de encerramento há mais de alguns minutos. Dessa forma, os nodes antigos serão removidos da API do mestre e substituídos pelos novos nodes.

3. As regras de firewall da rede não permitem acesso SSH ao mestre.

   Todas as redes do Compute Engine são criadas com uma regra de firewall denominada "default-allow-ssh" que permite acesso SSH de todos os endereços IP (o que certamente requer uma chave privada válida). O Kubernetes Engine também insere uma regra SSH em cada cluster no formato gke-<cluster_name>-<random-characters>-ssh, que permite acesso SSH especificamente do IP principal do cluster aos nodes do cluster. Se não houver nenhuma dessas regras, o mestre não poderá abrir os túneis SSH.

   Para corrigir isso, adicione novamente uma regra de firewall que permita acesso às VMs com a tag que está em todos os nodes do cluster do endereço IP do mestre.

4. A entrada de metadados comuns do projeto "sshKeys" está cheia.

   Quando a entrada de metadados do projeto chamada "sshKeys" está próxima do limite de tamanho de 32 KiB, a chave SSH do Kubernetes Engine não pode ser adicionada para ativar a abertura de túneis SSH. Para ver os metadados, execute gcloud compute project-info describe [--project=PROJECT] e verifique o tamanho da lista de sshKeys.

   Para corrigir isso, exclua algumas chaves SSH que não são mais necessárias.

5. Você definiu um campo de metadados com a chave "sshKeys" nas VMs no cluster.

   O agente de node nas VMs prefere as sshKeys por instância em vez das chaves SSH do projeto inteiro, portanto, se você definiu quaisquer chaves SSH especificamente nos nodes do cluster, os nodes não respeitam a chave SSH do mestre nos metadados do projeto. Para verificar isso, execute gcloud compute instances describe <VM-name> e procure o campo "sshKeys" nos metadados.

   Para corrigir esse problema, exclua as chaves SSH por instância dos metadados da instância.

É importante observar que esses recursos não são necessários para o funcionamento correto do cluster. Se você preferir manter a rede do cluster bloqueada contra qualquer acesso externo, saiba que recursos como esse não funcionarão.

As métricas do cluster não são exibidas no Stackdriver

Verifique se você ativou a Stackdriver Monitoring API e a Stackdriver Logging API no projeto. Além disso, veja se ele aparece no Stackdriver.

Se o problema continuar, verifique estas possíveis causas:

1. Verifique se o monitoramento está ativado no cluster.

   O monitoramento é ativado por padrão nos clusters criados no Developers Console e na ferramenta de linha de comando gcloud. Entretanto, para ter certeza disso, execute o comando a seguir ou clique nos detalhes do cluster no Developers Console:

   gcloud container clusters describe cluster-name
   

   Na saída da ferramenta de linha de comando gcloud, o status exibido do "monitoringService" precisa ser "monitoring.googleapis.com" e o Cloud Monitoring precisa estar ativado no Developers Console.

   Se o monitoramento não estiver ativado, execute o seguinte comando para ativá-lo:

   gcloud container clusters update cluster-name --monitoring-service=monitoring.googleapis.com
   

2. Quanto tempo faz desde que o cluster foi criado ou desde que o monitoramento foi ativado?

   Pode levar até uma hora para as métricas do novo cluster começarem a aparecer no Stackdriver Monitoring.

3. Há um heapster sendo executado no cluster, no namespace "kube-system"?

   É possível que a falha na programação desse pod esteja ocorrendo porque o cluster está muito cheio. Para verificar isso, chame kubectl get pods --namespace=kube-system.

4. O mestre do cluster consegue se comunicar com os nodes?

   O Stackdriver Monitoring depende disso. Para verificar se esse é o caso, execute kubectl logs [POD-NAME]. Se um erro é retornado, talvez os túneis SSH sejam a causa do problema. Consulte esta seção.

Se você está com algum problema relacionado ao agente do Stackdriver Logging, consulte a documentação de solução de problemas dele.

Para mais informações, consulte a documentação do Stackdriver.

Erro 404: recurso "não encontrado" ao chamar os comandos gcloud container

Refaça a autenticação da ferramenta de linha de comando gcloud:

gcloud auth login

Erro 400: permissões de edição ausentes na conta

A conta de serviço do Compute Engine foi excluída ou editada.

Quando você ativa a Compute Engine API, essa conta é criada e recebe permissões de edição no projeto. Se você edita essas permissões ou remove a conta completamente, uma falha ocorre na criação do cluster.

Para resolver o problema, recrie a conta e restaure a permissão de edição da conta no projeto.