Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
3b10c76ca7
commit
2a120450eb
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Déployer des clusters avec kubeadm
|
||||
description: Déploiement cluster Kubernetes kubeadm
|
||||
description: Déploiement cluster Kubernetes kubeadm
|
||||
weight: 30
|
||||
---
|
||||
|
||||
@@ -9,16 +9,16 @@ weight: 40
|
||||
|
||||
{{< feature-state for_k8s_version="1.12" state="stable" >}}
|
||||
|
||||
L'objet `ClusterConfiguration` de kubeadm expose le champ `extraArgs` qui peut
|
||||
remplacer les indicateurs par défaut transmis au control plane à des composants
|
||||
tels que l'APIServer, le ControllerManager et le Scheduler. Les composants sont
|
||||
L'objet `ClusterConfiguration` de kubeadm expose le champ `extraArgs` qui peut
|
||||
remplacer les indicateurs par défaut transmis au control plane à des composants
|
||||
tels que l'APIServer, le ControllerManager et le Scheduler. Les composants sont
|
||||
définis à l'aide des champs suivants:
|
||||
|
||||
- `apiServer`
|
||||
- `controllerManager`
|
||||
- `scheduler`
|
||||
|
||||
Le champ `extraArgs` se compose de paires` clé: valeur`. Pour remplacer un indicateur
|
||||
Le champ `extraArgs` se compose de paires` clé: valeur`. Pour remplacer un indicateur
|
||||
pour un composant du control plane:
|
||||
|
||||
1. Ajoutez les champs appropriés à votre configuration.
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 50
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Cette page explique les deux options de configuration de topologie de vos clusters Kubernetes
|
||||
Cette page explique les deux options de configuration de topologie de vos clusters Kubernetes
|
||||
pour la haute disponibilité.
|
||||
|
||||
Vous pouvez configurer un cluster en haute disponibilité:
|
||||
@@ -15,7 +15,7 @@ Vous pouvez configurer un cluster en haute disponibilité:
|
||||
- Avec des nœuds du control plane empilés, les nœuds etcd étant co-localisés avec des nœuds du control plane
|
||||
- Avec des nœuds etcd externes, où etcd s'exécute sur des nœuds distincts du control plane
|
||||
|
||||
Vous devez examiner attentivement les avantages et les inconvénients de chaque topologie avant
|
||||
Vous devez examiner attentivement les avantages et les inconvénients de chaque topologie avant
|
||||
de configurer un cluster en haute disponibilité.
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -23,11 +23,11 @@ de configurer un cluster en haute disponibilité.
|
||||
|
||||
## Topologie etcd empilée
|
||||
|
||||
Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau)
|
||||
où le cluster de stockage de données distribuées est fourni par etcd et est superposé au
|
||||
Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau)
|
||||
où le cluster de stockage de données distribuées est fourni par etcd et est superposé au
|
||||
cluster formé par les noeuds gérés par kubeadm qui exécute les composants du control plane.
|
||||
|
||||
Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et
|
||||
Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et
|
||||
`kube-controller-manager`.
|
||||
Le `kube-apiserver` est exposé aux nœuds à l'aide d'un loadbalancer.
|
||||
|
||||
@@ -35,15 +35,15 @@ Chaque nœud du control plane crée un membre etcd local et ce membre etcd commu
|
||||
le `kube-apiserver` de ce noeud. Il en va de même pour le `kube-controller-manager` local
|
||||
et les instances de `kube-scheduler`.
|
||||
|
||||
Cette topologie couple les control planes et les membres etcd sur les mêmes nœuds. C'est
|
||||
plus simple à mettre en place qu'un cluster avec des nœuds etcd externes et plus simple à
|
||||
Cette topologie couple les control planes et les membres etcd sur les mêmes nœuds. C'est
|
||||
plus simple à mettre en place qu'un cluster avec des nœuds etcd externes et plus simple à
|
||||
gérer pour la réplication.
|
||||
|
||||
Cependant, un cluster empilé présente un risque d'échec du couplage. Si un noeud tombe en panne,
|
||||
un membre etcd et une instance du control plane sont perdus et la redondance est compromise. Vous
|
||||
Cependant, un cluster empilé présente un risque d'échec du couplage. Si un noeud tombe en panne,
|
||||
un membre etcd et une instance du control plane sont perdus et la redondance est compromise. Vous
|
||||
pouvez atténuer ce risque en ajoutant plus de nœuds au control plane.
|
||||
|
||||
Par conséquent, vous devez exécuter au moins trois nœuds de control plane empilés pour un cluster
|
||||
Par conséquent, vous devez exécuter au moins trois nœuds de control plane empilés pour un cluster
|
||||
en haute disponibilité.
|
||||
|
||||
C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement
|
||||
@@ -53,18 +53,18 @@ Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stac
|
||||
|
||||
## Topologie etcd externe
|
||||
|
||||
Un cluster haute disponibilité avec un etcd externe est une
|
||||
[topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) où le cluster de stockage de données
|
||||
distribué fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
|
||||
Un cluster haute disponibilité avec un etcd externe est une
|
||||
[topologie réseau](https://fr.wikipedia.org/wiki/Topologie_de_r%C3%A9seau) où le cluster de stockage de données
|
||||
distribué fourni par etcd est externe au cluster formé par les nœuds qui exécutent les composants
|
||||
du control plane.
|
||||
|
||||
Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
|
||||
une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
|
||||
est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
|
||||
Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
|
||||
une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
|
||||
est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
|
||||
des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane.
|
||||
|
||||
Cette topologie dissocie le control plane et le membre etcd. Il fournit donc une configuration HA où
|
||||
perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du
|
||||
perdre une instance de control plane ou un membre etcd a moins d'impact et n'affecte pas la redondance du
|
||||
cluster autant que la topologie HA empilée.
|
||||
|
||||
Cependant, cette topologie requiert le double du nombre d'hôtes de la topologie HA integrée.
|
||||
|
||||
@@ -10,19 +10,19 @@ weight: 60
|
||||
Cette page explique deux approches différentes pour configurer un Kubernetes à haute disponibilité.
|
||||
cluster utilisant kubeadm:
|
||||
|
||||
- Avec des nœuds de control plane empilés. Cette approche nécessite moins d'infrastructure.
|
||||
- Avec des nœuds de control plane empilés. Cette approche nécessite moins d'infrastructure.
|
||||
Les membres etcd et les nœuds du control plane sont co-localisés.
|
||||
- Avec un cluster etcd externe cette approche nécessite plus d'infrastructure.
|
||||
- Avec un cluster etcd externe cette approche nécessite plus d'infrastructure.
|
||||
Les nœuds du control plane et les membres etcd sont séparés.
|
||||
|
||||
Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux
|
||||
aux besoins de vos applications et de l'environnement. [Cette comparaison](/docs/setup/independent/ha-topology/)
|
||||
Avant de poursuivre, vous devez déterminer avec soin quelle approche répond le mieux
|
||||
aux besoins de vos applications et de l'environnement. [Cette comparaison](/docs/setup/independent/ha-topology/)
|
||||
décrit les avantages et les inconvénients de chacune.
|
||||
|
||||
Vos clusters doivent exécuter Kubernetes version 1.12 ou ultérieure. Vous devriez aussi savoir que
|
||||
la mise en place de clusters HA avec kubeadm est toujours expérimentale et sera simplifiée davantage
|
||||
dans les futures versions. Vous pouvez par exemple rencontrer des problèmes lors de la mise à niveau de vos clusters.
|
||||
Nous vous encourageons à essayer l’une ou l’autre approche et à nous faire part de vos commentaires dans
|
||||
Nous vous encourageons à essayer l’une ou l’autre approche et à nous faire part de vos commentaires dans
|
||||
[Suivi des problèmes Kubeadm](https://github.com/kubernetes/kubeadm/issues/new).
|
||||
|
||||
Notez que la fonctionnalité alpha `HighAvailability` est obsolète dans la version 1.12 et supprimée dans la version 1.13
|
||||
@@ -30,7 +30,7 @@ Notez que la fonctionnalité alpha `HighAvailability` est obsolète dans la vers
|
||||
Voir aussi [La documentation de mise à niveau HA](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13).
|
||||
|
||||
{{< caution >}}
|
||||
Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un
|
||||
Cette page ne traite pas de l'exécution de votre cluster sur un fournisseur de cloud. Dans un
|
||||
environnement Cloud, les approches documentées ici ne fonctionne ni avec des objets de type
|
||||
load balancer, ni avec des volumes persistants dynamiques.
|
||||
{{< /caution >}}
|
||||
@@ -69,7 +69,7 @@ Toutes les commandes d'un control plane ou d'un noeud etcd doivent être
|
||||
{{< /note >}}
|
||||
|
||||
- Certains plugins réseau CNI tels que Calico nécessitent un CIDR tel que `192.168.0.0 / 16` et
|
||||
certains comme Weave n'en ont pas besoin. Voir la
|
||||
certains comme Weave n'en ont pas besoin. Voir la
|
||||
[Documentation du CNI réseau](/docs/setup/independent/create-cluster-kubeadm/#pod-network).
|
||||
Pour ajouter un CIDR de pod, définissez le champ `podSubnet: 192.168.0.0 / 16` sous
|
||||
l'objet `networking` de` ClusterConfiguration`.
|
||||
@@ -77,20 +77,20 @@ certains comme Weave n'en ont pas besoin. Voir la
|
||||
### Créez un load balancer pour kube-apiserver
|
||||
|
||||
{{< note >}}
|
||||
Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer).
|
||||
Il existe de nombreuses configurations pour les équilibreurs de charge (load balancer).
|
||||
L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent nécessiter une configuration différente.
|
||||
{{< /note >}}
|
||||
|
||||
1. Créez un load balancer kube-apiserver avec un nom résolu en DNS.
|
||||
|
||||
- Dans un environnement cloud, placez vos nœuds du control plane derrière un load balancer TCP.
|
||||
Ce load balancer distribue le trafic à tous les nœuds du control plane sains dans sa liste.
|
||||
La vérification de la bonne santé d'un apiserver est une vérification TCP sur le port que
|
||||
- Dans un environnement cloud, placez vos nœuds du control plane derrière un load balancer TCP.
|
||||
Ce load balancer distribue le trafic à tous les nœuds du control plane sains dans sa liste.
|
||||
La vérification de la bonne santé d'un apiserver est une vérification TCP sur le port que
|
||||
kube-apiserver écoute (valeur par défaut: `6443`).
|
||||
|
||||
- Il n'est pas recommandé d'utiliser une adresse IP directement dans un environnement cloud.
|
||||
|
||||
- Le load balancer doit pouvoir communiquer avec tous les nœuds du control plane sur le
|
||||
- Le load balancer doit pouvoir communiquer avec tous les nœuds du control plane sur le
|
||||
port apiserver. Il doit également autoriser le trafic entrant sur son réseau de port d'écoute.
|
||||
|
||||
- [HAProxy](http://www.haproxy.org/) peut être utilisé comme load balancer.
|
||||
@@ -105,7 +105,7 @@ L'exemple suivant n'est qu'un exemple. Vos exigences pour votre cluster peuvent
|
||||
```
|
||||
|
||||
- Une erreur `connection refused` est attendue car l'apiserver n'est pas encore en fonctionnement.
|
||||
Cependant, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du
|
||||
Cependant, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du
|
||||
control plane. Si un timeout survient, reconfigurez le load balancer pour communiquer avec le nœud du control plane.
|
||||
|
||||
1. Ajouter les nœuds du control plane restants au groupe cible du load balancer.
|
||||
@@ -163,18 +163,18 @@ SSH est requis si vous souhaitez contrôler tous les nœuds à partir d'une seul
|
||||
```sh
|
||||
sudo kubeadm init --config=kubeadm-config.yaml
|
||||
```
|
||||
|
||||
|
||||
Vous devriez voir quelque chose comme:
|
||||
|
||||
|
||||
```sh
|
||||
...
|
||||
Vous pouvez à présent joindre n'importe quelle machine au cluster en lancant la commande suivante sur
|
||||
Vous pouvez à présent joindre n'importe quelle machine au cluster en lancant la commande suivante sur
|
||||
chaque nœeud en tant que root:
|
||||
|
||||
|
||||
kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
|
||||
```
|
||||
|
||||
1. Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre
|
||||
1. Copiez ce jeton dans un fichier texte. Vous en aurez besoin plus tard pour joindre
|
||||
d’autres nœuds du control plane au cluster.
|
||||
|
||||
1. Activez l'extension CNI Weave:
|
||||
@@ -192,7 +192,7 @@ d’autres nœuds du control plane au cluster.
|
||||
- Il est recommandé de ne joindre les nouveaux nœuds du control plane qu'après l'initialisation du premier nœud.
|
||||
|
||||
1. Copiez les fichiers de certificat du premier nœud du control plane dans les autres:
|
||||
|
||||
|
||||
Dans l'exemple suivant, remplacez `CONTROL_PLANE_IPS` par les adresses IP des autres nœuds du control plane.
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
@@ -211,7 +211,7 @@ d’autres nœuds du control plane au cluster.
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
N'utilisez que les certificats de la liste ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SANs requis pour les instances du control plane qui se joignent.
|
||||
N'utilisez que les certificats de la liste ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SANs requis pour les instances du control plane qui se joignent.
|
||||
Si vous copiez tous les certificats par erreur, la création de noeuds supplémentaires pourrait
|
||||
échouer en raison d'un manque de SANs requis.
|
||||
{{< /caution >}}
|
||||
@@ -236,7 +236,7 @@ Si vous copiez tous les certificats par erreur, la création de noeuds suppléme
|
||||
|
||||
Ce processus écrit tous les fichiers demandés dans le dossier `/etc/kubernetes`.
|
||||
|
||||
1. Lancez `kubeadm join` sur ce nœud en utilisant la commande de join qui vous avait été précédemment
|
||||
1. Lancez `kubeadm join` sur ce nœud en utilisant la commande de join qui vous avait été précédemment
|
||||
donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelque chose
|
||||
comme ça:
|
||||
|
||||
@@ -244,7 +244,7 @@ donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelqu
|
||||
sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
|
||||
```
|
||||
|
||||
- Remarquez l'ajout de l'option `--experimental-control-plane`. Ce paramètre automatise l'adhésion au
|
||||
- Remarquez l'ajout de l'option `--experimental-control-plane`. Ce paramètre automatise l'adhésion au
|
||||
control plane du cluster.
|
||||
|
||||
1. Tapez ce qui suit et observez les pods des composants démarrer:
|
||||
@@ -295,9 +295,9 @@ donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelqu
|
||||
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
|
||||
|
||||
- La différence entre etcd empilé et externe, c’est que nous utilisons le champ `external`
|
||||
pour `etcd` dans la configuration de kubeadm. Dans le cas de la topologie etcd empilée,
|
||||
pour `etcd` dans la configuration de kubeadm. Dans le cas de la topologie etcd empilée,
|
||||
c'est géré automatiquement.
|
||||
|
||||
|
||||
- Remplacez les variables suivantes dans le modèle (template) par les valeurs appropriées
|
||||
pour votre cluster:
|
||||
|
||||
@@ -335,13 +335,13 @@ Pour résumer:
|
||||
### Installer un réseau de pod
|
||||
|
||||
[Suivez ces instructions](/docs/setup/independent/create-cluster-kubeadm/#pod-network) afin
|
||||
d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni
|
||||
d'installer le réseau de pod. Assurez-vous que cela correspond au pod CIDR que vous avez fourni
|
||||
dans le fichier de configuration principal.
|
||||
|
||||
### Installer les workers
|
||||
|
||||
Chaque nœud worker peut maintenant être joint au cluster avec la commande renvoyée à partir du resultat
|
||||
de n’importe quelle commande `kubeadm init`. L'option `--experimental-control-plane` ne doit pas
|
||||
de n’importe quelle commande `kubeadm init`. L'option `--experimental-control-plane` ne doit pas
|
||||
être ajouté aux nœuds workers.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 20
|
||||
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">Cette page vous
|
||||
apprend comment installer la boîte à outils `kubeadm`.
|
||||
Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez
|
||||
Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez
|
||||
effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour créer un cluster](/docs/setup/independent/create-cluster-kubeadm/).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -40,8 +40,8 @@ effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour cré
|
||||
* Vous pouvez obtenir l'adresse MAC des interfaces réseau en utilisant la commande `ip link` ou` ifconfig -a`
|
||||
* Le product_uuid peut être vérifié en utilisant la commande `sudo cat/sys/class/dmi/id/product_uuid`
|
||||
|
||||
Il est très probable que les périphériques matériels aient des adresses uniques, bien que
|
||||
certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise
|
||||
Il est très probable que les périphériques matériels aient des adresses uniques, bien que
|
||||
certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise
|
||||
ces valeurs pour identifier de manière unique les nœuds du cluster.
|
||||
Si ces valeurs ne sont pas uniques à chaque nœud, le processus d'installation
|
||||
peut [échouer](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
@@ -49,7 +49,7 @@ peut [échouer](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
## Vérifiez les cartes réseaux
|
||||
|
||||
Si vous avez plusieurs cartes réseaux et que vos composants Kubernetes ne sont pas accessibles par la
|
||||
route par défaut, nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses
|
||||
route par défaut, nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses
|
||||
de cluster Kubernetes soient acheminées via la carte approprié.
|
||||
|
||||
## Vérifiez les ports requis {#check-required-ports}
|
||||
@@ -76,7 +76,7 @@ de cluster Kubernetes soient acheminées via la carte approprié.
|
||||
Tous les numéros de port marqués d'un * sont écrasables. Vous devrez donc vous assurer que
|
||||
les ports personnalisés que vous utilisez sont également ouverts.
|
||||
|
||||
Bien que les ports etcd soient inclus dans les nœuds masters, vous pouvez également héberger
|
||||
Bien que les ports etcd soient inclus dans les nœuds masters, vous pouvez également héberger
|
||||
votre propre cluster etcd en externe ou sur des ports personnalisés.
|
||||
|
||||
Le plug-in de réseau de pod que vous utilisez (voir ci-dessous) peut également nécessiter certains ports à ouvrir. Étant donné que cela diffère d’un plugin à l’autre, veuillez vous reporter à la
|
||||
@@ -109,16 +109,16 @@ Vous installerez ces paquets sur toutes vos machines:
|
||||
kubeadm **n'installera pas** ni ne gèrera les `kubelet` ou` kubectl` pour vous.
|
||||
Vous devez vous assurer qu'ils correspondent à la version du control plane de Kubernetes que vous
|
||||
souhaitez que kubeadm installe pour vous. Si vous ne le faites pas, vous risquez qu'
|
||||
une erreur de version se produise, qui pourrait conduire à un comportement inattendu.
|
||||
Cependant, une version mineure entre les kubelets et le control plane est pris en charge,
|
||||
mais la version de la kubelet ne doit jamais dépasser la version de l'API server. Par exemple,
|
||||
les kubelets exécutant la version 1.7.0 devraient être entièrement compatibles avec un API
|
||||
une erreur de version se produise, qui pourrait conduire à un comportement inattendu.
|
||||
Cependant, une version mineure entre les kubelets et le control plane est pris en charge,
|
||||
mais la version de la kubelet ne doit jamais dépasser la version de l'API server. Par exemple,
|
||||
les kubelets exécutant la version 1.7.0 devraient être entièrement compatibles avec un API
|
||||
server en 1.8.0, mais pas l'inverse.
|
||||
|
||||
{{< warning >}}
|
||||
Ces instructions excluent tous les packages Kubernetes de toutes les mises à niveau du système
|
||||
d'exploitation.
|
||||
C’est parce que kubeadm et Kubernetes ont besoin d'une
|
||||
C’est parce que kubeadm et Kubernetes ont besoin d'une
|
||||
[attention particulière lors de la mise à niveau](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/).
|
||||
{{</ warning >}}
|
||||
|
||||
@@ -164,11 +164,11 @@ systemctl enable --now kubelet
|
||||
|
||||
**Note:**
|
||||
|
||||
- Mettre SELinux en mode permissif en lançant `setenforce 0` et `sed ... `le désactive efficacement.
|
||||
C'est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte, qui
|
||||
- Mettre SELinux en mode permissif en lançant `setenforce 0` et `sed ... `le désactive efficacement.
|
||||
C'est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte, qui
|
||||
est nécessaire par exemple pour les réseaux de pod.
|
||||
Vous devez le faire jusqu'à ce que le support de SELinux soit amélioré dans la kubelet.
|
||||
- Certains utilisateurs de RHEL / CentOS 7 ont signalé des problèmes de routage incorrect
|
||||
- Certains utilisateurs de RHEL / CentOS 7 ont signalé des problèmes de routage incorrect
|
||||
du trafic en raison du contournement d'iptables. Vous devez vous assurer que
|
||||
`net.bridge.bridge-nf-call-iptables` est configuré à 1 dans votre config `sysctl` par exemple:
|
||||
|
||||
@@ -230,7 +230,7 @@ kubeadm, pour lui dire quoi faire.
|
||||
Lorsque vous utilisez Docker, kubeadm détecte automatiquement le pilote ( driver ) de cgroup pour la kubelet
|
||||
et le configure dans le fichier `/var/lib/kubelet/kubeadm-flags.env` lors de son éxecution.
|
||||
|
||||
Si vous utilisez un autre CRI, vous devez modifier le fichier `/etc/default/kubelet` avec votre
|
||||
Si vous utilisez un autre CRI, vous devez modifier le fichier `/etc/default/kubelet` avec votre
|
||||
valeur de `cgroup-driver` comme ceci:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 80
|
||||
|
||||
{{< feature-state for_k8s_version="1.11" state="stable" >}}
|
||||
|
||||
Le cycle de vie de l’outil CLI kubeadm est découplé de celui de la
|
||||
Le cycle de vie de l’outil CLI kubeadm est découplé de celui de la
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet), qui est un démon qui s'éxécute
|
||||
sur chaque noeud du cluster Kubernetes. L'outil CLI de kubeadm est exécuté par l'utilisateur lorsque
|
||||
Kubernetes est initialisé ou mis à niveau, alors que la kubelet est toujours exécutée en arrière-plan.
|
||||
@@ -19,11 +19,11 @@ Comme la kubelet est un démon, elle doit être maintenue par une sorte d'init s
|
||||
systemd est configuré pour gérer la kubelet. Vous pouvez utiliser un gestionnaire différent à la place,
|
||||
mais vous devez le configurer manuellement.
|
||||
|
||||
Certains détails de configuration de la kubelet doivent être identiques pour
|
||||
toutes les kubelets du cluster, tandis que d’autres aspects de la configuration
|
||||
doivent être définis par nœud, pour tenir compte des différentes caractéristiques
|
||||
d’une machine donnée, telles que le système d’exploitation, le stockage et la
|
||||
mise en réseau. Vous pouvez gérer la configuration manuellement de vos kubelets,
|
||||
Certains détails de configuration de la kubelet doivent être identiques pour
|
||||
toutes les kubelets du cluster, tandis que d’autres aspects de la configuration
|
||||
doivent être définis par nœud, pour tenir compte des différentes caractéristiques
|
||||
d’une machine donnée, telles que le système d’exploitation, le stockage et la
|
||||
mise en réseau. Vous pouvez gérer la configuration manuellement de vos kubelets,
|
||||
mais [kubeadm fournit maintenant un type d’API `KubeletConfiguration` pour la gestion centralisée de vos configurations de kubelets](#configure-kubelets-using-kubeadm).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -32,7 +32,7 @@ mais [kubeadm fournit maintenant un type d’API `KubeletConfiguration` pour la
|
||||
|
||||
## Patterns de configuration des Kubelets
|
||||
|
||||
Les sections suivantes décrivent les modèles de configuration de kubelet simplifiés en
|
||||
Les sections suivantes décrivent les modèles de configuration de kubelet simplifiés en
|
||||
utilisant kubeadm, plutôt que de gérer manuellement la configuration des kubelets pour chaque nœud.
|
||||
|
||||
### Propagation de la configuration niveau cluster à chaque kubelet {#propagating-cluster-level-configuration-to-each-kubelet}
|
||||
@@ -50,11 +50,11 @@ kubeadm init --service-cidr 10.96.0.0/12
|
||||
|
||||
Les adresses IP virtuelles pour les services sont maintenant attribuées à partir de ce sous-réseau.
|
||||
Vous devez également définir l'adresse DNS utilisée par la kubelet, en utilisant l'option
|
||||
`--cluster-dns`. Ce paramètre doit être le même pour chaque kubelet sur chaque master et worker
|
||||
`--cluster-dns`. Ce paramètre doit être le même pour chaque kubelet sur chaque master et worker
|
||||
du cluster. La kubelet fournit un objet API structuré versionné qui peut configurer la plupart des
|
||||
paramètres dans la kubelet et pousser cette configuration à chaque exécution de la kubelet dans
|
||||
paramètres dans la kubelet et pousser cette configuration à chaque exécution de la kubelet dans
|
||||
le cluster. Cet objet s'appelle la **ComponentConfig** de la kubelet.
|
||||
La ComponentConfig permet à l’utilisateur de spécifier des options tels que les adresses IP DNS du
|
||||
La ComponentConfig permet à l’utilisateur de spécifier des options tels que les adresses IP DNS du
|
||||
cluster exprimées en une liste de valeurs pour une clé formatée en CamelCased, illustrée par l'exemple suivant:
|
||||
|
||||
```yaml
|
||||
@@ -68,41 +68,41 @@ Pour plus de détails sur ComponentConfig, jetez un œil à [cette section](#con
|
||||
|
||||
### Fournir des détails de configuration spécifiques à l'instance {#providing-instance-specific-configuration-details}
|
||||
|
||||
Certaines machines nécessitent des configurations de kubelet spécifiques, en raison de la différences de
|
||||
Certaines machines nécessitent des configurations de kubelet spécifiques, en raison de la différences de
|
||||
matériel, de système d’exploitation, réseau ou d’autres paramètres spécifiques à l’hôte. La liste suivante
|
||||
fournit quelques exemples.
|
||||
|
||||
- Le chemin d'accès au fichier de résolution DNS, tel que spécifié par l'option de configuration
|
||||
de la kubelet `--resolv-conf`, peut différer selon les systèmes d'exploitation ou selon que vous utilisez
|
||||
ou non `systemd-resolved`. Si ce chemin est incorrect, la résolution DNS échouera sur le nœud
|
||||
ou non `systemd-resolved`. Si ce chemin est incorrect, la résolution DNS échouera sur le nœud
|
||||
dont la kubelet est configuré de manière incorrecte.
|
||||
|
||||
- L'objet API de nœud `.metadata.name` est défini par défaut sur le hostname de la machine,
|
||||
- L'objet API de nœud `.metadata.name` est défini par défaut sur le hostname de la machine,
|
||||
sauf si vous utilisez un fournisseur de cloud. Vous pouvez utiliser l’indicateur `--hostname-override`
|
||||
pour remplacer le comportement par défaut si vous devez spécifier un nom de nœud différent du hostname
|
||||
de la machine.
|
||||
|
||||
- Actuellement, la kubelet ne peut pas détecter automatiquement le driver cgroup utilisé par le
|
||||
runtime CRI, mais la valeur de `--cgroup-driver` doit correspondre au driver cgroup
|
||||
- Actuellement, la kubelet ne peut pas détecter automatiquement le driver cgroup utilisé par le
|
||||
runtime CRI, mais la valeur de `--cgroup-driver` doit correspondre au driver cgroup
|
||||
utilisé par le runtime CRI pour garantir la santé de la kubelet.
|
||||
|
||||
- En fonction du runtime du CRI utilisé par votre cluster, vous devrez peut-être spécifier des
|
||||
options différentes pour la kubelet. Par exemple, lorsque vous utilisez Docker,
|
||||
- En fonction du runtime du CRI utilisé par votre cluster, vous devrez peut-être spécifier des
|
||||
options différentes pour la kubelet. Par exemple, lorsque vous utilisez Docker,
|
||||
vous devez spécifier des options telles que
|
||||
`--network-plugin = cni`, mais si vous utilisez un environnement d’exécution externe, vous devez spécifier
|
||||
`--network-plugin = cni`, mais si vous utilisez un environnement d’exécution externe, vous devez spécifier
|
||||
`--container-runtime = remote` et spécifier le CRI endpoint en utilisant l'option
|
||||
`--container-runtime-path-endpoint = <chemin>`.
|
||||
|
||||
Vous pouvez spécifier ces options en modifiant la configuration d’une kubelet individuelle dans
|
||||
Vous pouvez spécifier ces options en modifiant la configuration d’une kubelet individuelle dans
|
||||
votre gestionnaire de service, tel que systemd.
|
||||
|
||||
## Configurer les kubelets en utilisant kubeadm {#configure-kubelets-using-kubeadm}
|
||||
|
||||
Il est possible de configurer la kubelet que kubeadm va démarrer si un objet API personnalisé
|
||||
`KubeletConfiguration` est passé en paramètre via un fichier de configuration comme
|
||||
Il est possible de configurer la kubelet que kubeadm va démarrer si un objet API personnalisé
|
||||
`KubeletConfiguration` est passé en paramètre via un fichier de configuration comme
|
||||
`kubeadm ... --config some-config-file.yaml`.
|
||||
|
||||
En appelant `kubeadm config print-default --api-objects KubeletConfiguration` vous
|
||||
En appelant `kubeadm config print-default --api-objects KubeletConfiguration` vous
|
||||
pouvez voir toutes les valeurs par défaut pour cette structure.
|
||||
|
||||
Regardez aussi la [référence API pour le composant ComponentConfig des kubelets](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
|
||||
@@ -110,16 +110,16 @@ pour plus d'informations sur les champs individuels.
|
||||
|
||||
### Workflow lors de l'utilisation de `kubeadm init`
|
||||
|
||||
Lorsque vous appelez `kubeadm init`, la configuration de la kubelet est organisée sur le disque
|
||||
Lorsque vous appelez `kubeadm init`, la configuration de la kubelet est organisée sur le disque
|
||||
sur `/var/lib/kubelet/config.yaml`, et également chargé sur une ConfigMap du cluster. La ConfigMap
|
||||
est nommé `kubelet-config-1.X`, où `.X` est la version mineure de la version de Kubernetes
|
||||
que vous êtes en train d'initialiser. Un fichier de configuration de kubelet est également écrit dans
|
||||
`/etc/kubernetes/kubelet.conf` avec la configuration de base à l'échelle du cluster pour tous les
|
||||
kubelets du cluster. Ce fichier de configuration pointe vers les certificats clients permettant aux
|
||||
kubelets de communiquer avec l'API server. Ceci répond au besoin de
|
||||
que vous êtes en train d'initialiser. Un fichier de configuration de kubelet est également écrit dans
|
||||
`/etc/kubernetes/kubelet.conf` avec la configuration de base à l'échelle du cluster pour tous les
|
||||
kubelets du cluster. Ce fichier de configuration pointe vers les certificats clients permettant aux
|
||||
kubelets de communiquer avec l'API server. Ceci répond au besoin de
|
||||
[propager la configuration niveau cluster à chaque kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
|
||||
|
||||
Pour répondre au besoin de
|
||||
Pour répondre au besoin de
|
||||
[fournir des détails de configuration spécifiques à l'instance de kubelet](#providing-instance-specific-configuration-details),
|
||||
kubeadm écrit un fichier d'environnement dans `/var/lib/kubelet/kubeadm-flags.env`, qui contient une liste
|
||||
d'options à passer à la kubelet quand elle démarre. Les options sont représentées dans le fichier comme ceci:
|
||||
@@ -128,8 +128,8 @@ d'options à passer à la kubelet quand elle démarre. Les options sont représe
|
||||
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
|
||||
```
|
||||
|
||||
Outre les indicateurs utilisés lors du démarrage de la kubelet, le fichier contient également des
|
||||
informations dynamiques comme des paramètres tels que le driver cgroup et s'il faut utiliser un autre
|
||||
Outre les indicateurs utilisés lors du démarrage de la kubelet, le fichier contient également des
|
||||
informations dynamiques comme des paramètres tels que le driver cgroup et s'il faut utiliser un autre
|
||||
socket de runtime CRI (`--cri-socket`).
|
||||
|
||||
Après avoir rassemblé ces deux fichiers sur le disque, kubeadm tente d’exécuter ces deux commandes,
|
||||
@@ -145,7 +145,7 @@ Si le rechargement et le redémarrage réussissent, le workflow normal de `kubea
|
||||
|
||||
Lorsque vous exécutez `kubeadm join`, kubeadm utilise les informations d'identification du bootstrap
|
||||
token pour faire un bootstrap TLS, qui récupère les informations d’identité nécessaires pour télécharger le
|
||||
`kubelet-config-1.X` ConfigMap puis l'écrit dans `/var/lib/kubelet/config.yaml`. Le fichier d’environnement
|
||||
`kubelet-config-1.X` ConfigMap puis l'écrit dans `/var/lib/kubelet/config.yaml`. Le fichier d’environnement
|
||||
dynamique est généré exactement de la même manière que `kubeadm init`.
|
||||
|
||||
Ensuite, `kubeadm` exécute les deux commandes suivantes pour charger la nouvelle configuration dans la kubelet:
|
||||
@@ -157,7 +157,7 @@ systemctl daemon-reload && systemctl restart kubelet
|
||||
Après le chargement de la nouvelle configuration par la kubelet, kubeadm écrit le fichier KubeConfig
|
||||
`/etc/kubernetes/bootstrap-kubelet.conf`, qui contient un certificat de CA et un jeton Bootstrap.
|
||||
Ceux-ci sont utilisés par la kubelet pour effectuer le TLS Bootstrap et obtenir une information
|
||||
d'identification unique, qui est stocké dans `/etc/kubernetes/kubelet.conf`. Quand ce fichier est
|
||||
d'identification unique, qui est stocké dans `/etc/kubernetes/kubelet.conf`. Quand ce fichier est
|
||||
écrit, la kubelet a terminé l'exécution du bootstrap TLS.
|
||||
|
||||
## Le fichier kubelet généré pour systemd {#the-kubelet-drop-in-file-for-systemd}
|
||||
@@ -187,11 +187,11 @@ Ce fichier spécifie les emplacements par défaut pour tous les fichiers gérés
|
||||
mais il n'est utilisé que si `/etc/kubernetes/kubelet.conf` n'existe pas.
|
||||
- Le fichier KubeConfig avec l’identité unique de la kubelet est `/etc/kubernetes/kubelet.conf`.
|
||||
- Le fichier contenant le ComponentConfig de la kubelet est `/var/lib/kubelet/config.yaml`.
|
||||
- Le fichier d'environnement dynamique qui contient `KUBELET_KUBEADM_ARGS` est sourcé à partir de
|
||||
- Le fichier d'environnement dynamique qui contient `KUBELET_KUBEADM_ARGS` est sourcé à partir de
|
||||
`/var/lib/kubelet/kubeadm-flags.env`.
|
||||
- Le fichier qui peut contenir les paramètres surchargés par l'utilisateur avec `KUBELET_EXTRA_ARGS`
|
||||
provient de `/etc/default/kubelet` (pour les DEBs), ou `/etc/sysconfig/kubelet` (pour les RPMs)
|
||||
`KUBELET_EXTRA_ARGS` est le dernier de la chaîne d'options et a la priorité la plus élevée en cas
|
||||
`KUBELET_EXTRA_ARGS` est le dernier de la chaîne d'options et a la priorité la plus élevée en cas
|
||||
de conflit de paramètres.
|
||||
|
||||
## Fichiers binaires de Kubernetes et contenu du package
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 70
|
||||
{{% capture overview %}}
|
||||
|
||||
Par défaut, Kubeadm exécute un cluster etcd mono nœud dans un pod statique géré
|
||||
par la kubelet sur le nœud du plan de contrôle (control plane). Ce n'est pas une configuration haute disponibilité puisque le cluster etcd ne contient qu'un seul membre et ne peut donc supporter
|
||||
par la kubelet sur le nœud du plan de contrôle (control plane). Ce n'est pas une configuration haute disponibilité puisque le cluster etcd ne contient qu'un seul membre et ne peut donc supporter
|
||||
qu'aucun membre ne devienne indisponible. Cette page vous accompagne dans le processus de création
|
||||
d'un cluster etcd à trois membres en haute disponibilité, pouvant être utilisé en tant que cluster externe lors de l’utilisation de kubeadm pour configurer un cluster kubernetes.
|
||||
|
||||
@@ -41,8 +41,8 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
|
||||
|
||||
1. Configurez la kubelet pour qu'elle soit un gestionnaire de service pour etcd.
|
||||
|
||||
Etant donné qu'etcd a été créé en premier, vous devez remplacer la priorité de service en
|
||||
créant un nouveau fichier unit qui a une priorité plus élevée que le fichier unit de la kubelet fourni
|
||||
Etant donné qu'etcd a été créé en premier, vous devez remplacer la priorité de service en
|
||||
créant un nouveau fichier unit qui a une priorité plus élevée que le fichier unit de la kubelet fourni
|
||||
par kubeadm.
|
||||
|
||||
```sh
|
||||
@@ -105,7 +105,7 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
|
||||
`/etc/kubernetes/pki/etcd/ca.key`. Une fois ces fichiers copiés,
|
||||
passez à l'étape suivante, "Créer des certificats pour chaque membre".
|
||||
|
||||
Si vous ne possédez pas déjà de CA, exécutez cette commande sur `$HOST0` (où vous
|
||||
Si vous ne possédez pas déjà de CA, exécutez cette commande sur `$HOST0` (où vous
|
||||
avez généré les fichiers de configuration pour kubeadm).
|
||||
|
||||
```
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 90
|
||||
|
||||
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 à
|
||||
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:
|
||||
@@ -17,12 +17,12 @@ 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
|
||||
- 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
|
||||
- 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 %}}
|
||||
@@ -38,7 +38,7 @@ Si vous voyez les warnings suivants lors de l'exécution `kubeadm init`
|
||||
[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
|
||||
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`.
|
||||
@@ -54,10 +54,10 @@ Si vous remarquez que `kubeadm init` se bloque après la ligne suivante:
|
||||
|
||||
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
|
||||
- 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
|
||||
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
|
||||
@@ -77,7 +77,7 @@ de `journalctl -u kubelet`. Si vous voyez quelque chose comme ce qui suit:
|
||||
|
||||
## 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
|
||||
Les événements suivants peuvent se produire si Docker s'arrête et ne supprime pas les conteneurs gérés
|
||||
par Kubernetes:
|
||||
|
||||
```bash
|
||||
@@ -111,26 +111,26 @@ Juste après `kubeadm init`, il ne devrait pas y avoir de pods dans ces états.
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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é.
|
||||
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
|
||||
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.
|
||||
|
||||
@@ -143,14 +143,14 @@ Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, v
|
||||
|
||||
## Les pods ne sont pas accessibles via leur IP de service
|
||||
|
||||
- De nombreux add-ons réseau ne permettent pas encore
|
||||
- De nombreux add-ons réseau ne permettent pas encore
|
||||
[hairpin mode](/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
|
||||
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
|
||||
- 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.
|
||||
|
||||
@@ -160,7 +160,7 @@ 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
|
||||
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")
|
||||
```
|
||||
|
||||
@@ -187,33 +187,33 @@ 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`,
|
||||
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
|
||||
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
|
||||
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:
|
||||
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
|
||||
- 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
|
||||
- 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
|
||||
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:
|
||||
|
||||
@@ -221,9 +221,9 @@ dernière comme` InternalIP` du noeud au lieu du public.
|
||||
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 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`:
|
||||
@@ -235,7 +235,7 @@ dernière comme` InternalIP` du noeud au lieu du public.
|
||||
|
||||
## 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
|
||||
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).
|
||||
@@ -248,7 +248,7 @@ kubectl -n kube-system get deployment coredns -o yaml | \
|
||||
kubectl apply -f -
|
||||
```
|
||||
|
||||
une autre raison pour laquelle CoreDNS peut se retrouver dans l'état `CrashLoopBackOff` est lorsqu'un
|
||||
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.
|
||||
|
||||
@@ -262,8 +262,8 @@ la sécurité de votre cluster.
|
||||
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
|
||||
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\""
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user