Kubeadm: Modification de l'adresse IP principale

Il ne s'agit pas d'une limitation de kubeadm, mais simplement d'une pratique de sécurité générale.
Le certificat est signé pour {your-old-IP-here} et la communication sécurisée ne peut alors pas arriver à {your-new-ip-here}

Vous pouvez cependant ajouter plus d'adresses IP dans le certificat au préalable...

Merci pour votre réponse.

Comme les adresses IP sont attribuées par le fournisseur de cloud, la génération d'un certificat au préalable ne fonctionnerait que si je pouvais le définir sur un caractère générique. (Désolé, je ne connais rien aux certificats.)

J'ai oublié que kubeadm reset existe réellement, car ce n'est pas mentionné dans le guide de référence . La réinitialisation et l'initialisation ont assez bien fonctionné pour moi, et je suppose que j'éviterai d'arrêter la machine principale - je suppose que mon problème est rare et loin de tout cas d'utilisation en production. Pourtant, je me demande s'il y a une meilleure façon. Je suppose que je pourrais imiter les étapes de kubeadm reset , mais conserver le dossier de données etcd pour préserver la configuration de mon cluster ?

Quoi qu'il en soit, merci pour tout le travail effectué sur kubeadm ! C'est magique de voir le cluster apparaître en quelques minutes - j'utilise Kubernetes depuis 0.14, en production depuis 1.0.

@analytik j'ai exactement le même problème que le vôtre. Mon réseau d'entreprise bloque gcr.io . J'utilise donc un dongle pour l'installation. Cependant, l'IP du fournisseur continue de changer de manière dynamique et n'est pas sous mon contrôle. Donc même moi je cherche une solution. Même si je garde mon dongle branché, parfois en raison de la réinitialisation du réseau, l'IP change. Avez-vous une solution à cela? Comment gérez-vous cela?
@luxas pourriez-vous s'il vous plaît suggérer comment je peux procéder. Je suis un débutant sur K8S. Complètement perdu avec cette configuration. Pourriez-vous me dire comment je peux résoudre ce problème d'IP dynamique ?

Comment gérez-vous la nouvelle adresse IP principale ?

Y a-t-il une mise à jour sur ce problème?

Même problème ici. Une documentation pour procéder à une modification de l'adresse IP principale sans réinitialiser l'ensemble du cluster s'il vous plaît ?

J'ai pu y parvenir en :

• remplacement de l'adresse IP dans tous les fichiers de configuration dans /etc/kubernetes
• sauvegarde de /etc/kubernetes/pki
• identifiant les certificats dans /etc/kubernetes/pki qui ont l'ancienne adresse IP comme nom alternatif[1]
• supprimer à la fois le cert et la clé pour chacun d'eux (pour moi c'était juste apiserver et etcd/peer)
• régénérer les certificats en utilisant kubeadm alpha phase certs [2]
• identifiant configmap dans l'espace kube-system noms
• modifier manuellement ces configmaps
• redémarrage de kubelet et docker (pour forcer la recréation de tous les conteneurs)

[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 ...

Wow, je n'étais pas au courant de ces commandes. Super infos, ça a fait l'affaire. Merci !

existe-t-il un moyen de trouver les configmaps manuellement et de les modifier ?

J'espère que kubeadm pourra couvrir ce processus dans une future version.

@patricklucas sérieusement, merci pour cet article. Cela m'a sauvé la vie.

Pour ceux qui recherchent encore plus de clarté, voici mes expériences :

1. remplacer l'adresse IP dans tous les fichiers de configuration dans /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. sauvegarde /etc/kubernetes/pki
bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. identifiant les certificats dans /etc/kubernetes/pki qui ont l'ancienne adresse IP comme nom alternatif (cela pourrait être nettoyé)
   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. identifiez configmap dans l'espace kube-system noms

   # 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. changer l'adresse IP (via cli ou gui pour votre distribution)

6. supprimez à la fois le certificat et la clé pour chacun identifié par grep à l'étape précédente, régénérez ces certificats

   REMARQUE : avant de recréer les certificats via kubeadm admin phase certs ... , vous devez appliquer la nouvelle adresse 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. redémarrer kubelet et docker
   bash sudo systemctl restart kubelet sudo systemctl restart docker
8. copier sur la nouvelle configuration
   bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

autre chose à noter, la modification des certificats était possible en mode hors ligne en spécifiant la version k8s dans un fichier de configuration : https://github.com/kubernetes/kubernetes/issues/54188#issuecomment -418880831

@weisjohn Pourriez-vous également mettre à jour votre commentaire en notant que :

kubectl edit cm -nkube-public cluster-info

est également nécessaire pour kubeadm?

Sinon, mes commandes de jointure kubeadm continuent d'échouer en utilisant l'ancienne/mauvaise adresse IP apiserver à mi-chemin du processus.

Merci!

J'ai appliqué toutes les étapes de @weisjohn (https://github.com/kubernetes/kubeadm/issues/338#issuecomment-418879755) et @michaelfig (https://github.com/kubernetes/kubeadm/issues/ 338#issuecomment-428340099) pour remplacer l'adresse partout.

Ceci est utilisé pour permettre à kubernetes d'utiliser l'adresse VPC nouvellement créée sur eth1, au lieu de l'adresse IP publique sur eth0. Pourtant, lorsque j'exécute kubeadm upgrade diff v1.12.3 il souhaite toujours rétablir les modifications apportées à --advertise-address dans /etc/kubernetes/manifests/kube-apiserver.yaml .

Des indices ?

Même dans kubectl get all --export=true --all-namespaces -o yaml l'ancienne IP n'est présente nulle part

Mise à jour : il s'avère que kubeadm upgrade diff a suggéré un changement, mais que kubeadm upgrade apply n'a pas du tout changé l'adresse. (l'un des nombreux bugs de kubernetes 1.13 comme des correctifs)

@weisjohn Merci pour

@patricklucas sérieusement, merci pour cet article. Cela m'a sauvé la vie.

Pour ceux qui recherchent encore plus de clarté, voici mes expériences :

1. remplacer l'adresse IP dans tous les fichiers de configuration dans /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. sauvegarde /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. identifiant les certificats dans /etc/kubernetes/pki qui ont l'ancienne adresse IP comme nom alternatif (cela pourrait être nettoyé)
   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. identifiez configmap dans l'espace kube-system noms

   # 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. changer l'adresse IP (via cli ou gui pour votre distribution)

6. supprimez à la fois le certificat et la clé pour chacun identifié par grep à l'étape précédente, régénérez ces certificats

   REMARQUE : avant de recréer les certificats via kubeadm admin phase certs ... , vous devez appliquer la nouvelle adresse 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. redémarrer kubelet et docker
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. copier sur la nouvelle configuration
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

Merci pour les étapes.
Pouvez-vous nous en dire plus sur les modifications que nous devons apporter au nœud maître et, après cela, quelle procédure nous devons appliquer pour que l'ancien nœud de travail rejoigne ce nœud maître reconfiguré ?

Merci d'avance :)

Il est peut-être bon de mentionner que lors du déplacement de l'adresse IP principale vers un réseau privé, il peut également être utile de mettre à jour le réseau superposé. Calico n'utilisait pas l'interface VPC tant qu'il n'était pas lié à cette interface :

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

kubeadm alpha phase certs apiserver

@weisjohn kubeadm alpha phase certs apiserver ne fonctionne pas dans la v1.13.0, indiquant "Cette commande n'est pas destinée à être exécutée seule. Voir la liste des sous-commandes disponibles." des commentaires mis à jour disponibles?

en 1.13 la commande s'appelle kubeadm init phase certs apiserver :
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

Étapes très utiles pour y remédier - merci @patricklucas et @weisjohn !

Un conseil supplémentaire si, comme moi, vous partez de l'état où l'adresse IP a déjà changé, vous ne pouvez donc pas contacter le serveur api pour modifier les configmaps à l'étape 4 :
Le certificat du serveur API est signé pour le nom d'hôte kubernetes , vous pouvez donc l'ajouter en tant qu'alias à la nouvelle adresse IP dans /etc/hosts puis faire kubectl --server=https://kubernetes:6443 ... .

@bboreham @weisjohn @patricklucas Merci beaucoup pour votre expérience. Pourriez-vous s'il vous plaît donner un conseil, que dois-je faire sur les nœuds de travail après avoir changé l'adresse IP sur le nœud maître ?
Supprimer/ajouter au cluster ? Ou modifiez simplement _/etc/kubernetes/kubelet.conf_ et _/etc/kubernetes/pki/ca.crt_ manuellement ?

Je sais que c'est un vieux problème mais peut-être que mon commentaire sera utile à quelqu'un.
Malheureusement, la solution proposée par @patricklucas et @weisjohn n'a pas fonctionné pour moi, j'ai donc créé la mienne :

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 merci mec, tu

Merci @valerius257
J'ai essayé toutes les écritures / instructions de @patricklucas et @weisjohn . Ils n'ont pas fonctionné pour mon cluster. La bonne partie est que ces instructions mettent en évidence certains des aspects clés des certificats et des clés et à quel moment ils doivent prendre soin.

L'instruction mentionnée par @valerius257 a fonctionné de manière transparente, jusqu'à ce que je rencontre des problèmes très spécifiques à mon nœud maître kubeadm. J'essayais de récupérer le nœud maître kubeadm dont l'adresse IP a été modifiée.

Suite de la publication des étapes mentionnées par @valerius257
J'utilisais le plugin Flannel n/w sur un seul nœud maître.
Problème de flanelle : échec du redémarrage du conteneur lors du redémarrage de kube-flannel-ds-xxxx
État du pod : CrashLoopBackOff. En raison de cela, d'autres pods comme core-dns-xxx ne parviennent pas non plus à apparaître.

Résolution : comme j'ai lancé le cluster avec kubeadm init avec cidr n/w (lorsque l'IP était ancienne ou lors de la mise en service du nœud maître), l'étape suivante a effacé les paramètres cidr de "/etc/kubernetes/manifests/kube-controller-manager fichier .yaml".
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd.

Par conséquent, si vous avez lancé le nœud maître kubeadm (avec la première adresse IP) avec la commande "kubeadm init --token {{ kubeadm_token }} --pod-network-cidr=10.244.0.0/16" ", puis post-allocation de nouvelle IP, vous devez exécuter la commande suivante avec --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"

Ou modifiez le fichier "/etc/kubernetes/manifests/kube-controller-manager.yaml avec les paramètres suivants inclus, s'ils sont manquants sous Spec:containers :command:

• --allocate-node-cidrs=true
• --cluster-cidr=10.244.0.0/16
  
  
  
  • --node-cidr-mask-size=24
    
    Référence : https://github.com/coreos/flanel/issues/728 , lisez la solution de @wkjun
    
    Une fois que les changements ci-dessus sont en place,
    
    systemctl stop kubelet docker
    
    dormir 20
    
    systemctl démarrer docker kubelet
    
    Vérifiez que toutes les gousses sont opérationnelles, y compris la flanelle.
    
    kubect obtenir des pods -n kube-system
  
  

Question 2 :
Tous les pods de l'espace de noms de l'application ou du système kube commencent à afficher des erreurs dans les commandes de pod de description, par exemple :
« Avertissement FailedScheduling default-scheduler 0/1 les nœuds sont disponibles : 1 nœud présentait des défauts que le pod ne tolérait pas. »
Exécutez la commande : kubectl taint nodes --all node-role.kubernetes.io/master-
décrivez tous les pods exécutés dans l'espace de travail des applications ou dans l'espace de noms kube-system, les erreurs mentionnées ne seront pas observées. Dans un cluster multi-nœuds, vous devrez peut-être être très prudent.

@patricklucas sérieusement, merci pour cet article. Cela m'a sauvé la vie.

Pour ceux qui recherchent encore plus de clarté, voici mes expériences :

1. remplacer l'adresse IP dans tous les fichiers de configuration dans /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. sauvegarde /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. identifiant les certificats dans /etc/kubernetes/pki qui ont l'ancienne adresse IP comme nom alternatif (cela pourrait être nettoyé)
   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. identifiez configmap dans l'espace kube-system noms

   # 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. changer l'adresse IP (via cli ou gui pour votre distribution)

6. supprimez à la fois le certificat et la clé pour chacun identifié par grep à l'étape précédente, régénérez ces certificats

   REMARQUE : avant de recréer les certificats via kubeadm admin phase certs ... , vous devez appliquer la nouvelle adresse 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. redémarrer kubelet et docker
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. copier sur la nouvelle configuration
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

à la place de newip quelle ip doit-on donner ?
pouvons-nous créer notre propre adresse IP ?

@VipinKrizz, le contexte de ce problème est que l'IP a déjà changé en raison de facteurs au sein de l'infrastructure. Personne ne peut vous dire quelle IP vous devez utiliser, sauf quelqu'un qui connaît votre configuration particulière.

Peut-être pouvez-vous trouver quelqu'un avec qui discuter à ce sujet sur Slack ? Les problèmes de Kubeadm ne sont pas au bon endroit.

@valerius257 merci beaucoup pour ce script, je vois maintenant un certain nombre d'inconvénients dans mon approche. Je peux confirmer que votre solution a fonctionné, cependant, il y a beaucoup de petits bords (comme dans tous les k8). J'ai dû réappliquer tous les correctifs aux services activés / intégrés, DNS, classes de stockage spéciales, etc.

Mais oui, votre script a sauvé mon bacon aujourd'hui.

@ valerius257 J'ai suivi votre étape mais

root@ubuntu :/etc/kubernetes/pki# kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd
W0122 10:15:34.819150 102032 version.go:101] n'a pas pu récupérer une version de Kubernetes sur Internet : impossible d'obtenir l'URL " https://dl.k8s.io/release/stable-1.txt " : Get https : //dl.k8s.io/release/stable-1.txt : composez tcp : recherchez dl.k8s.io sur 127.0.0.53 : 53 : le serveur se comporte mal
W0122 10:15:34.819340 102032 version.go:102] revenant à la version du client local : v1.16.3
[init] Utilisation de la version Kubernetes : v1.16.3
[preflight] Exécuter des vérifications avant le vol
[AVERTISSEMENT IsDockerSystemdCheck] : a détecté « cgroupfs » en tant que pilote de groupe de contrôle Docker. Le pilote recommandé est "systemd". Veuillez suivre le guide sur https://kubernetes.io/docs/setup/cri/
[AVERTISSEMENT DirAvailable--var-lib-etcd] : /var/lib/etcd n'est pas vide
[contrôle en amont] Extraction des images requises pour la configuration d'un cluster Kubernetes
[vol en amont] Cela peut prendre une minute ou deux, selon la vitesse de votre connexion Internet
[preflight] Vous pouvez également effectuer cette action au préalable en utilisant 'kubeadm config images pull'
[kubelet-start] Écriture du fichier d'environnement kubelet avec des indicateurs dans le fichier "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Écriture de la configuration de kubelet dans le fichier "/var/lib/kubelet/config.yaml"
[kubelet-start] Activer le service kubelet
[certs] Utilisation du dossier certificateDir "/etc/kubernetes/pki"
[certs] Utilisation de l'autorité de certification ca existante
[certs] Génération du certificat et de la clé "apiserver"
[certs] le certificat de service apiserver est signé pour les noms DNS [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] et les adresses IP [10.96.0.1 192.168.120.137]
[certs] Utilisation du certificat et de la clé apiserver-kubelet-client existants sur le disque
[certs] Utilisation de l'autorité de certification front-proxy-ca existante
[certs] Utilisation d'un certificat client-proxy frontal et d'une clé existants sur le disque
[certs] Utilisation de l'autorité de certification etcd/ca existante
[certs] Utilisation du certificat et de la clé etcd/server existants sur le disque
[certs] Génération du certificat et de la clé "etcd/peer"
[certs] le certificat de service etcd/peer est signé pour les noms DNS [ubuntu localhost] et les adresses IP [192.168.120.137 127.0.0.1 ::1]
[certs] Utilisation du certificat et de la clé etcd/healthcheck-client existants sur le disque
[certs] Utilisation du certificat et de la clé apiserver-etcd-client existants sur le disque
[certs] Utilisation de la clé "sa" existante
[kubeconfig] Utilisation du dossier kubeconfig "/etc/kubernetes"
[kubeconfig] Écriture du fichier kubeconfig "admin.conf"
[kubeconfig] Écriture du fichier kubeconfig "kubelet.conf"
[kubeconfig] Écriture du fichier kubeconfig "controller-manager.conf"
[kubeconfig] Écriture du fichier kubeconfig "scheduler.conf"
[control-plane] Utilisation du dossier manifest "/etc/kubernetes/manifests"
[control-plane] Création d'un manifeste de pod statique pour "kube-apiserver"
[control-plane] Création d'un manifeste de pod statique pour "kube-controller-manager"
[control-plane] Création d'un manifeste de pod statique pour "kube-scheduler"
[etcd] Création d'un manifeste de pod statique pour etcd local dans "/etc/kubernetes/manifests"
[wait-control-plane] En attente que le kubelet démarre le plan de contrôle en tant que pods statiques à partir du répertoire "/etc/kubernetes/manifests". Cela peut prendre jusqu'à 4m0s
[kubelet-check] Le délai initial de 40 s est dépassé.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] L'appel HTTP égal à 'curl -sSL http://localhost :10248/healthz' a échoué avec l'erreur : Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refusé.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] L'appel HTTP égal à 'curl -sSL http://localhost :10248/healthz' a échoué avec l'erreur : Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refusé.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] L'appel HTTP égal à 'curl -sSL http://localhost :10248/healthz' a échoué avec l'erreur : Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refusé.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] L'appel HTTP égal à 'curl -sSL http://localhost :10248/healthz' a échoué avec l'erreur : Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refusé.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] L'appel HTTP égal à 'curl -sSL http://localhost :10248/healthz' a échoué avec l'erreur : Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refusé.

Malheureusement, une erreur s'est produite :
a expiré en attendant la condition

Cette erreur est probablement causée par :
- Le kubelet ne fonctionne pas
- Le kubelet n'est pas sain en raison d'une mauvaise configuration du nœud d'une manière ou d'une autre (groupes de contrôle obligatoires désactivés)

Si vous utilisez un système alimenté par systemd, vous pouvez essayer de résoudre l'erreur avec les commandes suivantes :
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

De plus, un composant du plan de contrôle peut avoir planté ou s'être arrêté lorsqu'il a été démarré par l'environnement d'exécution du conteneur.
Pour résoudre les problèmes, répertoriez tous les conteneurs à l'aide de votre CLI d'exécution de conteneur préférée, par exemple docker.
Voici un exemple de liste de tous les conteneurs Kubernetes exécutés dans docker :
- 'docker ps -a | grep kube | grep -v pause'
Une fois que vous avez trouvé le conteneur défaillant, vous pouvez inspecter ses journaux avec :
- 'docker logs CONTAINERID'
erreur phase d'exécution wait-control-plane : impossible d'initialiser un cluster Kubernetes
Pour voir la trace de la pile de cette erreur, exécutez avec --v=5 ou supérieur

aide aimablement

J'ai pu y parvenir en :

• remplacement de l'adresse IP dans tous les fichiers de configuration dans /etc/kubernetes
• sauvegarde de /etc/kubernetes/pki
• identifiant les certificats dans /etc/kubernetes/pki qui ont l'ancienne adresse IP comme nom alternatif[1]
• supprimer à la fois le cert et la clé pour chacun d'eux (pour moi c'était juste apiserver et etcd/peer)
• régénérer les certificats en utilisant kubeadm alpha phase certs [2]
• identifiant configmap dans l'espace kube-system noms
• modifier manuellement ces configmaps
• redémarrage de kubelet et docker (pour forcer la recréation de tous les conteneurs)

[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 ...

A fonctionné pour moi merci

La seule chose est que vous devez utiliser

 kubeadm init phase ..

Pour les dernières versions de kubectl

@bboreham
J'ai suivi les étapes mentionnées par @patricklucas
comme vous l'avez mentionné à l'étape 4, vous devez effectuer une configuration dans /etc/hosts car l'IP a déjà changé et ne peut pas se connecter au serveur api.

Générer un certificat en utilisant
kubeadm init --kubernetes-version=v1.16.3 phase certs apiserver

j'ai changé dans /etc/hosts

et essayé kubectl --server=https://:6443 ne fonctionne toujours pas :(

une configuration spécifique à faire dans /etc/hosts ??