Compartilhar via

Solução de problemas do Kubernetes

  • Artigo

Esta página aborda vários problemas comuns com a configuração, a rede e as implantações do Kubernetes.

Dica

Sugira um item de FAQ levantando um PR para o nosso repositório de documentação.

Esta página está subdividida nas seguintes categorias:

  1. Perguntas gerais
  2. Erros comuns de rede
  3. Erros comuns do Windows
  4. Erros comuns do mestre do Kubernetes

Perguntas gerais

Como saber se o Kubernetes no Windows foi concluído com êxito?

Você deve ver kubelet, kube-proxy e (se você escolheu Flannel como sua solução de rede) processos de agente de host flanneld em execução no seu nó. Além disso, seu nó do Windows deve ser listado como "Pronto" no cluster do Kubernetes.

Posso configurar para executar tudo isso em segundo plano?

A partir do Kubernetes versão 1.11, kubelet & kube-proxy pode ser executado como Windows Services nativo. Você também pode sempre usar gerenciadores de serviços alternativos como nssm.exe para sempre executar esses processos (flanneld, kubelet & kube-proxy) em segundo plano para você.

Erros comuns de rede

Os balanceadores de carga são canalizados de forma inconsistente nos nós do cluster

No Windows, o kube-proxy cria um balanceador de carga HNS para cada serviço Kubernetes no cluster. Na configuração kube-proxy (padrão), nós em clusters contendo muitos (geralmente 100+) balanceadores de carga podem ficar sem portas TCP efêmeras disponíveis (também conhecido como intervalo dinâmico de portas, que por padrão abrange as portas 49152 a 65535). Isso se deve ao alto número de portas reservadas em cada nó para cada balanceador de carga (não DSR). Esse problema pode se manifestar por meio de erros no kube-proxy, como:

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

Os usuários podem identificar esse problema executando o script CollectLogs.ps1 e consultando os *portrange.txt arquivos.

O CollectLogs.ps1 também imitará a lógica de alocação do HNS para testar a disponibilidade de alocação do pool de portas no intervalo de portas TCP efêmero e relatar sucesso/falha no reservedports.txt. O script reserva 10 intervalos de 64 portas TCP efêmeras (para emular o comportamento do HNS), conta os êxitos de reserva e as falhas e, em seguida, libera os intervalos de portas alocados. Um número de sucesso menor que 10 indica que o pool efêmero está ficando sem espaço livre. Um resumo heurístico de quantas reservas de porta de 64 blocos estão aproximadamente disponíveis também será gerado no reservedports.txt.

Para resolver esse problema, algumas etapas podem ser executadas:

  1. Para uma solução permanente, o balanceamento de carga kube-proxy deve ser definido para o modo DSR. O modo DSR é totalmente implementado e está disponível apenas na versão 18945 (ou superior) mais recente do Windows Server Insider.
  2. Como solução alternativa, os usuários também podem aumentar a configuração padrão do Windows de portas efêmeras disponíveis usando um comando como netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. AVISO: Substituir o intervalo de portas dinâmicas padrão pode ter consequências em outros processos/serviços no host que dependem de portas TCP disponíveis do intervalo não efêmero, portanto, esse intervalo deve ser selecionado cuidadosamente.
  3. Há um aprimoramento de escalabilidade para balanceadores de carga de modo não DSR usando o compartilhamento inteligente de pool de portas incluído no KB4551853 de atualização cumulativa (e todas as atualizações cumulativas mais recentes).

A publicação do HostPort não está funcionando

Para usar o recurso HostPort, verifique se seus plug-ins CNI estão na versão v0.8.6 ou superior e se o arquivo de configuração CNI tem os portMappings recursos definidos:

"capabilities": {
    "portMappings":  true
}

Estou vendo erros como "hnsCall falhou no Win32: O disquete errado está na unidade."

Esse erro pode ocorrer ao fazer modificações personalizadas em objetos HNS ou instalar o novo Windows Update que introduz alterações no HNS sem derrubar objetos HNS antigos. Ele indica que um objeto HNS que foi criado anteriormente antes de uma atualização é incompatível com a versão HNS atualmente instalada.

No Windows Server 2019 (e versões anteriores), os usuários podem excluir objetos HNS excluindo o arquivo HNS.data

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Os usuários devem ser capazes de excluir diretamente quaisquer endpoints ou redes HNS incompatíveis:

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Os usuários no Windows Server, versão 1903 podem ir para o seguinte local do Registro e excluir quaisquer NICs começando com o nome da rede (por exemplo vxlan0 , ou cbr0):

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Os contêineres na minha implantação do Flannel host-gw no Azure não podem acessar a Internet

Ao implantar o Flannel no modo host-gw no Azure, os pacotes precisam passar pelo vSwitch do host físico do Azure. Os usuários devem programar rotas definidas pelo usuário do tipo "dispositivo virtual" para cada sub-rede atribuída a um nó. Isso pode ser feito por meio do portal do Azure (veja um exemplo aqui) ou por meio az da CLI do Azure. Aqui está um exemplo UDR com nome "MyRoute" usando comandos az para um nó com IP 10.0.0.4 e respectiva sub-rede pod 10.244.0.0/24:

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

Dica

Se você estiver implantando o Kubernetes no Azure ou em VMs IaaS de outros provedores de nuvem, também poderá usá-lo overlay networking .

Meus pods do Windows não podem executar ping em recursos externos

Os pods do Windows não têm regras de saída programadas para o protocolo ICMP atualmente. No entanto, TCP/UDP é suportado. Ao tentar demonstrar conectividade com recursos fora do cluster, substitua ping <IP> por comandos correspondentes curl <IP> .

Se você ainda estiver enfrentando problemas, provavelmente sua configuração de rede no cni.conf merece alguma atenção extra. Você sempre pode editar esse arquivo estático, a configuração será aplicada a qualquer recurso Kubernetes recém-criado.

Por quê? Um dos requisitos de rede do Kubernetes (consulte Modelo do Kubernetes) é que a comunicação de cluster ocorra sem NAT internamente. Para honrar esse requisito, temos uma ExceptionList para toda a comunicação onde não queremos que o NAT de saída ocorra. No entanto, isso também significa que você precisa excluir o IP externo que você está tentando consultar da ExceptionList. Só então o tráfego originado de seus pods do Windows será SNAT corretamente para receber uma resposta do mundo exterior. A esse respeito, sua ExceptionList em cni.conf deve ter a seguinte aparência:

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

Meu nó do Windows não pode acessar um serviço NodePort

O acesso NodePort local do próprio nó pode falhar. Essa é uma lacuna de recursos conhecida que está sendo resolvida com KB4571748 de atualização cumulativa (ou posterior). O acesso NodePort funcionará a partir de outros nós ou clientes externos.

Meu nó do Windows para de rotear thourgh NodePorts depois que eu reduzi meus pods

Devido a uma limitação de design, é necessário que haja pelo menos um pod em execução no nó do Windows para que o encaminhamento do NodePort funcione.

Depois de algum tempo, vNICs e HNS endpoints de contêineres estão sendo excluídos

Esse problema pode ser causado quando o parâmetro não é passado para kube-proxyhostname-override. Para resolvê-lo, os usuários precisam passar o nome do host para kube-proxy da seguinte maneira:

C:\k\kube-proxy.exe --hostname-override=$(hostname)

No modo Flannel (vxlan), meus pods estão tendo problemas de conectividade depois de ingressar novamente no nó

Sempre que um nó excluído anteriormente estiver sendo reingressado no cluster, o flannelD tentará atribuir uma nova sub-rede de pod ao nó. Os usuários devem remover os arquivos de configuração de sub-rede de pod antigos nos seguintes caminhos:

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

Depois de lançar o Kubernetes, Flanneld está preso em "Esperando que a rede seja criada"

Esse problema deve ser resolvido com o Flannel v0.12.0 (e superior). Se você estiver usando uma versão mais antiga do Flanneld, há uma condição de corrida conhecida que pode ocorrer de modo que o IP de gerenciamento da rede de flanela não esteja definido. Uma solução alternativa é simplesmente reiniciar o FlannelD manualmente.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Meus pods do Windows não podem ser iniciados devido à falta de /run/flannel/subnet.env

Isso indica que o Flannel não foi iniciado corretamente. Você pode tentar reiniciar o flanneld.exe ou copiar os arquivos manualmente do mestre do /run/flannel/subnet.env Kubernetes para o nó de trabalho do Windows e modificar a linha para C:\run\flannel\subnet.env a FLANNEL_SUBNET sub-rede atribuída. Por exemplo, se a sub-rede do nó 10.244.4.1/24 foi atribuída:

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Na maioria das vezes, há outro problema que pode estar causando esse erro que precisa ser investigado primeiro. Recomenda-se deixar flanneld.exe gerar este arquivo para você.

A conectividade pod-to-pod entre hosts está quebrada no meu cluster Kubernetes em execução no vSphere

Como o vSphere e o Flannel reservam a porta 4789 (porta VXLAN padrão) para sobreposição de rede, os pacotes podem acabar sendo interceptados. Se o vSphere for usado para sobreposição de rede, ele deverá ser configurado para usar uma porta diferente para liberar 4789.

Meus endpoints/IPs estão vazando

Existem 2 problemas atualmente conhecidos que podem causar o vazamento de endpoints.

  1. O primeiro problema conhecido é um problema no Kubernetes versão 1.11. Por favor, evite usar o Kubernetes versão 1.11.0 - 1.11.2.
  2. O segundo problema conhecido que pode causar vazamento de endpoints é um problema de simultaneidade no armazenamento de endpoints. Para receber a correção, você deve usar o Docker EE 18.09 ou superior.

Meus pods não podem ser iniciados devido a erros de "rede: falha ao alocar para intervalo"

Isso indica que o espaço de endereço IP no nó está esgotado. Para limpar quaisquer pontos de extremidade vazados, migre todos os recursos nos nós afetados e execute os seguintes comandos:

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Meu nó do Windows não pode acessar meus serviços usando o IP do serviço

Esta é uma limitação conhecida da pilha de rede atual no Windows. No entanto, os podsdo Windows podem acessar o IP do serviço.

Nenhum adaptador de rede é encontrado ao iniciar o Kubelet

A pilha de rede do Windows precisa de um adaptador virtual para que a rede Kubernetes funcione. Se os comandos a seguir não retornarem nenhum resultado (em um shell de administração), a criação de rede HNS — um pré-requisito necessário para que o Kubelet funcione — falhou:

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

Muitas vezes, vale a pena modificar o parâmetro InterfaceName do script start.ps1, nos casos em que o adaptador de rede do host não é "Ethernet". Caso contrário, consulte a saída do script para ver se há erros durante a start-kubelet.ps1 criação da rede virtual.

Ainda estou vendo problemas. O que devo fazer?

Pode haver restrições adicionais em vigor em sua rede ou em hosts que impedem certos tipos de comunicação entre nós. Verifique se:

  • Você configurou corretamente a topologia de rede escolhida (l2bridge ou overlay)
  • O tráfego que parece estar vindo de pods é permitido
  • O tráfego HTTP é permitido, se você estiver implantando serviços Web
  • Pacotes de protocolos diferentes (ou seja, ICMP vs. TCP/UDP) não estão sendo descartados

Dica

Para recursos adicionais de autoajuda, há também um guia de solução de problemas de rede do Kubernetes para Windows disponível aqui.

Erros comuns do Windows

Meus pods do Kubernetes estão presos em "ContainerCreating"

Esse problema pode ter muitas causas, mas uma das mais comuns é que a imagem de pausa foi configurada incorretamente. Este é um sintoma de alto nível da próxima edição.

Ao implantar, os contêineres do Docker continuam reiniciando

Verifique se a imagem de pausa é compatível com a versão do sistema operacional. O Kubernetes pressupõe que o sistema operacional e os contêineres têm números de versão do sistema operacional correspondentes. Se você estiver usando uma compilação experimental do Windows, como uma compilação do Insider, será necessário ajustar as imagens de acordo. Consulte o repositório do Docker da Microsoft para obter imagens.

Erros comuns do mestre do Kubernetes

A depuração do mestre do Kubernetes se enquadra em três categorias principais (em ordem de probabilidade):

  • Algo está errado com os contêineres do sistema Kubernetes.
  • Algo está errado com a forma como kubelet está correndo.
  • Algo está errado com o sistema.

Corra kubectl get pods -n kube-system para ver os pods que estão sendo criados pelo Kubernetes, isso pode dar alguma visão sobre quais deles em particular estão travando ou não estão iniciando corretamente. Em seguida, corra docker ps -a para ver todos os contêineres brutos que dão suporte a essas cápsulas. Finalmente, execute docker logs [ID] no(s) contêiner(es) suspeito(s) de estar causando o problema para ver a saída bruta dos processos.

Não é possível conectar-se ao servidor de API em https://[address]:[port]

Na maioria das vezes, esse erro indica problemas de certificado. Verifique se você gerou o arquivo de configuração corretamente, se os endereços IP nele correspondem aos do host e se você o copiou para o diretório montado pelo servidor de API.

Bons lugares para encontrar esse arquivo de configuração são:

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

caso contrário, consulte o arquivo de manifesto do servidor de API para verificar os pontos de montagem.