<p>kubeadm init bloqué sur "Le premier nœud s'est enregistré, mais n'est pas encore prêt"</p>

Il m'arrive exactement la même chose sur Ubuntu 16.04.02, les installations GCE et VMWare locales, Docker version 1.12.6, noyau 4.8.0-44-generic 47~16.04.1-Ubuntu SMP.

Le journal de kubelet affiche un avertissement concernant l'absence de /etc/cni/net.d avant l'erreur que nous voyons dans le rapport de jimmycuadra :

Mar 29 04:43:25 instance-1 kubelet[6800]: W0329 04:43:25.763117    6800 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Mar 29 04:43:25 instance-1 kubelet[6800]: E0329 04:43:25.763515    6800 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Même problème sur Ubuntu AWS VM. Docker 1.12.5

root@ip-10-43-0-20 :~# version de kubeadm
kubeadm version : version.Info{Major : "1", Minor : "6", GitVersion :"v1.6.0", GitCommit :"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState :"clean", BuildDate : "2017-03-28T16:24 : 30Z", GoVersion:"go1.7.5"

root@ip-10-43-0-20 :~# uname -a
Linux ip-10-43-0-20 4.4.0-45-generic #66-Ubuntu SMP Mer 19 octobre 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@ip-10-43-0-20 :~# kubeadm init --config cfg.yaml
[kubeadm] ATTENTION : kubeadm est en version bêta, veuillez ne pas l'utiliser pour les clusters de production.
[init] Utilisation de la version Kubernetes : v1.6.0
[init] Utilisation du mode d'autorisation : RBAC
[init] AVERTISSEMENT : pour que les intégrations cloudprovider fonctionnent, --cloud-provider doit être défini pour tous les kubelets du cluster.
(/etc/systemd/system/kubelet.service.d/10-kubeadm.conf doit être édité à cet effet)
[preflight] Exécuter des vérifications avant le vol
[vol en amont] Démarrage du service kubelet
[certificats] Certificat et clé CA générés.
[certificats] Certificat et clé de serveur d'API générés.
[certificats] Le certificat de service du serveur API est signé pour les noms DNS [ip-10-43-0-20 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] et les adresses IP [10.96.0.1 10.43.0.20 ]
[certificats] Certificat et clé du client kubelet du serveur API généré.
[certificats] Clé de signature de jeton de compte de service et clé publique générées.
[certificats] Certificat et clé CA de proxy frontal générés.
[certificats] Certificat et clé client du proxy frontal générés.
[certificats] Des certificats et des clés valides existent maintenant dans "/etc/kubernetes/pki"
[kubeconfig] A écrit le fichier KubeConfig sur le disque : "/etc/kubernetes/admin.conf"
[kubeconfig] A écrit le fichier KubeConfig sur le disque : "/etc/kubernetes/kubelet.conf"
[kubeconfig] A écrit le fichier KubeConfig sur le disque : "/etc/kubernetes/controller-manager.conf"
[kubeconfig] A écrit le fichier KubeConfig sur le disque : "/etc/kubernetes/scheduler.conf"
[apiclient] Client API créé, en attente que le plan de contrôle soit prêt
[apiclient] Tous les composants du plan de contrôle sont sains après 16,531681 secondes
[apiclient] Attendre qu'au moins un nœud s'enregistre et soit prêt
[apiclient] Le premier nœud s'est enregistré, mais n'est pas encore prêt
[apiclient] Le premier nœud s'est enregistré, mais n'est pas encore prêt
[apiclient] Le premier nœud s'est enregistré, mais n'est pas encore prêt

++ le même problème (Ubuntu 16.04.1)

Même chose ici sur Ubuntu 16.04

Sur CentOS 7, j'ai rétrogradé le kubelet à 1.5.4 . Cela l'a résolu pour moi. Il semble que la vérification de disponibilité fonctionne différemment dans le 1.6.0 kubelet.

Même problème sur CentOS 7 sur une machine bare metal x64, depuis la mise à niveau vers k8s 1.6.0

Même problème sur Ubuntu 16.04

Même problème sur Ubuntu 16.04, la rétrogradation manuelle du package kubelet résolu le problème.

# apt install kubelet=1.5.6-00

@ctrlaltdel cela n'a pas fonctionné pour moi.

Je soupçonne qu'il s'agit d'un problème de Kubelet. Il ne doit pas marquer le nœud comme non prêt lorsque CNI n'est pas configuré. Seuls les pods qui nécessitent CNI doivent être marqués comme non prêts.

@jbeda Savez-vous quand ce problème sera-t-il résolu ?

@kristiandrucker -- non -- toujours en train de comprendre ce qui se passe. Besoin d'en faire d'abord la cause.

@jbeda D'accord, mais une fois le problème résolu, alors quoi ? Reconstruire kubelet à partir de la source ?

@kristiandrucker Cela devra sortir dans une version ponctuelle de k8s s'il s'agit d'un problème de kubelet.

Je soupçonne que https://github.com/kubernetes/kubernetes/pull/43474 est la cause première. Je vais signaler un bogue et faire le suivi avec les gens du réseau.

@dcbw Vous êtes dans le

On dirait que le problème est qu'un DaemonSet n'est pas planifié sur les nœuds qui ont la condition Net workReady:false , car les vérifications des pods de planification ne sont pas suffisamment précises. Nous devons régler cela; un pod ho stNetwork:true doit être planifié sur un nœud Net workReady:false , mais pas un pod ho

En guise de solution de contournement, l'ajout de l'annotation scheduler.alpha.kubernetes.io/critical-pod sur votre DaemonSet fait-il fonctionner à nouveau les choses ?

@janetkuo @lukaszo pouvez-vous trier le comportement DS ?

Il y a aussi une discussion en cours dans #sig-network sur slack, d'ailleurs.

Même problème CentOS 7 x64

@prapdm, cela semble sans défense de la distribution que vous exécutez.

CentOS Linux version 7.3.1611 (Core)

Je l'ai essayé sur un nœud avec Ubuntu 16.04. Il se bloque avec le message "pas encore prêt". J'ai également créé manuellement le DaemonSet en flanelle, mais dans mon cas, il a programmé un pod sans aucun problème. Le pod démon lui-même est entré dans CrashLoopBackOff avec l'erreur : E0329 22:57:03.065651 1 main.go:127] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-z3xgn': the server does not allow access to the requested resource (get pods kube-flannel-ds-z3xgn)

Je vais essayer Centos aussi mais je ne pense pas que DaemonSet soit à blâmer ici, kubeadm se bloque ici.

c'est une erreur d'autorisation rbac.

@jimmycuadra Je viens de remarquer que vous l'exécutez sur raspberry pi qui a un processeur de bras.

Pour l'ensemble de démons en flanelle, vous avez :

``` nodeSelector :
beta.kubernetes.io/arch : amd64

but your node is labeled with: 

beta.kubernetes.io/arch=arm
```

Donc DaemonSet ne peut pas déjeuner de pod sur ce nœud, il suffit de changer le sélecteur de nœud et cela fonctionnera.
Vous obtiendrez toujours l'erreur avec l'autorisation rbac mais peut-être que @mikedanese vous dira comment la corriger car je ne le sais pas.

Ah, merci @lukaszo ! Je ne suivais pas le guide spécifique à RPi cette fois (que j'ai utilisé pour k8s 1.5) et j'ai oublié cette étape. Je l'aurais découvert lorsque l'ensemble de démons a fait une erreur, mais il s'avère que je ne suis pas allé aussi loin. :}

Je vois également ce problème lorsque je suis les instructions décrites ici :
https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

réussi à le faire fonctionner après avoir installé le bon pod réseau en flanelle.

Je pense que @jimmycuadra pourrait le faire fonctionner avec le commentaire de @lukaszo .

Lorsque le message [apiclient] First node has registered, but is not ready yet commence à inonder, le serveur d'API kubernetes est en cours d'exécution, vous pouvez donc :

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | kubectl create -f -

Pour l'installation de Raspberry Pi :

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | sed "s/amd64/arm/g" | kubectl create -f -

Ensuite, il finira :

[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 245.050597 seconds
[apiclient] Test deployment succeeded
[token] Using token: 4dc99e............
[apiconfig] Created RBAC rules
[addons] Created essential addon: kube-proxy
[addons] Created essential addon: kube-dns

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token 4dc99e........... 192.168.1.200:6443

J'ai eu le même problème et j'ai résolu de cette façon :
tu devrais être root

dans la 1.6.0 de kubeadm vous devez supprimer la variable d'environnement $KUBELET_NETWORK_ARGS dans le fichier système : /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

puis redémarrer les démons

systemctl daemon-reload

kubeadm init

cela prend un peu de temps ... après le succès

téléchargez le module complémentaire réseau que vous souhaitez utiliser : http://kubernetes.io/docs/admin/addons/

calico semble être le meilleur, pas sûr mais toujours en test pour moi.

@thelastworm
J'ai juste essayé de le faire et ça n'a pas fonctionné.
Ubuntu 16.04.2 LTS, kubeadm 1.6.0
J'ai fait les étapes suivantes :

1. éditez /etc/systemd/system/kubelet.service.d/10-kubeadm.conf et supprimez $KUBELET_NETWORK_ARGS
2. kubeadm reset pour nettoyer la tentative précédente de le démarrer
3. kubeadm init --token=<VALUE> --apiserver-advertise-address=<IP>

[ÉDITÉ]
Cela a fonctionné après que @srinat999 ait souligné la nécessité d'exécuter systemctl daemon-reload avant kubeadm init

La solution de @jcorral a fonctionné pour moi avec une modification du déploiement de la flanelle puisque le port API non sécurisé n'est plus créé par kubeadm .

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | \
kubectl --kubeconfig /etc/kubernetes/admin.conf create -f -

@MaximF Vous devez faire systemctl daemon-reload après avoir modifié le fichier de configuration. A travaillé pour moi.

@jcorral Votre solution fonctionne pour moi. Merci.

@MaximF je viens d'ajouter la ligne de commande du démon de redémarrage

kubeadm init se termine avec succès, mais lorsque je vérifie la version, j'obtiens l'erreur suivante :

Version du client : version.Info{Major:"1", Minor :"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36: 33Z", GoVersion :"go1.7.5", Compilateur :"gc", Plate-forme :"linux/amd64"}
La connexion au serveur localhost:8080 a été refusée - avez-vous spécifié le bon hôte ou le bon port ?

@haribole
Vous devez définir la variable d'environnement KUBECONFIG

Est-ce que quelqu'un a fait exécuter Flannel après les solutions de contournement liées à CNI ? Je peux passer le problème non prêt, mais lorsque j'exécute Flannel, j'obtiens une erreur qui ressemble à ceci :

Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-g5cbj': the server does not allow access to the requested resource (get pods kube-flannel-ds-g5cbj)

L'état des pods indique « CrashLoopBackOff »

Vous devez ajouter des rôles rbac pour autoriser la lecture de flannel à partir de l'API.

Vous devez ajouter des rôles rbac pour autoriser la lecture de flannel à partir de l'API.

Au cas où quelqu'un d'autre se demande ce que cela signifie, il semble que vous deviez créer kube-flannel-rbac.yml avant de créer de la flanelle :

kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Je pense qu'un problème racine est résolu et que le ticket associé est fermé , nous devrions également fermer celui-ci :)

Juste pour information : cela fonctionne pour moi maintenant avec les packages mis à jour sous Ubuntu 16.04.

1.6.1 fonctionne pour moi ! Merci à tous ceux qui ont aidé à résoudre ce problème !

J'ai réussi à configurer mon cluster Kubernetes sur centos-release-7-3.1611.el7.centos.x86_64 en procédant comme suit (je suppose que Docker est déjà installé) :

1) (de /etc/yum.repo.d/kubernetes.repo) baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Pour utiliser le référentiel instable pour le dernier Kubernetes 1.6.1
2) miam install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) ajoutez "--cgroup-driver=systemd" à la fin de la dernière ligne.
=> C'est parce que Docker utilise systemd pour cgroup-driver tandis que kubelet utilise cgroupfs pour cgroup-driver.
4) systemctl activer kubelet && systemctl démarrer kubelet
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Si vous aviez l'habitude d'ajouter --api-advertise-addresses, vous devez utiliser --apiserver-advertise-address à la place.
6) cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
export KUBECONFIG=$HOME/admin.conf
=> Sans cette étape, vous pourriez obtenir une erreur avec kubectl get
=> je ne l'ai pas fait avec 1.5.2
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 introduit un contrôle d'accès basé sur les rôles, vous devez donc ajouter un ClusterRole et un ClusterRoleBinding avant de créer un démon Flannel
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Créer un démon Flannel
9) (sur chaque nœud esclave) kubeadm join --token (votre jeton) (ip):(port)
=> comme indiqué dans le résultat de kubeadm init

Toutes les étapes ci-dessus sont le résultat de la combinaison de suggestions de divers problèmes autour de Kubernetes-1.6.0, en particulier kubeadm.

J'espère que cela vous fera gagner du temps.

@eastcirclek @Sliim Tu es génial

@eastcirclek ce sont les étapes exactes que je viens d'exécuter en interrogeant également plusieurs forums. Un décalage horaire, peut-être ? Merci à tous, ce sujet m'a beaucoup aidé.

J'ai un serveur Ubuntu 16.04 sur AWS et j'ai suivi les étapes

1. éditez /etc/systemd/system/kubelet.service.d/10-kubeadm.conf et supprimez $KUBELET_NETWORK_ARGS
2. kubeadm reset pour nettoyer la tentative précédente de le démarrer
3. kubeadm init --token=--apiserver-advertise-address=

qui a apparemment fonctionné correctement, mais lorsque j'essaie d'installer Calico en tant que plug-in réseau, j'obtiens l'erreur suivante
La connexion au serveur localhost:8080 a été refusée - avez-vous spécifié le bon hôte ou le bon port ?

L'équipe k8s travaille-t-elle sur un patch ?

Merci

@overip Je ne pense pas qu'un correctif soit requis pour cela... Il vous suffit de spécifier le bon fichier kubeconfig lors de l'utilisation de kubectl. kubeadm aurait dû l'écrire dans /etc/kubernetes/admin.conf .

@jimmycuadra pourriez-vous s'il vous plaît expliquer les étapes pour le faire?

@overip La sortie de kubeadm init a les instructions :

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Personnellement, je préfère copier le fichier dans $HOME/.kube/config , c'est là que kubectl le recherchera par défaut. Ensuite, vous n'avez pas besoin de définir la variable d'environnement KUBECONFIG.

Si vous prévoyez d'utiliser kubectl depuis votre ordinateur local, vous pouvez utiliser scp (ou même simplement copier-coller le contenu) pour l'écrire sur ~/.kube/config sur votre propre ordinateur.

Recherchez « admin.conf » dans ce problème GitHub pour plus de détails. Cela a été mentionné à quelques reprises.

@eastcirclek - a suivi les étapes, mais pour une raison quelconque, les nœuds ne sont pas en mesure d'installer correctement la flanelle.
(Remarque : sur le maître, tout est fluide.)

Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666206   22893 kuberuntime_manager.go:458] Container {Name:install-cni Image:quay.io/coreos/flannel:v0.7.0-amd64 Command:[/bin/sh -c set -e -x; cp -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conf; while true; do sleep 3600; done] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:cni ReadOnly:false MountPath:/etc/cni/net.d SubPath:} {Name:flannel-cfg ReadOnly:false MountPath:/etc/kube-flannel/ SubPath:} {Name:flannel-token-g65nf ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:nil ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:nil Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666280   22893 kuberuntime_manager.go:742] checking backoff for container "install-cni" in pod "kube-flannel-ds-3smf7_kube-system(2e6ad0f9-207f-11e7-8f34-0050569120ff)"
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846325   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/configmap/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-cfg" (spec.Name: "flannel-cfg") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846373   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-token-g65nf" (spec.Name: "flannel-token-g65nf") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").

Partagez simplement ma méthode de contournement. Premièrement, $KUBELET_NETWORK_ARGS est requis, sinon CNI n'est pas activé/configuré. Supprimer puis restaurer $KUBELET_NETWORK_ARGS semble trop compliqué.
Lorsque kubeadm init affiche "[apiclient] Le premier nœud s'est enregistré, mais n'est pas encore prêt", le cluster k8s est en fait prêt à répondre à la demande. À ce moment-là, l'utilisateur peut simplement passer à l'étape 3/4 de https://kubernetes.io/docs/getting-started-guides/kubeadm/ comme suit.

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:  http://kubernetes.io/docs/admin/addons/

Lorsqu'un utilisateur installe le podnetwork, assurez-vous que le compte de service de la politique podnetwork dispose d'une autorisation suffisante. Prenant la flanelle comme exemple. Je viens de lier le rôle cluster-admin au compte de service de la flanelle comme suit. Ce n'est peut-être pas l'idéal et vous pouvez définir un rôle spécifique pour le compte de service en flanelle. BTW, lorsqu'un utilisateur déploie un autre service complémentaire comme le tableau de bord, il doit également accorder suffisamment d'autorisations au compte de service associé.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: flannel:daemonset
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: flannel
  namespace:  kube-system

Une fois que le serveur podnetwork est prêt, kubeadm init indique que le nœud est prêt et que l'utilisateur peut continuer avec l'instruction.

Prenant la flanelle comme exemple. Je viens de lier le rôle cluster-admin au compte de service de la flanelle comme suit. Ce n'est peut-être pas l'idéal et vous pouvez définir un rôle spécifique pour le compte de service en flanelle.

Il y a déjà https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Merci à tous pour l'aide.
Enfin, k8s 1.6.1 entièrement fonctionnel avec de la flanelle. Tout est maintenant dans des playbooks ansible.
Testé sur Centos/RHEL. Les préparatifs ont également commencé pour la base de Debian (par exemple, Ubuntu), mais il pourrait avoir besoin d'être affiné.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS : travail basé sur sjenning/kubeadm-playbook - Merci beaucoup @sjenning

Obtenir ceci pour rejoindre un cluster :
[discovery] Création d'un client de découverte d'informations sur le cluster, en demandant des informations à " https://10.100.2.158 :6443"
[discovery] Échec de la demande d'informations sur le cluster, je réessayerai : [configmaps "cluster-info" est interdit : l'utilisateur " system:anonymous " ne peut pas obtenir les configmaps dans l'espace de noms "kube-public"]
[discovery] Échec de la demande d'informations sur le cluster, je réessayerai : [configmaps "cluster-info" est interdit : l'utilisateur " system:anonymous " ne peut pas obtenir les configmaps dans l'espace de noms "kube-public"]

J'ai démarré le nœud en tant que SelfHosting.