Apprendre les bases de Kubernetes

Installation

Kubernetes v1.15 documentation non maintenue. Vous consultez une version statique. Pour une documentation à jour, veuillez consulter: dernière version.

Edit This Page

Dépanner kubeadm

Comme avec n’importe quel programme, vous pourriez rencontrer une erreur lors de l’installation ou de l’exécution de kubeadm. Cette page répertorie certains scénarios d’échec courants et propose des étapes pouvant vous aider à comprendre et résoudre le problème.

Si votre problème ne figure pas dans la liste ci-dessous, procédez comme suit:

ebtables ou un exécutable similaire introuvable lors de l’installation

Si vous voyez les warnings suivants lors de l’exécution kubeadm init

[preflight] WARNING: ebtables not found in system path
[preflight] WARNING: ethtool not found in system path

Ensuite, il peut vous manquer ebtables, ethtool ou un exécutable similaire sur votre nœud. Vous pouvez l’installer avec les commandes suivantes:

kubeadm reste bloqué en attente du control plane pendant l’installation

Si vous remarquez que kubeadm init se bloque après la ligne suivante:

[apiclient] Created API client, waiting for the control plane to become ready

Cela peut être causé par un certain nombre de problèmes. Les plus communs sont:

Il existe deux méthodes courantes pour résoudre le problème du driver cgroup:

  1. Installez à nouveau Docker en suivant les instructions ici.
  2. Changez manuellement la configuration de la kubelet pour correspondre au driver Docker cgroup, vous pouvez vous référer à     Configurez le driver de cgroupe utilisé par la kubelet sur le Nœud Master pour des instruction détaillées.

kubeadm bloque lors de la suppression de conteneurs gérés

Les événements suivants peuvent se produire si Docker s’arrête et ne supprime pas les conteneurs gérés par Kubernetes:

sudo kubeadm reset
[preflight] Running pre-flight checks
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Removing kubernetes-managed containers
(block)

Une solution possible consiste à redémarrer le service Docker, puis à réexécuter kubeadm reset:

sudo systemctl restart docker.service
sudo kubeadm reset

L’inspection des journaux de Docker peut également être utile:

journalctl -ul docker

Pods dans l’état RunContainerError,CrashLoopBackOff ou Error

Juste après kubeadm init, il ne devrait pas y avoir de pods dans ces états.

coredns (oukube-dns) est bloqué dans l’état Pending

Ceci est prévu et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur de réseau, ainsi l’administrateur devrait installer la solution réseau pod de choix. Vous devez installer un réseau de pods avant que CoreDNS ne soit complètement déployé. D’où l’ état Pending avant la mise en place du réseau.

Les services HostPort ne fonctionnent pas

Les fonctionnalités HostPort et HostIP sont disponibles en fonction de votre fournisseur de réseau de pod. Veuillez contacter l’auteur de la solution de réseau de Pod pour savoir si Les fonctionnalités HostPort etHostIP sont disponibles.

Les fournisseurs de CNI Calico, Canal, et Flannel supportent HostPort.

Pour plus d’informations, voir la CNI portmap documentation.

Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, vous devrez peut-être utiliser le NodePort feature of services ou utiliser HostNetwork=true.

Les pods ne sont pas accessibles via leur IP de service

Erreurs de certificats TLS

L’erreur suivante indique une possible incompatibilité de certificat.

# kubectl get pods
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of 
"crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

Carte réseau par défaut lors de l’utilisation de flannel comme réseau de pod dans Vagrant

L’erreur suivante peut indiquer que quelque chose n’allait pas dans le réseau de pod:

Error from server (NotFound): the server could not find the requested resource

  Vagrant attribue généralement deux interfaces à tous les ordinateurs virtuels. La première, pour laquel tous les hôtes se voient attribuer l’adresse IP 10.0.2.15, est pour le trafic externe qui est NATé.

  Cela peut entraîner des problèmes avec Flannel, qui utilise par défaut la première interface sur un hôte. Ceci conduit au fait que tous les hôtes pensent qu’ils ont la même adresse IP publique. Pour éviter cela, passez l’option --iface eth1 sur Flannel pour que la deuxième interface soit choisie.

IP non publique utilisée pour les conteneurs

Dans certaines situations, les commandes kubectl logs etkubectl run peuvent
renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel:

Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: 
dial tcp 10.19.0.41:10250: getsockopt: no route to host

Utilisez ip addr show pour verifier ce scénario au lieu deifconfig car ifconfig n’affichera pas l’alias de l’adresse IP incriminée. Sinon, une API spécifique à Digital Ocean  permet de rechercher l’adresse IP d’ancrage à partir du droplet:

  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address

La solution consiste à indiquer à la kubelet l’adresse IP à utiliser avec--node-ip. Lors de l’utilisation de Digital Ocean, il peut être public (assigné à eth0) ou privé (assigné àeth1) si vous voulez utiliser le réseau privé optionnel. la la section KubeletExtraArgs de kubeadm NodeRegistrationOptions structure peut être utilisé pour cela.

Puis redémarrer la kubelet:

  systemctl daemon-reload
  systemctl restart kubelet

Les pods coredns sont en étatCrashLoopBackOff ou Error

Si vous avez des nœuds qui exécutent SELinux avec une version plus ancienne de Docker, vous risquez de rencontrer un problème ou les pods de coredns ne démarrent pas. Pour résoudre ce problème, vous pouvez essayer l’une des options suivantes:

une autre raison pour laquelle CoreDNS peut se retrouver dans l’état CrashLoopBackOff est lorsqu’un Pod de CoreDNS déployé dans Kubernetes détecte une boucle. Un certain nombre de solutions de contournement sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s’arrête.

Attention: Désactiver SELinux ou paramètrer allowPrivilegeEscalation surtrue peut compromettre la sécurité de votre cluster.

Les pods etcd redémarrent continuellement

Si vous rencontrez l’erreur suivante:

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container 
process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection 
reset by peer\""

ce problème apparaît si vous exécutez CentOS 7 avec Docker 1.13.1.84. Cette version de Docker peut empêcher la kubelet de s’exécuter dans le conteneur etcd.

Pour contourner le problème, choisissez l’une de ces options.:

Feedback