Kubeadm: apiserver no se inicia porque livenessprobe es demasiado agresivo

Parece que configuramos InitialDelaySeconds y TimeoutSeconds en 15 para los módulos de plano de control actualmente, lo que coincide con lo que hace kube-up.sh también. Entiendo que el lanzamiento inicial fue lento, con todas las imágenes extraídas a la vez, pero después de que se hayan extraído todas las imágenes, ¿cuánto tiempo le toma a su servidor responder a las comprobaciones de /healthz después de ser lanzadas?

Sin duda, probablemente deberíamos modificar ambos valores para adaptarlos a las máquinas de menor potencia.

Una vez iniciado, puede responder a las comprobaciones de estado en << 15 s; en realidad, son solo todas las cosas adicionales que hace el apiserver entre exec () y estar realmente listo para servir afaics.

oh, y el tiempo de extracción de la ventana acoplable no cuenta contra InitialDelaySeconds afaics (bueno). En otros ejemplos con imágenes más grandes (ubuntu genérica) a través de mi enlace de red lento, la extracción puede tardar muchos minutos, pero el temporizador initialDelaySeconds no parece comenzar a marcar hasta que la extracción se ha completado y la ejecución de la ventana acoplable ha comenzado. (No he mirado el código relevante, solo experiencia anecdótica frecuente)

Tengo el mismo problema. Con máquinas lentas, kubeadm queda para siempre. Usando v1.7.4

@anguslees y @koalalorenzo , ¿puedes confirmar que si cambias manualmente la configuración de la sonda de actividad (editando los archivos de manifiesto en /etc/kubernetes/manifests/ ), esto soluciona tu problema? También vi recientemente un caso en Slack en el que el usuario tenía los mismos síntomas, pero probablemente tenía limitaciones de memoria, porque el problema desapareció cuando se trasladó a un tipo de host con más memoria.

Solo quiero asegurarme de que este enfoque realmente solucionará el problema antes de invertir tiempo en codificarlo. ¡Gracias!

También estoy experimentando este problema cuando intento usar kubeadm en QEMU sin virtualización asistida por hardware (lo cual es una mala idea porque es terriblemente lento). El aumento de InitialDelaySeconds y TimeoutSeconds ayuda; el clúster finalmente aparecerá.

@pipejakob Puedo confirmar que (en mi bananapi) ejecutar esto en otra terminal en el punto correcto en la ejecución de kubeadm hace que todo salga correctamente:

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

(Por lo general, también docker kill manualmente el contenedor apiserver antiguo / reiniciado, no estoy seguro de si eso se limpia automáticamente con pods estáticos)

@anguslees ¡Genial! Gracias por la confirmación.

Puedo confirmar que también acabo de tener este problema, en mi caso en una frambuesa pi 3. El cambio a 180 lo solucionó, sin embargo, creo que también encontré el problema # 106, ya que en mi caso simplemente murió con:

1 de septiembre 10:47:30 raspberrypi kubelet [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] Eliminando el módulo espejo "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1
1e7-ae86-b827ebdd4b52) "porque está desactualizado

Tuve que HUP manualmente el proceso de kubelet para que volviera a la vida.

También puedo confirmar que tenía esto y quería agradecerles por salvarme la cordura. Tengo Raspberry Pi 2B y estuve atascado en la fase de inicio durante el último mes. Después de ejecutar ese one-liner una vez que comenzó a esperar el avión de control, lo hice avanzar.

Este problema todavía existe en kubeadm v1.8.0, y es peor porque kubeadm ahora tiene un tiempo de espera de 1 minuto en la mayoría de las acciones. El tiempo de espera de 1min parece haber sido elegido arbitrariamente, y desafortunadamente a) no le da suficiente tiempo para saltar y depurar / solucionar el problema (por ejemplo: sed hack arriba), b) tiempo suficiente para que el apiserver se inicie (~ 90 para mí), incluso cuando initialDelaySeconds se ha extendido, yc) no se puede aumentar sin piratear / reconstruir kubeadm afaics.

Los tiempos de espera rompen la lógica correcta, particularmente en sistemas complejos eventualmente consistentes; nunca debemos agregarlos "solo porque" :( Tengo entendido que kubeadm está destinado a ser un componente básico del que pueden depender los sistemas de implementación más grandes. En consecuencia, propongo audazmente eliminar todos los tiempos de espera de kubeadm en sí (las diversas fases deben continuar reintentando para siempre), y confiar en el proceso de nivel superior para agregar un tiempo de espera general si / cuando sea apropiado en ese contexto de nivel superior. En el caso de uso simple / directo, este significaría "reintentar hasta que el usuario se dé por vencido y presione ^ c".

@anguslees Tuvimos el comportamiento de "esperar para siempre" antes; pero eso fue muy subóptimo desde un UX PoV, por lo que ahora tenemos tiempos de espera. Es posible que deseemos aumentar algunos de esos tiempos de espera si lo desea.

El problema es que el uso de kubeadm es doble. Ambos tenemos usuarios que escriben kubeadm de forma interactiva que quieren saber si algo está sucediendo o no _y_ consumidores de alto nivel.

.. Entonces, ¿en qué dirección vamos a ir aquí? Actualmente utilizo una bifurcación de kubeadm que tiene numerosos tiempos de espera aumentados 10 veces, y _ me gustaría_ creer que puedo volver a usar los binarios estándar kubeadm en algún momento.

@anguslees Tuvimos el comportamiento de "esperar para siempre" antes; pero eso fue muy subóptimo desde un UX PoV, por lo que ahora tenemos tiempos de espera. Es posible que deseemos aumentar algunos de esos tiempos de espera si lo desea.

¿Qué tal hacerlos configurables? ¿Tiene sentido tener una sola opción que los posea todos?

/ prioridad importante-pronto

¿Tiene sentido tener una sola opción que los posea todos?

Probablemente, o algún tipo de "peso" para que todos los tiempos de espera se multipliquen ... De lo contrario, nos meteremos en el infierno de configuración con 20 tipos diferentes de indicadores de tiempo de espera :)

Se encuentra con el mismo problema al usar la actualización de kubeadm en el clúster raspberry pi 2. La actualización falla debido a tiempos de espera agresivos. Cambiar la configuración de la sonda de vida en los manifiestos no ayuda. ¿Algunas ideas?

Sigo proponiendo un patrón en el que cualquier tiempo de espera de kubeadm se hereda del contexto de llamada (o parte de una estrategia de recuperación de errores más sofisticada), en lugar de esparcir tiempos de espera arbitrarios en los niveles inferiores de la base de código de kubeadm.

En su forma más simple, esto se comportaría casi exactamente como eliminar todos los tiempos de espera de kubeadm y reemplazarlos con un temporizador global "ejecutar durante xx minutos, luego abortar si no ha terminado" (ya que kubeadm no puede hacer mucho en cuanto a errores recuperación que no sea simplemente esperar más).

Para los tiempos de espera de livenessProbe del manifiesto original, es literalmente un parche de una sola línea. Desafortunadamente, arreglar el livenessProbe por sí solo ya no es suficiente ya que la falacia de "desviación del error normal ==" se ha extendido aún más a lo largo del código base de kubeadm. Cambiar la conciencia cultural es difícil, así que mientras tanto tengo una versión bifurcada de kubeadm aquí , si alguien quiere simplemente instalarla en una raspberry pi. (Construir con make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm )

@anguslees ¿Tiene una versión 1.9.4 compilada de su kubeadm parcheado? Tengo problemas para compilar su versión parcheada.

Me sorprende que kubeadm no tenga este comportamiento detrás de una bandera. ¿Quizás un PR está en orden?

/ asignar @liztio

Así que hemos solucionado dos problemas en 1.11 que podrían afectar esto.

1. Prepara la imagen etcd antes del inicio.
2. Corrija la verificación de la condición de carrera al inicio.
   ...

Si esto solo ocurre en Rasberry Pi - Gear, entonces necesitamos alguna forma de calificar un mínimo común denominador.

¿Cuál es la plataforma de destino más baja que planeamos admitir?

Creo que Raspberry Pi 2 es la plataforma más baja en la que le gustaría ejecutar Kubernetes. Mis pruebas con QEMU no asistidas por hardware son demasiado exóticas para ser tomadas en cuenta.

Teniendo en cuenta que el Pi sufre mucho de E / S lentas, la extracción previa de todas las imágenes ya ayudará mucho, pero necesitaremos algunas pruebas del mundo real para determinar los tiempos de espera reales.

imo rasberry pi2 es demasiado antiguo para admitirlo: http://socialcompare.com/en/comparison/raspberrypi-models-comparison , salió en 2015.

>= 3 parece más razonable en mi opinión.

Preparar imágenes no ayudará. El temporizador livenessProbe no se inicia hasta que se extrae la imagen (como señalé anteriormente ).

La solución es simplemente extender el tiempo de espera de initialDelaySeconds . Los valores de tiempo de espera actuales en kubeadm se están utilizando incorrectamente para "imponer" una experiencia de UX rápida y no para la detección de errores.

Editar: Y para ser claros, es solo el inicio lo que lleva años: mi grupo de control funciona bien en 3xRPi2, una vez que aumento el tiempo de espera de apiserver intialDelaySeconds (y otros tiempos de espera de solo instalación utilizados dentro de kubeadm). No entiendo por qué seguimos hablando de esto: /

Tengo un clúster ARM64 en 1.9.3 y actualicé exitosamente a 1.9.7, pero tuve el problema de tiempo de espera para actualizar de 1.9.7 a 1.10.2.

Incluso intenté editar y recompilar kubeadm aumentando los tiempos de espera (como estas últimas confirmaciones https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) con los mismos 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]

En caso de que se utilice kubeadm y se inicie el apiserver, podemos intentar medir los puntos en el primer inicio. Quizás modifiquemos la configuración en una etapa posterior para los tiempos de espera adaptados a las mediciones en la primera inicialización. También es difícil saber que el apiserver es pateado por la verificación de healtz mirando los registros, al menos podemos obtener un mejor registro en el lugar para estar al tanto del problema. Me tomó bastante tiempo descubrir que el problema era el livenessprobe. Debo mencionar que soy un principiante, y al menos sería útil que se mencionara en algún lugar de la salida de falla de kubeadm.

RaspberryPi 3 todavía demuestra este problema, incluso con imágenes extraídas previamente. El servidor de API tarda de 2 a 3 minutos en llegar a un lugar donde puede servir una página ...

Sería genial tener esto configurable, porque en este momento, estoy parcheando el archivo YAML en segundo plano mientras se ejecuta kubeadm.

@carlosedp lo que hago durante una actualización es eliminar el kubelet mientras se inicia el apiserver. Es un poco hacky, pero evita que se active la verificación de estado hasta que el apiserver esté activo.

Pero honestamente kubeadm upgrade y ARM simplemente no funcionan tan bien juntos en mi experiencia ...

@brendandburns Funcionó perfectamente hasta el 1.9. Implementé mi clúster 1.8 con él sin contratiempos, luego actualicé a 1.9 dos veces. No tengo idea de lo que podría haber cambiado en 1.10 para causar este problema.

Vi que el tiempo de espera cambió en 1,11 a 5 minutos (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). ¿Has probado con 1.11?

Probaré este truco después de que regrese de vacaciones. ¡Gracias por el consejo!

@brendandburns @carlosedp
sí, intente 1.11 para confirmar que el aumento del tiempo de espera es una solución para usted.

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

¡Oye! También me encuentro con este problema.
Curiosamente, sin embargo, me las arreglé para construir un clúster maestro desde cero en mi Raspberry 3, pero no lo logro consistentemente en mi 3+.
De todos modos, la versión que estoy usando actualmente (según la documentación paso a paso en https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/) es
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"}

Al igual que con los demás, el contenedor apiserver se levanta eventualmente, pero no antes de que kubeadm se salga, dejándome en el limbo ya que no tengo experiencia para recogerlo manualmente desde allí.

Actualización rápida: corriendo
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
en una terminal separada permitió que mi clúster se levantara.

@DJGummikuh
gracias por probar 1.11.

Al igual que con los demás, el contenedor apiserver se levanta eventualmente, pero no antes de que kubeadm se salga, dejándome en el limbo ya que no tengo experiencia para recogerlo manualmente desde allí.

¿Cuánto tiempo tarda el apiserver en iniciarse en su caso?
parece que tendremos que hacer esto configurable.

Es difícil de decir, supongo que aproximadamente 1 minuto, sin embargo, no sé cómo medirlo correctamente.

Además, ahora que mi maestro está operativo, no le agrego un nodo con lo que parece ser otro problema de tiempo de espera.
`[Preflight] ejecutando comprobaciones previas al vuelo
[ADVERTENCIA RequiredIPVSKernelModulesAvailable]: el proxy IPVS no se utilizará, porque los siguientes módulos de kernel requeridos no están cargados: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] o no hay soporte integrado de ipvs de kernel: map [ip_vs_rr: {} ipsh_vs_wrvs_: {} nf_conntrack_ipv4: {} ip_vs: {}]
puede resolver este problema con los siguientes métodos:

1. Ejecute 'modprobe -' para cargar los módulos del kernel que faltan;
   
   
   
   1. Proporcionar el soporte de ipvs integrado del kernel que falta
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] Validando la versión del kernel
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] Validando la configuración del kernel
[ADVERTENCIA SystemVerification]: la versión de Docker es mayor que la versión validada más recientemente. Versión de Docker: 18.03.1-ce. Versión máxima validada: 17.03
[descubrimiento] Intentando conectarse al servidor API "192.168.2.2:6443"
[descubrimiento] Se creó el cliente de descubrimiento de información de clúster, solicitando información de " https://192.168.2.2 : 6443"
[descubrimiento] Solicitando información de " https://192.168.2.2 : 6443" nuevamente para validar TLS con la clave pública fijada
[descubrimiento] La firma y el contenido de la información del clúster son válidos y el certificado TLS se valida con las raíces ancladas, utilizará el servidor API "192.168.2.2:6443"
[descubrimiento] Conexión establecida con éxito con el servidor API "192.168.2.2:6443"
[kubelet] Descargando la configuración para kubelet desde el ConfigMap "kubelet-config-1.11" en el espacio de nombres del sistema kube
[kubelet] Escribiendo la configuración de kubelet en el archivo "/var/lib/kubelet/config.yaml"
[kubelet] Escribiendo un archivo de entorno kubelet con banderas en el archivo "/var/lib/kubelet/kubeadm-flags.env"
[Preflight] Activación del servicio kubelet
[tlsbootstrap] Esperando que kubelet realice el TLS Bootstrap ...
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
Desafortunadamente, ha ocurrido un error:
Se agotó el tiempo de espera para la condición.

Es probable que este error se deba a:
- El kubelet no se está ejecutando
- El kubelet no está en buen estado debido a una mala configuración del nodo de alguna manera (se requieren cgroups deshabilitados)

Si está en un sistema alimentado por systemd, puede intentar solucionar el error con los siguientes comandos:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
agotó el tiempo de espera para la condición`

Durante este tiempo, no aparece ni un solo contenedor acoplable en mi nodo.

[ADVERTENCIA RequiredIPVSKernelModulesAvailable]:

offtopic, estamos hablando de esto aquí:
https://github.com/kubernetes/kubeadm/issues/975

Además, ahora que mi maestro está operativo, no le agrego un nodo con lo que parece ser otro problema de tiempo de espera.
[kubelet-check] La llamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falló con el error: Obtenga http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : conexión denegada.

el kubelet no se pudo iniciar. mejor mira los registros de Kubelet.

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

la sonda de vida debería ser configurable, pero probablemente deberíamos hablar sobre la mejor forma de hacerlo en la configuración de kubeadm.

Creo que estos son los valores utilizados, así que si está construyendo kubeadm usted mismo, intente jugar con:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
pero tenga en cuenta que esto aumentaría los tiempos de espera en todos los componentes del plano de control.

Editar: aparentemente soy demasiado estúpido para formatear correctamente los comentarios en 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, tenga en cuenta que estos registros no muestran errores.

Sí, pero creo que es parte del problema. Para empezar, no puedo encontrar una sola línea concluyente de [ERROR] en ninguna parte. Eso es lo que me frustra tanto :-)

De todos modos, gracias por formatear ese lío mío :-D

Entonces, ¿cuál sería un buen próximo paso?

Entonces, ¿cuál sería un buen próximo paso?

Como se mencionó previamente:

la sonda de vida debería ser configurable, pero probablemente deberíamos hablar sobre la mejor forma de hacerlo en la configuración de kubeadm.

Creo que estos son los valores utilizados, así que si está construyendo kubeadm usted mismo, intente jugar con:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
pero tenga en cuenta que esto aumentaría los tiempos de espera en todos los componentes del plano de control.

oof No construyo kubeadm solo, lo estoy extrayendo a través de apt desde apt.kubernetes.io. No tengo nada que se parezca remotamente a una canalización de compilación para ir a ninguna de mis máquinas (nunca lo modifiqué todavía). Esperaba que hubiera un archivo similar para modificar al unirse a un clúster como lo hubo para crearlo, sin embargo, como parece que estos valores están codificados en utils.go: - |

puedes probar esta solución, pero es complicado:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

el problema es que esto necesita un cambio de configuración y no creo que pueda incluirse en una versión 1.11.X (pero podemos intentarlo). también debe discutirse primero.

Eso es lo que ya hice en el comentario donde les dije que el maestro está activo (eso es lo que estaba haciendo mi comando watch -n 1.0). Lo que está sucediendo ahora es que kubeadm join no funciona y, por lo que puedo ver, kubeadm join no coloca archivos yaml para que pueda parchearlos en cualquier lugar: - /

podría estar experimentando otro problema. Difícil de decir.

estos son los valores utilizados, así que si está construyendo kubeadm usted mismo, intente jugar con:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

Así que observo que el tiempo de espera de InitialDelaySeconds aquí es _todavía_ 15 s un año después, y no entiendo por qué no se ha aumentado a algo que realmente represente la realidad. ¿Este informe de error tiene algún propósito? Inicialmente no propuse un PR para cambiar este número porque sentí que alguien que ya estaba en el círculo interno de kubeadm podría hacerlo y fusionarse en unos minutos, pero estoy feliz de hacerlo si la "falta de un PR" es la única razón por la que no hemos avanzado.

Siento que todos están tratando de encontrar razones para declarar que el informe de error original no es válido (tal vez no deberíamos admitir rPi2, tal vez deberíamos configurar el retardo inicial, tal vez deberíamos extraer previamente las imágenes o algún otro cambio no relacionado, tal vez un La falla de tiempo de espera opaco rápido es una mejor experiencia de usuario que un éxito más lento), en lugar de simplemente aumentar el tiempo de espera initialDelay para reflejar el InitialDelay real que muestran claramente nuestros binarios y luego pasar a otra cosa que realmente merece discusión.

Así que observo que el tiempo de espera de InitialDelaySeconds aquí todavía es de 15 segundos un año después, y no entiendo por qué no se ha aumentado a algo que realmente represente la realidad. ¿Este informe de error tiene algún propósito? Inicialmente no propuse un PR para cambiar este número porque sentí que alguien que ya estaba en el círculo interno de kubeadm podría hacerlo y fusionarse en unos minutos, pero estoy feliz de hacerlo si la "falta de un PR" es la única razón por la que no hemos avanzado.

No puedo responder a sus preguntas ya que todo el tema es nuevo para mí, pero podemos intentar hablar de ello esta semana. tenga en cuenta que el equipo detrás de kubeadm es un equipo pequeño con grandes objetivos y, a menudo, no hay nadie para trabajar en una determinada tarea, como esta.

Siento que todos están tratando de encontrar razones para declarar que el informe de error original no es válido (tal vez no deberíamos admitir rPi2, tal vez deberíamos configurar el retardo inicial, tal vez deberíamos extraer previamente las imágenes o algún otro cambio no relacionado, tal vez un La falla de tiempo de espera opaco rápido es una mejor experiencia de usuario que un éxito más lento), en lugar de simplemente aumentar el tiempo de espera initialDelay para reflejar el InitialDelay real que muestran claramente nuestros binarios y luego pasar a otra cosa que realmente merece discusión.

sí, las opciones ya se han discutido en este hilo. es cuestión de elegir la opción correcta y realizar la implementación.

De hecho, creo que tendría sentido establecer de forma predeterminada "sin tiempo de espera" con la opción de establecer un tiempo de espera para todo el proceso (como se sugirió anteriormente en este número).

La razón es que a la mayoría de los casos de uso en los que puedo pensar en realidad no les importa si un paso específico se ejecuta en X Seconds o no, ya que todo lo que se importa en un sistema distribuido es la consistencia eventual (poner en cola otro nodo por si acaso es más barato que jugar con la configuración).

Sin embargo, como solución provisional, sería suficiente leer la configuración de tiempo de espera para kubeadm join desde un archivo de configuración tal como lo hace kubeadm init para que nuestro truco con el reemplazo del tiempo de espera durante el vuelo funcione. Es un truco, no lo pienses diferente, pero un truco terrible es mejor que no tener ninguna solución.

Personalmente, estoy en contra de intentar "adivinar" los tiempos de espera razonables, ya que las conjeturas siempre pueden ser incorrectas, en realidad no servirían para nada en este caso (ya que la estrategia de afrontamiento para los tiempos de espera transcurridos es simplemente rescatar) y haría que la reproducción de errores fuera un problema ass ya que dos sistemas idénticos podrían comenzar a comportarse de manera diferente por una miríada de razones.

@anguslees @DJGummikuh tuvimos una charla sobre eso en la reciente reunión de SIG.

este es un problema espinoso, pero aquí hay algunas notas aleatorias a continuación.

notas:

• algunos de nuestra gente tienen mucha experiencia y dicen que esto huele a condición de carrera que paraliza la salida. no debería llevar tanto tiempo. esto podría ser una cosa ARM vs GOLANG.
• Le pregunté a SIG API Machinery pero no obtuve respuesta sobre los valores sugeridos de la sonda de vida y si sospechan un tipo diferente de problema aquí.
• hemos acordado que exponer una opción de configuración o una variable de entorno o un parámetro de línea de comandos es una mala idea para kubeadm . El razonamiento detrás de esto es que no queremos exponer parámetros que pueden tener un significado completamente arbitrario para los usuarios.
• nadie en el equipo ha visto nunca un problema de este tipo en máquinas lentas (por ejemplo, VM lentas), lo que significa que esto podría estar relacionado con RPi y todo el argumento de que se debe a hardware "lento" no es válido.
• eche un vistazo a esto: https://github.com/kubernetes/kubernetes/issues/64357 el usuario no está informando un problema de sonda de vida en absoluto. ¿Alguna idea de por qué es eso?
• ¿Alguien ha visto un problema en algo como https://www.scaleway.com/ , según la teoría de este hilo, también debería suceder allí?
• Como conclusión, hemos discutido que codificar valores de tiempo de espera / retardo más grandes no importaría demasiado para kubeadm, así que si alguien quiere enviar un PR para eso, adelante. ( @anguslees )

eche un vistazo a esto: kubernetes / kubernetes # 64357 el usuario no informa un problema de sondeo de vida en absoluto. ¿Alguna idea de por qué es eso?

No, ahora ni siquiera parece realmente reproducible en mi hardware. Dado que el token para unirse a los nodos se agotó, pensé "qué diablos" y kubeadm reinició mi clúster maestro e intenté reiniciarlo (con esa solución de reloj ejecutándose); ahora, incluso con esa solución, ya no puedo levantar un maestro en mi Raspberry Pi 3+. Incluso aumenté el tiempo de espera configurado de 180 a 300 segundos sin ninguna diferencia. Así que me gusta la idea de que esto sea una condición de carrera.
Aún así, agradezco su sugerencia de solicitar tiempos de espera más altos. No duele mucho y le da al pi (que ES un hardware lento, creo que todos podemos estar de acuerdo en eso :-)) un poco más de espacio para respirar.

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

Investigué un poco más con mi (aún fallando :-() Pi Cluster durante el fin de semana.

Reinstalé uno de mis nodos porque sospechaba que tal vez actualizar de un Pi 2 a un Pi 3+ sin reinstalar el sistema operativo podría causar algunos problemas. Este no es el caso, el problema es el mismo con el nuevo sistema operativo.
Además, me esforcé por compilar kubernetes con los tiempos de espera aumentados y probé con eso. Además, esto realmente no produjo ningún resultado.
Pude levantar el maestro (con mi solución de reloj para parchear los archivos de configuración) pero unirme al clúster con el segundo nodo simplemente nunca funciona.

Sería realmente bueno tener una salida de registro útil adicional para resolver este problema. Sin embargo, no entiendo lo suficiente de cómo interactúan los componentes de kubernetes para saber dónde agregar líneas.

¿Alguien está preparado para el desafío? ^^

esto es realmente un problema fuera de kubeadm ...

La gente de la maquinaria de la API no miró mi solicitud de comentarios sobre el problema, por lo que, a menos que ya se haya registrado un ticket para esto, alguien debería registrar uno en el repositorio kubernetes/kubernetes y etiquetar /sig api-machinery .

Sería realmente bueno tener una salida de registro útil adicional para resolver este problema. Sin embargo, no entiendo lo suficiente de cómo interactúan los componentes de kubernetes para saber dónde agregar líneas.

para empezar, se puede habilitar --v 4 para el kubelet en el archivo desplegable de systemd, que le indicará al registrador GLOG que habilite la alta verbosidad.
también se puede hacer lo mismo para los componentes del plano de control desde la configuración de kubeadm con esto:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

Esto resolvió el problema en mi clúster Raspberry Pi 3: https://github.com/kubernetes/kubernetes/pull/66264

@joejulian nice Me las arreglé para parchear eso y ahora también mi clúster se está disparando. ¡POR FIN, después de semanas de agonía! Gracias :-)

@joejulian ¡ gracias por investigar!
se puede encontrar una solución potencial en https://github.com/kubernetes/kubernetes/pull/66264

cierre hasta nuevo aviso.

/cerca

¿Hay alguna manera de pasar tales configuraciones en el archivo init de kubeadm? tal vez en apiServerExtraArgs ? es un fastidio estar mirando archivos para parchearlos, un poco difícil de automatizar.

No hay. Quizás esa sería una buena característica para agregar.

Las actualizaciones posteriores han agregado aún más cosas para verificar y el tiempo de espera extendido que proporcionó mi PR ya no fue suficiente. Dejé de administrar el tiempo de espera. La solución para mí fue utilizar certificados ecdsa.

Además, los servicios del controlador, incluido etcd, ocupan más memoria RAM, ahora, de la que tiene una Raspberry Pi, por lo que en lugar de duplicar la cantidad de nodos para alojar el plano de control, me actualicé a Rock64s.

Disculpe el juego de palabras, pero mi plano de control ha sido sólido como una roca desde entonces.

Acabo de intentar realizar una instalación en una Raspberry Pi 3+ y puedo confirmar que la instalación realmente falla. El uso del truco 'watch' en kube-apiserver.yaml mencionado anteriormente parece funcionar de manera consistente ... pero solo si cambio initialDelaySeconds a 360. El valor sugerido de 180 parece marginal en mis máquinas.

Justo cuando las cosas se estaban poniendo demasiado fáciles, kubeadm ahora se queja de que la versión de Docker (18.09) no es compatible. Una rápida reversión a 18.06 solucionó el problema.

en kubeadm 1.13 estamos agregando un indicador de configuración en ClusterConfig-> ApiServer que puede controlar el tiempo de espera del servidor api.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

bandera de configuración en ClusterConfig-> ApiServer que puede controlar el tiempo de espera del servidor api.

Buscando en la base de código TimeoutForControlPlane , creo que este valor predeterminado es 4min, y solo se usa para el retraso que usa kubeadm para esperar a que el apiserver se vuelva saludable. En particular, _no_ altera el apiserver livenessprobe utilizado por el propio kubelet. ¿Es eso correcto?

No creo que haya visto un contraargumento planteado en ninguna parte de la discusión sobre este tema. ¿Hay alguna razón por la que _no_ simplemente aumentamos livenessProbe initialDelaySeconds y pasamos a algún otro problema?

Aparte: por lo que puedo ver en una lectura rápida, TimeoutForControlPlane tampoco tiene en cuenta otras causas que no son fallas para un mayor retraso en el inicio de un servidor, como la congestión al extraer varias imágenes, o tiempo de espera adicional + bucle de reintento iteraciones mientras todo está convergiendo en el momento de la instalación inicial (el tiempo de espera + reintentar repetidamente es el patrón de diseño de k8s ... y esto sucede a veces en un sistema cargado, lo cual es esperado y está bien). Personalmente, siento que 4 minutos es demasiado largo para los usuarios interactivos impacientes que esperan una falla rápida y demasiado corto para un proceso de instalación en un sistema cargado / lento / automatizado que está preparado para esperar más tiempo para el éxito esperado. ¿Cómo se llegó a esto? ¿Podemos predeterminar 5 minutos? ¿Podemos seguir intentándolo hasta SIGINT? ¿Por qué estamos imponiendo internamente una fecha límite de reloj de pared artificial en lugar de heredarla del entorno de llamadas?

Afaics TimeoutForControlPlane solo está exponiendo una fecha límite interna fatal arbitraria como un parámetro donde la única UX intencionada es simplemente aumentar el parámetro hasta que nunca se alcance la fecha límite. Alternativamente, podríamos simplemente _no_ imponer esa fecha límite interna fatal arbitraria en primer lugar ...

Ese es un punto excelente y estoy totalmente de acuerdo.

En particular, no altera el apiserver livenessprobe utilizado por el propio kubelet. ¿Es eso correcto?

sí, todavía no hay planes para modificar las sondas de vida de kubeadm.

este problema de rpi se calificó en una reunión sig-cluster-lifecyle como "algo que no debería suceder", "parece casi una condición de carrera en el kubelet", "por qué solo ocurre en rpi y no en otros dispositivos más lentos". Debo admitir que yo mismo no he probado dispositivos lentos.

es decir, hubo un acuerdo para aumentar este valor:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
no es una buena solución y parece una solución para otro error.

¿Cómo se llegó a esto? ¿Podemos predeterminar 5 minutos?

el tiempo de espera fue 30 minutos antes de 4 minutos, porque tomó en consideración las imágenes de extracción antes de 1.11.
Si tiene una opinión sobre 4 vs 5 minutos, un PR bien delineado con puntos fuertes sobre el tema podría hacerlo en 1.14.

este problema de rpi se calificó en una reunión sig-cluster-lifecyle como "algo que no debería suceder", "parece casi una condición de carrera en el kubelet", "por qué solo ocurre en rpi y no en otros dispositivos más lentos".

Esas son todas razones para continuar buscando otro error en otro lugar también, pero ninguna de esas son razones _no_ para aumentar initialDelaySeconds. ¿Existe realmente una desventaja en aumentar initialDelaySeconds?

Para abordarlo desde otra dirección, si sabemos que tenemos un problema en otro lugar en kubernetes con una solución que se puede usar en kubeadm, ¿es el papel de kubeadm "mantener la línea" en la pureza y producir un resultado roto conocido? Eso parece entrar en conflicto con el objetivo de ser una herramienta que esperamos que las personas utilicen realmente para implementaciones reales. Hasta ahora no he podido usar kubeadm en mi clúster sin parchearlo para aumentar los tiempos de espera (a pesar de informarlo, con parches, hace más de un año), lo que me entristece.

(Disculpas por dejar que parte de mi frustración por este tema se filtre en mi tono)

si tiene una opinión sobre 4 vs 5 minutos

Suspiro. Estaba tratando de defender el caso de _no_ timeout en kubeadm, pero todavía tengo que encontrar una manera de expresar esa propuesta de manera convincente (vea este y otros intentos fallidos en este número, por ejemplo) :(

Esas son todas razones para seguir buscando otro error en otro lugar también, pero ninguna de esas son razones para no aumentar initialDelaySeconds. ¿Existe realmente una desventaja en aumentar initialDelaySeconds?

es un pequeño cambio, pero se acordó no agregar este aumento porque también se aplicará a los sistemas que no resuelven el problema.

Para abordarlo desde otra dirección, si sabemos que tenemos un problema en otro lugar en kubernetes con una solución que se puede usar en kubeadm, ¿es el papel de kubeadm "mantener la línea" en la pureza y producir un resultado roto conocido? Eso parece entrar en conflicto con el objetivo de ser una herramienta que esperamos que las personas utilicen realmente para implementaciones reales.

enfrentarse al usuario final es un objetivo de kubeadm, eso es cierto.
pero nuevamente, es solo un informe para rpis y el error real debe escalarse a sig-api-machinery (servidor api) y sig-node (kubelet) y posiblemente reproducirse fuera de kubeadm.

Hasta ahora no he podido usar kubeadm en mi clúster sin parchearlo para aumentar los tiempos de espera (a pesar de informarlo, con parches, hace más de un año), lo que me entristece.

no tiene que parchear kubeadm, puede parchear archivos de manifiesto en su lugar.
kubeadm 1.13 gradúa las fases de inicio a comandos de nivel superior, por ejemplo, kubeadm init phase [phase-name]
Las fases están ahí principalmente porque los usuarios quieren un control personalizado de cómo se crea el nodo del plano de control.

si lo hace kubeadm init --help le mostrará en qué orden se ejecutan las fases.

para que pueda dividir su comando kubeadm init en las fases apropiadas, use manifiestos personalizados para los componentes del plano de control y omita la fase control-plane . también hay --skip-phases ahora.

ya puede hacer eso en 1.11 y 1.12, pero es menos sencillo.

porque también se aplicará a sistemas que no resuelvan el problema.

Entonces ... ¿qué hay de malo en eso? Arreglamos errores todo el tiempo que solo se activan en algunos sistemas. Donde sea que tengamos tiempos de espera, tendremos que ajustarlos para nuestro sistema más lento, no solo para un subconjunto de nuestros entornos, ¿no?

Otro ángulo sobre esto es que, como técnico de operaciones, me aterrorizan las fallas en cascada en situaciones de sobrecarga, particularmente con el apiserver en sí. Afaics, el tiempo de espera de livenessprobe solo debería activarse No hay ninguna ventaja en tener un pequeño InitialDelaySeconds . El livenessprobe predeterminado de kubeadm es innecesariamente agresivo en todas las plataformas.

Lo siento, sigo repitiendo los mismos puntos, pero afaics hay fuertes razones prácticas y teóricas para extender initialDelaySeconds, y simplemente no entiendo el argumento opuesto para mantenerlo pequeño :(

agregar una opción de configuración de kubeadm para esto es poco probable en este momento.

Estoy tratando de explicar que esto ya es factible con 3 comandos en 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

No quiero una opción, estoy tratando de decir que el valor fijo actual (15) debe cambiarse a un valor fijo diferente (360 se sugirió anteriormente).

.. Pero no quiero alargar más esto. Está claro que la decisión es seguir con el valor actual, así que me retiraré derrotado. Gracias por su paciencia :)

@ neolit123 esa combinación se ve muy bien, mucho más fácil de lo que había documentado, tener que esperar a que se establezca el plano de control y luego ejecutar sed rápidamente en otra terminal. https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

Probaré las instrucciones y buscaré actualizar la guía.

@ neolit123 esto es lo que obtuve usando la configuración anterior en un 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"}

En kubeadm-config.yaml - 192.168.0.26 es un LB que apunta a 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"

Consigo lo mismo incluso sin la configuración externa / lb IP.

Alex

He estado presionando a la gente para que use kubeadm durante un tiempo, incluso a las escuelas que desean ejecutarlo en sus clústeres pi. Si bien entiendo que no quiero complicar la base del código, creo que probablemente sea bueno que su base de usuarios admita la ejecución en estos pequeños dispositivos. permite a los jóvenes patear los neumáticos de Kubernetes en hardware barato que de otra manera no podría hacerlo. La solución anterior, aunque válida, es mucho más difícil para este caso de uso.

¿Qué tal un compromiso? En lugar de hacerlo configurable, agregue una heurística simple que diga, si no es x86_64, ¿establecer el tiempo de espera predeterminado más alto?

[kubeconfig] Escribiendo el archivo kubeconfig "admin.conf"
[kubeconfig] Escribiendo archivo "kubelet.conf" kubeconfig
pánico: error de tiempo de ejecución: dirección de memoria no válida o desreferencia del puntero nulo
[señal SIGSEGV: código de infracción de segmentación = 0x1 addr = 0x8 pc = 0xaa7204]

impar, el admin.conf es generado por la máquina y debe contener un tipo Config válido con un archivo current-context apuntando a un contexto.

el pánico viene de esta línea:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

Veo exactamente el mismo error que: point_up: arriba con lo siguiente:

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

El siguiente script me resuelve el problema usando las versiones 1.12, 1.13 de kubeadm (la mayoría de las veces)

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}

Estaba en la misma situación, obteniendo el mismo error con el enfoque sugerido por @ neolit123 .
No pude ejecutar el script de @stephenmoloney , no estoy muy familiarizado con los scripts de bash, probablemente mi culpa.

Así que porté el script a Python (que está instalado de forma predeterminada en Raspbian, por lo que no es necesario que haya dependencias adicionales), en caso de que alguien esté interesado:

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 ejecutarlo: sudo python however_you_name_the_file.py
¡Gracias por indicarme la solución, @stephenmoloney y @ neolit123 !

¡Hola! este problema fue de mucha ayuda

Encontré una forma elegante de resolver esto 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