Kubeadm: apiserver falha ao iniciar porque livenessprobe é muito agressivo

Parece que definimos InitialDelaySeconds e TimeoutSeconds como 15 para os pods do plano de controle atualmente, o que corresponde ao que kube-up.sh faz. Eu entendo que o lançamento inicial está lento, com todas as imagens sendo retiradas de uma vez, mas depois que todas as imagens foram retiradas, quanto tempo seu apiserver leva para responder aos cheques de /healthz após o lançamento?

Sem dúvida, provavelmente deveríamos ajustar esses dois valores para acomodar máquinas de baixa potência.

Uma vez iniciado, ele pode responder a verificações de saúde em << 15s - é realmente apenas todas as coisas extras que o apiserver faz entre exec () e estar realmente pronto para servir a afaics.

ah, e o tempo de pull do docker não conta contra InitialDelaySeconds afaics (bom). Em outros exemplos com imagens maiores (ubuntu genérico) no meu link de rede lento, o pull pode levar muitos minutos, mas o cronômetro initialDelaySeconds não parece começar a contar até que o pull seja concluído e a execução do docker tenha iniciado. (Eu não olhei para o código relevante - apenas experiências anedóticas frequentes)

Estou com o mesmo problema. Com máquinas lentas, kubeadm fica para sempre. Usando v1.7.4

@anguslees e @koalalorenzo , você pode confirmar que, se alterar manualmente as configurações da detecção de atividade (editando os arquivos de manifesto em /etc/kubernetes/manifests/ ), isso corrigirá o seu problema? Também vi recentemente um caso no Slack em que o usuário tinha os mesmos sintomas, mas provavelmente estava enfrentando restrições de memória, porque o problema foi embora quando eles mudaram para um tipo de host com mais memória.

Só quero ter certeza de que essa abordagem realmente resolverá o problema antes de investirmos tempo em codificá-lo. Obrigado!

Também estou tendo esse problema ao tentar usar o kubeadm no QEMU sem virtualização assistida por hardware (o que é uma má ideia porque é terrivelmente lento). Aumentar InitialDelaySeconds e TimeoutSeconds ajuda; o cluster irá eventualmente surgir.

@pipejakob , posso confirmar que (no meu bananapi) executar isso em outro terminal no ponto certo da execução do kubeadm faz com que tudo seja executado com sucesso:

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

(Eu normalmente também manualmente docker kill o contêiner apiserver antigo / reiniciado, não tenho certeza se isso é limpo automaticamente com pods estáticos)

@anguslees Ótimo! Obrigado pela confirmação.

Posso confirmar que também acabei de ter esse problema, no meu caso, em um framboesa pi 3. Mudar para 180s corrigiu isso, no entanto, acho que também encontrei o problema # 106, pois no meu caso ele simplesmente morreu com:

01 de setembro 10:47:30 raspberrypi kubelet [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] Excluindo pod de espelho "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1
1e7-ae86-b827ebdd4b52) "porque está desatualizado

Tive que HUP manualmente o processo kubelet para que ele voltasse à vida.

Também posso confirmar que tive isso e gostaria de agradecer por salvar minha sanidade. Eu tenho o Raspberry Pi 2B e fiquei preso na fase de inicialização no último mês. Depois de executar aquele one-liner uma vez que ele começou a esperar pelo avião de controle, eu o fiz seguir em frente.

Este problema ainda existe em kubeadm v1.8.0, e é pior porque kubeadm si agora tem um tempo limite de 1 minuto na maioria das ações. O tempo limite de 1 minuto parece ter sido escolhido arbitrariamente e, infelizmente, a) não dá tempo suficiente para pular e depurar / contornar o problema (por exemplo: hack do sed acima), b) tempo suficiente para o apiserver iniciar (~ Anos 90 para mim), mesmo quando initialDelaySeconds foi estendido ec) não pode ser aumentado sem hackear / reconstruir kubeadm afaics.

Timeouts quebram a lógica correta de outra forma, particularmente em sistemas complexos eventualmente consistentes - nunca devemos adicioná-los "apenas porque" :( Meu entendimento é que kubeadm deve ser um bloco de construção do qual sistemas de implantação maiores podem depender. Consequentemente, proponho ousadamente remover todos os tempos limite do próprio kubeadm (as várias fases devem continuar repetindo para sempre) e confio no processo de nível superior para adicionar um tempo limite geral se / quando apropriado nesse contexto de nível superior. No caso de uso simples / direto, significaria "tentar novamente até que o usuário desista e pressione ^ c". Tal PR seria aceitável?

@anguslees Tínhamos o comportamento de "esperar para sempre" anteriormente; mas isso era muito abaixo do ideal de um PoV UX, então agora temos tempos limite. Podemos querer aumentar alguns desses tempos limite, se quiser.

O problema é que o uso de kubeadm é duplo. Ambos temos usuários digitando kubeadm interativamente que desejam saber se algo está acontecendo ou não _e_ consumidores de nível superior.

.. Então, em que direção vamos seguir aqui? Atualmente eu uso um fork de kubeadm que tem vários tempos limite aumentados 10 vezes, e eu _gostaria_ de acreditar que posso voltar a usar os binários kubeadm padrão em algum momento.

@anguslees Tínhamos o comportamento de "esperar para sempre" anteriormente; mas isso era muito abaixo do ideal de um PoV UX, então agora temos tempos limite. Podemos querer aumentar alguns desses tempos limite, se quiser.

Que tal torná-los configuráveis? Faz sentido ter uma única opção que possua todos eles?

/ prioridade importante em breve

Faz sentido ter uma única opção que possua todos eles?

Provavelmente, ou algum tipo de "peso" para todos os tempos limite serem multiplicados ... Caso contrário, entraremos no inferno de configuração com 20 tipos diferentes de sinalizadores de tempo limite :)

Encontrando o mesmo problema ao usar a atualização do kubeadm no cluster do raspberry pi 2. A atualização falha devido a tempos limite agressivos. Alterar as configurações da detecção de atividade nos manifestos não ajuda. Alguma ideia?

Ainda proponho um padrão em que qualquer tempo limite de kubeadm é herdado do contexto de chamada (ou parte de uma estratégia de recuperação de erro mais sofisticada), em vez de espalhar tempos limites arbitrários em todos os níveis inferiores da base de código kubeadm.

Em sua forma mais simples, isso se comportaria quase exatamente como remover todos os tempos limite do kubeadm e substituí-los por um cronômetro global "executar por xx minutos, então abortar se não terminar" (já que o kubeadm não pode fazer muito no sentido de erro recuperação além de apenas esperar mais).

Para os tempos limites originais do manifesto livenessProbe, é literalmente um patch de uma linha. Infelizmente, corrigir o livenessProbe sozinho não é mais suficiente, pois a falácia "desvio do erro normal ==" se espalhou ainda mais por toda a base de código kubeadm. Mudar a consciência cultural é difícil, por isso, entretanto, tenho uma versão bifurcada do kubeadm aqui , se alguém quiser apenas instalar em um raspberry pi. (Construir com make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm )

@anguslees Você tem uma versão 1.9.4 compilada de seu kubeadm corrigido? Estou tendo problemas para compilar sua versão corrigida.

Estou surpreso que o kubeadm não tenha esse comportamento por trás de uma bandeira. Talvez um PR esteja em ordem?

/ assign @liztio

Então, corrigimos dois problemas no 1.11 que podem afetar isso.

1. Puxe a imagem etcd antes da inicialização.
2. Corrija a verificação de condição de corrida na inicialização.
   ...

Se isso está acontecendo apenas na engrenagem rasberry pi, então precisamos de alguma forma de qualificar um denominador comum mais baixo.

Qual é a plataforma de destino mais baixa que planejamos oferecer suporte?

Acho que o Raspberry Pi 2 é a (s) plataforma (s) mais baixa (s) em que você deseja executar o Kubernetes. Meus testes com QEMU não assistido por hardware são muito exóticos para serem levados em consideração.

Considerando que o Pi sofre muito de I / O lento, pré-puxar todas as imagens já vai ajudar muito, mas vamos precisar de alguns testes do mundo real para determinar os tempos limites reais.

imo rasberry pi2 é muito antigo para ser compatível - http://socialcompare.com/en/comparison/raspberrypi-models-comparison , lançado em 2015.

>= 3 parece mais razoável.

Pré-pintar as imagens não vai ajudar. O temporizador livenessProbe não inicia até que a imagem seja puxada (como indiquei acima ).

A correção é apenas estender o (s) tempo limite (s) initialDelaySeconds . Os valores de tempo limite atuais no kubeadm estão sendo usados ​​incorretamente para "impor" uma experiência UX rápida, e não a detecção de erros.

Edit: E para ficar claro, é apenas a inicialização que leva muito tempo - meu cluster de controle opera em 3xRPi2 muito bem, uma vez que eu aumento o tempo limite de intialDelaySeconds apiserver (e outros tempos limite apenas de instalação usados ​​no próprio kubeadm). Não entendo por que ainda estamos falando sobre isso: /

Eu tenho um cluster ARM64 no 1.9.3 e atualizei com sucesso para 1.9.7, mas tive o problema de tempo limite para atualizar de 1.9.7 para 1.10.2.

Eu até tentei editar e recompilar o kubeadm aumentando os tempos limites (como esses últimos commits https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) com os mesmos resultados.

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

Caso o kubeadm seja usado e o apiserver seja inicializado, podemos tentar medir os pontos na primeira inicialização. Talvez alteremos a configuração em um estágio posterior para os timeouts adaptados nas medições na primeira inicialização. Também é difícil descobrir que o apiserver é chutado pela verificação de healtz olhando os logs, podemos pelo menos obter um melhor registro no local para estarmos cientes do problema. Levei algum tempo para descobrir que o livenessprobe era o problema. Devo mencionar que sou um iniciante e seria útil pelo menos ser mencionado em algum lugar na saída de falha do kubeadm.

O RaspberryPi 3 ainda demonstra esse problema, mesmo com imagens pré-extraídas. O servidor da API leva de 2 a 3 minutos para chegar a um local onde possa exibir uma página ...

Seria ótimo ter isso configurável, porque agora, estou corrigindo o arquivo YAML em segundo plano enquanto o kubeadm é executado.

@carlosedp o que eu faço durante uma atualização é derrubar o kubelet enquanto o apiserver está inicializando. É meio hacky, mas evita que a verificação de integridade seja acionada até que o apiserver seja ativado.

Mas, honestamente, kubeadm upgrade e ARM simplesmente não funcionam tão bem juntos na minha experiência ...

@brendandburns Funcionou perfeitamente até 1.9. Implantei meu cluster 1.8 sem soluços e, em seguida, atualizei para 1.9 duas vezes. Não tenho ideia do que pode ter mudado no 1.10 para causar esses problemas.

Eu vi que o tempo limite mudou em 1,11 para 5 minutos (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). Você já tentou com 1.11?

Vou tentar esse hack depois que eu voltar das férias. Obrigado pela dica!

@brendandburns @carlosedp
sim, tente 1.11 para confirmar que o aumento do tempo limite é uma correção para você.

/ cc @ kubernetes / sig-cluster-lifecycle-bugs

Ei! Também estou encontrando esse problema.
Curiosamente, porém, eu consigo construir um cluster master do zero no meu Raspberry 3, mas sempre falho no meu 3+.
De qualquer forma, a versão que estou usando atualmente (de acordo com a documentação passo a passo em https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/) é
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

Tal como acontece com os outros, o contêiner apiserver levanta eventualmente, mas não antes de kubeadm ir embora, me deixando no limbo, pois não tenho experiência para pegar manualmente a partir daí.

Atualização rápida: em execução
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
em um terminal separado permitiu que meu cluster se levantasse.

@DJGummikuh
obrigado por testar 1.11.

Tal como acontece com os outros, o contêiner apiserver levanta eventualmente, mas não antes de kubeadm ir embora, me deixando no limbo, pois não tenho experiência para pegar manualmente a partir daí.

quanto tempo leva para o apiserver iniciar no seu caso?
parece que podemos ter que fazer isso configurável.

É difícil dizer, acho que cerca de 1 minuto, no entanto, não sei como medir isso corretamente.

Além disso, agora que meu mestre está operacional, não consigo adicionar um nó a ele com o que parece ser outro problema de tempo limite.
`[preflight] executando verificações pré-voo
[AVISO RequiredIPVSKernelModulesAvailable]: o proxy IPVS não será usado, porque os seguintes módulos do kernel obrigatórios não são carregados: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] ou nenhum kernel embutido suporte ipvs: map [ip_vs_rr: {} ip_vs_wrr: {} ip_wrr: {} nf_conntrack_ipv4: {} ip_vs: {}]
você pode resolver esse problema com os seguintes métodos:

1. Execute 'modprobe -' para carregar os módulos do kernel ausentes;
   
   
   
   1. Fornece o suporte para ipvs do kernel integrado ausente
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] Validando a versão do kernel
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] Validando a configuração do kernel
[AVISO SystemVerification]: a versão do docker é superior à versão validada mais recentemente. Versão do Docker: 18.03.1-ce. Versão máxima validada: 17.03
[descoberta] Tentando conectar ao servidor API "192.168.2.2:6443"
[descoberta] Cliente de descoberta de informações de cluster criado, solicitando informações de " https://192.168.2.2 : 6443"
[descoberta] Solicitando informações de " https://192.168.2.2 : 6443" novamente para validar o TLS em relação à chave pública fixada
[descoberta] A assinatura e o conteúdo das informações do cluster são válidos e o certificado TLS é validado em relação às raízes fixadas; usará o servidor API "192.168.2.2:6443"
[descoberta] Conexão estabelecida com sucesso com o servidor API "192.168.2.2:6443"
[kubelet] Baixando a configuração do kubelet do ConfigMap "kubelet-config-1.11" no namespace do sistema kube
[kubelet] Gravando a configuração do kubelet no arquivo "/var/lib/kubelet/config.yaml"
[kubelet] Gravando o arquivo de ambiente kubelet com sinalizadores no arquivo "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Ativando o serviço kubelet
[tlsbootstrap] Esperando que o kubelet execute o TLS Bootstrap ...
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
Infelizmente, ocorreu um erro:
expirou o tempo de espera pela condição

Este erro é provavelmente causado por:
- O kubelet não está funcionando
- O kubelet não está íntegro devido a uma configuração incorreta do nó de alguma forma (cgroups obrigatórios desativados)

Se você estiver em um sistema com base em systemd, poderá tentar solucionar o erro com os seguintes comandos:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
expirou o tempo de espera pela condição »

Durante esse tempo, nem um único contêiner docker aparece em meu nó.

[AVISO RequeridoIPVSKernelModulesAvailable]:

offtopic, estamos falando sobre isso aqui:
https://github.com/kubernetes/kubeadm/issues/975

Além disso, agora que meu mestre está operacional, não consigo adicionar um nó a ele com o que parece ser outro problema de tempo limite.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: conectar : Ligação recusada.

o kubelet não pôde ser iniciado. melhor olhar os logs do kubelet.

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

a análise de atividade deve ser configurada, mas provavelmente devemos falar sobre a melhor maneira de fazer isso na configuração do kubeadm.

Acho que esses são os valores usados, então, se você está construindo o kubeadm, tente brincar com:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
mas lembre-se de que isso aumentaria os tempos limite em todos os componentes do plano de controle.

Editar: aparentemente, sou muito estúpido para formatar comentários no Github :-(

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

por favor, lembre-se de que esses logs não mostram erros.

Sim, mas acredito que isso seja parte da questão. Não consigo encontrar uma única linha conclusiva de [ERROR] em qualquer lugar para começar. Isso é o que está me frustrando tanto :-)

De qualquer forma, obrigado por formatar essa bagunça minha :-D

Então, qual seria um bom próximo passo?

Então, qual seria um bom próximo passo?

como dito anteriormente:

a análise de atividade deve ser configurada, mas provavelmente devemos falar sobre a melhor maneira de fazer isso na configuração do kubeadm.

Acho que esses são os valores usados, então, se você está construindo o kubeadm, tente brincar com:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
mas lembre-se de que isso aumentaria os tempos limite em todos os componentes do plano de controle.

oof, eu não construo o kubeadm sozinho, estou puxando-o via apt do apt.kubernetes.io. Não tenho nada que remotamente se assemelhe a um pipeline de construção para ir em qualquer uma das minhas máquinas (nunca mexi nele ainda). Eu esperava que houvesse um arquivo semelhante para modificar ao ingressar em um cluster como houve para criá-lo, no entanto, como parece que esses valores estão embutidos no código do utils.go: - |

você pode tentar esta solução, mas é complicada:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

o problema é que isso precisa de uma mudança de configuração e não acho que possa ser incluído em uma versão 1.11.X (mas podemos tentar). também deve ser discutido primeiro.

Isso é o que eu já fiz no comentário onde eu disse a vocês que o master está ativo (isso é o que meu comando watch -n 1.0 estava fazendo). O que está acontecendo agora é que o kubeadm join não funciona e, pelo que posso ver, o kubeadm join não coloca arquivos yaml para eu corrigir em qualquer lugar: - /

você pode estar tendo outro problema. difícil de dizer.

estes são os valores usados, portanto, se você estiver construindo o kubeadm por conta própria, tente brincar com:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

Portanto, noto que o tempo limite InitialDelaySeconds aqui é _ainda_ 15s um ano depois, e não entendo por que não foi aumentado para algo que realmente representa a realidade. Este relatório de bug está servindo a algum propósito? Eu não propus inicialmente um PR apenas para alterar este número, porque senti que alguém já no círculo interno do kubeadm poderia fazer isso e fundir em alguns minutos, mas estou feliz em fazer isso se "falta de um PR" a única razão pela qual não avançamos.

Eu sinto que todos estão tentando encontrar razões para declarar o relatório de bug original inválido (talvez não devêssemos suportar rPi2, talvez devêssemos tornar o atraso inicial configurável, talvez devêssemos pré-extrair imagens ou alguma outra mudança não relacionada, talvez um a falha de tempo limite opaco rápido é uma UX melhor do que um sucesso mais lento), em vez de apenas aumentar o tempo limite de atraso inicial para refletir o atraso inicial real que nossos binários exibem claramente e, em seguida, passar para outra coisa que realmente mereça discussão.

Portanto, noto que o tempo limite InitialDelaySeconds aqui ainda é de 15s um ano depois, e não entendo por que não foi aumentado para algo que realmente representa a realidade. Este relatório de bug está servindo a algum propósito? Eu não propus inicialmente um PR apenas para alterar este número, porque senti que alguém já no círculo interno do kubeadm poderia fazer isso e fundir em alguns minutos, mas estou feliz em fazer isso se "falta de um PR" a única razão pela qual não avançamos.

não posso responder às suas perguntas, pois todo o problema é novo para mim, mas podemos tentar falar sobre isso esta semana. Observe que a equipe por trás do kubeadm é uma equipe pequena com grandes objetivos e frequentemente não há ninguém para trabalhar em uma determinada tarefa, como esta.

Eu sinto que todos estão tentando encontrar razões para declarar o relatório de bug original inválido (talvez não devêssemos suportar rPi2, talvez devêssemos tornar o atraso inicial configurável, talvez devêssemos pré-extrair imagens ou alguma outra mudança não relacionada, talvez um a falha de tempo limite opaco rápido é uma UX melhor do que um sucesso mais lento), em vez de apenas aumentar o tempo limite de atraso inicial para refletir o atraso inicial real que nossos binários exibem claramente e, em seguida, passar para outra coisa que realmente mereça discussão.

sim, as opções já foram discutidas neste tópico. é uma questão de escolher a opção certa e fazer a implementação.

Na verdade, acredito que faria sentido usar como padrão "sem tempo limite" com a opção de definir um tempo limite para todo o processo (como foi sugerido anteriormente nesta edição).

A razão é que a maioria dos casos de uso em que consigo pensar não se importam se uma etapa específica é executada em X segundos ou não, pois tudo o que importa em um sistema distribuído é a consistência eventual (enviar outro nó para o caso é mais barato do que mexer nas configurações).

Como uma solução provisória, no entanto, seria suficiente ler as configurações de tempo limite para junção do kubeadm de um arquivo de configuração, assim como o init do kubeadm faz para que nosso hack com a substituição do tempo limite em andamento funcione. É um hack, não pense diferente - mas um hack terrível ainda é melhor do que nenhuma solução alternativa.

Pessoalmente, sou contra tentar "adivinhar" tempos limites razoáveis, pois os palpites sempre podem estar errados, não serviriam realmente a um propósito neste caso (uma vez que a estratégia de enfrentamento para tempos limite decorridos é simplesmente escapar) e tornaria a reprodução de erros uma dor no bunda, já que dois sistemas idênticos podem começar a se comportar de maneira diferente por uma infinidade de razões.

@anguslees @DJGummikuh conversamos sobre isso na reunião recente da SIG.

este é um problema espinhoso, mas aqui estão algumas notas aleatórias abaixo.

notas:

• alguns de nosso pessoal têm muita experiência e estão dizendo que isso cheira a uma condição de corrida que impede a largada do apiserver. não deve demorar tanto. isso poderia ser uma coisa ARM vs GOLANG.
• Eu perguntei ao SIG API Machinery, mas não obtive resposta sobre os valores de teste de vivacidade sugeridos e se eles suspeitam de um tipo diferente de problema aqui.
• concordamos que expor uma opção de configuração ou variável de ambiente ou parâmetro de linha de comando é uma má ideia para o kubeadm . o raciocínio por trás disso é que não queremos expor parâmetros que podem ter um significado completamente arbitrário para os usuários.
• ninguém na equipe jamais viu tal problema em máquinas lentas (por exemplo, VMs lentas), o que significa que isso pode estar relacionado ao RPi e todo o argumento de que isso é devido a hardware "lento" é inválido.
• dê uma olhada nisso: https://github.com/kubernetes/kubernetes/issues/64357 o usuário não está relatando um problema de detecção de atividade. alguma ideia de por que isso?
• Alguém viu um problema em algo como https://www.scaleway.com/ , de acordo com a teoria neste tópico, isso deveria acontecer lá também?
• Como resultado, discutimos que codificar valores maiores de tempo limite / atraso não importaria muito para o kubeadm, então, se alguém quiser enviar um PR para isso, vá em frente. ( @anguslees )

dê uma olhada nisto: kubernetes / kubernetes # 64357 o usuário não está relatando um problema de sondagem de atividade. alguma ideia de por que isso?

Não, nem parece realmente reproduzível no meu hardware agora. Uma vez que o token para unir nós passou, pensei "o que diabos" e o kubeadm redefiniu meu mestre do cluster e tentei reiniciá-lo (tendo aquela solução alternativa do relógio em execução) - agora, mesmo com essa solução alternativa, não sou mais capaz de puxar um mestre no meu Raspberry Pi 3+. Eu até aumentei o tempo limite configurado de 180 para 300 segundos sem nenhuma diferença. Então eu gosto da ideia de ser uma condição de corrida.
Ainda assim, agradeço sua sugestão de obter tempos limite maiores de solicitação. Não vai doer muito e dá ao pi (que É um hardware lento, acho que todos concordamos nisso :-)) um pouco mais de espaço para respirar.

problema relacionado no ARM64 no apiserver:
https://github.com/kubernetes/kubernetes/issues/64649

Fiz mais pesquisas com meu (ainda falhando :-() Pi Cluster no fim de semana.

Reinstalei um de meus nós porque suspeitei que talvez atualizar de um Pi 2 para um Pi 3+ sem reinstalar o sistema operacional poderia causar alguns problemas. Este não é o caso, o problema é o mesmo com o novo sistema operacional.
Além disso, me esforcei para compilar kubernetes com tempos limite aumentados e testei isso. Além disso, isso realmente não produziu nenhum resultado.
Consegui levantar o master (com a solução alternativa do meu relógio para corrigir os arquivos de configuração), mas juntar o cluster com o segundo nó nunca dá certo.

Seria realmente legal ter alguma saída de log útil adicional para resolver esse problema. No entanto, não entendo o suficiente sobre como os componentes do kubernetes interagem para saber onde adicionar linhas.

Alguém está pronto para o desafio? ^^

este é realmente um problema fora do kubeadm ...

o pessoal da máquina da API não analisou meu pedido de comentários sobre o problema, então, a menos que um tíquete já esteja registrado para isso, alguém deve registrá-lo no kubernetes/kubernetes repo e marcar /sig api-machinery .

Seria realmente legal ter alguma saída de log útil adicional para resolver esse problema. No entanto, não entendo o suficiente sobre como os componentes do kubernetes interagem para saber onde adicionar linhas.

para começar, pode-se habilitar --v 4 para o kubelet no arquivo drop-in systemd, que dirá ao GLOG logger para habilitar alta verbosidade.
também se pode fazer o mesmo para os componentes do plano de controle da configuração kubeadm com isto:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

Isso resolveu o problema no meu cluster do Raspberry Pi 3: https://github.com/kubernetes/kubernetes/pull/66264

@joejulian nice Consegui consertar isso e agora meu cluster também está inicializando. FINALMENTE, após semanas de agonia! Obrigada :-)

@joejulian obrigado por investigar!
uma possível correção pode ser encontrada em https://github.com/kubernetes/kubernetes/pull/66264

fechando até novo aviso.

/perto

existe uma maneira de passar essas configurações no arquivo kubeadm init? talvez em apiServerExtraArgs ? é uma pena ficar olhando os arquivos para corrigi-los, meio difícil de automatizar.

Não há. Talvez esse seja um bom recurso a ser adicionado.

Atualizações posteriores adicionaram ainda mais itens para verificar e o tempo limite estendido que meu PR forneceu não era mais suficiente. Desisti de gerenciar o tempo limite. A solução para mim foi usar certificados ecdsa.

Além disso, os serviços do controlador, incluindo o etcd, ocupam mais memória RAM do que o Raspberry Pi, então, em vez de dobrar o número de nós para hospedar o plano de controle, atualizei para o Rock64s.

Desculpe o trocadilho, mas meu plano de controle tem sido sólido como uma rocha desde então.

Estou tentando fazer uma instalação em um Raspberry Pi 3+ e posso confirmar que a instalação realmente falhou. Usar o truque 'watch' no kube-apiserver.yaml listado acima parece funcionar de forma consistente ... mas apenas se eu alterar initialDelaySeconds para 360. O valor sugerido de 180 parece marginal em minhas máquinas.

Exatamente quando as coisas estavam ficando muito fáceis, o kubeadm agora reclama que a versão do Docker (18.09) não é compatível. Uma rápida reversão para 18,06 corrigiu o problema.

no kubeadm 1.13, estamos adicionando o sinalizador de configuração em ClusterConfig-> ApiServer que pode controlar o tempo limite do servidor API.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

sinalizador de configuração em ClusterConfig-> ApiServer que pode controlar o tempo limite do servidor api.

Pesquisando na base de código TimeoutForControlPlane , acho que o padrão é 4min e é usado apenas para o atraso usado pelo próprio kubeadm para esperar que o apiserver se torne saudável. Em particular, _não_ altera o livenessprobe apiserver usado pelo próprio kubelet. Isso está correto?

Não acho que tenha visto um contra-argumento levantado em qualquer lugar da discussão sobre esse assunto. Existe uma razão para que _não_ simplesmente aumentemos livenessProbe initialDelaySeconds e passemos para algum outro problema?

À parte: pelo que posso ver em uma leitura rápida, TimeoutForControlPlane também não leva em consideração outras causas de não falha para maior atraso de inicialização do apiserver, como congestionamento ao extrair várias imagens ou tempo limite adicional + loop de repetição iterações enquanto tudo está convergindo no tempo de instalação inicial (tempo limite + nova tentativa repetidamente é o padrão de design do k8s ... e isso acontece às vezes em um sistema carregado, o que é esperado e muito bem). Pessoalmente, acho que 4 minutos é muito tempo para usuários interativos impacientes que esperam uma falha rápida e muito curto para um processo de instalação em um sistema carregado / lento / automatizado que está preparado para esperar mais pelo sucesso esperado. Como isso foi feito, podemos usar o padrão em 5 minutos? Podemos continuar tentando até SIGINT? Por que estamos impondo um prazo final de relógio de parede artificial internamente, em vez de herdá-lo do ambiente de chamada?

Afaics TimeoutForControlPlane está apenas expondo um prazo interno fatal arbitrário como um parâmetro onde a única UX pretendida é apenas aumentar o parâmetro até que o prazo nunca seja atingido. Alternativamente, poderíamos simplesmente _não_ impor esse prazo interno fatal arbitrário em primeiro lugar ...

Esse é um ponto excelente e concordo de todo o coração.

Em particular, ele não altera o livenessprobe apiserver usado pelo próprio kubelet. Isso está correto?

sim, ainda não há planos para modificar as sondas de vivacidade do kubeadm.

este problema de rpi foi qualificado em uma reunião sig-cluster-lifecyle como "algo que não deveria acontecer", "parece quase uma condição de corrida no kubelet", "por que isso só acontece na rpi e não em outros dispositivos mais lentos". Tenho que admitir que não testei dispositivos lentos.

ou seja, houve um acordo que aumentava este valor:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
não é uma boa solução e parece uma solução alternativa para outro bug.

Como isso foi feito, podemos usar o padrão em 5 minutos?

o tempo limite foi de 30 minutos antes de ser 4 minutos, porque levou em consideração puxar imagens antes de 1.11.
se você tiver uma opinião sobre 4 vs 5 minutos, um PR bem delineado com pontos fortes sobre o assunto pode chegar em 1.14.

este problema de rpi foi qualificado em uma reunião sig-cluster-lifecyle como "algo que não deveria acontecer", "parece quase uma condição de corrida no kubelet", "por que isso só acontece na rpi e não em outros dispositivos mais lentos".

Essas são todas as razões para continuar procurando por outro bug em outro lugar também, mas nenhuma dessas são razões _não_ para aumentar initialDelaySeconds. Existe realmente uma desvantagem em aumentar initialDelaySeconds?

Para abordá-lo de outra direção, se sabemos que temos um problema em outro lugar no kubernetes com uma solução alternativa que pode ser usada no kubeadm - é função do kubeadm "segurar a linha" na pureza e produzir um resultado defeituoso conhecido? Isso parece entrar em conflito com o objetivo de ser uma ferramenta que esperamos que as pessoas realmente usem para implantações reais. Até agora, não consegui usar o kubeadm no meu cluster sem corrigi-lo para aumentar o tempo limite (apesar de relatar isso, com correções, há mais de um ano), o que me deixa triste.

(Peço desculpas por deixar um pouco da minha frustração em torno deste problema vazar em meu tom)

se você tem uma opinião sobre 4 vs 5 minutos

Suspirar. Eu estava tentando justificar _não_ tempo limite no kubeadm, mas ainda não encontrei uma maneira de expressar essa proposta de maneira convincente (veja esta e outras tentativas fracassadas neste problema, por exemplo) :(

Essas são todas as razões para continuar procurando outro bug em outro lugar também, mas nenhuma delas são razões para não aumentar initialDelaySeconds. Existe realmente uma desvantagem em aumentar initialDelaySeconds?

é uma pequena alteração, mas foi acordado não adicionar este aumento porque também se aplicará a sistemas que não exercem o problema.

Para abordá-lo de outra direção, se sabemos que temos um problema em outro lugar no kubernetes com uma solução alternativa que pode ser usada no kubeadm - é função do kubeadm "segurar a linha" na pureza e produzir um resultado defeituoso conhecido? Isso parece entrar em conflito com o objetivo de ser uma ferramenta que esperamos que as pessoas realmente usem para implantações reais.

enfrentar o usuário final é um objetivo do kubeadm, isso é verdade.
mas, novamente, é apenas um relatório para rpis e o bug real deve ser escalado para sig-api-machines (servidor api) e sig-node (kubelet) e possivelmente reproduzido fora do kubeadm.

Até agora, não consegui usar o kubeadm no meu cluster sem corrigi-lo para aumentar o tempo limite (apesar de relatar isso, com correções, há mais de um ano), o que me deixa triste.

você não precisa corrigir o kubeadm; em vez disso, você pode corrigir os arquivos de manifesto.
O kubeadm 1.13 gradua as fases do init para os comandos de nível superior - por exemplo, kubeadm init phase [phase-name]
fases existem principalmente porque os usuários desejam controle personalizado de como o nó do plano de controle é criado.

se você fizer kubeadm init --help ele mostrará em que ordem as fases são executadas.

para que você possa dividir seu comando kubeadm init nas fases apropriadas, use manifestos personalizados para os componentes do plano de controle e pule a fase control-plane . também há --skip-phases agora.

você já pode fazer isso em 1.11 e 1.12, mas é menos direto.

porque também se aplica a sistemas que não resolvem o problema.

Então ... o que há de errado nisso? Corrigimos bugs o tempo todo que só disparam em alguns sistemas. Em qualquer lugar que tenhamos limites de tempo, precisaremos ajustá-los para nosso sistema mais lento de todos os tempos, não apenas para algum subconjunto de nossos ambientes, não?

Outro ângulo sobre isso é que, como cara de operações, tenho pavor de falhas em cascata em situações de sobrecarga, especialmente com o próprio apiserver. Afaics, o tempo limite do livenessprobe só deve ser acionado quando as coisas claramente falharam , não apenas quando se desvia da ideia de "normal" de alguém. Afaics nós _devemos_ ter um liveprobe bem tranquilo configurado, mesmo em nosso hardware mais rápido. Meu pequeno rpi está apenas demonstrando essa falha de sobrecarga com mais facilidade - mas também se aplica a servidores maiores em cenários de sobrecarga / DoS maiores. Não há nenhuma vantagem em ter um pequeno initialDelaySeconds . O livenessprobe padrão do kubeadm é desnecessariamente agressivo em todas as plataformas.

Lamento continuar repetindo os mesmos pontos, mas afaics existem fortes razões práticas e teóricas para estender initialDelaySeconds, e eu simplesmente não estou entendendo o argumento oposto para mantê-lo pequeno :(

adicionar uma opção de configuração kubeadm para isso é improvável neste momento.

estou tentando explicar que isso já é possível com 3 comandos no 1.13:

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

Não quero uma opção, estou tentando dizer que o valor fixo atual (15) deve ser alterado para um valor fixo diferente (360 foi sugerido acima).

.. Mas eu não quero arrastar isso mais longe. Está claro que a decisão é ficar com o valor atual, então vou me retirar derrotado. Obrigado pela sua paciência :)

@ neolit123 aquela combinação parece ótima - muito mais fácil do que o que eu documentei - ter que esperar o plano de controle definido e rodar rapidamente o sed em outro terminal. https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

Vou testar as instruções e atualizar o guia.

@ neolit123 foi isso que consegui usando a configuração acima em um RPi3 B +

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

Em kubeadm-config.yaml - 192.168.0.26 é um LB apontando para 192.168.0.110

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

Recebo o mesmo sem o IP externo de configuração / lb.

Alex

Eu tenho pressionado as pessoas a usar o kubeadm por um tempo, até mesmo as escolas que querem executá-lo em seus clusters pi. Embora eu entenda não querer complicar a base de código, acho que provavelmente é uma coisa boa para sua base de usuários oferecer suporte à execução nesses pequenos dispositivos. ele permite que os jovens chutem os pneus do Kubernetes em hardware de piada que de outra forma não faria. A solução alternativa acima, embora válida, é muito mais difícil para esse caso de uso.

Que tal um compromisso? Em vez de torná-lo configurável, adicione uma heurística simples que diga, se não x86_64, defina o tempo limite padrão mais alto?

[kubeconfig] Gravando o arquivo kubeconfig "admin.conf"
[kubeconfig] Gravando o arquivo kubeconfig "kubelet.conf"
pânico: erro de tempo de execução: endereço de memória inválido ou desreferência de ponteiro nulo
[sinal SIGSEGV: código de violação de segmentação = 0x1 addr = 0x8 pc = 0xaa7204]

ímpar, o admin.conf é gerado por máquina e deve conter um tipo Config válido com um current-context apontando para um contexto.

o pânico vem desta linha:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

Estou vendo exatamente o mesmo erro que: point_up: acima com o seguinte:

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

O script a seguir resolve o problema para mim usando kubeadm versões 1.12, 1.13 (na maioria das vezes)

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

Eu estava na mesma situação, recebendo o mesmo erro com a abordagem sugerida por @ neolit123 .
Não consegui executar o script de @stephenmoloney , não estou muito familiarizado com o script bash, provavelmente por minha culpa.

Então, eu portei o script para python (que é instalado por padrão no Raspbian, portanto, não há necessidade de dependências extras), caso alguém esteja interessado:

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

Para executá-lo: sudo python however_you_name_the_file.py
Obrigado por me apontar a solução, @stephenmoloney e @ neolit123 !

Oi! este problema foi de muita ajuda

Eu encontrei uma maneira sofisticada de resolver isso usando kustomize

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom