Kubeadm: A execução de verificações pré-voo trava

Com parâmetro v10.

[ root@vm03 etcd]# kubeadm join vm10.andrefagundes. Org: 6443 --token 07nh7g.v8p5fcs61fn3o2h4 --discovery-token-ca-cert-de hash sha256: 039a5f9229dafe39d4a51af6899c20adff1de5dda23f780ac9b896e95f95623a --experimental-chave do plano de controlo --certificate-cf3c8ca4f74751bfe7fc9d3e00e03a37619d36a6d6fb79fb5ba3645d74dd7bf4 -v10
I0401 00:34:08.531961 16893 join.go:367] [comprovação] encontrado NodeName vazio; usando o nome do host do SO como NodeName
I0401 00:34:08.532014 16893 join.go:371] [comprovação] encontrado anunciarAddress vazio; usando o endereço IP da interface padrão como AdvertAddress
I0401 00:34:08.532048 16893 initconfiguration.go:105] detectado e usando o soquete CRI: /var/run/dockershim.sock
I0401 00:34:08.532179 16893 interface.go:384] Procurando rotas padrão com endereços IPv4
I0401 00:34:08.532187 16893 interface.go:389] Interface de trânsitos de rota padrão "eth0"
I0401 00:34:08.532324 16893 interface.go:196] A interface eth0 está ativa
I0401 00:34:08.532380 16893 interface.go:244] Interface "eth0" tem 4 endereços :[192.168.122.103/24 fe80::a3c0:2a34:91f2:e0eb/64 fe80::8439:c3eb:5848:c1f2/ 64 fe80::4381:b4a5:5836:a0e1/64].
I0401 00:34:08.532399 16893 interface.go:211] Verificando o endereço 192.168.122.103/24.
I0401 00:34:08.532407 16893 interface.go:218] IP encontrado 192.168.122.103
I0401 00:34:08.532415 16893 interface.go:250] Encontrado endereço IPv4 válido 192.168.122.103 para a interface "eth0".
I0401 00:34:08.532421 16893 interface.go:395] Encontrado IP ativo 192.168.122.103
[preflight] Executando verificações de pré-voo
I0401 00:34:08.532495 16893 preflight.go:90] [preflight] Executando verificações gerais
I0401 00:34:08.532539 16893 checks.go:254] validando a existência e vazio do diretório /etc/kubernetes/manifests
I0401 00:34:08.532570 16893 checks.go:292] validando a existência do arquivo /etc/kubernetes/kubelet.conf
I0401 00:34:08.532579 16893 checks.go:292] validando a existência do arquivo /etc/kubernetes/bootstrap-kubelet.conf
I0401 00:34:08.532586 16893 checks.go:105] validando o tempo de execução do contêiner
I0401 00:34:08.580885 16893 checks.go:131] validando se o serviço está habilitado e ativo
I0401 00:34:08.638659 16893 checks.go:341] validando o conteúdo do arquivo /proc/sys/net/bridge/bridge-nf-call-iptables
I0401 00:34:08.638724 16893 checks.go:341] validando o conteúdo do arquivo /proc/sys/net/ipv4/ip_forward
I0401 00:34:08.638755 16893 checks.go:653] validando se a troca está habilitada ou não
I0401 00:34:08.638788 16893 checks.go:382] validando a presença de ip executável
I0401 00:34:08.638809 16893 checks.go:382] validando a presença de iptables executáveis
I0401 00:34:08.638824 16893 checks.go:382] validando a presença de montagem executável
I0401 00:34:08.638837 16893 checks.go:382] validando a presença do executável nsenter
I0401 00:34:08.638849 16893 checks.go:382] validando a presença de ebtables executáveis
I0401 00:34:08.638860 16893 checks.go:382] validando a presença do executável ethtool
I0401 00:34:08.638871 16893 checks.go:382] validando a presença do executável socat
I0401 00:34:08.638883 16893 checks.go:382] validando a presença do executável tc
I0401 00:34:08.638894 16893 checks.go:382] validando a presença de toque executável
I0401 00:34:08.638914 16893 checks.go:524] executando todas as verificações
I0401 00:34:08.664826 16893 checks.go:412] verificando se o nome do nó fornecido é alcançável usando net.LookupHost
I0401 00:34:08.665583 16893 checks.go:622] validando a versão do kubelet
I0401 00:34:08.709573 16893 checks.go:131] validando se o serviço está habilitado e ativo
I0401 00:34:08.716270 16893 checks.go:209] validando a disponibilidade da porta 10250
I0401 00:34:08.716418 16893 checks.go:439] validando se o tipo de conectividade é via proxy ou direto
I0401 00:34:08.716444 16893 join.go:427] [comprovação] Descobrindo informações do cluster
I0401 00:34:08.716498 16893 token.go:200] [discovery] Tentando se conectar ao servidor API "vm10.andrefagundes. org:6443 "
I0401 00:34:08.716961 16893 token.go:75] [discovery] Criado cliente de descoberta de informações de cluster, solicitando informações de " https://vm10.andrefagundes.org :6443"
I0401 00:34:08.717031 16893 round_trippers.go:419] curl -k -v -XGET -H "Aceitar: application/json, / " -H "User-Agent: kubeadm/v1.14.0 (linux/amd64) kubernetes/ 641856d" ' https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info'
I0401 00:34:08.722405 16893 round_trippers.go:438] GET https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info 403 Proibido em 5 milissegundos
I0401 00:34:08.722423 16893 round_trippers.go:444] Cabeçalhos de resposta:
I0401 00:34:08.722432 16893 round_trippers.go:447] Tipo de conteúdo: application/json
I0401 00:34:08.722441 16893 round_trippers.go:447] X-Content-Type-Options: nosniff
I0401 00:34:08.722450 16893 round_trippers.go:447] Content-Length: 321
I0401 00:34:08.722458 16893 round_trippers.go:447] Data: Seg, 01 de abril de 2019 03:34:08 GMT
I0401 00:34:08.722497 16893 request.go:942] Corpo da resposta: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message ":"configmaps \"cluster-info\" é proibido: Usuário \" system:anonymous\ " não pode obter o recurso \"configmaps\" no grupo de API \"\" no namespace \"kube-public\""," reason":"Proibido","details":{"name":"cluster-info","kind":"configmaps"},"code":403}
I0401 00:34:08.722937 16893 token.go:83] [discovery] Falha ao solicitar informações do cluster, tentará novamente: [configmaps "cluster-info" é proibido: Usuário " system:anonymous " não pode obter o recurso "configmaps" na API group "" no namespace "kube-public"]

Outra informação... vm10.andrefagundes.org é um Haproxy na frente do meu avião de controle.

parece ser um problema de rede para mim.
você tem certeza de que este nó de junção tem conectividade com a porta 6443 no LB e pode resolver vm10.andrefagundes.org?

Sim, também mudei vm10 para apontar para o plano de controle. Eu vi tráfego no plano de controle entrando em monitoramento com TCDUMP.

você está vendo algum erro pendente nos logs do kubelet?

Existem vários erros nos logs. Também tentei reinstalar o cluster algumas vezes e cada vez recebo erros diferentes. estou desistindo. Podemos encerrar o caso. Obrigado!!

a criação de um único nó do plano de controle + alguns nós do trabalhador funciona para você ou o problema ocorre apenas ao unir nós adicionais do plano de controle?

O usuário " system:anonymous " não pode obter o recurso "configmaps" no grupo de API "" no namespace "kube-public"","reason":"Forbidden","details":{"name":"cluster-info", "kind":"configmaps"},"code":403

Parece que o kubeadm init não cria / configura as informações do cluster corretamente
Você poderia compartilhar os logs de inicialização do kubeadm?

Eu tenho o mesmo erro depois de executar o comando 'kubeadm join ...': Executando verificações pré-vôo travadas. Eu não tenho ideia de lidar com isso.

Eu tive o mesmo problema. Eu precisava reiniciar o mestre e depois disso executar o comando 'kubeadm join ...' novamente nos nós funcionavam para mim.

eu tive os mesmos problemas com kubeadm v1.15 , reboot master não funciona para mim

eu tive os mesmos problemas com kubeadm v1.15 , reboot master não funciona para mim

voltar ao kubelet & kubeadm v1.13.1 corrigiu esses problemas

certifique-se de chamar kubeadm init/join com, por exemplo --v=2 para ter mais detalhes sobre o que está acontecendo.

Ocorreu o mesmo problema, mas o problema foi rastreado até a conectividade de rede do meu lado com meus daemons keepalived e haproxy que foram configurados incorretamente, impedindo que o nó mestre de suspensão ingressasse no cluster por meio do serviço de API VIP

Vale ressaltar que executar o kubeadm init/join com --v=2 foi como eu consegui resolvê-lo

certifique-se de chamar kubeadm init/join com, por exemplo --v=2 para ter mais detalhes sobre o que está acontecendo.

kubeadm v1.15

kubeadm join .. --v=2

I0802 11:47:31.027812 359 token.go:202] [discovery] Falha ao conectar-se ao servidor API "": o ID do token "r5uyqk" é inválido para este cluster ou expirou. Use "kubeadm token create" no nó do plano de controle para criar um novo token válido

kubeadm init phase upload-certs --upload-certs
criação de token kubeadm

então kubeadm junte-se ao sucesso

No meu caso, consegui ingressar no nó com êxito parando o firewall no nó mestre.

systemctl stop firewall

No meu caso, consegui ingressar no nó com êxito parando o firewall no nó mestre.

systemctl stop firewall

Este funcionou como charme.
[ root @ localhost ~] # kubeadm Junte-se 192.168.8.128:6443 --token 38lhr8.kxi5uy8aoy71dj17 --Discovery-token-ca-cert-hash sha256: a12c805b8d98f42a256486d27EABA190AB8F5BDCE89BBB8F5BCA983
[preflight] Executando verificações de pré-voo
[AVISO IsDockerSystemdCheck]: detectado "cgroupfs" como o driver do Docker cgroup. O driver recomendado é "systemd". Siga o guia em https://kubernetes.io/docs/setup/cri/
[AVISO SystemVerification]: esta versão do Docker não está na lista de versões validadas: 19.03.1. Última versão validada: 18.09
[comprovação] Lendo a configuração do cluster...
[preflight] FYI: Você pode olhar para este arquivo de configuração com 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Baixando a configuração para o kubelet do ConfigMap "kubelet-config-1.14" no namespace kube-system
[kubelet-start] Gravando a configuração do kubelet no arquivo "/var/lib/kubelet/config.yaml"
[kubelet-start] Escrevendo arquivo de ambiente kubelet com sinalizadores para o arquivo "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Ativando o serviço kubelet
[kubelet-start] Aguardando o kubelet executar o TLS Bootstrap...

Este nó ingressou no cluster:

• A solicitação de assinatura de certificado foi enviada ao apiserver e uma resposta foi recebida.
• O Kubelet foi informado dos novos detalhes da conexão segura.

Execute 'kubectl get nodes' no plano de controle para ver esse nó ingressar no cluster.

olhando para o log no OP novamente, isso não é um "trava" no preflight, mas o mapa de configuração de informações do cluster não pode ser acessado, a única maneira de isso acontecer se a fase "boostrap-token" de "init" é ignorado.

olhando para relatórios posteriores, vejo problemas de rede e token expirado que se enquadram em itens de "suporte" e não em bugs.

/suporte de triagem
em caso de dúvidas, tente stackoverflow, reddit ou #kubeadm no k8s slack.

se você encontrar um bug real, por favor, abra um novo problema.

No meu caso, consegui ingressar no nó com êxito parando o firewall no nó mestre.

systemctl stop firewall

systemctl parar firewalld

Acho que o tráfego não tinha permissão para conectar o nó mestre.

adicionar regras no sg resolveu meu problema

Eu tenho o mesmo erro depois de executar o comando 'kubeadm join ...': Executando verificações pré-vôo travadas. Eu não tenho ideia de lidar com isso.

Você achou alguma solução?

Acho que o tráfego não tinha permissão para conectar o nó mestre.

adicionar regras no sg resolveu meu problema

qual porta de entrada você permitiu?