Kubeadm: Cambiar la dirección IP maestra

Esta no es una limitación de kubeadm, sino solo una práctica de seguridad general.
El certificado está firmado para {your-old-IP-here} y la comunicación segura no puede ocurrir con {your-new-ip-here}

Sin embargo, puede agregar más direcciones IP en el certificado de antemano ...

Gracias por su respuesta.

Como las direcciones IP son asignadas por el proveedor de la nube, generar un certificado de antemano solo funcionaría si pudiera configurarlo como comodín. (Lo siento, no sé nada sobre certificados).

Pasé por alto que kubeadm reset realmente existe, ya que no se menciona en la guía de referencia . Reset e init funcionaron lo suficientemente bien para mí, y supongo que evitaré apagar la máquina maestra; asumo que mi problema es raro y está lejos de cualquier caso de uso de producción. Aún así, me pregunto si hay una mejor manera. Supongo que podría imitar los pasos de kubeadm reset , pero ¿conservar la carpeta de datos etcd para preservar la configuración de mi clúster?

De cualquier manera, ¡gracias por todo el trabajo realizado en kubeadm! Es mágico ver aparecer el clúster en minutos: he estado usando Kubernetes desde 0.14, en producción desde 1.0.

@analytik tengo exactamente el mismo problema que el tuyo. Mi red corporativa bloquea gcr.io. Entonces estoy usando un dongle para la instalación. Sin embargo, la IP del proveedor sigue cambiando dinámicamente y no está bajo mi control. Así que incluso yo estoy buscando una solución. Incluso si mantengo mi dongle enchufado, a veces debido a que la red restablece los cambios de IP. ¿Tienes alguna solución para esto? ¿Cómo estás manejando esto?
@luxas, ¿ podría sugerirme cómo puedo proceder? Soy un novato en K8S. Completamente perdido con esta configuración. ¿Podría decirme cómo puedo solucionar este problema de IP dinámica?

¿Cómo lidian con la IP maestra modificada?

¿Hay alguna actualización sobre este tema?

El mismo problema aqui. ¿Alguna documentación para proceder con una modificación de la IP maestra sin restablecer todo el clúster, por favor?

Pude lograr esto mediante:

• reemplazar la dirección IP en todos los archivos de configuración en / etc / kubernetes
• haciendo una copia de seguridad de / etc / kubernetes / pki
• identificando certificados en / etc / kubernetes / pki que tienen la antigua dirección IP como un nombre alternativo [1]
• eliminando tanto el certificado como la clave para cada uno de ellos (para mí fue solo apiserver y etcd / peer)
• regenerando los certificados usando kubeadm alpha phase certs [2]
• identificando configmap en el espacio kube-system nombres
• editar manualmente esos configmaps
• reiniciando kubelet y docker (para forzar la recreación de todos los contenedores)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Vaya, no estaba al tanto de estos comandos. Excelentes informaciones, eso hizo el truco. Gracias !

¿Hay alguna manera de encontrar los mapas de configuración manualmente y cambiarlos?

Espero que kubeadm pueda cubrir este proceso en una versión futura.

@patricklucas en serio, gracias por ese artículo. Me salvó la vida.

Para aquellos que buscan aún más claridad, estas fueron mis experiencias:

1. reemplace la dirección IP en todos los archivos de configuración en /etc/kubernetes
bash oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. copia de seguridad /etc/kubernetes/pki
bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. identificando certificados en /etc/kubernetes/pki que tienen la antigua dirección IP como un nombre alternativo (esto podría limpiarse)
   bash cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. identifique configmap en el espacio kube-system nombres

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. cambie la dirección IP (a través de cli o gui para su distribución)

6. elimine tanto el certificado como la clave para cada uno identificado por grep en el paso anterior, regenere esos certificados

   NOTA: antes de recrear los certificados a través de kubeadm admin phase certs ... , deberá aplicar la nueva dirección IP

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. reiniciar kubelet y docker
   bash sudo systemctl restart kubelet sudo systemctl restart docker
8. copiar la nueva configuración
   bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

Otra cosa a tener en cuenta, fue posible cambiar los certificados en modo fuera de línea especificando la versión k8s en un archivo de configuración: https://github.com/kubernetes/kubernetes/issues/54188#issuecomment -418880831

@weisjohn ¿Podría también actualizar su comentario señalando que:

kubectl edit cm -nkube-public cluster-info

también es necesario para kubeadm?

De lo contrario, mis comandos kubeadm join siguen fallando al usar la IP de apiserver antigua / incorrecta a la mitad del proceso.

¡Gracias!

He aplicado todos los pasos de @weisjohn (https://github.com/kubernetes/kubeadm/issues/338#issuecomment-418879755) y @michaelfig (https://github.com/kubernetes/kubeadm/issues/ 338 # issuecomment-428340099) para reemplazar la dirección en todas partes.

Esto se usa para permitir que kubernetes use la dirección de VPC recién creada en eth1, en lugar de la IP pública en eth0. Sin embargo, cuando ejecuto kubeadm upgrade diff v1.12.3 , todavía quiere revertir los cambios a --advertise-address en /etc/kubernetes/manifests/kube-apiserver.yaml .

¿Alguna pista?

Incluso en kubectl get all --export=true --all-namespaces -o yaml la antigua IP no está presente en ninguna parte

Actualización: resulta que kubeadm upgrade diff sugirió un cambio, pero kubeadm upgrade apply realidad no cambió la dirección en absoluto. (uno de los muchos errores de kubernetes 1.13 como correcciones)

@weisjohn Gracias por

@patricklucas en serio, gracias por ese artículo. Me salvó la vida.

Para aquellos que buscan aún más claridad, estas fueron mis experiencias:

1. reemplace la dirección IP en todos los archivos de configuración en /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. copia de seguridad /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. identificando certificados en /etc/kubernetes/pki que tienen la antigua dirección IP como un nombre alternativo (esto podría limpiarse)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. identifique configmap en el espacio kube-system nombres

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. cambie la dirección IP (a través de cli o gui para su distribución)

6. elimine tanto el certificado como la clave para cada uno identificado por grep en el paso anterior, regenere esos certificados

   NOTA: antes de recrear los certificados a través de kubeadm admin phase certs ... , deberá aplicar la nueva dirección IP

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. reiniciar kubelet y docker
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. copiar la nueva configuración
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

Gracias por los pasos.
¿Puede proporcionar más información sobre qué cambios debemos hacer en el nodo maestro y, después, qué procedimiento debemos aplicar para que el nodo trabajador anterior se una a ese nodo maestro reconfigurado?

Gracias por adelantado :)

Quizás sea bueno mencionar que, al mover la IP maestra a una red privada, también podría ser útil actualizar la red superpuesta. Calico no estaba usando la interfaz VPC hasta que se vinculó a esa interfaz:

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

certificados de fase alfa de kubeadm apiserver

@weisjohn kubeadm alpha phase certs apiserver no funciona en v1.13.0, mostrando "Este comando no debe ejecutarse por sí solo. Consulte la lista de subcomandos disponibles". ¿Hay comentarios actualizados disponibles?

en 1.13 el comando se llama kubeadm init phase certs apiserver :
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

Pasos muy útiles para remediarlo: ¡gracias @patricklucas y @weisjohn !

Un consejo adicional si, como yo, comienza desde el estado en que la dirección IP ya ha cambiado, por lo que no puede comunicarse con el api-server para cambiar los configmaps en el paso 4:
El certificado de api-server está firmado para el nombre de host kubernetes , por lo que puede agregarlo como un alias a la nueva dirección IP en /etc/hosts luego hacer kubectl --server=https://kubernetes:6443 ... .

@bboreham @weisjohn @patricklucas Muchas gracias por su experiencia. ¿Podría dar un consejo, qué debo hacer en los nodos trabajadores después de cambiar la ip en el nodo maestro?
¿Eliminarlo / agregarlo al clúster? ¿O simplemente cambiar _ / etc / kubernetes / kubelet.conf_ y _ / etc / kubernetes / pki / ca.crt_ manualmente?

Sé que es un problema antiguo, pero tal vez mi comentario sea de utilidad para alguien.
Desafortunadamente, la solución propuesta por @patricklucas y @weisjohn no me ha funcionado, así que he creado la mía propia:

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

@ valerius257 gracias hombre, salvas nuestro fin de semana)

Gracias @ valerius257 👍
Probé todos los escritos / instrucciones de @weisjohn . No funcionaron para mi grupo. Lo bueno es que esas instrucciones resaltan algunos de los aspectos clave de los certificados y claves y en qué línea de tiempo deben cuidar.

La instrucción mencionada por @ valerius257 funcionó a la perfección, hasta que encontré problemas que son muy específicos de mi nodo maestro kubeadm. Estaba intentando recuperar kubeadm Master Node cuya IP se cambió.

Publicar continuación de los pasos mencionados por @ valerius257
Estaba usando el complemento de franela n / w en un solo nodo maestro.
Problema de franela: kube-flannel-ds-xxxx retroceso al reiniciar el contenedor fallido
Estado del pod: CrashLoopBackOff. Debido a esto, otros pods como core-dns-xxx tampoco aparecen.

Resolución: como inicié el clúster con kubeadm init con cidr n / w (cuando la IP era antigua o mientras ponía en marcha el nodo maestro), el siguiente paso borró la configuración de cidr de "/ etc / kubernetes / manifests / kube-controller-manager archivo .yaml ".
kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd.

Por lo tanto, si ha iniciado el nodo maestro kubeadm (con la primera dirección IP) con el comando "kubeadm init --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16" ", luego publique la asignación de nueva IP debe ejecutar el siguiente comando con --pod-network-cidr = 10.244.0.0 / 16.
"kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16"

O modifique el archivo "/etc/kubernetes/manifests/kube-controller-manager.yaml con los siguientes parámetros incluidos, si faltan en Spec: containers : command:

• --allocate-node-cidrs = verdadero
• --cluster-cidr = 10.244.0.0 / 16
  
  
  
  • --node-cidr-mask-size = 24
    
    Referencia: https://github.com/coreos/flannel/issues/728 , lea la solución de @wkjun
    
    Una vez que se hayan implementado los cambios anteriores,
    
    systemctl stop kubelet docker
    
    dormir 20
    
    systemctl start docker kubelet
    
    Compruebe que todas las cápsulas estén en funcionamiento, incluida la franela.
    
    kubect obtener pods -n kube-system
  
  

Problema 2:
Todos los pods en el espacio de nombres de la aplicación o en el sistema kube comienzan a mostrar errores en los comandos de descripción del pod, algo como:
"Advertencia FailedScheduling los nodos 0/1 del programador predeterminado están disponibles: 1 nodo (s) tenía manchas que el pod no toleró".
Ejecute el comando: kubectl taint nodes --all node-role.kubernetes.io/master-
describir todos los pods que se ejecutan en el espacio de trabajo de las aplicaciones o en el espacio de nombres del sistema kube, los errores mencionados no se observarán. En el clúster de varios nodos, es posible que deba ser más cauteloso.

@patricklucas en serio, gracias por ese artículo. Me salvó la vida.

Para aquellos que buscan aún más claridad, estas fueron mis experiencias:

1. reemplace la dirección IP en todos los archivos de configuración en /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. copia de seguridad /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. identificando certificados en /etc/kubernetes/pki que tienen la antigua dirección IP como un nombre alternativo (esto podría limpiarse)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. identifique configmap en el espacio kube-system nombres

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. cambie la dirección IP (a través de cli o gui para su distribución)

6. elimine tanto el certificado como la clave para cada uno identificado por grep en el paso anterior, regenere esos certificados

   NOTA: antes de recrear los certificados a través de kubeadm admin phase certs ... , deberá aplicar la nueva dirección IP

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. reiniciar kubelet y docker
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. copiar la nueva configuración
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

en lugar de newip, ¿qué ip debemos dar?
¿Podemos crear una ip propia?

@VipinKrizz el contexto de este problema es que la IP ya cambió debido a factores dentro de la infraestructura. Nadie puede responder qué IP debe usar, excepto alguien familiarizado con su configuración particular.

¿Quizás puedas encontrar a alguien con quien conversar sobre esto en Slack? Los problemas de Kubeadm no son el lugar adecuado.

@ valerius257 muchas gracias por ese script, ahora veo una serie de desventajas en mi enfoque. Puedo confirmar que su solución funcionó, sin embargo, hay muchos bordes pequeños (como en todos los k8). Tuve que volver a aplicar los parches a los servicios / incorporados habilitados, dns, clases de almacenamiento especiales, etc.

Pero sí, tu guión me salvó el tocino hoy.

@ valerius257 Seguí tu paso pero

root @ ubuntu : / etc / kubernetes / pki # kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd
W0122 10: 15: 34.819150 102032 version.go: 101] no se pudo obtener una versión de Kubernetes de Internet: no se pudo obtener la URL " https://dl.k8s.io/release/stable-1.txt ": Obtenga https: //dl.k8s.io/release/stable-1.txt : marque tcp: lookup dl.k8s.io en 127.0.0.53:53: el servidor no funciona correctamente
W0122 10: 15: 34.819340 102032 version.go: 102] recurriendo a la versión del cliente local: v1.16.3
[init] Con la versión de Kubernetes: v1.16.3
[Preflight] Ejecución de comprobaciones previas al vuelo
[ADVERTENCIA IsDockerSystemdCheck]: se detectó "cgroupfs" como el controlador cgroup de Docker. El controlador recomendado es "systemd". Siga la guía en https://kubernetes.io/docs/setup/cri/
[ADVERTENCIA DirAvailable - var-lib-etcd]: / var / lib / etcd no está vacío
[Preflight] Obtención de imágenes necesarias para configurar un clúster de Kubernetes
[Preflight] Esto puede demorar uno o dos minutos, dependiendo de la velocidad de su conexión a Internet.
[Preflight] También puede realizar esta acción de antemano usando 'kubeadm config images pull'
[kubelet-start] Escribiendo un archivo de entorno kubelet con banderas en el archivo "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Escribiendo la configuración de kubelet en el archivo "/var/lib/kubelet/config.yaml"
[kubelet-start] Activando el servicio kubelet
[certs] Usando la carpeta certificateDir "/ etc / kubernetes / pki"
[certs] Usando una autoridad certificadora de CA existente
[certs] Generando certificado y clave "apiserver"
[certs] El certificado de servicio de apiserver está firmado para los nombres DNS [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] y las direcciones IP [10.96.0.1 192.168.120.137]
[certs] Usando el certificado y la clave de apiserver-kubelet-client existentes en el disco
[certs] Uso de la autoridad de certificación front-proxy-ca existente
[certs] Usando el certificado de cliente de proxy frontal existente y la clave en el disco
[certs] Usando una autoridad de certificación de etcd / ca existente
[certs] Usando el certificado y la clave existentes de etcd / server en el disco
[certs] Generando certificado y clave "etcd / peer"
[certs] etcd / peer serve cert está firmado para nombres DNS [ubuntu localhost] e IPs [192.168.120.137 127.0.0.1 :: 1]
[certs] Utilizando el certificado y la clave existentes de etcd / healthcheck-client en el disco
[certs] Usando el certificado y la clave de apiserver-etcd-client existentes en el disco
[certs] Usando la clave "sa" existente
[kubeconfig] Usando la carpeta kubeconfig "/ etc / kubernetes"
[kubeconfig] Escribiendo el archivo kubeconfig "admin.conf"
[kubeconfig] Escribiendo archivo "kubelet.conf" kubeconfig
[kubeconfig] Escribiendo el archivo kubeconfig "controller-manager.conf"
[kubeconfig] Escribiendo el archivo kubeconfig "planificador.conf"
[plano de control] Usando la carpeta de manifiesto "/ etc / kubernetes / manifiestos"
[control-plane] Creación de un manifiesto de pod estático para "kube-apiserver"
[control-plane] Creación de un manifiesto de pod estático para "kube-controller-manager"
[control-plane] Creación de un manifiesto de pod estático para "kube-Scheduler"
[etcd] Creación de un manifiesto de pod estático para etcd local en "/ etc / kubernetes / manifiestos"
[wait-control-plane] Esperando que kubelet inicie el plano de control como Pods estáticos desde el directorio "/ etc / kubernetes / manifests". Esto puede tardar hasta 4 min.
[kubelet-check] Pasó el tiempo de espera inicial de 40 segundos.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] La llamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falló con el error: Obtenga http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection se negó.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] La llamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falló con el error: Obtenga http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection se negó.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] La llamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falló con el error: Obtenga http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection se negó.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] La llamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falló con el error: Obtenga http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection se negó.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] La llamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falló con el error: Obtenga http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection se negó.

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'

Además, es posible que un componente del plano de control se haya bloqueado o salido cuando lo inició el tiempo de ejecución del contenedor.
Para solucionar problemas, enumere todos los contenedores utilizando su CLI de tiempo de ejecución de contenedor preferido, por ejemplo, Docker.
A continuación, se muestra un ejemplo de cómo puede enumerar todos los contenedores de Kubernetes que se ejecutan en la ventana acoplable:
- 'docker ps -a | grep kube | grep -v pausa '
Una vez que haya encontrado el contenedor defectuoso, puede inspeccionar sus registros con:
- 'Docker logs CONTAINERID'
fase de ejecución de error plano de control de espera: no se pudo inicializar un clúster de Kubernetes
Para ver el seguimiento de la pila de este error, ejecute con --v = 5 o superior

amablemente ayuda

Pude lograr esto mediante:

• reemplazar la dirección IP en todos los archivos de configuración en / etc / kubernetes
• haciendo una copia de seguridad de / etc / kubernetes / pki
• identificando certificados en / etc / kubernetes / pki que tienen la antigua dirección IP como un nombre alternativo [1]
• eliminando tanto el certificado como la clave para cada uno de ellos (para mí fue solo apiserver y etcd / peer)
• regenerando los certificados usando kubeadm alpha phase certs [2]
• identificando configmap en el espacio kube-system nombres
• editar manualmente esos configmaps
• reiniciando kubelet y docker (para forzar la recreación de todos los contenedores)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Funcionó para mí gracias

Lo único que necesitas es usar

 kubeadm init phase ..

Para las últimas versiones de kubectl

@bboreham
He seguido los pasos mencionados por @patricklucas
como mencionó en el paso 4, es necesario realizar alguna configuración en / etc / hosts porque la IP ya ha cambiado y no se puede conectar a api-server.

Generar certificado usando
kubeadm init --kubernetes-version = certificados de fase v1.16.3 apiserver

he cambiado en / etc / hosts

y probé kubectl --server = https: //: 6443 todavía no funciona :(

¿Alguna configuración específica necesita hacer en / etc / hosts?