Solução de problemas do Kubernetes
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 gerando um PR para nosso repositório de documentação.
Esta página está subdividida nas seguintes categorias:
Perguntas gerais
Como sei que o Kubernetes no Windows foi concluído com sucesso?
Você deve ver os processos de agente de host kubelet, kube-proxy e (se você escolheu Flannel como sua solução de rede) flanneld em execução em 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 da versão 1.11 do Kubernetes, o kubelet e o kube-proxy podem ser executados como serviços nativos do Windows. Você também pode sempre usar gerenciadores de serviços alternativos, como o nssm.exe , para sempre executar esses processos (flanneld, kubelet e kube-proxy) em segundo plano para você.
Erros comuns de rede
Os balanceadores de carga são conectados de forma inconsistente entre os nós do cluster
No Windows, o kube-proxy cria um balanceador de carga HNS para cada serviço do Kubernetes no cluster. Na configuração kube-proxy (padrão), os nós em clusters contendo muitos balanceadores de carga (geralmente 100+) podem ficar sem portas TCP efêmeras disponíveis (também conhecido como intervalo de portas dinâmicas, que por padrão cobre 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 efêmeras TCP (para emular o comportamento do HNS), conta os sucessos e falhas da reserva 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:
- Para uma solução permanente, o balanceamento de carga kube-proxy deve ser definido como o modo DSR. O modo DSR é totalmente implementado e está disponível apenas no Windows Server Insider build 18945 ou superior.
- 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âmico 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 com cuidado. - 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, certifique-se de que seus plug-ins CNI sejam a versão v0.8.6 ou superior e que o arquivo de configuração CNI tenha 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 um novo Windows Update que introduz alterações no HNS sem derrubar objetos HNS antigos. Indica que um objeto HNS que foi criado anteriormente antes de uma atualização é incompatível com a versão do HNS atualmente instalada.
No Windows Server 2019 (e anterior), 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 pontos de extremidade 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 do Windows Server, versão 1903, podem acessar o seguinte local do Registro e excluir todas as NICs que começam 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 "solução de virtualização" 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 de UDR com o nome "MyRoute" usando comandos az para um nó com IP 10.0.0.4 e respectiva sub-rede de 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 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 hoje. No entanto, há suporte para TCP/UDP. Ao tentar demonstrar conectividade com recursos fora do cluster, substitua ping <IP> pelos comandos correspondentes curl <IP> .
Se você ainda estiver enfrentando problemas, provavelmente sua configuração de rede no cni.conf merece atenção extra. Você sempre pode editar esse arquivo estático, a configuração será aplicada a qualquer recurso do Kubernetes recém-criado.
Por quê?
Um dos requisitos de rede do Kubernetes (consulte o modelo do Kubernetes) é que a comunicação do cluster ocorra sem NAT internamente. Para atender a esse requisito, temos uma ExceptionList para todas as comunicações em que não queremos que o NAT de saída ocorra. No entanto, isso também significa que você precisa excluir o IP externo que está tentando consultar da ExceptionList. Somente 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 deve cni.conf 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 recurso conhecida que está sendo resolvida com KB4571748 de atualização cumulativa (ou posterior). O acesso ao NodePort funcionará a partir de outros nós ou clientes externos.
Meu nó do Windows para de rotear 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, os pontos de extremidade vNICs e HNS dos contêineres estão sendo excluídos
Esse problema pode ser causado quando o hostname-override parâmetro não é passado para kube-proxy. 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 após reingressar no nó
Sempre que um nó excluído anteriormente estiver sendo reingressado no cluster, flannelD tentará atribuir uma nova sub-rede de pod ao nó. Os usuários devem remover os arquivos de configuração de sub-rede do pod antigos nos seguintes caminhos:
Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json
Depois de iniciar o Kubernetes, Flanneld fica preso em "Aguardando a criação da rede"
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 flanneld.exe ou copiar os arquivos manualmente do mestre do /run/flannel/subnet.env Kubernetes para C:\run\flannel\subnet.env o nó de trabalho do Windows e modificar a FLANNEL_SUBNET linha para a sub-rede que foi 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 de pod para pod entre hosts é interrompida no meu cluster do Kubernetes em execução no vSphere
Como o vSphere e o Flannel reservam a porta 4789 (porta VXLAN padrão) para rede de sobreposição, os pacotes podem acabar sendo interceptados. Se o vSphere for usado para rede de sobreposição, 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 vazamento de endpoints.
- O primeiro problema conhecido é um problema no Kubernetes versão 1.11. Evite usar o Kubernetes versão 1.11.0 - 1.11.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 em seu nó está esgotado. Para limpar quaisquer endpoints 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 de serviço
Essa é uma limitação conhecida da pilha de rede atual no Windows. No entanto, os pods doWindows 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 do Kubernetes funcione. Se os comandos a seguir não retornarem resultados (em um shell de administração), a criação da rede HNS — um pré-requisito necessário para o Kubelet funcionar — 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 (
l2bridgeouoverlay) - O tráfego que parece vir de pods é permitido
- O tráfego HTTP é permitido, se você estiver implantando serviços da 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 do próximo problema.
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 tenham 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, precisará ajustar as imagens de acordo. Consulte o repositório 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 maneira como
kubeletestá 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 algumas dicas sobre quais em particular estão travando ou não iniciando corretamente. Em seguida, corra docker ps -a para ver todos os contêineres brutos que suportam esses pods. Por fim, 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. Certifique-se de ter gerado o arquivo de configuração corretamente, de que os endereços IP nele correspondem aos do seu host e de que 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.