docs fr: setup: idenpendent: fixed peirra , yohan and sieben comments (#12742)
This commit is contained in:
lledru
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
d191cb8408
commit
adfaf7a816
@@ -0,0 +1,285 @@
|
||||
---
|
||||
title: Dépanner kubeadm
|
||||
content_template: templates/concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
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:
|
||||
|
||||
- Si vous pensez que votre problème est un bug avec kubeadm:
|
||||
- Aller à [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) et rechercher
|
||||
les problèmes existants.
|
||||
- Si aucune issue n'existe, veuillez [en ouvrir une](https://github.com/kubernetes/kubeadm/issues/new) et
|
||||
suivez le modèle ( template ) d'issue
|
||||
|
||||
- Si vous ne savez pas comment fonctionne kubeadm, vous pouvez demander sur [Slack](http://slack.k8s.io/)
|
||||
dans le canal #kubeadm, ou posez une questions sur
|
||||
[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Merci d'ajouter les tags pertinents
|
||||
comme `#kubernetes` et `#kubeadm`, ainsi on pourra vous aider.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## `ebtables` ou un exécutable similaire introuvable lors de l'installation
|
||||
|
||||
Si vous voyez les warnings suivants lors de l'exécution `kubeadm init`
|
||||
|
||||
```sh
|
||||
[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:
|
||||
|
||||
- For Ubuntu/Debian users, run `apt install ebtables ethtool`.
|
||||
- For CentOS/Fedora users, run `yum install ebtables ethtool`.
|
||||
|
||||
## kubeadm reste bloqué en attente du control plane pendant l'installation
|
||||
|
||||
Si vous remarquez que `kubeadm init` se bloque après la ligne suivante:
|
||||
|
||||
```sh
|
||||
[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:
|
||||
|
||||
- problèmes de connexion réseau. Vérifiez que votre machine dispose d'une connectivité réseau
|
||||
complète avant de continuer.
|
||||
- la configuration du driver cgroup par défaut pour la kubelet diffère de celle utilisée par Docker.
|
||||
Vérifiez le fichier journal du système (par exemple, `/var/log/message`) ou examinez le résultat
|
||||
de `journalctl -u kubelet`. Si vous voyez quelque chose comme ce qui suit:
|
||||
|
||||
```shell
|
||||
error: failed to run Kubelet: failed to create kubelet:
|
||||
misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
|
||||
```
|
||||
|
||||
Il existe deux méthodes courantes pour résoudre le problème du driver cgroup:
|
||||
|
||||
1. Installez à nouveau Docker en suivant les instructions
|
||||
[ici](/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
1. 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](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
|
||||
pour des instruction détaillées.
|
||||
|
||||
- Les conteneurs Docker du control plane sont en crashloop ou suspendus. Vous pouvez le vérifier en lançant `docker ps` et étudier chaque conteneur en exécutant `docker logs`.
|
||||
|
||||
## 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:
|
||||
|
||||
```bash
|
||||
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`:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart docker.service
|
||||
sudo kubeadm reset
|
||||
```
|
||||
|
||||
L'inspection des journaux de Docker peut également être utile:
|
||||
|
||||
```sh
|
||||
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.
|
||||
|
||||
- S'il existe des pods dans l'un de ces états _juste après_ `kubeadm init`, veuillez ouvrir un
|
||||
issue dans le dépôt de Kubeadm. `coredns` (ou` kube-dns`) devrait être dans l'état `Pending`
|
||||
jusqu'à ce que vous ayez déployé la solution réseau.
|
||||
- Si vous voyez des pods dans les états `RunContainerError`,` CrashLoopBackOff` ou `Error`
|
||||
après le déploiement de la solution réseau et que rien ne se passe pour `coredns` (ou` kube-dns`),
|
||||
il est très probable que la solution Pod Network que vous avez installée est en quelque sorte
|
||||
endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version
|
||||
plus récente. S'il vous plaît créez une issue dans le dépôt du fournisseur de réseau de Pod.
|
||||
- Si vous installez une version de Docker antérieure à 1.12.1, supprimez l'option `MountFlags = slave`
|
||||
lors du démarrage de `dockerd` avec` systemd` et redémarrez `docker`. Vous pouvez voir les options
|
||||
de montage dans `/usr/lib/systemd/system/docker.service`.
|
||||
Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les
|
||||
pods dans l'état`CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
|
||||
`var/run/secrets/kubernetes.io/serviceaccount`.
|
||||
|
||||
## `coredns` (ou` kube-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](/docs/concepts/cluster-administration/addons/)
|
||||
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` et` HostIP` sont disponibles.
|
||||
|
||||
Les fournisseurs de CNI Calico, Canal, et Flannel supportent HostPort.
|
||||
|
||||
Pour plus d'informations, voir la [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
|
||||
|
||||
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](/docs/concepts/services-networking/service/#nodeport) ou utiliser `HostNetwork=true`.
|
||||
|
||||
## Les pods ne sont pas accessibles via leur IP de service
|
||||
|
||||
- De nombreux add-ons réseau ne permettent pas encore
|
||||
[hairpin mode](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
|
||||
qui permet aux pods d’accéder à eux-mêmes via leur IP de service. Ceci est un problème lié
|
||||
au [CNI](https://github.com/containernetworking/cni/issues/476). S'il vous plaît contacter
|
||||
le fournisseur d'add-on réseau afin d'obtenir des informations en matière de prise en charge du mode hairpin.
|
||||
|
||||
- Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que
|
||||
`hostname -i` renvoie une adresse IP routable. Par défaut la première interface est connectée
|
||||
à un réseau d’`hôte uniquement` non routable. En contournement vous pouvez modifier`/etc/hosts`,
|
||||
jetez un œil à ce [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) par exemple.
|
||||
|
||||
## Erreurs de certificats TLS
|
||||
|
||||
L'erreur suivante indique une possible incompatibilité de certificat.
|
||||
|
||||
```none
|
||||
# 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")
|
||||
```
|
||||
|
||||
- Vérifiez que le fichier `$HOME/.kube/config` contient un certificat valide, et
|
||||
re-générer un certificat si nécessaire. Les certificats dans un fichier kubeconfig
|
||||
sont encodés en base64. La commande `base64 -d` peut être utilisée pour décoder le certificat
|
||||
et `openssl x509 -text -noout` peut être utilisé pour afficher les informations du certificat.
|
||||
- Une autre solution consiste à écraser le `kubeconfig` existant pour l'utilisateur" admin ":
|
||||
|
||||
```sh
|
||||
mv $HOME/.kube $HOME/.kube.bak
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
sudo chown $(id -u):$(id -g) $HOME/.kube/config
|
||||
```
|
||||
|
||||
## 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:
|
||||
|
||||
```sh
|
||||
Error from server (NotFound): the server could not find the requested resource
|
||||
```
|
||||
|
||||
- Si vous utilisez flannel comme réseau de pod dans Vagrant, vous devrez spécifier le
|
||||
nom d'interface par défaut pour flannel.
|
||||
|
||||
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` et` kubectl run` peuvent
|
||||
renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel:
|
||||
|
||||
```sh
|
||||
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
|
||||
```
|
||||
|
||||
- Cela peut être dû au fait que Kubernetes utilise une adresse IP qui ne peut pas communiquer
|
||||
avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une politique mise en place
|
||||
par le fournisseur de la machine.
|
||||
- Digital Ocean attribue une adresse IP publique à `eth0` ainsi qu’une adresse privée à
|
||||
utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais `kubelet` choisira cette
|
||||
dernière comme` InternalIP` du noeud au lieu du public.
|
||||
|
||||
Utilisez `ip addr show` pour verifier ce scénario au lieu de` ifconfig` 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:
|
||||
|
||||
```sh
|
||||
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](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) peut être utilisé pour cela.
|
||||
|
||||
Puis redémarrer la `kubelet`:
|
||||
|
||||
```sh
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
## Les pods `coredns` sont en état` CrashLoopBackOff` 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:
|
||||
|
||||
- Mise à niveau vers une [nouvelle version de Docker](/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
- [Désactiver SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
|
||||
- Modifiez le déploiement de `coredns` pour définir` allowPrivilegeEscalation` à `true`:
|
||||
|
||||
```bash
|
||||
kubectl -n kube-system get deployment coredns -o yaml | \
|
||||
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
|
||||
kubectl apply -f -
|
||||
```
|
||||
|
||||
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](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
|
||||
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.
|
||||
|
||||
{{< warning >}}
|
||||
Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur` true` peut compromettre
|
||||
la sécurité de votre cluster.
|
||||
{{< /warning >}}
|
||||
|
||||
## 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.:
|
||||
|
||||
- Revenir à une version antérieure de Docker, telle que la 1.13.1-75:
|
||||
```
|
||||
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
|
||||
```
|
||||
|
||||
- Installez l'une des versions les plus récentes recommandées, telles que la 18.06:
|
||||
```bash
|
||||
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user