/ cc @lukemarsden @luxas @mikedanese

Si nous revenons complètement au #43474, nous sommes à nouveau dans une situation où nous cassons les plugins CNI 0.2.0 (voir https://github.com/kubernetes/kubernetes/issues/43014)

Devrions-nous envisager de faire quelque chose comme https://github.com/kubernetes/kubernetes/pull/43284 ?

Aussi /cc @thockin

/ cc @ kubernetes / sig-network-bugs

Réf : https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda puis-je obtenir des journaux kubelet avec --loglevel=5 ?

@yujuhong -- vous mentionnez que vous pensez que cela fonctionne comme prévu. Quoi qu'il en soit, kubeadm dépendait de ce comportement. Nous avons introduit un changement décisif avec le #43474. Nous pouvons parler de la bonne façon de résoudre ce problème pour la 1.7 mais, pour l'instant, nous devons faire fonctionner à nouveau kubeadm.

Discussion Slack en cours -- https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

Il semble que les DaemonSets seront toujours planifiés même si le nœud n'est pas prêt. C'est vraiment, dans ce cas, kubeadm étant un peu trop paranoïaque.

Le plan actuel que nous allons tester consiste à faire en sorte que kubeadm n'attende plus que le nœud maître soit prêt mais qu'il soit simplement enregistré. Cela devrait être suffisant pour permettre à un DaemonSet CNI d'être programmé pour configurer CNI.

@kensimon teste cela.

@jbeda ouais, on dirait que le contrôleur DaemonSet les mettra toujours en file d'attente principalement parce qu'il ignore complètement le réseau. Nous devrions vraiment résoudre ce problème de manière plus générale. Y a-t-il quelque chose à faire immédiatement dans kube ou tout est-il dans kubeadm pour le moment ?

J'essaie d'installer kubernetes avec kubeadm sur Ubuntu 16.04. Existe-t-il une solution rapide pour cela?

@jbeda si vous avez une version corrigée, content de la tester..

J'ai kubeadm qui dépasse le statut NotReady du nœud, mais le déploiement factice qu'il crée ne fonctionne pas en raison de la souillure node.alpha.kubernetes.io/notReady empêchant de s'exécuter. L'ajout de tolérances ne semble pas aider, je ne sais pas exactement comment procéder à ce stade. Quelqu'un peut-il nous éclairer sur la façon de déployer un pod qui tolère la souillure notReady ?

J'explore d'autres options comme ne pas marquer le nœud comme non prêt, mais ce n'est pas clair que c'est ce que nous voulons faire.

nous avons contourné cela en supprimant KUBELET_NETWORK_ARGS de la ligne de commande de kubelet. après cela, kubeadm init a bien fonctionné et nous avons pu installer le plugin canal cni.

@sbezverk pourriez -vous s'il vous plaît décrire comment faire cela?

Peut confirmer les résultats de @sbezverk (bonne trouvaille :) ), en ajustant /etc/systemd/system/10-kubeadm.conf et en supprimant KUBELET_NETWORK_ARGS le fera fonctionner sur centos. Testé avec tissage.

@overip vous devez éditer /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

supprimer $ KUBELET_NETWORK_ARGS

puis redémarrez kubelet après que bebeadm init devrait fonctionner.

c'est ce que j'ai fait

kubeadm réinitialiser

supprimer les entrées ENV de :

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

recharger les services systemd et kube

systemctl démon-recharger
systemctl redémarrer kubelet.service

relancer l'initialisation

kubeadm init

Tout est correct, et tant qu'on y est

Si vous voyez ceci :
kubelet : erreur : échec de l'exécution de Kubelet : échec de création de kubelet : configuration incorrecte : pilote de groupe de contrôle kubelet : "cgroupfs" est différent du pilote de groupe de contrôle de docker : "systemd"

vous devez éditer votre /etc/systemd/system/kubelet.service.d/10-kubeadm.conf et ajouter le drapeau --cgroup-driver="systemd"

et fais comme ci-dessus

réinitialisation de kuebadm
systemctl démon-recharger
systemctl redémarrer kubelet.service
kubeadm init.

Je ferais attention en supprimant --network-plugin=cni des indicateurs CLI de kubelet, cela oblige kubelet à utiliser le plugin no_op par défaut... Je serais surpris si des plugins courants comme calico/weave fonctionneraient même dans ce cas (mais là encore, ma compréhension du fonctionnement de ces plugins en dessous est un peu limitée.)

@kensimon hm, je n'ai vu aucun problème sur ma configuration, j'ai déployé le plugin canal cni et cela a bien fonctionné..

@sbezverk La mise en réseau inter-hôtes fonctionne-t-elle également bien ?

@resouer ne peut pas confirmer, j'ai la 1.6.0 uniquement en tant que tout-en-un.

@resouer @sbezverk J'ai rejoint avec succès une machine.

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

``` [ root@deploy-01 x86_64]# kubectl get pods -n kube-system
NOM ÉTAT PRÊT REDÉMARRAGE ÂGE
etcd-deploy-01 1/1 Course à pied 0 50m
kube-apiserver-deploy-01 1/1 Running 0 51m
kube-controller-manager-deploy-01 1/1 Course à pied 0 50m
kube-dns-3913472980-6plgh 3/3 Course 0 51m
kube-proxy-mbvdh 1/1 Course 0 4m
kube-proxy-rmp36 1/1 Course 0 51m
kube-scheduler-deploy-01 1/1 Course à pied 0 50m
kubernetes-tableau de bord-2396447444-fm8cz 1/1 Course à pied 0 24m
tissage-filet-3t487 2/2 Course à pied 0 44m
tisser-filet-hhcqp 2/2 Running 0 4m

```

la solution de contournement fonctionne mais ne peut pas faire fonctionner la flanelle ...

@stevenbower pire des cas, vous pouvez remettre ce paramètre et redémarrer kubelet lorsque vous avez terminé avec kubeadm business..

J'ai un cluster à trois nœuds avec weave fonctionne. Je ne sais pas à quel point cela pourrait être stable avec ce hack, mais merci quand même! :souriant:

Sur un nœud latéral, vous pouvez remettre le $KUBELET_NETWORK_ARGS, après le passage de l'init sur le maître. En fait, je ne l'ai pas supprimé sur la machine que j'ai rejoint, seulement le pilote de groupe de contrôle, sinon kubelet et docker ne fonctionneront pas ensemble.

Mais vous n'avez pas besoin de réinitialiser kubeadm, changez simplement /etc/systemd/system/kubelet.service.d/10-kubeadm.conf et faites la danse systemctl :

systemctl démon-recharger
systemctl redémarrer kubelet.service

À ceux d'entre vous qui abandonnent KUBELET_NETWORK_ARGS et signalent que cela fonctionne pour vous :

Pour moi, j'ai 2 clusters : un où j'ai appliqué le correctif de https://github.com/kubernetes/kubernetes/pull/43824 et laissé kubeadm procéder normalement à l'initialisation, et un avec KUBELET_NETWORK_ARGS supprimé. Sur le cluster avec KUBELET_NETWORK_ARGS supprimé, tout trafic entre les pods échoue.

Sur un cluster avec KUBELET_NETWORK_ARGS supprimé :

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

Sur un cluster avec KUBELET_NETWORK_ARGS normal mais avec un kubeadm patché :

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

Si vous faites partie de ceux qui ont désactivé KUBELET_NETWORK_ARGS, vérifiez si ce qui précède fonctionne pour vous.

Je suggère que nous laissions tomber à la fois le nœud prêt et le test de déploiement factice
au total pour 1.6 et les déplacer vers une phase de validation pour 1.7.

Le 29 mars 2017 à 10h13, "Dan Williams" [email protected] a écrit :

@jbeda https://github.com/jbeda ouais, ça ressemble au DaemonSet
le contrôleur les mettra toujours en file d'attente principalement parce qu'il est complètement ignorant
du réseau-ness. Nous devrions vraiment résoudre ce problème de manière plus générale. Y a-t-il
quelque chose d'immédiat à faire dans kube ou tout est-il dans kubeadm pour le moment ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

Quelqu'un d'autre utilise Ubuntu 16.04 ? J'ai supprimé le KUBELET_NETWORK_ARGS du service systemd et rechargé le démon systemd . Je peux activer un nœud maître mais je ne peux pas rejoindre un nœud. Il échoue avec l'erreur The requested resource is unavailable

KUBELET_NETWORK_ARGS supprimé, tout trafic entre les pods échoue.

Je ne serais pas surpris puisque KUBELET_NETWORK_ARGS indique à kubelet quel plugin utiliser, où chercher la configuration et les binaires. Vous EN AVEZ BESOIN.

Je recommande le n° 43835 (et le choix de cerise 1.6 n° 43837) comme correctif que nous réalisons pour le 1.6. J'ai testé les deux et ils fonctionnent. J'ai assigné @jbeda et @luxas à revoir quand ils se réveillent.

Ces deux PR semblent raisonnables. Mais je pense que nous devrions plutôt utiliser https://github.com/kubernetes/kubernetes/pull/43824 . Bien que ce soit un peu plus compliqué, cela préserve ce chemin de code afin que les utilisateurs qui préconfigurent CNI en dehors de l'utilisation d'un Daemonset (je le fais dans https://github.com/jbeda/kubeadm-gce-tf bien que je n'aie pas mis à jour à 1.6) attendez toujours que les nœuds soient prêts.

En prime, c'est de première @kensimon PR à Kubernetes et il a retiré les arrêts pour tester ce genre de choses. Mais, pour être honnête, ils sont tous les deux réalisables et je veux vraiment que cela soit corrigé. :)

Désolé j'ai raté https://github.com/kubernetes/kubernetes/pull/43824. Je suis également satisfait de l'un ou l'autre s'ils fonctionnent tous les deux.

Je suis également satisfait de l'un ou l'autre s'ils fonctionnent tous les deux aussi

@kensimon Cela fonctionne pour moi, lorsque je ne désactive KUBELET_NETWORK_ARGS pendant kubadm init . Grâce à vos instructions, j'ai pu vérifier cela.

@webwurst confirmé pour que cela fonctionne lorsque vous ne désactivez que KUBELET_NETWORK_ARGS pendant kubadm init . J'ai dû redémarrer kube-dns pour qu'il le récupère. Le chèque de @kensimon fonctionne, dns résout.

Bien que je convienne que c'est un hack terrible, et trop horrible pour la plupart des gens à suivre, en regardant les canaux slack.

Une meilleure solution est présentée par les correctifs de @kensimon ou @mikedanese.

@coeki comment exactement avez-vous redémarré kube-dns. J'ai essayé kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system et maintenant kube-dns reste en attente kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
Il a fait exactement comme décrit : supprimez KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , ajoutez KUBELET_NETWORK_ARGS , encore sudo systemctl daemon-reload && sudo systemctl restart kubelet.service fois
Mais mon maître reste dans NotReady . En describe je reçois

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

J'ai essayé le redémarrage de kube-dns comme décrit ci-dessus, mais sans succès. Une idée? Je meurs d'envie d'essayer de relancer notre cluster après l'échec de la mise à niveau 1.6.0 de ce morging :(

@patte Donc je viens de delete pods kube-dns-3913472980-3ljfx -n kube-system Et puis kube-dns revient.

Après kubeadm init, avez-vous ajouté KUBELET_NETWORK_ARGS , encore sudo systemctl daemon-reload && sudo systemctl restart kubelet.service fois

J'ai essayé et testé sur centos7 et je viens de le faire sur ubuntu/xenial, donc ça devrait fonctionner.

Pour récapituler ce que j'ai fait :

supprimer KUBELET_NETWORK_ARGS
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

ajouter à nouveau KUBELET_NETWORK_ARGS
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

Rejoint une machine, je dois généralement ajouter une route statique à 10.96.0.0 (cluster ip) car je suis sur vagrant.
A utiliser avec le $TOKEN, mais cette étape est en sus.

Puis:

delete pods kube-dns-3913472980-3ljfx -n kube-system

Attends-le

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

Fonctionne pour moi, même si c'est un hack horrible ;)

Je suis vraiment surpris que la communauté de développement de Kubernetes n'ait fourni aucun ETA pour un correctif officiel. Je veux dire qu'il s'agit d'un bug horrible qui devrait être facilement détecté lors des tests de code. Comme ce n'est pas le cas, à tout le moins, la 1.6.1 devrait être poussée dès que possible avec le correctif afin que les gens arrêtent de pirater leurs clusters et commencent à faire des choses productives ;). Est-ce que je me trompe ici ?

Salut à tous,

J'étais un peu distrait cette semaine, et c'est un long fil plein de
des trucs de kubeadm que je ne connais pas bien. Quelqu'un peut-il me résumer ? je
pense avoir compris l'essentiel du bug, mais quelles sont les solutions proposées et
qu'est-ce qui les rend horribles ?

Le jeu. 30 mars 2017 à 8h13, Serguei Bezverkhi < [email protected]

a écrit:

Je suis vraiment surpris que la communauté de développement de Kubernetes n'ait pas
fourni un ETA pour un correctif officiel. Je veux dire que c'est un bug horrible qui
devrait être facilement attrapé lors des tests de code. Comme il ne l'a pas fait, à
à tout le moins, 1.6.1 devrait être poussé dès que possible avec le correctif afin que les gens
arrêtez de pirater leurs clusters et commencez à faire des choses productives ;). Suis-je
mal ici?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

Un changement dans kubelet (#43474) a fait que kubelet a commencé à signaler correctement que le réseau n'était pas prêt avant l'initialisation du plug-in cni. Cela a brisé certains ordres dont nous dépendions et a provoqué un blocage dans l'initialisation du maître kubeadm. Nous ne l'avons pas compris car les tests kubeadm e2e avaient été interrompus pendant quelques jours avant ce changement.

Les correctifs actuellement proposés sont les 43824 et 43835.

ok, c'est ce que j'ai compris. L'interverrouillage entre le plugin réseau
à venir et la préparation des nœuds est un peu horrible en ce moment.

Le jeu. 30 mars 2017 à 8h28, Mike Danese [email protected]
a écrit:

Un changement de kubelet (#43474
https://github.com/kubernetes/kubernetes/pull/43474 ) a causé kubelet à
commencer correctement à signaler que le réseau n'est pas prêt avant que le plug-in cni ne soit
initialisé. Cela a brisé certains ordres dont nous dépendions et a causé
un blocage dans l'initialisation du maître kubeadm. Nous ne l'avons pas attrapé parce que
Les tests kubeadm e2e avaient été interrompus pendant quelques jours avant ce changement.

Les correctifs proposés actuellement sont le n° 43824
https://github.com/kubernetes/kubernetes/pull/43824 et #43835
https://github.com/kubernetes/kubernetes/pull/43835 .

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

Je préfère toujours le #43835. C'est un changement plus simple, je ne pense pas que les contrôles e2e devraient être effectués là où ils se trouvent, et il y a des rapports de #43824 qui ne fonctionnent toujours pas. Je vais faire pression pour que cela soit résolu aujourd'hui.

+1 pour le résoudre aujourd'hui, car de nombreux efforts sont gaspillés pour traiter les garanties de la solution de contournement.

Je ne peux pas croire que personne n'ait vraiment essayé kubeadm 1.6.0 avant la sortie de la 1.6.0...

Et, kubelet 1.5.6 + kubeadm 1.5.6 sont également cassés, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf fait référence à /etc/kubernetes/pki/ca.crt mais kubeadm ne génère pas ca.crt, il y a bien ca.pem.

Actuellement, les versions 1.6.0 et 1.5.6 sont les seules versions restantes du référentiel k8s apt...

"sorti des sentiers battus", mots appris aujourd'hui.

Je préfère toujours le #43835. C'est un changement plus simple, je ne pense pas que les contrôles e2e devraient être effectués là où ils se trouvent, et il y a des rapports de #43824 qui ne fonctionnent toujours pas. Je vais faire pression pour que cela soit résolu aujourd'hui.

D'accord avec Mike sur celui-ci. #43835 est le changement le plus simple, et la validation (si nécessaire) peut être effectuée dans une phase distincte.

@thockin, nous avons vraiment besoin de conditions et de statuts plus précis pour la mise en réseau, en particulier avec ho stNetwork:true. Les nœuds peuvent être prêts pour certains pods, mais pas pour d'autres.

Nous ne pouvons pas utiliser nodeNetworkUnavailable, car c'est spécifique aux fournisseurs de cloud. Nous en avons probablement besoin d'un autre, ou d'un moyen pour le planificateur d'autoriser les pods hostNetwork:true sur les nœuds avec Net workReady:false , ou de faire fonctionner les taches pour les nœuds non prêts. Et les tests kubeadm e2e fonctionnels :(

Se mettre d'accord. J'ai retardé le problème parce que je n'avais pas de bonnes réponses,
mais nous devons obtenir cela en 1.7

Le jeu. 30 mars 2017 à 10h02, Dan Williams [email protected]
a écrit:

@thockin https://github.com/thockin nous avons vraiment besoin d'un grain plus fin
conditions et statut de la mise en réseau, en particulier avec hostNetwork:true.
Les nœuds peuvent être prêts pour certains pods, mais pas pour d'autres.

Nous ne pouvons pas utiliser nodeNetworkUnavailable, car c'est spécifique au cloud
fournisseurs. Nous en avons probablement besoin d'un autre, ou d'un moyen pour le planificateur de
autoriser les pods ho workReady:false , ou faire le
les rejets fonctionnent pour les nœuds non prêts.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin une solution préférée? Nous pouvons soit bloquer la préparation des nœuds et découvrir qui utilise IsNodeReady() comme nous l'avons déjà fait, soit ajouter une autre condition de nœud, puis corriger qui sait combien de bits de la base de code ailleurs pour cela. Ou peut-être y a-t-il une autre option.

Nous ne pouvons pas utiliser nodeNetworkUnavailable, car c'est spécifique aux fournisseurs de cloud. Nous en avons probablement besoin d'un autre, ou d'un moyen pour le planificateur d'autoriser les pods hostNetwork:true sur les nœuds avec Net workReady:false , ou de faire fonctionner les taches pour les nœuds non prêts.

Je pense que le planificateur peut être corrigé pour respecter les altérations et les tolérances, au lieu d'exclure complètement tous les nœuds non prêts.
Quelqu'un devra cependant appliquer la tolérance sur les pods hostNetwork:true . Je ne sais pas qui, mais cela ne devrait pas être le planificateur, car enseigner au planificateur à comprendre les spécifications du pod semble beaucoup trop.

/cc @davidopp @dchen1107

De plus, pour tous ceux qui ont essayé les correctifs de my ou de michael et qui se bloquent sur le plan de contrôle à venir, il semble que la construction d'un kubeadm à partir de master ne fonctionne pas lorsqu'il gère un cluster v1.6.0 , en raison de kubeadm essayant de lancer kube-apiserver avec des arguments non valides :

unknown flag: --proxy-client-cert-file

Si vous souhaitez tester les modifications de michael ou de michael par rapport à un cluster v1.6.0, sélectionnez-les par rapport à la v1.6.0 au lieu de les construire sur master pour le moment.

@yujuhong le planificateur applique déjà automatiquement les tolérances aux pods (voir https://github.com/kubernetes/kubernetes/pull/41414), cela semble être un cas d'utilisation assez similaire

Je n'ai pas une image claire de tous les défauts et de l'état de préparation en ce qui concerne
réseau, à ce stade. Dan, as-tu une demi-heure pour rédiger le
l'état actuel, afin que nous puissions commencer à le dissocier ? je pense que tu le sais
meilleur. J'ai l'impression que nous avons un certain nombre de problèmes granulaires que nous venons de
couvert de couverture jusqu'à présent.

Le jeu. 30 mars 2017 à 10h22, Ken Simon [email protected]
a écrit:

@yujuhong https://github.com/yujuhong le planificateur déjà
applique automatiquement les tolérances aux pods (voir #41414
https://github.com/kubernetes/kubernetes/pull/41414 ), cela ressemble à un
cas d'utilisation assez similaire

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin je peux faire ça, où dois-je le mettre ?

il y a quelques problèmes liés, pouvons-nous retitrer l'un d'entre eux, poster un
résumé de l'état actuel et partir de là ?

Le jeu. 30 mars 2017 à 10h50, Dan Williams [email protected]
a écrit:

@thockin https://github.com/thockin Je peux le faire, où dois-je mettre
ce?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
.

Avons-nous une ligne à tout moment pour savoir quand ce correctif sera porté sur le référentiel CentOS ?

Dans la version 1.6, par défaut, le noyau Kubernetes n'applique automatiquement aucune altération aux nœuds. Le planificateur respecte les rejets ajoutés par les systèmes de déploiement tels que kubeadm, kops, etc. ou ajoutés manuellement par les utilisateurs (et respecte les tolérances correspondantes ajoutées aux pods).

Dans 1.6, par défaut, le planificateur Kubernetes exclut les nœuds de la considération s'ils signalent certaines conditions de nœud, y compris le réseau indisponible. Le code pour cela est ici . Cela n'a rien à voir avec les altérations - il s'agit simplement de regarder l'état du nœud.

Dans 1.6, vous pouvez activer une fonctionnalité alpha qui amène le noyau Kubernetes (le NodeController) à ajouter une teinte NoExecute chaque fois qu'il y a NodeReady == "False" ou NodeReady == "Unknown". Cela entraînera l'expulsion des pods exécutés sur le nœud (s'ils ne tolèrent pas la contamination) et empêchera de nouveaux pods de se programmer sur le nœud (s'ils ne tolèrent pas la contamination).

Le plan à long terme est de déplacer toute la logique « comment le noyau Kubernetes réagit aux conditions des nœuds, en ce qui concerne la planification et l'éviction » pour utiliser les altérations et les tolérances (par exemple, n° 42001). Mais nous n'en sommes pas encore là et ne le serons pas avant un moment. Donc, à court terme, il n'y a aucun moyen pour un pod de « tolérer » NetworkUnavailable ou toute autre condition de nœud que vous pourriez décider d'ajouter.

Si je comprends bien ce que @davidopp a dit, alors la fonction est NodeReady, qui renvoie maintenant vrai ou faux ou inconnu, coche une liste avec ce qui est nécessaire. S'il peut renvoyer une liste de valeurs non satisfaites, vous pouvez effectuer un test par rapport à cela.

Dans le cas de kubeadm, if then NetworkUnavailable, est le seul. kubeadm peut retourner vrai. C'est dans le cas où nous ne voulons pas que le plugin networking/cni soit transmis au moment de l'initialisation de kubeadm.

Parce que si je comprends bien, l'altération et la tolérance sont définies en fonction de cette fonction, au moins pour kubeadm.

Corrige moi si je me trompe ;)

Je saute sur ce fil parce que j'ai rencontré ce problème et c'est ennuyeux:

Pourquoi la préparation du réseau ne peut-elle pas devenir une souillure que le kubelet ajoute et supprime en fonction de l'état du réseau sur le nœud ?
De cette façon, le nœud peut être « Prêt » pour tous les pods qui tolèrent la teinte de préparation du réseau (applications de réseau de pods).

En ce qui concerne les pods du réseau hôte, un contrôleur d'admission pourrait injecter des tolérances à l'état de préparation du réseau des pods.

Je pense que cela correspond au plan à long terme du commentaire de Davidopp.

Je pense que cela correspond au plan à long terme du commentaire de Davidopp.

Oui, exactement. Le plan à long terme est d'avoir une tache pour chaque condition de nœud et d'arrêter d'avoir quoi que ce soit d'interne dans Kubernetes, prêter attention aux conditions de nœud. Nous avons commencé ce travail avec la fonctionnalité 1.6 alpha que j'ai mentionnée.

Ac. Y a-t-il une raison de ne pas passer aux rejets dans la version 1.6 ?

Le code permettant d'ajouter automatiquement des rejets en fonction des conditions des nœuds vient d'être mis en alpha dans la version 1.6. Il n'est pas prêt à être invoqué. (Et il ne gère actuellement que la condition de nœud prêt, pas le réseau).

Donc, si je comprends bien, pour l'instant, puisque https://github.com/kubernetes/features/issues/166 prend un peu plus de temps pour pouvoir entacher correctement la disponibilité du réseau, nous devons contourner le problème. Si nous pouvons pousser un correctif dès que possible pour kubeadm, comme #43835, avec un commentaire pour résoudre ce problème avec https://github.com/kubernetes/features/issues/166 , beaucoup de gens seront heureux.

@davidopp, je suppose que vous vouliez dire " pas invoqué ". Il me manque toujours la relation entre la condition automatique et la logique de souillure que vous avez mentionnée avec la publication des souillures de kubelet directement pour les problèmes de réseau.

Oui merci, c'était une faute de frappe, corrigé maintenant

Oui, vous pourriez demander à Kubelet d'ajouter la souillure. Il n'est peut-être pas idéal que Kubelet ajoute les altérations pour certaines conditions de nœud et que NodeController les ajoute pour d'autres conditions de nœud (cette dernière est nécessaire car seul le maître peut détecter un nœud inaccessible), mais ce n'est qu'un argument d'ingénierie logicielle, rien de fondamental. Mon plan était que NodeController ajoute les altérations pour toutes les conditions de nœud, mais il n'y a aucune exigence forte pour le faire de cette façon.

Ac. Dans ce cas, une seule condition de nœud a plusieurs attributs qui lui sont associés que le contrôleur de nœud peut ne pas être en mesure de discerner.
@mikedanese Je pense que le comportement existant de kubeadm init résultant en un nœud fonctionnel est attrayant. J'espère que l'exigence d'ajouter une phase validation n'est pas principalement motivée par ce problème.
@dcbw @thockin @yujuhong avez- vous des idées sur l'utilisation des rejets pour représenter les problèmes de configuration des nœuds dans le kubelet ?

Notez que si vous souhaitez que votre nouveau rejet remplace le filtrage automatique actuel des nœuds avec NetworkUnavailable, vous devrez modifier la fonction que j'ai mentionnée précédemment (c'est-à-dire la supprimer de l'ensemble des conditions qui filtrent un nœud). Je ne sais pas quels autres effets secondaires cela aura, car cette fonction peut être utilisée dans des listes de nœuds autres que le simple planificateur.

Existe-t-il un moyen d'installer la 1.5.6 qui devrait fonctionner sur Ubuntu ? S'il y en a, pouvez-vous expliquer comment faire ? Merci!

Notez que si vous souhaitez que votre nouveau rejet remplace le filtrage automatique actuel des nœuds avec NetworkUnavailable, vous devrez modifier la fonction que j'ai mentionnée précédemment (c'est-à-dire la supprimer de l'ensemble des conditions qui filtrent un nœud). Je ne sais pas quels autres effets secondaires cela aura, car cette fonction peut être utilisée dans des listes de nœuds autres que le simple planificateur.

@davidopp, nous devons faire attention à NetworkUnavailable vs. NodeReady. Il y a deux conditions distinctes qui devraient vraiment être nettoyées :

nodeNetworkUnavailable - ceci est spécifique aux routes cloud, et seuls les contrôleurs de route cloud effacent cette condition lorsque les routes cloud entre les nœuds ont été configurées. Les plugins réseau qui créent des superpositions ou qui ne font pas de routage L3 entre les nœuds ne veulent pas ou n'utilisent pas cette condition. Cette condition n'est ajoutée par aucun plugin réseau ; il est ajouté par kubelet spécifiquement lorsque GCE ou AWS sont sélectionnés comme fournisseurs de cloud. N'affecte pas NodeReady car il s'agit d'une condition distincte.

NodeReady - affecté directement par les plugins réseau (par exemple, CNI ou kubenet ou les runtimes distants comme dockershim/CRI-O).

Il y a trois questions distinctes à considérer :

1. Routes cloud : si l'infrastructure cloud et le plug-in réseau nécessitent des routes cloud, le manque de routes cloud (par exemple, NodeNetworkUnavailable=true) doit bloquer la planification des pods hostNetwork=false
2. Plugins réseau - si le plugin n'est pas encore prêt, cela doit bloquer la planification des pods hostNetwork=false. Ceci est distinct de NodeNetworkUnavailable car le plug-in peut n'avoir aucune interaction directe avec un contrôleur de routes car il ne dépend pas des routes cloud. Par exemple, kubenet peut être utilisé localement sur le nœud si vous avez autre chose (routes cloud, flanelle, etc.) configuré pour les routes de nœud.
3. hostNetwork=true les pods doivent ignorer toutes ces conditions et être planifiés, mais soumis à toute autre condition applicable (espace disque, etc.)

NodeReady est tout simplement trop gros comme un marteau. Je pense que nous voulons probablement une condition NetworkPluginReady supplémentaire pour la préparation du plugin réseau (séparée de la préparation des routes cloud !)

Un autre travail autour que j'ai trouvé.

Alors que kubeadm continue d'imprimer '[apiclient] Le premier nœud s'est enregistré, mais n'est pas encore prêt', j'ai déployé 'kube-flanel.yml' qui installe flanneld. Et cela a fonctionné sans modifier les fichiers de configuration.

1) kubeadm init --pod-network-cidr=10.244.0.0/16 &
2) cp /etc/kubernetes/admin.conf ~/.kube/config
3) kubectl applique -f kube-flanel-rbac.yml (nécessaire dans kubeadm 1.6)
4) kubectl applique -f kube-flanel.yaml
Utilisez kube-flannel.yaml dans https://github.com/coreos/flanel/blob/master/Documentation/kube-flannel.yml

Je pourrais rendre le nœud maître « Prêt ». Mais, kube-dns a échoué avec le message,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

Après avoir changé le plug-in réseau en weave-net, cela a fonctionné.

@dcbw Je ne connais pas assez le problème spécifique abordé dans ce numéro pour vous dire exactement quoi faire. Je voulais juste expliquer l'état actuel des souillures et comment elles pourraient s'appliquer ici.

VEUILLEZ TESTER LES DEBS PATCHES

Le kubernetes-xenial-unstable maintenant une version corrigée 1.6.1-beta.0.5+d8a384c1c5e35d-00 que @pipejakob et moi avons testée aujourd'hui. Les nœuds ne restent pas prêts jusqu'à ce qu'un réseau de pods soit créé (par exemple en appliquant des configurations de tissage/flanelle). Réussite du test de conformité. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

Est-ce la direction générale que les souillures peuvent exprimer à peu près tout
les conditions peuvent et sont donc meilleures à tous égards ?

Je suis d'accord que nous avons besoin d'un signal plus granulaire. Nous devons encore régler le
interaction entre kubelet, pilote net, contrôleur de cloud et fournisseur de cloud
pour déverrouiller les pods hostNetwork=false, mais hostNetwork=true ne devrait pas être
bloqué.

Le jeu. 30 mars 2017 à 19:24, Dan Williams [email protected]
a écrit:

Notez que si vous voulez que votre nouvelle empreinte remplace l'automatique actuel
filtrage des nœuds avec NetworkUnavailable, vous devrez modifier le
fonction que j'ai mentionnée plus tôt (c'est-à-dire la supprimer de l'ensemble de conditions
qui filtrent un nœud). Je ne sais pas quels autres effets secondaires
ont, puisque cette fonction peut être utilisée dans des listes de nœuds autres que simplement le
planificateur.

@davidopp https://github.com/davidopp nous devons faire attention
NetworkUnavailable vs. NodeReady. Il y a deux conditions distinctes qui
devrait vraiment être nettoyé:

nodeNetworkUnavailable - ceci est spécifique aux routes cloud, et uniquement au cloud
les contrôleurs de route effacent cette condition lorsque les routes cloud entre les nœuds ont
été mis en place. Plugins réseau qui créent des superpositions ou qui ne font pas L3
le routage entre les nœuds ne veut pas ou n'utilise pas cette condition. Cette condition est
non ajouté par aucun plug-in réseau ; il est ajouté par kubelet spécifiquement lorsque
GCE ou AWS sont sélectionnés comme fournisseurs de cloud. N'affecte pas NodeReady depuis
c'est une condition distincte.

NodeReady - affecté directement par les plugins réseau (par exemple, CNI ou kubenet
ou des runtimes distants comme dockershim/CRI-O).

Il y a trois questions distinctes à considérer :

1. Cloud Routes - si l'infrastructure cloud et le plug-in réseau
   nécessitent des routes cloud, puis le manque de routes cloud (par exemple,
   NodeNetworkUnavailable=true) doit bloquer la planification hostNetwork=false
   gousses
2. Plugins réseau - si le plugin n'est pas encore prêt, cela doit
   planification de bloc de hostNetwork=false pods
3. hostNetwork=true les pods doivent ignorer toutes ces conditions et être
   programmé, mais sous réserve de toutes autres conditions applicables (espace disque, etc.)

NodeReady est tout simplement trop gros comme un marteau. Je pense que nous voulons probablement un
condition supplémentaire NetworkPluginReady pour la préparation du plug-in réseau
(séparé de la préparation des routes cloud !)
jusqu'à des endroits qui se soucient :(

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

Pour tous ceux qui essaient encore le correctif temporaire en supprimant la ligne de configuration kubelet KUBELET_NETWORK_ARGS, @jc1arke a trouvé une solution de contournement plus simple - ayez deux sessions avec le nouveau maître et, en attendant que le premier nœud soit prêt, appliquez une configuration nœud-réseau dans le second session:
Première session après l'exécution de kubeadmin init :

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[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
...

Deuxième séance (avec Calico. Votre choix peut bien entendu varier) :

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

Retour à la première séance :

...
[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 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

Est-ce la direction générale que les souillures peuvent exprimer à peu près tout
les conditions peuvent et sont donc meilleures à tous égards ?

Plutôt. Nous ne pouvons probablement pas nous débarrasser des conditions de nœud en raison de problèmes de compatibilité descendante, mais nous pouvons nous débarrasser de toute la logique du maître qui prend des mesures en fonction de celles-ci (comme le blocage de la planification ou l'expulsion des pods). En plus de rendre le comportement plus évident (pas besoin de mémoriser quelles conditions bloquent la planification, qui provoquent l'expulsion, combien de temps nous attendons pour l'expulsion, etc.), la réaction aux conditions est configurable sur une base par pod.

Je viens de tester les debs de @mikedanese et @pipejakob , ils fonctionnent bien.

Testé sur ubuntu/xenial :

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Je viens de tester les debs de @mikedanese et @pipejakob , il gèle toujours à
[apiclient] Created API client, waiting for the control plane to become ready

J'ai attendu environ cinq minutes, mais rien n'a changé.
Et hier ça se répétait
[apiclient] First node has registered, but is not ready yet

TTI pense que le problème n'est toujours pas une solution?

Testé sur Ubuntu 16.04 :
kubeadm version : version.Info{Major : "1", Minor : "6+", GitVersion :"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f"201764", GitTree", BuildDate:"clean:" -03-31T04:20:36Z", GoVersion:"go1.7.5", Compilateur:"gc", Plate-forme:"linux/amd64"}

@myqq0000 pouvez-vous publier la version que vous utilisez ?

kubeadm version

@coeki Oh, je l'oublie. J'ai édité tout à l'heure et poste la version dans mon commentaire précédent. :)

@mikedanese Avez-vous l'intention de mettre à jour centos yum repo ? Ou est-il déjà déployé sur yum repo ?

Je viens d'essayer 1.6.1-beta.0.5+d8a384c1c5e35d-00 (le 1.6.1-beta.0.5+48c6a53cf4ff7d-00 mentionné dans https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036 ne semble pas exister).

Cela semble marcher correctement.
Sans rapport : notez que si vous utilisez weave, vous devez appliquer https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml au lieu du https « par défaut »

@mausch Pourriez-vous me dire comment obtenir ces debs ?

@srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

Les debs patchés

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch Merci. Ils travaillent aussi pour moi avec le fournisseur de réseau Weave.

Avez-vous également la possibilité de créer le même correctif pour Centos ? Notre système de portes utilise principalement des centos pour la base de cluster kubernetes. Si j'ai la version centos, je peux garantir env. 100 exécutions de kubeadm init par jour en tant que test.

Les debs patchés kubeadm indique que le cluster est prêt, mais pas le nœud lui-même.

Les nœuds kubectl apply -f https://git.io/weave-kube-1.6

Dans mon environnement de test (dans vagrant, basé sur des machines centos/7), kubeadm se bloque. En utilisant strace, je peux le voir essayer de se connecter au serveur kubelet sur le maître et faire FUTEX_WAIT, epoll_wait retry boucles. Mais il n'y a pas une seule ligne de sortie qui en sort.

kubelet ne démarre pas, ce qui semble être la raison.
(Mais je ne vois pas pourquoi kublet ne démarre pas..)

Est-ce le problème de cette question?

Je reçois des binaires du dépôt http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 .
J'essaie également de mettre à jour les binaires à partir de https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ .

==> Où puis-je obtenir une version corrigée de kubeadm pour la tester ? <==

Remarque : j'ai trouvé une version corrigée (réclamée) de kubeadm référencée dans ce numéro à l' adresse https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (la version corrigée est la suivante : https://heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), mais cela ne fonctionne pas pour moi. Le comportement est toujours le même (aucune sortie que ce soit)...

@squall0gd Pouvez-vous nous montrer le message exact que vous voyez ? D'après ce que vous décrivez, je me demande si vous avez réellement récupéré les nouveaux fichiers .deb ou si vous utilisiez d'anciennes versions en cache.

@thockin @davidopp donc, selon la suggestion de Tim, je vais réquisitionner un problème existant ou en déposer un nouveau pour suivre les conditions de préparation du réseau de démêlage et les convertir tous en altérations au lieu de conditions réelles, et copier dans la plupart des https://github. com/kubernetes/kubernetes/issues/43815#issuecomment -290597988 dans celui-ci.

Voici ce qui semble fonctionner pour moi avec le unstable (testé uniquement le maître lui-même) :

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

Cela crache error: taint "dedicated:" not found à un moment donné, mais cela semble continuer malgré tout.

N'exécute-t-on pas ces tests sur la branche 1.6 ?

Les conditions

kubeadm ne semble pas avoir été testé sur la branche release :
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 apparemment, les tests kubeadm e2e ont été désactivés/non fonctionnels pendant environ une semaine avant la version 1.6, IIRC

Les conditions de nœud sont destinées à fournir des informations supplémentaires aux humains, pour comprendre ce qui se passe, comme la raison, le message et le temps de transition.

@ bgrant0607 sont-ils principalement destinés aux informations humaines, ou s'agit-il simplement d'un effet secondaire heureux ? Si principalement pour les humains, devraient-ils être utilisés pour planifier les décisions comme ils le sont actuellement ou devrions-nous nous en éloigner ?

@dcbw Les Taints sont destinés à devenir le GUT de l'imprévisibilité et des perturbations. Finalement, le planificateur doit ignorer les conditions.

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment-169220144
https://github.com/kubernetes/kubernetes/issues/29178

Notez que si nous allons ajouter une teinte aux nœuds, nous devons considérer

a) Rétrocompatibilité, comme avec le master taint : https://github.com/kubernetes/kubernetes/pull/43537

b) Variation de version. Lors de la mise à niveau des clusters vers la 1.6, les kubelets seront des versions mixtes, et certaines peuvent être aussi anciennes que la 1.4.

donc pour récapituler ou comme j'analyse ceci:

basé sur @dcbw

nodeNetworkUnavailable est un fournisseur de cloud, non lié à kubeadm atm, nous pourrions rencontrer cela.

Mais NodeReady, qui est la cause première de la boucle, doit être plus granulaire. C'est ce que @davidopp veut être une souillure, basée sur une liste qui coche des cases, en ce qui concerne la sonde / la vivacité, la préparation CNI, etc.

bien, bien que vous puissiez discuter, pourquoi ne pas étiqueter?

Mais @dcbw avez-vous trouvé un fil plus adapté à cette discussion ? Parce que celui-ci devient un seau pour les problèmes de déploiement et pas vraiment la racine des choses.

Je sais, je faisais partie du fait de ne pas vraiment aborder le problème et de poster des hacks autour :)

Mais de toute façon, nous devrions discuter des principes fondamentaux à un autre endroit, nous assurer qu'un ETA sur correctif est placé ici, et passer à autre chose.

Pas accrocheur, mais bon :)

PS oui @ bgrant0607 nous aurions dû tester cela plus
PS2 Si je vois mal, vous pouvez m'en vouloir ;)

@coeki J'ajouterais également une demande pour que les versions N-1 soient conservées dans les

@ kfox1111 gating est aussi un problème... nous avons besoin d'une meilleure stratégie à ce sujet :)

Pourquoi même supprimer les anciennes versions ? Cela pourrait facilement briser l'automatisation des personnes et empêcher les installations répétables.

Les conditions de nœud sont destinées à fournir des informations supplémentaires aux humains, pour comprendre ce qui se passe, comme la raison, le message et le temps de transition.

D'accord. L'UX est certainement l'une des principales raisons pour lesquelles nous ne pouvons probablement pas nous débarrasser des conditions de nœud. Cependant, je pense que nous pouvons nous débarrasser de toutes les utilisations des conditions de nœud en tant que déclencheur d'actions principales (comme l'expulsion et la planification de blocage) et utiliser des altérations pour cela à la place.

À long terme (comme l'API v2 à long terme), il est concevable que nous puissions ajouter une raison et un message aux rejets, puis nous débarrasser des conditions de nœud, mais je n'y ai pas vraiment pensé et je ne propose certainement pas formellement de le faire. (Nous avons déjà l'équivalent du temps de transition dans un sens, à savoir TimeAdded.)

@coeki non, ce dont je parlais n'a rien à voir avec le gate. Le gate ne peut pas trouver tous les problèmes à moins que vous n'ayez un gate qui teste tout ce qui pourrait être fait. Les opérateurs aiment faire des choses étranges dans leurs environnements. :) Coût prohibitif pour tester tout ce qui est possible.

Je demande de ne pas supprimer l'ancienne version avant que la nouvelle n'ait atteint au moins la première version de correction de bogues. Pour cet exemple, 1.6.1. Au minimum. Conserver des versions plus anciennes est encore mieux. Il s'agit d'une bonne pratique pour permettre aux opérateurs de continuer à progresser pendant que les bogues de la nouvelle version sont corrigés.

@ kfox1111 , c'est ce que fait le

@davidopp Je suis d'accord pour dire que les étiquettes et les altérations peuvent avoir une distinction différente d'une manière api de les voir, UX et machines, mais bon, c'est diffus en ce moment. Moi aussi, c'est :)

Quoi qu'il en soit, vous m'attirez dans une discussion, nous n'avons vraiment pas à avoir dans cette question, c'était mon point.

J'aimerais demander à nouveau : si je vois « kubeadm init » simplement suspendu sans sortie (en essayant de se connecter au serveur kubelet, qui n'a pas pu démarrer), est-ce que je souffre de ce problème ? Et si c'est un cas, le n°43835 est-il un correctif pour moi ?

Maintenant, où puis-je obtenir :

• soit des versions plus anciennes (pré 1.6.0) de kubeadm / kubectl / kubelet
• ou une version corrigée de kubeadm (y compris #43835 ou tout autre correctif) ?

Merci!

(remarque : la version corrigée de kubeadm référencée dans le commit mentionné ci-dessus ne fonctionne pas pour moi...)

@obnoxxx essayez le bout de la branche release-1.6.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese merci ! en essayant...

Si vous exécutez kubeadm sans installer le package os, vous devez

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

de https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

@mikedanese merci. J'installe le package os (à partir du référentiel kube), puis j'installe les binaires à partir de l'URL Web sur les binaires des rpms...

la version 1.6.1-beta.0.12 n'a pas fonctionné pour moi cependant :
kubeadm init se bloque toujours sans aucune sortie. (j'essaye de me connecter à kubelet)

N'oubliez pas non plus le pilote systemd si centos.

pilote système ?

https://github.com/kubernetes/release/issues/306

mon Dieu, merci, c'est mieux ! :-)

@pipejakob Je n'ai pas accès à ces journaux pour le moment, mais j'ai vérifié la version de kubeadm et c'était la même version que @webwurst . De plus, j'ai vérifié les versions possibles de kubeadm avec apt-cache policy kubeadm . Et il n'y avait qu'une seule entrée - de kubernetes-xenial-unstable.
@mikedanese j'ai essayé avec de la flanelle avant de poster ;)
EDIT : j'ai reconstruit toute la plate-forme et kubadm fonctionne bien :+1 :

Les gars, quel est le statu quo pour le correctif ? va-t-il bientôt passer au référentiel stable ?

Les debs patchés

Quelqu'un peut-il me dire comment créer une version corrigée de kubeadm pour rhel (rpm) ?

@mikedanese avec

Le nœud maître est dans NotReady .

Le weave-net (weaveworks/weave-kube:1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) est en 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

Le pod kube-dns est dans 0/3 Pending .

@ChipmunkV Vous devez probablement configurer kube-proxy pour qu'il s'exécute dans l'espace utilisateur. Cela a également été un problème dans la 1.5.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

Pour ce que ça vaut, kubernetes-xenial-unstable fonctionne bien pour moi.

@pstadler , grâce à @errordeveloper dans le chat qui a souligné que j'ai des réseaux qui se chevauchent, j'ai reconfiguré le IPALLOC_RANGE dans le tissage.

Merci @thenayr. Je pourrais afficher le maître Kubernetes, mais je pourrais également y connecter un travailleur à l'aide de kubeadm join. Publiera bientôt plus de mises à jour

@mikedanese, il m'a fallu une éternité pour savoir quelle version utiliser, jusqu'à ce que je lis tous les commentaires ici. Nous devons vraiment rendre beaucoup plus facile la recherche de binaires pour une version donnée. J'ai essayé d'utiliser ce que les points ci-cross/latest.txt (à savoir v1.7.0-alpha.0.1982+70684584beeb0c ), et cela a introduit un nouveau drapeau kube-apiserver (à savoir --proxy-client-key-file dans d8be13fee85075abfc087632b3dbc586a10897ad), qui ne fonctionne avec aucune des balises récentes dans gcr.io/google_containers/kube-apiserver-amd64 ...

Comment pouvons-nous faciliter l'identification des révisions qui contiennent des binaires ? Être capable de répertorier les répertoires serait bien, ou d'avoir un simple fichier de carte ou tout ce qui ne nécessite pas d'avoir à savoir ou à deviner.

@errordeveloper, nous essayons de faire une version afin que nous puissions envoyer un correctif à la branche stable, cela devrait être fait dans O (jours) j'espère. Il y a un lien dans la description de ce problème vers les debs corrigés dans unstable.

La version précédente 1.5.6 fonctionnait pour moi sur CentOs 7, mais maintenant je ne peux même plus revenir en arrière car la seule version de kubeadm dans http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 est la 1.6 cassée. 0. Des suggestions sur la façon d'obtenir kubeadm 1.5.6 RPM ?

En effet, c'est dommage. Les anciennes versions semblent avoir été entièrement supprimées. :-(

Mes résultats sont ceux-ci sur centos 7 :

• Je n'ai pas réussi à obtenir de Kubadm init pour me donner aucun résultat, même avec un dernier kubeadm patché, sans faire quelque chose à propos de kubectl.
• J'ai pu démarrer kubectl avec les instructions de @coeki , puis kubeadm a même réussi. Mais après ça, plus rien ne fonctionne pour moi. kubectl dit

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Un indice sur ce qui se passe ?

@obnoxxx par défaut apiserver n'écoute pas sur 8080, il écoute sur le port sécurisé 6443, vous pouvez vérifier avec netstat -tunlp.
Vous devez copier admin.conf de /etc/kubernetes vers vous $HOME/.kube/config
assurez-vous de modifier les autorisations sur le fichier dans votre $HOME/.kube/, après cela, votre kubectl devrait pouvoir contacter correctement apiserver. HTH. Sergueï

@apsinha Connaissez -vous ce fil? Il serait peut-être bon d'avoir des spécialistes du produit, car je pense qu'il y aura des choses importantes à retenir pour l'avenir.

Du haut de ma tête:

• 1.6.0 n'a jamais fait l'objet de tests automatisés : https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• Les binaires/paquets des anciennes versions ont été supprimés, de sorte que les utilisateurs ne peuvent pas revenir en arrière en toute sécurité ; a cassé toute automatisation d'installation qui supposait qu'ils étaient toujours disponibles : https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• Aucune annonce publique (que j'ai vu) du fait que cela est cassé
• Aucune chronologie donnée sur un correctif (je suis un développeur, donc je sais à quel point il est odieux de demander "quand sera-t-il corrigé ?", mais néanmoins, les gens le demanderont, il est donc bon d'offrir au moins une période de temps estimée)
• Les utilisateurs continuent de se joindre à la conversation confus au sujet de l'état des choses, des solutions de contournement et du calendrier de correction
• Beaucoup de discussions techniques entre les contributeurs, dont beaucoup portent sur la stratégie à long terme, combinées dans le même fil que les utilisateurs essayant de comprendre ce qui se passe et comment traiter le problème immédiat

Aucun manque de respect envers toutes les personnes formidables qui font de Kubernetes ce qu'il est. J'espère juste qu'il y aura des "moments propices à l'apprentissage" ici, car cela semble mauvais en termes de perception du public selon laquelle Kubernetes est fiable/stable. (Certes kubeadm est alpha/beta, mais il a toujours beaucoup de visibilité.)

J'ai construit kubeadm-1.5.6 en utilisant kubernetes/release.rpm uniquement pour trouver (à ma grande consternation) que

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone, vous devez ajuster le .spec ici .

@sbezverk merci pour l'astuce ! C'est mieux maintenant...

C'est curieux :

• Je ne me souviens pas que la copie du fichier admin.conf m'était nécessaire dans les versions précédentes.
• J'ai essayé avec kubectl -s localhost:6443 auparavant mais ce n'était pas suffisant.

Quoi qu'il en soit, maintenant je peux continuer. Merci encore

v1.6.1 est en cours de publication. Ce sera fait par EOD.

Quelques notes:

1. Le problème avec les anciens packages en cours de suppression a été suivi ici : https://github.com/kubernetes/release/issues/234. En raison de certaines versions farfelues de kubeadm et de la façon dont ces éléments sont triés par ordre alphabétique, il n'a apparemment pas été possible de conserver la version 1.5.x de kubeadm dans le référentiel. ( @bostone votre problème y est également référencé)
2. Les tests kubeadm e2e sur les PR sont suivis ici : https://github.com/kubernetes/kubeadm/issues/190
3. Quant à l'annonce publique -- j'ai posté sur Twitter mais ce n'est guère officiel. Pas clair quels sont les canaux corrects pour des problèmes critiques comme celui-ci.

Ce sont toutes de bonnes questions à soulever dans un MP. @pipejakob s'est gracieusement porté volontaire pour rassembler cette autopsie.

@obnoxxx L'exigence de copier/chown le admin.conf était nécessaire avant car avec 1.5, nous avions le serveur API exposant un port non sécurisé. Nous avons changé cela en 1.6. Vous devez maintenant utiliser des informations d'identification sécurisées pour accéder au serveur API (voir https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

@mikedanese ça sonne bien, merci !
Juste pour le mannequin que je suis - quel sera l'effet de cette version 1.6.1 par rapport à ce problème ?
Kubelet démarrera-t-il sans le changement de /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ( solution de contournement de

@jbeda merci pour l'explication !

@jbeda Je pense que la confusion vient du document officiel d'installation de kubadm définissant le référentiel YUM sur http://yum.kubernetes.io/repos/kubernetes-el7-x86_64. Ce référentiel n'a que kubeadm-1.6.0

Et encore une fois, à ma grande déception, la construction de 1,5,6 tr/min et l'installation se sont soldées par le même problème. L'exécution de kubeadm init est suspendue à la même ligne :

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

Je suppose que je vais juste attendre la version 1.6.1 et espérer...

1.6.1 est sorti.

@mikedanese avez-vous testé kubeadm avant de fermer ce bogue ? En ce moment, je regarde [apiclient] Created API client, waiting for the control plane to become ready depuis déjà 10 minutes. Sur CentOS 7 avec la toute nouvelle installation 1.6.1

@bostone, vous rencontrez peut-être ce problème : #43805

Essayez de modifier /etc/systemd/system/kubelet.service.d/10-kubeadm.conf et d'ajouter --cgroup-driver=systemd

N'oubliez pas de courir systemctl daemon-reload; systemctl restart kubelet

@gtirloni avec notre suggestion, je suis arrivé à la fin de kubeadm init mais toute tentative d'exécution de kubectl produit cette erreur : The connection to the server localhost:8080 was refused - did you specify the right host or port? Je ne sais pas où et comment changer cela ou quel est le bon port à ce point?

Je ne sais pas si cela est lié, mais voici ce que je vois lors de l'exécution de systemctl status kubelet :
``` systemctl status kubelet -l
● kubelet.service - kubelet : l'agent de nœud Kubernetes
Chargé : chargé (/etc/systemd/system/kubelet.service ; activé ; préréglage du fournisseur : désactivé)
Drop-In : /etc/systemd/system/kubelet.service.d
10-kubeadm.conf
Actif : actif (en cours d'exécution) depuis le lundi 03/04/2017 17:31:07 PDT ; il y a 11min
Documents : http://kubernetes.io/docs/
PID principal : 10382 (kubelet)
Groupe C : /system.slice/kubelet.service
├─10382 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true - -network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain =cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=systemd
└─10436 journalctl -k -f

03 avril 17:41:56 sdl02269 kubelet[10382]: W0403 17:41:56.645299 10382 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
03 avril 17:41:56 sdl02269 kubelet[10382]: E0403 17:41:56.645407 10382 kubelet.go:2067] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false Reason : NetworkPluginNotReady message : docker : le plug-in réseau n'est pas prêt : configuration cni non initialisé```

Oui nous avons testé. Les tests e2e passent sur la branche release. Vous rencontrez peut-être d'autres problèmes.

@bostone peut-être que vous manquez ces étapes après kubeadm init ?

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

Vous devez également suivre l'étape 3 décrite ici . Cela semble lié à l'erreur de configuration cni que vous obtenez.

En regardant également [apiclient] Client API créé, en attendant que le plan de contrôle soit prêt depuis 10 minutes déjà avec Ubuntu 16.04 et une nouvelle installation de 1.6.1

@pingthings Je recommanderais de rejoindre Slack Kubernetes et le canal kubeadm . Nous pouvons vous aider à déboguer là-bas.

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.

Cela ne semble pas être résolu (Ubuntu LTS, kubeadm 1.6.1).

Tout d'abord, j'ai également rencontré kubeadm suspendu à "Client API créé, attendant que le plan de contrôle soit prêt" lors de l'utilisation --apiserver-advertise-address indicateur

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

Si je ne fournis pas cet indicateur, kubeadm passe, mais même dans ce cas, j'obtiens l'erreur suivante pour le démarrage de kubelet :

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Kubelet refuse de démarrer correctement et je ne peux pas me connecter au cluster avec kubectl de quelque manière que ce soit

Il semble que les versions 1.5.x de kubeadm aient été supprimées non seulement du référentiel centos, mais également d'Ubuntu LTS : https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It rend difficile la rétrogradation et brise en fait la rétrocompatibilité

@bostone

Avez-vous compris le blocage à « attendre que l'avion de contrôle soit prêt » ? Je vois la même chose après avoir essayé tous les changements avec 1.6.1.

@gtirloni @srzjulio ajouter ces étapes après kubeadm init n'a pas aidé. Cela a fait passer le service kubelet de failed à active (running) mais j'ai toujours The connection to the server localhost:8080 was refused - did you specify the right host or port? message

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

Il y a donc un paramètre erroné (modifié ?) qui pointe à tort sur 8080 ?

@bostone ce n'est pas le port kubelet dont vous avez besoin, c'est kube-apiserver, il devrait écouter sur le port 6443.

@sbezverk Je n'ai modifié aucune valeur par défaut en ce qui concerne les ports (ce n'est dans aucune instruction) Que dois-je faire pour passer de 8080 à 6443 ?

@bostone si vous n'avez rien modifié dans le manifeste apiserver, il écoutera par défaut sur le port 6443. Il vous suffit de copier /etc/kubernetes/admin.conf dans $HOME/.kube/config, de modifier les autorisations sur le fichier de configuration et vous devriez être prêt.

@sbezverk BTW - kubeadm init sortie

Ok, j'ai fait toutes les étapes à partir de zéro et ça semble aller mieux. Voici les étapes qui ont fonctionné pour moi jusqu'à présent et je fonctionne en tant que root sur CentOS 7.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Ajoutez -cgroup-driver=systemd à 10-kubeadm.conf et économisez

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

À ce stade, je peux exécuter kubectl get nodes et voir mon nœud maître dans la liste.
Répétez toutes les étapes pour minion sauf kubeadm init et exécutez à la place kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 comme généré par kubeadm init
Cette étape se termine et je peux voir les nœuds maître et minion (s)

Et maintenant - le problème :

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

On dirait donc que les nœuds ne sont jamais prêts. Aucune suggestion?

J'imagine que votre tissage ne se déploie pas correctement parce que vous utilisez le
fichier yaml antérieur à 1.6.

Essayez "kubectl apply -f https://git.io/weave-kube-1.6 "

Le mardi 4 avril 2017 à 12h24, Bo Stone [email protected] a écrit :

Ok, j'ai fait toutes les étapes à partir de zéro et ça semble aller mieux. Voici
les étapes qui ont fonctionné pour moi jusqu'à présent et je cours en tant que root.

chat <

[kubernetes]
nom=Kubernetes
baseurl= http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
activé=1
gpgcheck=1
repo_gpgcheck=1
gpgkey= https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https :/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
FEO

mettre en vigueur 0

miam install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Ajoutez -cgroup-driver=systemd à 10-kubeadm.conf et enregistrez

systemctl activer docker && systemctl démarrer docker

systemctl activer kubelet && systemctl démarrer kubelet

sysctl -w net.bridge.bridge-nf-call-iptables=1

systemctl stop firewalld; systemctl désactiver pare-feu

kubeadm init

cp /etc/kubernetes/admin.conf $HOME/

chown $(id -u):$(id -g) $HOME/admin.conf

export KUBECONFIG=$HOME/admin.conf

kubectl applique -f https://git.io/weave-kube

À ce stade, je peux exécuter kubectl get nodes et voir mon nœud maître dans le
liste.
Répétez toutes les étapes pour minion sauf bien sûr en exécutant kubeadm join
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 tel que généré par kubeadm
init
Cette étape se termine et je peux voir les nœuds maître et minion (s)

Et maintenant - le problème :

kubectl obtenir des nœuds

NOM STATUT ÂGE VERSION
abc02918 Pas Prêt 42m v1.6.1
abc04576 Non Prêt 29m v1.6.1

kubectl décrire le nœud abc02918

Événements:
FirstSeen LastSeen Count From SubObjectPath Type Raison Message
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 kubelet, sdl02918 Démarrage normal Kubelet de départ.
43m 43m 1 kubelet, sdl02918 Warning ImageGCFailed impossible de trouver les données pour le conteneur /
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientDisk Le statut du nœud sdl02918 est maintenant : NodeHasSufficientDisk
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientMemory Le statut du nœud sdl02918 est maintenant : NodeHasSufficientMemory
43m 43m 29 kubelet, sdl02918 Normal NodeHasNoDiskPressure Le statut du nœud sdl02918 est maintenant : NodeHasNoDiskPressure
42m 42m 1 kube-proxy, sdl02918 Démarrage normal Démarrage de kube-proxy.

On dirait donc que les nœuds ne sont jamais prêts. Aucune suggestion?

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

En utilisant CentOS et la version 1.6.1-1 de kubeadm, et en suivant les étapes ci-dessus, j'obtiens un comportement légèrement différent : le cluster est signalé comme étant prêt, mais je reste bloqué sur ce message :

[apiclient] Temporarily unable to list nodes (will retry)

Dans les journaux, cependant, nous avons toujours la même erreur :

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning C'est tout ! J'ai encore besoin de déployer quelques images pour voir si tout fonctionne mais je peux voir tous les nœuds avec le statut Ready ! Merci à tous les gars (pour l'instant :)

@bostone J'ai suivi la même recette que vous avez utilisée, mais j'ai obtenu des résultats différents - je n'ai pas dépassé kubeadm init. Quelle version de docker utilisez-vous ? c'est peut-être la différence dans mon cas?

@dcowden C'est tout ce que yum choisit sur mon système Docker version 1.12.6, build 96d83a5/1.12.6 . De plus, ce qui m'a aidé, c'est de réapprovisionner toutes les machines virtuelles que j'utilisais au lieu d'essayer de les réparer en plus de mes installations précédentes.

@bostone merci. Je vais rétrograder à cette version pour voir si je peux obtenir une configuration fonctionnelle. sur mon système, la dernière version est une étrange version 17.03.1.ce (évidemment la plus récente)

Je ne sais pas si c'est généralement utile, mais j'ai un playbook ansible qui
fait toutes les étapes pour CentOS 7

https://github.com/sjenning/kubeadm-playbook

YMMV, mais il documente au moins le processus. Je fais aussi quelques trucs comme
changez le docker pour utiliser la journalisation des fichiers json et le stockage de superposition.

Peut être utile comme référence même si vous n'exécutez pas réellement le playbook.

Le mar. 4 avril 2017 à 12:55, Dave Cowden [email protected]
a écrit:

@bostone https://github.com/bostone merci. je vais rétrograder à ça
version pour voir si je peux obtenir une configuration de travail. sur mon système, le dernier est un
version bizarre 17.03.1.ce (évidemment la dernière plus grande)

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning Merci ! c'est très utile !

Ok, voici une complication. après avoir exécuté kubeadm reset sur master et minion et redémarré les services docker et kubelet kubeadm init bloque à nouveau Created API client, waiting for the control plane to become ready . Quelqu'un peut-il fournir des étapes complètes pour réinitialiser kubeadm ?
@sjenning avez-vous essayé de réexécuter votre playbook après l'avoir exécuté initialement ?

@bostone dans mon cas, déplacer /var/lib/etcd/ fait l'affaire.

@autostatic le répertoire était vide et le renommer n'a pas aidé. @sjenning ton playbook se bloque, j'ai créé un ticket pour toi

Est-ce que n'importe qui a essayé d'exécuter le tableau de bord sur v1.6.1 ? J'obtiens une erreur qui indique ce qui suit :

`Interdit (403)

L'utilisateur " system:serviceaccount :kube- system:default " ne peut pas répertorier les espaces de noms au niveau du cluster. (obtenir des espaces de noms)
`

Je suppose que je dois configurer plus de RBAC, comme vous devez le faire pour exécuter Flannel?

@srzjulio Pouvez-vous déposer un nouveau problème pour cela? Je suppose que c'est quelque chose sur lequel SIG Auth et l'équipe du tableau de bord devraient travailler ensemble. Il s'agit probablement d'un simple changement YAML.

@srzjulio, vous devez mettre à jour les règles RBAC, nous les avons utilisées pour nous lancer :

apiVersion : rbac.authorization.k8s.io/v1alpha1
genre : ClusterRoleBinding
métadonnées :
nom : cluster-admin
roleRef :
apiGroup : rbac.authorization.k8s.io
genre : ClusterRole
nom : cluster-admin
sujets:

• genre : Groupe
  nom : système : maîtres
• genre : Groupe
  nom : système : authentifié
• genre : Groupe
  nom : système : non authentifié

Soyez prudent - La liaison que @sbezverk a là-bas désactive essentiellement RBAC. Vous aurez un cluster super non sécurisé si vous faites cela.

kind: Group
name: system:unauthenticated

C'est particulièrement mauvais. Cela signifie que toute personne pouvant contacter votre serveur API, même sans informations d'identification, peut exécuter des commandes arbitraires.

@jbeda, cela correspond au comportement que nous avions avec 1.5.6 dès la sortie de la boîte. Cela donne aux gens la possibilité de revoir et d'ajuster progressivement la configuration de sécurité au lieu de ne rien pouvoir faire avec les nouvelles règles de sécurité.

En fait, faire de system:non authentifié un administrateur de cluster est bien pire que 1.5.6

Si vous ne voulez pas d'autorisation, utilisez l'autorisateur AlwaysAllow

Si vous souhaitez autoriser tout pendant l'audit, utilisez une combinaison de RBAC,AlwaysAllow

Cela désactivera les demandes anonymes, enregistrera les refus RBAC dans le journal du serveur API, mais continuera à autoriser toutes les demandes authentifiées à faire ce qu'elles veulent

Désolé, et je réitère sur ce point, cela n'a rien à voir avec le problème d'origine. Et bien que les problèmes et les enjeux soient valables, nous devrions déplacer la conversation ailleurs.

Encore une fois désolé, appuyez sur Entrée trop tôt, mais dans l'état actuel des choses :

1 - la version 1.6.0 cause des problèmes
2 - ne sont pas tous fixes
3 - passer à RBAC (bien à mon avis) mais c'est un problème, pourquoi ? voir point 4
4 - Ce n'était pas très bien communiqué, et il n'y a pas beaucoup de docs/blogs ou quoi que ce soit pour l'expliquer
5 - Je m'incline devant tous ceux qui essaient de sauver, mais nous avons besoin d'un meilleur moyen de le faire

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions est un bon guide des options les plus granulaires dont vous disposez pour ouvrir les autorisations.

l'ajout de " --cgroup-driver=systemd " dans le kublet provoque un nouveau problème sur Centos/RHEL 7.3 (entièrement à jour - aka docker 1.10.3):

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

alors que nous pouvons voir clairement que native.cgroupdriver=systemd est défini dans le démon docker :

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng pourquoi ne mettez-vous pas à jour docker vers 1.12.6 ? Fonctionne comme un charme avec cette version.

@sbezverk : Je viens de mettre à jour vers 1.12.5 et maintenant ça marche ! Merci beaucoup!

Merci à tous pour l'aide.
Enfin, k8s 1.6.1 entièrement fonctionnel avec 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 !

@sjenning @ReSearchITEng
Salut, j'ai un playbook vagrant+ansible [0] très similaire à ce que vous avez créé, mais je ne parviens toujours pas à le faire fonctionner, même si pour moi, la configuration du réseau échoue. J'ai essayé avec du calicot, du tissage et de la flanelle, et les trois échouent (bien qu'avec des symptômes différents).

J'exécute ces versions :
[ vagabond@maître ~]$ docker --version
Docker version 1.12.6, build 3a094bd/1.12.6
[ vagabond@maître ~]$ kubelet --version
Kubernetes v1.6.1
[ vagabond@maître ~]$ version kubeadm
kubeadm version : version.Info{Major : "1", Minor : "6", GitVersion : "v1.6.1", GitCommit :"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate :"2017-04-03T20:33 : 27Z", GoVersion:"go1.7.5", Compilateur:"gc", Plate-forme:"linux/amd64"}

les erreurs:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

Cela ressemble à des informations clés, mais je ne sais pas comment y remédier :

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

Toute aide serait grandement appréciée...

[0]- https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

Je n'ai pas pu identifier ce qui ne va pas de votre côté.
Je vous suggère fortement d'essayer de créer une installation distincte à l'aide des playbooks ici : https://github.com/ReSearchITEng/kubeadm-playbook et d'essayer de voir quelle est la différence.
PS: mes derniers tests sont avec 1.6.2 , à la fois kube* et images et semblent bien.

@kelseyhightower

@ReSearchITEng désolé j'ai oublié de faire rapport, mais j'ai finalement réussi à le faire fonctionner, mes fichiers vagrant+ansible sont ici : https://github.com/thiagodasilva/kubernetes-swift

J'ai également eu le même problème, mais je viens de copier la configuration cni sur le nœud maître à l'emplacement correspondant du nœud de travail, puis tout est devenu OK.

état systemctl kubelet.service -l

● kubelet.service - kubelet : l'agent de nœud Kubernetes
Chargé : chargé (/etc/systemd/system/kubelet.service ; activé ; préréglage du fournisseur : désactivé)
Drop-In : /etc/systemd/system/kubelet.service.d
10-kubeadm.conf
Actif : actif (en cours d'exécution) depuis le mar 2017-06-06 10:42:00 CST ; il y a 18min
Documents : http://kubernetes.io/docs/
PID principal : 4414 (kubelet)
Mémoire : 43.0M
Groupe C : /system.slice/kubelet.service
├─4414 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --network-plugin=cni - -cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorizatio -ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=cgroupfs
└─4493 journalctl -k -f

06 juin 10:59:46 contiv1.com kubelet[4414]: W0606 10:59:46.215827 4414 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
06 juin 10:59:46 contiv1.com kubelet[4414]: E0606 10:59:46.215972 4414 kubelet.go:2067] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false ready message : docker : le plug-in réseau n'est pas prêt : configuration cni non initialisé
06 juin 10:59:51 contiv1.com kubelet[4414]: W0606 10:59:51.216843 4414 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
06 juin 10:59:51 contiv1.com kubelet[4414]: E0606 10:59:51.216942 4414 kubelet.go:2067] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false ready message : docker : le plug-in réseau n'est pas prêt : configuration cni non initialisé
06 juin 10:59:56 contiv1.com kubelet[4414]: W0606 10:59:56.217923 4414 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
06 juin 10:59:56 contiv1.com kubelet[4414]: E0606 10:59:56.218113 4414 kubelet.go:2067] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false ready message : docker : le plug-in réseau n'est pas prêt : configuration cni non initialisé
06 juin 11:00:01 contiv1.com kubelet[4414]: W0606 11:00:01.219251 4414 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
06 juin 11:00:01 contiv1.com kubelet[4414]: E0606 11:00:01.219382 4414 kubelet.go:2067] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false ready message : docker : le plug-in réseau n'est pas prêt : configuration cni non initialisé
06 juin 11:00:06 contiv1.com kubelet[4414]: W0606 11:00:06.220396 4414 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
06 juin 11:00:06 contiv1.com kubelet[4414]: E0606 11:00:06.220575 4414 kubelet.go:2067] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false ready message : docker : le plug-in réseau n'est pas prêt : configuration cni non initialisé

L'état de tous les nœuds :
[ root@ swarm net.d]# kubectl obtenir le nœud
NOM STATUT ÂGE VERSION
contiv1.com Prêt 1h v1.6.4
contiv2.com Prêt 1h v1.6.4
swarm.com Prêt 1h v1.6.4

Une résolution à ce sujet ? Je n'ai pas pu le faire même après avoir essayé toutes les résolutions mentionnées.

Étant nouveau dans la configuration de Kubernetes, je suis très confus. J'ai essayé de suivre https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 qui utilise weave-kube pour le réseau mais je suis également coincé avec le même problème . Un moyen de résoudre cela ?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Pourquoi est-ce toujours un problème ? Ubuntu 16.04/CentOS 7.3 avec les dernières mises à jour utilisant les dépôts officiels k8s avec 1.6.4 et en suivant les étapes décrites ici : https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen Non, cela a affecté _uniquement la v1.6.0_ . On s'attend à ce que kubelet ne trouve pas de réseau puisque vous n'en avez installé aucun. Par exemple, exécutez simplement

kubectl apply -f https://git.io/weave-kube-1.6

pour installer Weave Net et ces problèmes disparaîtront. Vous pouvez choisir d'installer Flannel, Calico, Canal ou n'importe quel réseau CNI si vous le souhaitez

@luxas Je continue de voir des références à cela, mais comment suis-je supposé appliquer quelque chose à un cluster qui ne fonctionne pas ? Je n'ai rien à quoi me connecter.

@drajen Je pense que le point de
Les différents guides de configuration vous permettront de dépasser ce point - l'étape manquante typique des anciens guides, que luxas mentionne utilement, en ce sens que vous devez appliquer une configuration réseau avant que tout ne commence à fonctionner correctement.

Oui, ce n'est peut-être pas évident et nous en sommes désolés, mais nous ne pouvons pas non plus avoir un seul nom de fournisseur.

J'ai discuté avec @drajen sur Slack et le problème était lié au groupe de contrôle, le kubelet n'était pas sain et n'a pas pu créer de pods, d'où le problème.

Merci à @luxas d' avoir https://github.com/kubernetes/kubeadm/issues/302

Toujours en train de frapper cela dans l'arc sur 1.7, existe-t-il une solution rapide quelque part?

Éditer:

kubectl apply -f https://git.io/weave-kube-1.6

a fait l'affaire, on dirait que nous avions juste besoin de CNI en cours d'exécution

Au moins pour CentOS/RHEL, assurez-vous de mettre à jour /etc/systemd/system/kubelet.service.d/10-kubeadm.conf et d'ajouter l'indicateur --cgroup-driver="systemd"

Si vous réinstallez à nouveau sur la même machine, il s'agit d'une réinitialisation complète et correcte :
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(ceci est nécessaire surtout si vous utilisez de la flanelle)
Si vous voulez faire tout en un, vous pouvez utiliser l'intégralité du projet : https://github.com/ReSearchITEng/kubeadm-playbook/

J'ai rencontré ce problème, et absolument rien de ce que j'ai lu ci-dessus n'a fonctionné. J'ai donc réessayé avec une configuration beaucoup plus contrôlée, passant d'Ubuntu au dernier CoreOS, passant à une version antérieure de k8s pour commencer, et en général étant très anal sur chaque dernière chose installée dans chaque VM. Je n'utilise PAS kubeadm, mais plutôt une combinaison de vagrant et d'ansible.

(pourquoi ? parce que je n'avais aucune idée de ce qui se passait dans kubeadm et j'ai pensé de cette façon que j'aurais au moins le contrôle et que je serais capable de contourner tout contrôle en amont trop zélé, sans parler de l'impression que j'avais plus de contrôle d'automatisation en général, et aussi ne pas avoir à se soucier de l'avertissement de ne pas appliquer le logiciel alpha en production.)

Lorsque j'ai essayé cette configuration avec une ancienne édition (1.4.3) de k8s, cette approche était parfaite. J'ai ensuite essayé de passer à la 1.71. Encore une fois, je rencontre TOUJOURS le même problème malgré l'absence de kubeadm.

J'ai confirmé que j'exécute calico dans chacun de mes nœuds, y compris le maître et les trois travailleurs potentiels. TOUS mes nœuds sont signalés comme NotReady, donc je ne sais pas vraiment comment je pourrais appliquer le tissage (ou quoi que ce soit d'autre) pour le faire fonctionner.

Tout cela semble juste poulet / œuf ... ne peut pas allouer un pod car le réseau échoue, mais il faut que le réseau fonctionne pour créer un réseau sur /etc/cni/net.d afin de pouvoir allouer des pods. Et encore une fois, tout cela fonctionnait il y a quelques heures avec k8s 1.4.3. Je suis très frustré !

J'apprécierais toutes les idées que quelqu'un pourrait donner.

Notes de bas de page :

Sur le maître : journalctl -r -u kubelet me donne

24 juillet 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: E0724 00:48:16.592274 7647 kubelet.go:2136] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false Reason :NetworkPluginNotReady message :docker : le plugin réseau n'est pas
24 juillet 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: W0724 00:48:16.590588 7647 cni.go:189] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net .ré

docker ps | grep calicot

(tronqué pour plus de lisibilité)
cde... quay.io/calico/ leader-ector@sha256 :... "/run.sh --election=c" il y a 8 heures Jusqu'à 8 heures
f72... calico/ kube-policy-controller@sha256 :... "/dist/controller" il y a 8 heures Jusqu'à 8 heures
c47... gcr.io/google_containers/pause-amd64:3.0 "/pause" il y a 8 heures Jusqu'à 8 heures

Il n'y a pas de /etc/cni/net.d

Depuis ma boîte kubectl :
kubectl obtenir des nœuds
10.0.0.111 NotReady,SchedulingDisabled 8h v1.7.1+coreos.0
10.0.0.121 Non Prêt 8h v1.7.1+coreos.0
10.0.0.122 Non Prêt 8h v1.7.1+coreos.0
10.0.0.123 Pas prêt 8h v1.7.1+coreos.0

kubectl applique -f https://git.io/weave-kube-1.6

N'A RIEN réparé et ne semble en fait que créer plus de problèmes.

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl apply -f https://git.io/weave-kube-1.6
compte de service "weave-net" créé
clusterrolebinding "weave-net" créé
ensemble de démons "weave-net" créé
Erreur du serveur (Interdit) : clusterroles.rbac.authorization.k8s.io "weave-net" est interdit : tentez d'accorder des privilèges supplémentaires : [PolicyRule{Resources :["pods"], APIGroups :[""], Verbes : ["get"]} PolicyRule{Ressources :["pods"], APIGroups :[""], Verbs :["list"]} PolicyRule{Resources :["pods"], APIGroups :[""], Verbes : ["watch"]} PolicyRule{Ressources :["namespaces"], APIGroups :[""], Verbs :["get"]} PolicyRule{Resources :["namespaces"], APIGroups :[""], Verbes : ["list"]} PolicyRule{Ressources :["namespaces"], APIGroups :[""], Verbs :["watch"]} PolicyRule{Resources :["nodes"], APIGroups :[""], Verbes : ["get"]} PolicyRule{Ressources :["nodes"], APIGroups :[""], Verbs :["list"]} PolicyRule{Resources :["nodes"], APIGroups :[""], Verbes : ["watch"]} PolicyRule{Ressources :["networkpolicies"], APIGroups :["extensions"], Verbes :["get"]} PolicyRule{Resources :["networkpolicies"], APIGroups :["extensions"], Verbes :["list"]} PolicyRule{Ressources :["networkpolicies"], APIGroups :["extensions"], Verbes :["watch"]}] user=&{kube-admin [system:a uthenticated] map[]} ownerrules=[] ruleResolutionErrors=[]

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl get pods --namespace=kube-system
NOM ÉTAT PRÊT REDÉMARRAGE ÂGE
kube-apiserver-10.0.0.111 1/1 Exécution 1 8h
kube-controller-manager-10.0.0.111 1/1 Exécution 1 8h
kube-dns-v20-fcl01 0/3 En attente 0 8h
kube-proxy-10.0.0.111 1/1 Exécution 1 8h
kube-proxy-10.0.0.121 1/1 Exécution 1 8h
kube-proxy-10.0.0.122 1/1 Exécution 1 8h
kube-proxy-10.0.0.123 1/1 Exécution 1 8h
kube-scheduler-10.0.0.111 1/1 Exécution 1 8h
kubernetes-dashboard-v1.4.1-29zzk 0/1 En attente 0 8h
tissage-net-2lplj 1/2 CrashLoopBackOff 3 3m
tisser-net-2nbgd 1/2 CrashLoopBackOff 3 3m
Weave-net-fdr1v 2/2 Running 0 3m
tissage-net-jzv50 1/2 CrashLoopBackOff 3 3m

Une enquête plus approfondie sur les erreurs de tissage indique qu'ils (a) ne peuvent pas se connecter à l'apiserver, ou bien (b) dans le cas de celui marqué "En cours d'exécution", il se plaint de ne pas pouvoir se connecter à lui-même.

@billmilligan Ayant des problèmes similaires, DNS cesse de fonctionner quelques minutes après le démarrage du conteneur

@Paxa @billmilligan Si vous souhaitez obtenir de l'aide, ne commentez pas ce problème. Au lieu de cela, ouvrez-en de nouveaux dans le référentiel kubeadm avec suffisamment de détails demandés.

@luxas Respectueusement, je dois me demander s'il s'agit d'un nouveau problème. Étant donné que j'obtiens exactement le même résultat en configurant k8 sans kubeadm que tout le monde avec kubeadm, cela semble éliminer kubeadm comme source du problème. Peut-être faudrait-il renommer ce numéro en conséquence ?

@billmilligan respectueusement, puisque le problème concerne kubeadm et que vous êtes capable de le reproduire sans kubeadm, alors ce n'est pas le bon endroit pour le déposer ? Je pense que ce fil a résolu le problème de kubeadm. Il s'agit d'un nouveau problème. Je pense qu'il attirera plus d'attention en tant que nouveau problème. Comme les gens sur ce fil pensent que c'est déjà résolu et l'ignorent.

J'utilise kubeadm et j'ai été affecté par ce problème, et il a été résolu depuis la 1.6.1. J'ai déployé des pertes de k8 depuis, donc je pense vraiment que vous avez un problème distinct.

@kfox1111 Merci pour les commentaires. Je vais déposer un nouveau problème, mais le nombre de personnes qui semblent encore y faire face ailleurs dans 1.7.x me fait toujours me demander.

TL;DR;

Le message d'erreur

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

n'est PAS nécessairement mauvais.

Ce message d'erreur vous indique que vous devez vous connecter à un fournisseur d'implémentation de spécifications CNI tiers .

Qu'est-ce que CNI et comment s'intègre-t-il à Kubernetes ?

CNI signifie Container Network Interface et définit une spécification que kubelet utilise pour créer un réseau pour le cluster. Consultez cette page pour plus d'informations sur la façon dont Kubernetes utilise la spécification CNI pour créer un réseau pour le cluster.

Kubernetes ne se soucie pas de la façon dont le réseau est créé tant qu'il satisfait aux spécifications CNI.

kubelet est en charge de connecter les nouveaux Pods au réseau (peut être un réseau superposé par exemple).
kubelet lit un répertoire de configuration (souvent /etc/cni/net.d ) pour les réseaux CNI à utiliser.
Lorsqu'un nouveau Pod est créé, le kubelet lit les fichiers dans le répertoire de configuration, exec est envoyé vers le binaire CNI spécifié dans le fichier de configuration (le binaire est souvent dans /opt/cni/bin ). Le binaire qui sera exécuté appartient et est installé par un tiers (comme Weave, Flannel, Calico, etc.).

kubeadm est un outil générique pour faire tourner des clusters Kubernetes et ne sait pas quelle solution de mise en réseau vous voulez et ne favorise personne en particulier. Après l'exécution de kubeadm init , il n'y a plus de binaire CNI ni de configuration . Cela signifie que le kubeadm init N'EST PAS SUFFISANT pour obtenir un cluster entièrement fonctionnel.

Cela signifie qu'après kubeadm init , les journaux de kubelet diront

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

c'est très attendu. Si ce n'était pas le cas, nous aurions privilégié un fournisseur de réseau spécifique.

Alors comment "corriger" cette erreur ?
La prochaine étape du guide de démarrage de kubeadm est « Installer un réseau de pods ».
Cela signifie, kubectl apply un manifeste de votre fournisseur de réseau CNI préféré.

Le DaemonSet copiera les binaires CNI nécessaires dans /opt/cni/bin et la configuration nécessaire dans /etc/cni/net.d/ . De plus, il exécutera le démon réel qui configure le réseau entre les nœuds (en écrivant des règles iptables par exemple).

Une fois le fournisseur CNI installé, le kubelet remarquera que "oh, j'ai des informations sur la configuration du réseau", et utilisera la configuration et les binaires tiers.

Et lorsque le réseau est configuré par le fournisseur tiers (en l'invoquant par kubelet), le nœud se marque lui-même Ready .

Comment ce problème est-il lié à kubeadm ?

Vers la fin du cycle v1.6, un PR a été fusionné qui a changé la façon dont kubelet a signalé le statut Ready/NotReady . Dans les versions précédentes, kubelet avait toujours signalé le statut Ready , que le réseau CNI ait été configuré ou non. C'était en fait un peu faux et a changé pour respecter le statut du réseau CNI. C'est-à-dire NotReady lorsque CNI n'a pas été initialisé et Ready lors de l'initialisation.

kubeadm dans la version 1.6.0 a attendu à tort que le nœud maître soit dans l'état Ready avant de poursuivre le reste des tâches kubeadm init . Lorsque le comportement de kubelet a changé pour signaler NotReady lorsque CNI n'était pas initialisé, kubeadm attendrait indéfiniment que le nœud obtienne Ready .

QUI ATTENDENT UNE CONCEPTION FAUSSE DU CTÉ DE KUBEADM EST CE QUI EST À PROPOS DE CE PROBLÈME

Cependant, nous avons rapidement corrigé la régression dans la v1.6.1 et l'avons publiée quelques jours après la v1.6.0.

Veuillez lire la rétrospective pour plus d'informations à ce sujet, et pourquoi la v1.6.0 pourrait être publiée avec cette faille.

Alors, que faites-vous si vous pensez voir ce problème dans kubeadm v1.6.1+ ?

Eh bien, je pense vraiment que non. Ce problème survient lorsque kubeadm init est en interblocage.
Aucun utilisateur ou mainteneur n'a vu cela dans la version 1.6.1+.

Ce que vous verrez bien est

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

après chaque kubeadm init dans toutes les versions ci-dessus v1.6, mais ce n'est pas mal

Quoi qu'il en soit, veuillez ouvrir un nouveau problème si vous voyez quelque chose d'inattendu avec kubeadm

S'il vous plaît ne pas commenter plus sur cette question. Au lieu de cela, ouvrez-en un nouveau.

@billmilligan Donc, vous n'avez qu'à kubectl apply le manifeste d'un fournisseur CNI pour que votre cluster soit opérationnel, je pense

Je résume à peu près ce qui a été dit ci-dessus, mais j'espère d'une manière plus claire et détaillée.
Si vous avez des questions sur le fonctionnement de CNI, veuillez vous référer aux canaux d'assistance normaux comme StackOverflow, un problème ou Slack.

(Enfin, désolé pour ce texte si gras, mais j'avais l'impression que c'était nécessaire pour attirer l'attention des gens.)