Je construis un cluster Kubernetes en suivant ce tutoriel a >, et j'ai du mal à accéder au tableau de bord Kubernetes. J'ai déjà créé une autre question à ce sujet que vous pouvez voir ici , mais en creusant dans mon cluster, je pense que le problème pourrait être ailleurs et c'est pourquoi je crée une nouvelle question.
Je démarre mon maître, en exécutant les commandes suivantes:
kubectl -n kube-system get pod NAME READY STATUS RESTARTS AGE coredns-fb8b8dccf-kb2zq 0/1 Pending 0 40m coredns-fb8b8dccf-nnc5n 0/1 Pending 0 40m etcd-kubemaster 1/1 Running 0 38m kube-apiserver-kubemaster 1/1 Running 0 38m kube-controller-manager-kubemaster 1/1 Running 0 39m kube-proxy-lxhvs 1/1 Running 0 40m kube-proxy-xllx4 0/1 ContainerCreating 0 27m kube-scheduler-kubemaster 1/1 Running 0 38m kubernetes-dashboard-5f7b999d65-qn8qn 1/1 Pending 0 8s
Ici, nous pouvons voir que j'ai deux pods coredns bloqués dans l'état Pending pour toujours, et quand j'exécute la commande:
> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml
Je peux voir dans la partie Événements, l'avertissement suivant:
docker image ls REPOSITORY TAG k8s.gcr.io/kube-proxy v1.14.1 k8s.gcr.io/kube-apiserver v1.14.1 k8s.gcr.io/kube-controller-manager v1.14.1 k8s.gcr.io/kube-scheduler v1.14.1 k8s.gcr.io/coredns 1.3.1 k8s.gcr.io/etcd 3.3.10 k8s.gcr.io/pause 3.1
Puisqu'il s'agit d'un avertissement et non d'une erreur, et qu'en tant que débutant de Kubernetes, taints ne le fait pas signifie beaucoup pour moi, j'ai essayé de connecter un nœud au maître (en utilisant la commande précédemment enregistrée):
Failed create pod sandbox : rpx error: code = Unknown desc = failed pulling image "k8s.gcr.io/pause:3.1": Get https://k8s.gcr.io/v1/_ping: dial tcp: lookup k8s.gcr.io on [::1]:53 read up [::1]43133->[::1]:53: read: connection refused
Sur le maître, je vérifie que le nœud est connecté:
kubectl -n kube-system describe pod kube-proxy-xllx4
Et je vérifie mes pods:
> kubectl -n kube-system get pod NAME READY STATUS RESTARTS AGE coredns-fb8b8dccf-kb2zq 0/1 Pending 0 14m coredns-fb8b8dccf-nnc5n 0/1 Pending 0 14m etcd-kubemaster 1/1 Running 0 13m kube-apiserver-kubemaster 1/1 Running 0 13m kube-controller-manager-kubemaster 1/1 Running 0 13m kube-proxy-lxhvs 1/1 Running 0 14m kube-proxy-xllx4 0/1 ContainerCreating 0 2m16s kube-scheduler-kubemaster 1/1 Running 0 13m
Nous pouvons voir qu'un autre pod kube-proxy a été créé et est bloqué dans Statut de ContainerCreating.
Et quand je refais une description:
> kubectl get nodes NAME STATUS ROLES AGE VERSION kubemaster NotReady master 13m v1.14.1 kubeslave1 NotReady <none> 31s v1.14.1
Je peux voir dans la partie Événements plusieurs avertissements identiques:
XXX
Voici mes dépôts:
> cat join.sh
kubeadm join [MASTER_IP]:6443 --token [TOKEN] \
--discovery-token-ca-cert-hash sha256:[ANOTHER_TOKEN]
> ssh [USER]@[WORKER_IP] 'bash' < join.sh
This node has joined the cluster.
Et donc, pour la partie tableau de bord, j'ai essayé de le démarrer avec la commande
Failed Scheduling : 0/1 nodes are available 1 node(s) had taints that the pod didn't tolerate.
Mais le module du tableau de bord est bloqué à l'état En attente.
> kubectl -n kube-system describe pod coredns-fb8b8dccf-kb2zq
Donc, bien que mon problème à l'origine, je ne puisse pas accéder à mon tableau de bord, je suppose que le vrai problème est plus profond que cela.
Je sais que je viens de mettre beaucoup d'informations ici, mais je suis un débutant en k8 et je suis complètement perdu sur ce point.
3 Réponses :
En fait, c'est l'opposé d'un problème profond ou sérieux. C'est un problème trivial. Vous voyez toujours un pod bloqué sur l'état En attente , cela signifie que le planificateur a du mal à planifier le pod; principalement parce qu'il n'y a pas assez de ressources sur le nœud.
Dans votre cas, c'est un taint qui a le nœud, et votre pod n'a pas la tolérance. Ce que vous devez faire est de décrire le nœud et d’obtenir l’état:
kubectl taint node NODE key-
Remarque: vous pouvez en avoir plus d’une. Donc, vous voudrez peut-être faire kubectl describe no NODE car avec grep vous ne verrez qu'une seule teinte.
Une fois que vous aurez la souillure, ce sera quelque chose comme hello = monde: NoSchedule ; ce qui signifie key = value: effect , vous devrez ajouter une section tolérance dans votre déploiement . Voici un exemple de Déploiement afin que vous puissiez voir à quoi cela devrait ressembler:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 10
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
name: http
tolerations:
- effect: NoExecute #NoSchedule, PreferNoSchedule
key: node
operator: Equal
value: not-ready
tolerationSeconds: 3600
Comme vous pouvez le voir, il y a la section de tolérance dans le yaml. Donc, si j'aurais un nœud avec node = not-ready: NoExecute taint, aucun pod ne pourrait être planifié sur ce nœud, à moins d'avoir cette tolérance.
Vous pouvez également supprimer le taint , si vous n'en avez pas besoin. Pour supprimer une souillure , vous décririez le nœud, récupérez la clé de la souillure et faites:
kubectl describe node | grep -i taints
J'espère logique. Ajoutez simplement cette section à votre déploiement, et cela fonctionnera.
Merci pour votre réponse ! Sur mon nœud kubemaster, j'ai les teintes suivantes: node.kubernetes.io/not-ready:NoExecute , node-role.kubernetes.io/master:NoSchedule , < code> node.kubernetes.io/not-ready:NoSchedule . Ce que je ne comprends pas, c'est que j'ai uniquement exécuté la commande kubeadm init --apiserver-advertise-address = [MASTER_IP] . Je n'ai pas de fichier YAML à ce stade. Dois-je créer un nouveau fichier de déploiement?
Ouais, ces souillures ont du sens. Il s'agit de s'assurer qu'aucun pod ne fonctionnera sur le nœud maître (si ce n'est pas prévu), et qu'aucun pod ne devrait s'exécuter sur un nœud avec certains problèmes (nœud non prêt). Ajoutez simplement les tolérances comme expliqué à vos déploiements (par exemple core-dns), et cela devrait fonctionner. P.S. votre problème n'a rien à voir avec les plugins réseau. Au moins celui-ci que vous décrivez.
Eh bien, en fait, le fait est que mes coredns sont bloqués en attente avec un avertissement concernant les taches non tolérées, et dès que j'ai correctement démarré un plugin réseau, le statut des coredns passe à Running. Je ne sais pas si cela a du sens, mais c'est ce qui s'est passé.
Cela n'a aucun sens pour moi. À moins que votre nœud ne soit corrompu car pas prêt car le plugin n'a pas été installé. Dans ce cas, la souillure serait supprimée une fois que le nœud est prêt. Si vous exécutez kubectl describe node NODE , vous avez toujours les teintes?
Maintenant, je n'ai plus que le node-role.kubernetes.io/master:NoSchedule
Cela a du sens pour moi. Le nœud était dynamiquement corrompu.
J'ai rencontré un problème avec les pods coredns bloqués en mode en attente lors de la configuration de votre propre cluster; que je résout en ajoutant un réseau de pod.
On dirait qu'il n'y a pas de Network Addon installé, les nœuds sont corrompus car pas prêts . L'installation de l'addon supprimerait les taches et les pods pourront planifier. Dans mon cas, l'ajout de flanelle a résolu le problème.
EDIT: Il y a une note à ce sujet dans le documentation k8s - Créer un cluster avec kubeadm :
Le réseau doit être déployé avant toute application. Aussi, CoreDNS ne démarrera pas avant l'installation d'un réseau. kubeadm uniquement prend en charge les réseaux CNI (Container Network Interface) (et ne prend pas en charge kubenet).
N'est-ce pas à cela que sert kubectl apply -f https://git.io/weave-kube/ ?
J'ai remplacé la commande précédente par kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\ n')" , et maintenant weave-net apparaissent dans mes pods. Et depuis, mes pods de coredns ont commencé par magie à courir (comme vous l'avez dit :))
cela dépend de la façon dont vous allez "installer" votre pod-network . Heureux d'avoir été utile
Configurez l'outil de réseau Flannel.
Exécution des commandes:
$ sysctl net.bridge.bridge-nf-call-iptables=1 $ kubectl apply -f