J'ai le même problème. J'ai également essayé de supprimer le Network ARGS comme suggéré sur un autre problème. Il se bloque toujours à waiting for control plane to be ready .

Avez-vous rechargé Daemon et redémarré le service kubelet après avoir apporté les modifications. Cela a fonctionné après avoir changé le pilote et le réseau de commentaires. Il faut 10 à 11 minutes pour que le plan de contrôle se prépare pour la première fois pour moi, je suggérerais de le laisser pendant 15 minutes pour la première fois.

J'ai rechargé le démon et redémarré le service kubelet à chaque fois. J'ai même laissé la configuration intacte pendant toute la nuit, mais elle attendait toujours le plan de contrôle.

J'ai rechargé le démon ( systemctl daemon-reload ) et redémarré kubelet également. J'exécute kubeadm reset , modifie la configuration du service, recharge le démon, puis exécute le kubeadm init .

Les conteneurs Apiserver et etcd docker ne s'exécutent pas après avoir commenté les options de mise en réseau. J'ai également essayé d'installer weave-net manuellement pour que le répertoire de configuration cni soit rempli, mais cela n'a pas fonctionné non plus. Pour ce faire, j'ai installé weave, exécuté weave setup et weave launch . Je ne sais pas vraiment comment Kubeadm configure Docker pour utiliser les paramètres CNI, mais il y a peut-être une étape qui me manque ici.

On dirait que kubelet ne peut pas atteindre le serveur kube api.

J'ai remarqué qu'etcd n'était pas en mesure d'écouter sur le port 2380, j'ai à nouveau suivi ces étapes et mon cluster a démarré :

• Exécutez kubeadm reset pour supprimer toutes les modifications apportées au serveur.
• Ramenez la machine à l'état initial. En réinstallant kubeadm (pour récupérer les fichiers de configuration d'origine).
• Supprimez les conteneurs docker liés à kubernetes s'il y en a.
• Obtenez et installez Weave. Ne l'exécutez pas.
• Redémarrez le serveur.
• Assurez-vous que kubelet ne s'exécute pas.
• Exécutez weave setup et weave launch .
• Exécutez kubeadm init .

Si vous voulez vous débarrasser de la gestion du tissage à la main...

• Courez weave reset
• Appliquez l'addon weave pour kubernetes 1.6.
• Redémarrez le serveur.

La jointure Kubeadm devrait fonctionner sur d'autres serveurs.

@Yengas Pouvez-vous s'il vous plaît fournir plus de détails sur les étapes de tissage? Les avez-vous exécutés sur tous les nœuds ou uniquement sur le maître ?

@jruels juste le nœud maître. Weave n'est qu'un binaire unique. La commande setup sans aucun argument, télécharge les images docker weave et crée la configuration CNI. La commande de lancement sans aucun argument démarre les conteneurs weave sur l'hôte uniquement.

@Yengas Toujours pas sûr de ce que vous entendez par - "obtenir et installer Weave. Ne l'exécutez pas" Je ne peux évidemment pas appliquer kubectl -f https://git.io/weave-kube-1.6 alors comment installer Weave ?

Que disent les journaux de l'apiserver ?

@rushabh268
Pour installer Weave, exécutez ce qui suit sur le maître
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
Puis cours
weave setup
Lorsque cela se termine, exécutez
weave launch

vous n'avez pas besoin de le faire. kubectl apply -f https://git.io/weave-kube-1.6 devrait suffire.

Les journaux du serveur API disent exactement la même chose que ce que j'ai mentionné dans le bogue. De plus, je ne peux pas faire kubectl car Kubernetes n'est pas installé

@jruels Je vais l'essayer et mettre à jour ce fil !

Dans la description du bogue, il y a des journaux kubeadm et des journaux kubelet. Il n'y a pas de journaux d'apiserver.

@mikedanese Comment puis-je obtenir les journaux de l'apiserver ?
@jruels je suis capable d'apporter du tissage
@Yengas Même après avoir suivi vos étapes, je vois l'erreur suivante dans les journaux kubelet :
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

De plus, j'ai arrêté le pare-feu, donc je ne sais pas pourquoi la connexion est refusée.

J'ai le même problème signalé ici.

Snip de mes messages système (Master Node) alors qu'il était bloqué, juste au cas où, il pointe quelque chose. Au fait, je fais ça sur Linode.

12 avril 02:10:00 audit localhost : SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? adresse=? terminal=? res=succès'
12 avril 02:10:00 audit localhost : SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? adresse=? terminal=? res=succès'
12 avril 02:10:00 audit localhost : SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? adresse=? terminal=? res=succès'
12 avril 02:10:00 localhost systemd : kubelet.service : délai d'attente du service dépassé, planification du redémarrage.
12 avril 02:10:00 localhost systemd : kubelet arrêté : l'agent de nœud Kubernetes.
12 avril 02:10:00 localhost systemd : kubelet démarré : l'agent de nœud Kubernetes.
12 avril 02:10:00 localhost systemd : Démarrage de l'outil de comptabilisation de l'activité du système...
12 avril 02:10:00 audit localhost : SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? adresse=? terminal=? res=succès'
12 avril 02:10:00 audit localhost : SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? adresse=? terminal=? res=succès'
12 avril 02:10:00 localhost systemd : Démarrage de l'outil de comptabilisation de l'activité du système.
12 avril 02:10:00 localhost kubelet : I0412 02:10:00.924529 3445 feature_gate.go:144] portes de fonctionnalités : map[]
12 avril 02:10:00 localhost kubelet : I0412 02:10:00.928973 3445 docker.go:364] Connexion à docker sur unix:///var/run/docker.sock
12 avril 02:10:00 localhost kubelet : I0412 02:10:00.929201 3445 docker.go:384] Démarrez le client docker avec le délai d'attente de la demande = 2 m0s
12 avril 02:10:00 localhost kubelet : W0412 02:10:00.941088 3445 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
12 avril 02:10:00 localhost kubelet : I0412 02:10:00.948892 3445 manager.go:143] cAdvisor exécuté dans le conteneur : "/system.slice"
12 avril 02:10:00 localhost kubelet : W0412 02:10:00.974540 3445 manager.go:151] impossible de se connecter au service Rkt api : rkt : impossible de tcp Appeler le service rkt api : composer tcp [::1]:15441 : getsockopt : connexion refusée
12 avril 02:10:00 localhost kubelet : I0412 02:10:00.997599 3445 fs.go:117] Partitions du système de fichiers : map[/dev/root:{mountpoint:/var/lib/docker/devicemapper major:8 minor:0 fsType:ext4 blockSize:0 }]
12 avril 02:10:01 localhost kubelet: I0412 02: 10: 01,001662 3445 manager.go: 198] Machine: { NumCores: 1 Cpu Fréquence: 2799998 Memor yCapacity: 1037021184 MachineID: 5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID: 5e9a9a0b58984bfb8766dba9afa8a191 ID_démarrage: 7ed1a6ff-9848- 437b-9460-981eeefdfe5a Filesystems :[{Device:/dev/root Capacity:15447539712 Type:vfs Inodes:962880 HasInodes:true }] DiskMap:map [43:0:{ Name:nbd0 Major:43 Minor:0 Size:0 Programmateur :aucun } 43:11 :{ Nom :nbd11 Majeur :43 Mineur :11 Taille :0 Programmateur :aucun } 43:12 :{ Nom :nbd12 Majeur :43 Mineur :12 Taille :0 Programmateur :aucun } 43:15 : { Name:nbd15 Major:43 Minor:15 Size:0 Scheduler:none } 43:7:{ Name:nbd7 Major:43 Minor:7 Size:0 Scheduler:none } 8:0:{ Name:sda Major:8 Minor :0 Taille :15728640000 Planificateur :cfq } 252:0 :{ Nom :dm-0 Majeur :252 Mineur :0 Taille :107374182400 Planificateur :aucun } 43:1 :{ Nom :nbd1 Majeur :43 Mineur :1 Taille :0 Planificateur :aucun } 43:13 :{ Nom :nbd13 Majeur :43 Mineur :13 Taille :0 Planificateur :aucun } 43:8 :{ Nom :nbd8 Majeur :43 Mineur :8 Taille :0 Planificateur :aucun } 8 : 16 :{ Nom :sdb Majeur :8 Mineur :16 Taille :536870912 Planificateur :cfq } 9:0 :{ Nom :md0 Majeur :9 Mineur :0 Taille :0 Planificateur :aucun } 43:3 :{ Nom :nbd3 Majeur : 43 Mineur :3 Taille :0 Planificateur :aucun } 43:9 :{ Nom :nbd9 Majeur :43 Mineur :9 Taille :0 Planificateur :aucun } 43:10 :{ Nom :nbd10 Majeur :43 Mineur :10 Taille :0 Planificateur :aucun } 43:14 :{ Nom :nbd14 Majeur :43 Mineur :14 Taille :0 Planificateur :aucun } 43:2 :{ Nom :nbd2 Majeur :43 Mineur :2 Taille :0 Planificateur :aucun } 43:4 :{ Nom :nbd4 Majeur :43 Mineur :4 Taille :0 Programmateur :aucun } 43:5 :{ Nom :nbd5 Majeur :43 Mineur :5 Taille :0 Programmateur :aucun } 43:6 :{ Nom :nbd6 Majeur :43 Mineur : 6 Size:0 Scheduler:none }] NetworkDevices:[{ Name:dummy0 M acAddress:5a :34:bf:e4:23:cc Speed:0 Mtu:1500 } { Name:eth0 M acAddress:f2 :3c:91: 1f:cd:c3 Vitesse :-1 Mtu:1500 } { Nom:gre0 M acAddress:00 :00:00:00 Vitesse:0 Mtu:1476 } { Nom:gretap0 M acAddress:00 :00:00:00:00 :00 Vitesse : 0 Mtu : 1462 } { Nom : ip6_vti0 M acAddress : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 Vitesse : 0 Mtu:1500 } { Nom:ip6gre0 M acAddress:00 :00:00:00:00:00:00:00 : 00:00:00:00:00:00:00:00 Vitesse:0 Mtu:1448 } { Nom:ip6tnl0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00 Vitesse : 0 Mtu : 1452 } { Nom : ip_vti0 Ma
12 avril 02:10:01 localhost kubelet: cAddress:00 :00:00:00 Speed:0 Mtu:1428 } { Name:sit0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 } { Name: teql0 MacAddress : Vitesse : 0 Mtu : 1500 } { Nom : tunl0 M acAddress : 00 :00:00:00 Vitesse : 0 Mtu : 1480 }] Topologie : [{Id : 0 Mémoire : 1037021184 Cœurs : [{Id : 0 Threads :[0] Caches :[{ Taille :32768 Type : Niveau de données :1 } { Taille :32768 Type :Niveau d'instruction :1 } { Taille :4194304 Type : Niveau unifié :2 }]}] Caches :[]}] Clou dProvider :Type d'instance inconnu :ID d'instance inconnu :Aucun }
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.013353 3445 manager.go:204] Version : {Kern elVersion : 4.9.15-x86_64-linode81 Container OsVersion : Fedora 25 (Server Edition) Dock erVersion : 1.12. 6 CadvisorVersion : CadvisorRevision :}
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.014086 3445 server.go:509] --cgroups-per-qos activé, mais --cgroup-root n'a pas été spécifié. par défaut à /
12 avril 02:10:01 localhost kubelet : W0412 02:10:01.016562 3445 container_manager_linux.go:218] L'exécution avec swap activé n'est pas prise en charge, veuillez désactiver swap ! Ce sera une erreur fatale par défaut à partir de K8s v1.6 ! En attendant, vous pouvez choisir d'en faire une erreur fatale en activant --experimental-fail-swap-on.
12 avril 02:10:01 kubelet localhost : I0412 02:10:01.016688 3445 container_manager_linux.go:245] le gestionnaire de conteneurs a vérifié que l'utilisateur spécifié cgroup-root existe : /
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.016717 3445 container_manager_linux.go:250] Création d'un objet Container Manager basé sur Node Config : {RuntimeCgroupsName : SystemCgroupsName : KubeletCgroupsName : Contain erRuntime : docker Cgroup upsPerQOS : true CgroupRoot :/ Cgr oupDriver:cgroupfs ProtectKerne lDefaults:false EnableCRI:true NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable :map [pods:{}] Kub eReserved:map [] Syste mReserved:map [] HardEvictionThresholds:[{ Signal:memory.available Opérateur :LessThan Value:{ Quantity:100Mi P ercentage:0 } GracePeriod:0s MinReclaim:}]} ExperimentalQO SReserved:map []}
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.016943 3445 kubelet.go:255] Ajout du fichier manifeste : /etc/kubernetes/manifests
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.016966 3445 kubelet.go:265] Regarder apiserver
12 avril 02:10:01 localhost kubelet : E0412 02:10:01.025058 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390 : Échec de la liste *v1.Node : Obtenir https : //50.116.13.214 :6443/api/v1/nodes?fieldSelector=metadata.name%3Dli471-214.members.linode.com&resourceVersion=0 : composez tcp 50.116.13.214:6443 : getsockopt : connexion refusée
12 avril 02:10:01 localhost kubelet : E0412 02:10:01.025342 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382 : Échec de la liste *v1.Service : Obtenir https : //50.116.13.214 :6443/api/v1/services?resourceVersion=0 : composez tcp 50.116.13.214:6443 : getsockopt : connexion refusée
12 avril 02:10:01 localhost kubelet : E0412 02:10:01.025397 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46 : Échec de la liste *v1.Pod : Obtenir https://50.116.13.214 :6443/api/v1/pods?fieldSelector=spec.nodeName%3Dli471-214.members.linode.com&resourceVersion=0 : composez tcp 50.116.13.214:6443 : getsockopt : connexion refusée
12 avril 02:10:01 localhost kubelet : W0412 02:10:01.026574 3445 kubelet_network.go:70] Le mode Hairpin est défini sur "promiscuous-bridge" mais kubenet n'est pas activé, revenant à "hairpin-veth"
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.026599 3445 kubelet.go:494] Le mode Hairpin est défini sur "hairpin-veth"
12 avril 02:10:01 localhost kubelet : W0412 02:10:01.026661 3445 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
12 avril 02:10:01 localhost kubelet : W0412 02:10:01.034194 3445 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
12 avril 02:10:01 localhost kubelet : W0412 02:10:01.043157 3445 cni.go:157] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d
12 avril 02:10:01 localhost kubelet : I0412 02:10:01.043183 3445 docker_service.go:187] Réseau Docker cri géré par cni
12 avril 02:10:01 kubelet localhost : erreur : échec de l'exécution de Kubelet : échec de la création de kubelet : mauvaise configuration : pilote de groupe de contrôle kubelet : "cgroupfs" est différent du pilote de groupe de contrôle docker : "systemd"
12 avril 02:10:01 audit localhost : SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? adresse=? terminal=? res=échec'
12 avril 02:10:01 localhost systemd : kubelet.service : processus principal terminé, code=exited, status=1/FAILURE
12 avril 02:10:01 localhost systemd : kubelet.service : l'unité est entrée dans l'état d'échec.
12 avril 02:10:01 localhost systemd : kubelet.service : échec avec le résultat "code de sortie".

@acloudiator Je pense que vous devez définir cgroup-driver dans kubeadm config.

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

Et puis redémarrez le service kubelet

Ce serait formidable si kubeadm pouvait d'une manière ou d'une autre résoudre le problème de configuration du groupe de contrôle.
Idées :

• Abandon de l'initialisation en cas de mauvaise configuration
• Vérifiez au préalable les paramètres de Docker et utilisez ce que Docker utilise (pas sûr des implications ici)

Juste une mise à jour, quelle que soit la solution de contournement que j'ai essayée n'a pas fonctionné. J'ai donc migré vers CentOS 7.3 pour le master et ça marche à merveille ! J'ai cependant gardé les minions sur CentOS 7.2.

@rushabh268 salut, j'ai le même problème sur Redhat Linux 7.2. Après la mise à jour de systemd, ce problème est résolu. Vous pouvez essayer de mettre à jour systemd avant l'installation.
yum update -y systemd
et le journal des erreurs de kubelet :
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

J'ai rencontré ce problème sur CentOS 7.3. Le problème a disparu après avoir désinstallé docker-ce puis installé docker-io.
Je ne sais pas si c'est la cause première. Quoi qu'il en soit, vous pouvez essayer si les méthodes ci-dessus ne fonctionnent pas.

@ZongqiangZhang J'ai docker 1.12.6 installé sur mes nœuds. @juntaoXie J'ai également essayé de mettre à jour systemd et c'est toujours bloqué

J'ai donc exécuté Centos 7.3 avec 1.6.4 sans problème sur un certain nombre de machines.

Vous êtes-vous assuré d'avoir désactivé selinux ?

@timothysc J'ai CentOS 7.2 et non CentOS 7.3 et selinux est désactivé

J'ai une version CentOS Linux 7.3.1611 (Core) et KubeAdm 1.6.4 ne fonctionne pas.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

Sortir:

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

@paulobezerr pouvez-vous partager un peu plus de journaux kube-apiserver ? (ceux à la fin de votre commentaire)

Les lignes au-dessus de ce que vous avez déjà inclus mentionnent-elles la même adresse IP ? J'ai récemment essayé d'exécuter k8 sur deux nouveaux KVM, l'un avec Ubuntu 16.04 et l'autre avec CentOS 7.3. Les deux ont donné ceci :

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

Notez que d'abord l'adresse IP mentionnée est x.x.x.x , mais ensuite localhost est résolu en y.y.y.y (qui dans mon cas était une adresse IP publique d'un autre KVM assis sur le même serveur physique). Je pourrais finalement démarrer kubeadm sur Ubuntu, mais seulement après avoir installé dnsmasq de la même manière que https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861. La même solution de contournement sur CentOS n'a pas aidé.

Cela peut-il être un bogue dans kubedns ou quelque chose? Fait intéressant, les mêmes étapes sur les machines virtuelles AWS ont fait apparaître kubeadm. Mais les instances EC2 sont trop chères pour mes projets personnels.

J'ai le même problème que @paulobezerr.

## Versions :
kubelet-1.6.4-0.x86_64
kubernetes-cni-0.5.1-0.x86_64
kubectl-1.6.4-0.x86_64
kubeadm-1.6.4-0.x86_64
docker-client-1.12.6-28.git1398f24.el7.centos.x86_64
docker-common-1.12.6-28.git1398f24.el7.centos.x86_64
docker-1.12.6-28.git1398f24.el7.centos.x86_64

ALORS
uname -r > 3.10.0-229.1.2.el7.x86_64
cat /etc/redhat-release > CentOS Linux version 7.3.1611 (Core)

## Étapes suivies :

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/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
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## journaux du serveur API :
--> 37.247.XX.XXX est l'IP publique

[restful] 08/06/2017 10:45:19 log.go:30 : la liste [restful/swagger] est disponible sur https://37.247.XX.XXX :6443/swaggerapi/
[restful] 2017/06/08 10:45:19 log.go:30 : [restful/swagger] https://37.247.XX.XXX :6443/swaggerui/ est mappé au dossier /swagger-ui/
E0608 10:45:19.429839 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *api.Secret : Obtenir https://localhost : 6443/api/v1/secrets?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.430419 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *api.ResourceQuota : Obtenir https://localhost : 6443/api/v1/resourcequotas?resourceVersion=0 : composer TCP 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.430743 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *api.ServiceAccount : Obtenir https://localhost : 6443/api/v1/serviceaccounts?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.431076 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *storage.StorageClass : Obtenir https://localhost : 6443/apis/storage.k8s.io/v1beta1/storageclasses?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.431377 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *api.LimitRange : Obtenir https://localhost : 6443/api/v1/limitranges?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.431678 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *rbac.RoleBinding : Obtenir https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.431967 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *rbac.ClusterRoleBinding : Obtenir https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.432165 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *api.Namespace : Obtenir https://localhost : 6443/api/v1/namespaces?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.432386 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *rbac.ClusterRole : Obtenir https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterroles?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.432619 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70 : Échec de la liste *rbac.Role : Obtenir https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/roles?resourceVersion=0 : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
I0608 10:45:19.481612 1 serve.go:79] Diffusion sécurisée sur 0.0.0.0:6443
W0608 10:45:19.596770 1 storage_extensions.go:127] Échec de la synchronisation des ressources tierces : obtenez https://localhost :6443/apis/extensions/v1beta1/thirdpartyresources : composez TCP 108.59.253.109:6443 : getsockopt : connexion refusée
E0608 10:45:19.596945 1 client_ca_hook.go:58] Message https://localhost :6443/api/v1/namespaces : composez tcp 108.59.253.109:6443 : getsockopt : connexion refusée
F0608 10:45:19.597174 1 controller.go:128] Impossible d'effectuer la vérification initiale de l'allocation IP : impossible d'actualiser le bloc IP de service : obtenez https://localhost :6443/api/v1/services : composez tcp 108.59.253.109 : 6443 : getsockopt : connexion refusée

@albpal J'ai eu exactement le même problème il y a une semaine : dial tcp X.X.X.X affichait une adresse IP étrange et je ne pouvais pas résoudre ce problème sur CentOS même après avoir installé dnsmasq et être passé aux serveurs DNS de Google au lieu du DNS de mon fournisseur d'hébergement. Juste pour la curiosité : pouvez-vous vérifier si cette mauvaise adresse IP que vous voyez se trouve dans le même centre de données que votre machine virtuelle ? Vous pouvez utiliser http://ipinfo.io pour estimer cela avec un certain degré de certitude ou simplement traceroute.

Dans mon cas, la mauvaise adresse IP faisait référence à un autre KVM sur le même serveur physique. Cela peut être quelque chose à voir avec le DNS sur une machine physique, ce qui peut nécessiter une solution de contournement à l'intérieur de kube api ou kube dns, sinon le démarrage d'un cluster devient une énorme douleur pour de nombreux nouveaux arrivants ! J'ai perdu quelques soirées avant de remarquer dial tcp avec une mauvaise adresse IP dans les journaux, ce qui était une première expérience assez triste avec k8s. Je n'ai toujours pas de bonne solution prête à l'emploi pour les KVM CentOS sur mon fournisseur d'hébergement ( firstvds.ru ).

Qu'est-ce qui peut causer cette incompatibilité très étrange dans les adresses IP ?

@albpal Veuillez ouvrir un nouveau problème, ce que vous avez décrit et le sujet de ce problème sont des problèmes distincts (je pense, sur la base de ces informations)

@kachkaev Je viens de vérifier ce que vous suggérez.

J'ai trouvé que la mauvaise adresse IP se termine par un CPANEL : vps-1054290-4055.manage.myhosting.com.

D'un autre côté, l'adresse IP publique de mon VPS vient d'Italie et cette mauvaise adresse IP vient des États-Unis ... donc malgré le fait que la mauvaise adresse IP a quelque chose à voir avec l'hébergement (CPANEL), elle ne semble pas faire référence à un autre KVM sur le même serveur physique.

Avez-vous pu installer k8s?

@luxas j'ai le même comportement mais j'ai copié les logs du dockersortie aussi.

/var/log/messages et la sortie de kubeadm init sont les mêmes que le problème d'origine.

@albpal donc votre machine virtuelle et cette deuxième machine sont toutes les deux sur CPANEL ? Bon signe, car alors mon cas est le même ! Le fait qu'il s'agisse de la même machine physique pourrait n'être qu'une coïncidence.

J'ai utilisé deux KVM dans mes expériences, l'une avec Ubuntu 16.04 et l'autre avec CentOS 7.3. Les deux avaient le même problème d'adresse IP dial tcp . J'ai finalement pu démarrer kubeadm sur Ubuntu en me débarrassant des serveurs DNS de mon fournisseur. La solution était basée sur les conseils de ​crilozs :

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

Cela a amené la bonne adresse IP après dial tcp dans les journaux sur Ubuntu et kubeadm initialisé après quelques minutes ! J'ai essayé de configurer dnsmasq sur CentOS de la même manière, mais cela n'a pas résolu le problème. Mais je suis un débutant total dans ce système d'exploitation, il se peut donc que j'ai juste oublié de redémarrer un service ou de nettoyer un cache. Essayez cette idée!

Dans tous les cas, c'est une erreur de faire une étape supplémentaire de reconfiguration du DNS car c'est très déroutant (je ne suis pas un gars serveur/devops et toute cette enquête que j'ai menée m'a presque fait pleurer :craintif:). J'espère que kubeadm pourra une fois détecter si les serveurs DNS du fournisseur fonctionnent de manière étrange et réparer automatiquement tout ce qui est nécessaire dans le cluster.

Si quelqu'un de l'équipe k8s souhaite voir ce qui se passe, je serai heureux de partager l'accès root sur quelques nouveaux KVM FirstVDS. Il suffit de m'envoyer un e-mail ou un DM sur Twitter !

Merci @kachkaev ! je vais essayer demain

cc @kubernetes/sig-network-bugs Avez-vous une idée de la raison pour laquelle la résolution DNS échoue ci-dessus ?

Merci @kachkaev, nous allons essayer de l'examiner. Je ne pense pas que ce soit vraiment la faute de kubeadm en soi, mais si de nombreux utilisateurs sont bloqués sur la même mauvaise configuration, nous pourrions l'ajouter aux documents de dépannage ou autre...

Mes journaux sont très susceptibles d'être des journaux @albpal .
Mais je vais essayer le dnsmasq. Merci à tous!

@kachkaev , ça ne marche pas. Même problème 😢
Le journal complet est joint.

log.txt

j'ai réussi à le réparer !! Merci beaucoup @kachkaev pour vos conseils !

Je pense que le problème était :

### Scénario :
Un VPS avec le schéma de configuration suivant :

résolution.conf
[ root@apalau ~]# cat resolv.conf
serveur de noms 8.8.8.8
serveur de noms 8.8.4.4
serveur de noms 2001:4860:4860::8888
serveur de noms 2001:4860:4860::8844

Il n'y a pas de domaine de recherche !

hôtes
[ root@apalau ~]# chat /etc/hosts
127.0.0.1 localhost.localdomain localhost
37.XXX.XX.XXX nom.vpshosting.com

Selon les journaux, le conteneur Kubernetes tente de se connecter à :

Obtenez https://localhost :6443/api/v1/secrets?resourceVersion=0

Et quand je demande :
$ nslookup "localhost.$(hostname -d)"
L'adresse IP que j'obtiens est la mauvaise, c'est-à-dire 108.59.253.109.

Je pense donc que ces conteneurs essaient de résoudre localhost (sans domaine) et qu'ils obtiennent une mauvaise adresse IP. Probablement parce que "localhost.$(hostname -d)" résout cette adresse IP, ce qui, je pense, se produira sur presque tous les services VPS.

## Ce que j'ai fait pour résoudre le problème sur un VPS CentOS 7.3 (en dehors de ces étapes montrées sur https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm) :

En tant que root :

1. réinitialisation de kubeadm
2. miam installer dnsmasq
3. cp /etc/resolv.conf ~/resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. echo -e "serveur de noms 127.0.0.1\nserveur de noms $(nom d'hôte -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr +i /etc/resolv.conf
8. echo -e "serveur=8.8.8.8\nserveur=8.8.4.4" > /etc/dnsmasq.conf
9. echo -e "$(nom d'hôte -i)\tlocalhost.$(nom d'hôte -d)" >> /etc/hosts
10. redémarrage du service dnsmasq
11. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld
12. initialisation de kubeadm

J'ai ajouté le nom d'hôte -i à l'étape 5 car si je ne le fais pas, docker ajoutera 8.8.8.8 à resolv.conf sur les conteneurs.

J'espère que cela aidera également les autres.

Merci!!

Heureux d'entendre ça @albpal ! J'ai suivi vos étapes avant kubeadm init et le cluster a finalement été initialisé dans mon test FirstVDS KVM avec CentOS 7.3 ! La seule chose supplémentaire que j'avais à faire était d'arrêter et de désactiver le pare-feu car il bloquait les connexions externes au port 6443 :

systemctl disable firewalld
systemctl stop firewalld

_Je ne recommande pas de le faire car je ne suis pas conscient des conséquences - cela m'a simplement aidé à effectuer un test sur un système d'exploitation que je n'utilise pas normalement._

Maintenant, je me demande ce qui pourrait être fait pour faciliter le processus d'installation pour les débutants comme moi. Le chemin entre rester coincé à Created API client, waiting for the control plane to become ready et trier les choses est encore énorme, surtout si nous prenons en compte le temps nécessaire pour creuser ce problème et lire tous les commentaires. __Que pouvez-vous suggérer ?__

@paulobezerr d'après ce que je vois dans votre pièce jointe, je pense que votre problème est légèrement différent. Mes journaux apiserver contiennent quelque chose comme :

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

tandis que le vôtre dit :

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

(dans le premier cas c'est localhost / RANDOM_IP , tandis que dans le second cas c'est toujours 10.X.X.X )

Malheureusement, je ne sais pas quoi conseiller à part essayer divers --apiserver-advertise-address=??? lorsque vous kubeadm init (voir docs ). Mon expérience pratique de k8s vient d'atteindre 10 jours, dont la plupart étaient de vaines tentatives de démarrage d'un cluster à nœud unique sur FirstVDS :-)

J'espère que vous aurez résolu ce problème et que vous partagerez la solution avec d'autres !

@kachkaev J'ai oublié de mentionner que j'ai appliqué la règle de pare-feu suivante :

$ firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld

Cela fonctionne bien sur mon environnement lorsque cette règle est appliquée sans désactiver le pare-feu. Je vais l'ajouter à mon commentaire précédent pour rassembler toutes les étapes nécessaires.

@juntaoXie Merci. La mise à jour de la version systemd selon votre commentaire a fonctionné pour moi.

J'ai toujours ce problème depuis deux jours maintenant, j'exécute tout cela derrière un proxy et il ne semble pas y avoir de problème.
kubeadm init se bloque en attendant que le plan de contrôle soit prêt. Lorsque je fais docker ps, les conteneurs sont tirés et en cours d'exécution, mais aucun port n'est alloué en retard (je ne sais pas si c'est censé le faire, mais d'accord). etcd fonctionne également très bien. Cependant, lorsque je regarde mon service kubelet, il indique Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d qui, selon https://github.com/kubernetes/kubernetes/issues/43815 , est ok, vous besoin d'appliquer un réseau cni.
Ce que je fais selon https://www.weave.works/docs/net/latest/kubernetes/kube-addon/. Maintenant, kubectl indique que 8080 a été refusé - avez-vous spécifié le bon hôte ou le bon port ? Cela ressemble à un problème de poule et d'œuf, comment appliquer un réseau cni lorsque mon init kubeadm se bloque ??? C'est tellement déroutant

Ce n'est pas non plus un problème de cgroup, docker et mon service kubelet utilisent systemd.

FWIW, j'ai eu le même problème sur GCP, j'ai essayé d'utiliser Ubuntu 16.04 et CentOS en utilisant les commandes suivantes dans un projet propre :

$ gcloud compute instances create test-api-01 --zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nœud 1 pour les tests d'api'

$ gcloud compute instances create test-api-02 --zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nœud 2 pour les tests d'api'

$ gcloud compute instances create test-api-03 --zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nœud 3 pour les tests d'api'

$ apt-obtenir la mise à jour

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-clé ajouter -

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

$ systemctl redémarrer kubelet

$ kubeadm init

Donc, après m'être cogné la tête pendant plusieurs heures, j'ai fini par choisir:

$ gcloud beta container --project "weather-177507" clusters create "weather-api-cluster-1" --zone "us-west1-a" --username="admin" --cluster-version "1.6.7" --machine-type "f1-micro" --image-type "COS" --disk-size "100" --scopes " https://www.googleapis.com/auth/compute "," https:// www.googleapis.com/auth/devstorage.read_only "," https://www.googleapis.com/auth/logging.write "," https://www.googleapis.com/auth/monitoring.write "," https://www.googleapis.com/auth/servicecontrol "," https://www.googleapis.com/auth/service.management.readonly "," https://www.googleapis.com/auth/trace. ajouter " --num-nodes "3" --network "default" --enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

J'ai pu faire fonctionner un cluster là où je ne pouvais pas à partir d'une image vierge.

Même moi, je suis confronté au même problème avec la version Kubeadm :

ça coince dans
[apiclient] Created API client, waiting for the control plane to become ready

Même problème que @paulobezerr - mon env : CentOS 7.4.1708 version kubeadm : &version.Info{Major :"1", Minor :"8", GitVersion :"v1.8.0", GitCommit :"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState :"clean ", BuildDate :"2017-09-28T22:46:41Z", GoVersion :"go1.8.3", Compilateur :"gc", Plate-forme :"linux/amd64"}

Pour moi, ce problème ne fonctionnait pas avec SELinux désactivé. L'indice était ses pas, le commentaire :

éditez /etc/selinux/config et définissez SELINUX=disabled

Les étapes d'installation ici (https://kubernetes.io/docs/setup/independent/install-kubeadm/) pour CentOS disent :
"La désactivation de SELinux en exécutant setenforce 0 est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte"
mais il ne mentionne pas (au moins sur l'onglet CentOS/RHEL/Fedora) que vous devez modifier /etc/selinux/config et définir SELINUX=disabled

Pour moi, même si j'avais exécuté setenforce 0, j'obtenais toujours les mêmes erreurs. La modification de /etc/selinux/config et la définition de SELINUX=disabled, puis le redémarrage l'ont corrigé pour moi.

Il semble y avoir beaucoup de problèmes (potentiellement orthogonaux) en jeu ici, donc je tiens à ce que nous ne laissions pas les choses diverger. Jusqu'à présent, nous semblons avoir identifié 3 problèmes :

1. DNS ne parvient pas à résoudre correctement localhost sur certaines machines. @kachkaev @paulobezerr Avez-vous réussi à résoudre ce problème ? Je me demande comment rendre cela plus explicite dans nos exigences, des idées ?

2. Correspondance cgroup-driver incorrecte entre kubelet et Docker. Nous devrions ajouter cela à notre liste d'exigences.

3. SELinux n'est pas désactivé. Nous devrions ajouter cela à notre liste d'exigences.

Une fois que les trois seront traités avec les PR, peut-être devrions-nous fermer cela et laisser les gens qui rencontreront des problèmes à l'avenir créer leurs propres problèmes. Cela nous permettra de recevoir des informations plus structurées et de fournir un support plus granulaire, au lieu de jongler avec beaucoup de choses dans un fil. Qu'en pensez-vous @luxas ?

Pour moi, je suis allé avec docker 17.06 (17.03 est recommandé, mais non disponible sur docker.io) et j'ai rencontré le même problème. La mise à niveau vers 17.09 a résolu le problème comme par magie.

Comme ce fil de discussion est si long et qu'il y a probablement beaucoup de problèmes totalement différents, la chose la plus productive que je puisse ajouter en plus de l'excellent commentaire de @ jamiehannaford est que s'il vous plaît, ouvrez de nouveaux problèmes ciblés avec tous les journaux / informations pertinents au cas où quelque chose échoue _avec le dernier kubeadm v1.8_, qui détecte automatiquement un état défectueux bien mieux que les versions précédentes. Nous avons également amélioré notre documentation autour des exigences et des cas extrêmes qui, espérons-le, feront gagner du temps aux gens.

Merci tout le monde!

j'ai eu le même problème avec 1.8 dans CENTOS 7 avec 1.8 ? quelqu'un a eu le même problème ou sait comment le résoudre.

@rushins Si vous souhaitez obtenir de l'aide sur le problème éventuel que vous rencontrez, ouvrez un nouveau problème ici avec suffisamment de détails.

J'ai eu le même problème que @rushabh268 qui est connection refused et non localhost:6443/api .
Enfin, je l'ai résolu en remarquant le domaine en recherchant search xxx.xx.xxxx.org .

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

Env :
-> CentOS-7-x86_64-Minimal-1708
-> K8s v1.9.2
-> Docker v17.12.0.ce
-> sous Réseau privé xxx.xx.xxxx.org

S'il vous plaît, pour l'amour de Dieu, ajoutez ceci à la documentation. J'ai essayé de configurer mon cluster pendant de nombreuses nuits après le travail sous prétexte de "s'amuser et de jouer avec la technologie". Le nœud maître n'a pas obtenu la bonne adresse IP lors de l'exécution de nslookup localhost.

Merci à @kachkaev pour la solution.