kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs fr: setup: idenpendent: fixed peirra , yohan and sieben comments (#12742)

This commit is contained in:
lledru 2019-03-04 16:50:11 +01:00 committed by Kubernetes Prow Robot
parent d191cb8408
commit adfaf7a816
9 changed files with 2222 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/fr/docs/setup/independent/_index.md Executable file
View File

@ -0,0 +1,5 @@
---
title: "Déployer des clusters avec kubeadm"
weight: 30
---

90
content/fr/docs/setup/independent/control-plane-flags.md Normal file
View File

@ -0,0 +1,90 @@
---
title: Personnalisation de la configuration du control plane avec kubeadm
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
{{< 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
définis à l'aide des champs suivants:
- `apiServer`
- `controllerManager`
- `scheduler`
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.
2. Ajoutez les indicateurs à remplacer dans le champ.
Pour plus de détails sur chaque champ de la configuration, vous pouvez accéder aux
[pages de référence de l'API](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#ClusterConfiguration).
{{% /capture %}}
{{% capture body %}}
## Paramètres pour l'API Server
Pour plus de détails, voir la
[documentation de référence pour kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/).
Exemple d'utilisation:
```yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
name: 1.13-sample
apiServer:
extraArgs:
advertise-address: 192.168.0.103
anonymous-auth: false
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
audit-log-path: /home/johndoe/audit.log
```
## Paramètres pour le ControllerManager
Pour plus de détails, voir la [documentation de référence pour kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
Exemple d'utilisation:
```yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
name: 1.13-sample
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
bind-address: 0.0.0.0
deployment-controller-sync-period: 50
```
## Paramètres pour le Scheduler
Pour plus de détails, voir la
[documentation de référence pour kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
Example usage:
```yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
name: 1.13-sample
scheduler:
extraArgs:
address: 0.0.0.0
config: /home/johndoe/schedconfig.yaml
kubeconfig: /home/johndoe/kubeconfig.yaml
```
{{% /capture %}}

687
content/fr/docs/setup/independent/create-cluster-kubeadm.md Normal file
View File

@ -0,0 +1,687 @@
---
title: Création d'un Cluster a master unique avec kubeadm
content_template: templates/task
weight: 30
---
{{% capture overview %}}
<img src="https://raw.githubusercontent.com/cncf/artwork/master/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">**kubeadm** vous aide à démarrer un cluster Kubernetes minimum,
viable et conforme aux meilleures pratiques. Avec kubeadm, votre cluster
doit passer les [tests de Conformance Kubernetes](https://kubernetes.io/blog/2017/10/software-conformance-certification).
Kubeadm prend également en charge d'autres fonctions du cycle de vie, telles que les mises
à niveau, la rétrogradation et la gestion des
[bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).
Comme vous pouvez installer kubeadm sur différents types de machines (par exemple, un ordinateur
portable, un serveur,
Raspberry Pi, etc.), il est parfaitement adapté à l'intégration avec des systèmes d'approvisionnement
comme Terraform ou Ansible.
La simplicité de kubeadm lui permet d'être utilisé dans une large gamme de cas d'utilisation:
- Les nouveaux utilisateurs peuvent commencer par kubeadm pour essayer Kubernetes pour la première
fois.
- Les utilisateurs familiarisés avec Kubernetes peuvent créer des clusters avec kubeadm et tester
leurs applications.
- Les projets plus importants peuvent inclure kubeadm en tant que brique de base dans un système
plus complexe pouvant également inclure d'autres outils d'installation.
Kubeadm est conçu pour être un moyen simple pour les nouveaux utilisateurs de commencer à essayer
Kubernetes, pour la première fois éventuellement. C'est un moyen pour les utilisateurs avancés de
tester leur application en même temps qu'un cluster facilement, et aussi être
une brique de base dans un autre écosystème et/ou un outil d’installation avec une plus grand
portée.
Vous pouvez installer très facilement _kubeadm_ sur des systèmes d'exploitation prenant en charge
l'installation des paquets deb ou rpm. Le SIG responsable de kubeadm,
[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle),
fournit ces paquets pré-construits pour vous,
mais vous pouvez également les construire à partir des sources pour d'autres systèmes d'exploitation.
### Maturité de kubeadm
| Elément | Niveau de maturité |
|---------------------------|--------------------|
| Command line UX | GA |
| Implementation | GA |
| Config file API | beta |
| CoreDNS | GA |
| kubeadm alpha subcommands | alpha |
| High availability | alpha |
| DynamicKubeletConfig | alpha |
| Self-hosting | alpha |
Les fonctionnalités globales de kubeadm sont **GA**. Quelques sous-fonctionnalités, comme
la configuration, les API de fichiers sont toujours en cours de développement. L'implémentation de la création du cluster
peut changer légèrement au fur et à mesure que l'outil évolue, mais la mise en œuvre globale devrait être assez stable.
Toutes les commandes sous `kubeadm alpha` sont par définition prises en charge au niveau alpha.
### Calendrier de support
Les versions de Kubernetes sont généralement prises en charge pendant neuf mois et pendant cette
période, une version de correctif peut être publiée à partir de la branche de publication si un bug grave ou un
problème de sécurité est trouvé. Voici les dernières versions de Kubernetes et le calendrier de support
qui s'applique également à `kubeadm`.
| Version de Kubernetes | Date de sortie de la version | Fin de vie |
|-----------------------|------------------------------|----------------|
| v1.6.x | Mars 2017 | Décembre 2017 |
| v1.7.x | Juin 2017 | Mars 2018 |
| v1.8.x | Septembre 2017 | Juin 2018 |
| v1.9.x | Décembre 2017 | Septembre 2018 |
| v1.10.x | Mars 2018 | Décembre 2018 |
| v1.11.x | Juin 2018 | Mars 2019 |
| v1.12.x | Septembre 2018 | Juin 2019 |
| v1.13.x | Décembre 2018 | Septembre 2019 |
{{% /capture %}}
{{% capture prerequisites %}}
- Une ou plusieurs machines exécutant un système d'exploitation compatible deb/rpm, par exemple Ubuntu ou CentOS
- 2 Go ou plus de RAM par machine. Si vous essayez moins cela laissera trop peu de place pour vos applications.
- 2 processeurs ou plus sur le master
- Connectivité réseau entre toutes les machines du cluster, qu'il soit public ou privé.
{{% /capture %}}
{{% capture steps %}}
## Objectifs
* Installer un cluster Kubernetes à master unique ou un
[cluster à haute disponibilité](/docs/setup/independent/high-availability/)
* Installez un réseau de pods sur le cluster afin que vos pods puissent se parler
## Instructions
### Installer kubeadm sur vos hôtes
Voir ["Installation de kubeadm"](/docs/setup/independent/install-kubeadm/).
{{< note >}}
Si vous avez déjà installé kubeadm, lancez `apt-get update &&
apt-get upgrade` ou `yum update` pour obtenir la dernière version de kubeadm.
Lorsque vous effectuez une mise à niveau, la kubelet redémarre plusieurs fois au bout de quelques
secondes car elle attend dans une boucle de blocage
kubeadm pour lui dire quoi faire. Ce fonctionnement est normal.
Une fois que vous avez initialisé votre master, la kubelet s'exécute normalement.
{{< /note >}}
### Initialiser votre master
Le master est la machine sur laquelle s'exécutent les composants du control plane, y compris
etcd (la base de données du cluster) et l'API serveur (avec lequel la CLI kubectl communique).
1. Choisissez un add-on réseau pour les pods et vérifiez s’il nécessite des arguments à
passer à l'initialisation de kubeadm. Selon le
fournisseur tiers que vous choisissez, vous devrez peut-être définir le `--pod-network-cidr` sur
une valeur spécifique au fournisseur. Voir [Installation d'un add-on réseau de pod](#pod-network).
1. (Facultatif) Sauf indication contraire, kubeadm utilise l'interface réseau associée
avec la passerelle par défaut pour annoncer l’IP du master. Pour utiliser une autre
interface réseau, spécifiez l'option `--apiserver-advertise-address=<ip-address>`
à `kubeadm init`. Pour déployer un cluster Kubernetes en utilisant l’adressage IPv6, vous devez
spécifier une adresse IPv6, par exemple `--apiserver-advertise-address=fd00::101`
1. (Optional) Lancez `kubeadm config images pull` avant de faire `kubeadm init` pour vérifier la
connectivité aux registres gcr.io.
Maintenant, lancez:
```bash
kubeadm init <args>
```
### Plus d'information
Pour plus d'informations sur les arguments de `kubeadm init`, voir le
[guide de référence kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/).
Pour une liste complète des options de configuration, voir la
[documentation du fichier de configuration](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
Pour personnaliser les composants du control plane, y compris l'affectation facultative d'IPv6
à la sonde liveness, pour les composants du control plane et du serveur etcd, fournissez des arguments
supplémentaires à chaque composant, comme indiqué dans les [arguments personnalisés](/docs/admin/kubeadm#custom-args).
Pour lancer encore une fois `kubeadm init`, vous devez d'abord [détruire le cluster](#tear-down).
Si vous joignez un nœud avec une architecture différente par rapport à votre cluster, créez un
Déploiement ou DaemonSet pour `kube-proxy` et` kube-dns` sur le nœud. C’est nécéssaire car les images Docker pour ces
composants ne prennent actuellement pas en charge la multi-architecture.
`kubeadm init` exécute d’abord une série de vérifications préalables pour s’assurer que la machine
est prête à exécuter Kubernetes. Ces vérifications préalables exposent des avertissements et se terminent
en cas d'erreur. Ensuite `kubeadm init` télécharge et installe les composants du control plane du cluster.
Cela peut prendre plusieurs minutes. l'output devrait ressembler à:
```none
[init] Using Kubernetes version: vX.Y.Z
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 31.501735 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-master" as an annotation
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: <token>
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
Your Kubernetes master has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of machines by running the following on each node
as root:
kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
```
Pour que kubectl fonctionne pour votre utilisateur non root, exécutez ces commandes, qui font
également partie du resultat de la commande `kubeadm init`:
```bash
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
Alternativement, si vous êtes `root`, vous pouvez exécuter:
```bash
export KUBECONFIG=/etc/kubernetes/admin.conf
```
Faites un enregistrement du retour de la commande `kubeadm join` que` kubeadm init` génère. Vous avez
besoin de cette commande pour [joindre des noeuds à votre cluster](#join-nodes).
Le jeton est utilisé pour l'authentification mutuelle entre le master et les nœuds qui veulent le rejoindre.
Le jeton est secret. Gardez-le en sécurité, parce que n'importe qui avec ce
jeton peut ajouter des nœuds authentifiés à votre cluster. Ces jetons peuvent être listés,
créés et supprimés avec la commande `kubeadm token`. Voir le
[Guide de référence kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-token/).
### Installation d'un add-on réseau {#pod-network}
{{< caution >}}
Cette section contient des informations importantes sur l’ordre d’installation et de déploiement. Lisez-la attentivement avant de continuer.
{{< /caution >}}
Vous devez installer un add-on réseau pour pod afin que vos pods puissent communiquer les uns
avec les autres.
**Le réseau doit être déployé avant toute application. De plus, CoreDNS ne démarrera pas avant
l’installation d’un réseau.
kubeadm ne prend en charge que les réseaux basés sur un CNI (et ne prend pas
en charge kubenet).**
Plusieurs projets fournissent des réseaux de pod Kubernetes utilisant CNI, dont certains
supportent les [network policies](/docs/concepts/services-networking/networkpolicies/).
Allez voir la [page des add-ons](/docs/concepts/cluster-administration/addons/) pour une liste complète
des add-ons réseau disponibles.
- Le support IPv6 a été ajouté dans [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) et
[local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md)
sont les seuls plug-ins de réseau IPv6 pris en charge dans Kubernetes version 1.9.
Notez que kubeadm configure un cluster sécurisé par défaut et impose l’utilisation de
[RBAC](/docs/reference/access-authn-authz/rbac/).
Assurez-vous que votre manifeste de réseau prend en charge RBAC.
Veuillez également à ce que votre réseau Pod ne se superpose à aucun des réseaux hôtes,
car cela pourrait entraîner des problèmes.
Si vous constatez une collision entre le réseau de pod de votre plug-in de réseau et certains
de vos réseaux hôtes,
vous devriez penser à un remplacement de CIDR approprié et l'utiliser lors de `kubeadm init` avec
` --pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
Vous pouvez installer un add-on réseau de pod avec la commande suivante:
```bash
kubectl apply -f <add-on.yaml>
```
Vous ne pouvez installer qu'un seul réseau de pod par cluster.
{{< tabs name="tabs-pod-install" >}}
{{% tab name="Choisissez-en un..." %}}
Sélectionnez l'un des onglets pour consulter les instructions d'installation du fournisseur
de réseau de pods.{{% /tab %}}
{{% tab name="Calico" %}}
Pour plus d'informations sur l'utilisation de Calico, voir
[Guide de démarrage rapide de Calico sur Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/),
[Installation de Calico pour les netpols ( network policies ) et le réseau](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), ainsi que d'autres resources liées à ce sujet.
Pour que Calico fonctionne correctement, vous devez passer `--pod-network-cidr = 192.168.0.0 / 16`
à` kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
Notez que Calico fonctionne uniquement sur `amd64`,` arm64`, `ppc64le` et` s390x`.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
```
{{% /tab %}}
{{% tab name="Canal" %}}
Canal utilise Calico pour les netpols et Flannel pour la mise en réseau. Reportez-vous à la
documentation Calico pour obtenir le [guide de démarrage officiel](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
Pour que Canal fonctionne correctement, `--pod-network-cidr = 10.244.0.0 / 16` doit être passé à
` kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/canal/rbac.yaml
kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/canal/canal.yaml
```
{{% /tab %}}
{{% tab name="Cilium" %}}
Pour plus d'informations sur l'utilisation de Cilium avec Kubernetes, voir
[Guide d'installation de Kubernetes pour Cilium](https://docs.cilium.io/en/stable/kubernetes/).
Ces commandes déploieront Cilium avec son propre etcd géré par l'opérateur etcd.
Note: Si vous utilisez kubeadm dans un seul noeud, veuillez enlever sa marque (taint) pour que
les pods etcd-operator puissent être déployés dans le nœud du control plane.
```shell
kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
```
Pour déployer Cilium, il vous suffit de lancer:
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml
```
Une fois que tous les pods Cilium sont marqués «READY», vous commencez à utiliser votre cluster.
```shell
$ kubectl get pods -n kube-system --selector=k8s-app=cilium
NAME READY STATUS RESTARTS AGE
cilium-drxkl 1/1 Running 0 18m
```
{{% /tab %}}
{{% tab name="Flannel" %}}
Pour que `flannel` fonctionne correctement, vous devez passer` --pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant
` sysctl net.bridge.bridge-nf-call-iptables = 1`
passez le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI
fonctionnent, pour plus d'informations
allez voir [ici](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Notez que `flannel` fonctionne sur` amd64`, `arm`,` arm64`, `ppc64le` et` s390x` sous Linux.
Windows (`amd64`) est annoncé comme supporté dans la v0.11.0 mais son utilisation n’est pas
documentée.
```shell
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
```
Pour plus d’informations sur `flannel`, voir [le dépôt CoreOS sur GitHub](https://github.com/coreos/flannel).
{{% /tab %}}
{{% tab name="Kube-router" %}}
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant
`sysctl net.bridge.bridge-nf-call-iptables = 1`
Cette commande indiquera de passer le trafic IPv4 bridgé à iptables.
Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
s'il vous plaît allez voir [ici](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Kube-router s'appuie sur kube-controller-manager pour allouer le pod CIDR aux nœuds. Par conséquent,
utilisez `kubeadm init` avec l'option` --pod-network-cidr`.
Kube-router fournit un réseau de pod, une stratégie réseau et un proxy de service basé sur un
IP Virtual Server (IPVS) / Linux Virtual Server (LVS) hautement performant.
Pour plus d'informations sur la configuration du cluster Kubernetes avec Kube-router à l'aide de kubeadm,
veuillez consulter le [guide d'installation](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
{{% /tab %}}
{{% tab name="Romana" %}}
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à` 1` en exécutant
`sysctl net.bridge.bridge-nf-call-iptables = 1`
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent,
pour plus d'informations
veuillez consulter la documentation [ici](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Le guide d'installation officiel de Romana est [ici](https://github.com/romana/romana/tree/master/containerize#using-kubeadm).
Romana ne fonctionne que sur `amd64`.
```shell
kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
```
{{% /tab %}}
{{% tab name="Weave Net" %}}
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant` sysctl net.bridge.bridge-nf-call-iptables = 1`
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
s'il vous plaît allez voir [ici](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Le guide de configuration officiel de Weave Net est [ici](https://www.weave.works/docs/net/latest/kube-addon/).
Weave Net fonctionne sur `amd64`,` arm`, `arm64` et` ppc64le` sans aucune action supplémentaire requise.
Weave Net paramètre le mode hairpin par défaut. Cela permet aux pods de se connecter via leur adresse IP de service
s'ils ne connaissent pas leur Pod IP.
```shell
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
{{% /tab %}}
{{% tab name="JuniperContrail/TungstenFabric" %}}
Fournit une solution SDN superposée, offrant un réseau multicouches, un réseau de cloud hybride,
prise en charge simultanée des couches superposées, application de la stratégie réseau, isolation du réseau,
chaînage de service et équilibrage de charge flexible.
Il existe de nombreuses manières flexibles d’installer JuniperContrail / TungstenFabric CNI.
Veuillez vous référer à ce guide de démarrage rapide: [TungstenFabric](https://tungstenfabric.github.io/website/)
{{% /tab %}}
{{< /tabs >}}
Une fois qu'un réseau de pod a été installé, vous pouvez vérifier qu'il fonctionne en
vérifiant que le pod CoreDNS est en cours d’exécution dans l'output de `kubectl get pods --all-namespaces`.
Et une fois que le pod CoreDNS est opérationnel, vous pouvez continuer en joignant vos nœuds.
Si votre réseau ne fonctionne pas ou si CoreDNS n'est pas en cours d'exécution, vérifiez
notre [documentation de dépannage](/docs/setup/independent/troubleshooting-kubeadm/).
### Isolation des nœuds du control plane
Par défaut, votre cluster ne déploie pas de pods sur le master pour des raisons de sécurité.
Si vous souhaitez pouvoir déployer des pods sur le master, par exemple, pour un
cluster Kubernetes mono-machine pour le développement, exécutez:
```bash
kubectl taint nodes --all node-role.kubernetes.io/master-
```
Avec un resultat ressemblant à quelque chose comme:
```
node "test-01" untainted
taint "node-role.kubernetes.io/master:" not found
taint "node-role.kubernetes.io/master:" not found
```
Cela supprimera la marque `node-role.kubernetes.io/master` de tous les nœuds qui
l'ont, y compris du nœud master, ce qui signifie que le scheduler sera alors capable
de déployer des pods partout.
### Faire rejoindre vos nœuds {#join-nodes}
Les nœuds sont ceux sur lesquels vos workloads (conteneurs, pods, etc.) sont exécutées.
Pour ajouter de nouveaux nœuds à votre cluster, procédez comme suit pour chaque machine:
* SSH vers la machine
* Devenir root (par exemple, `sudo su-`)
* Exécutez la commande qui a été récupérée sur l'output de `kubeadm init`. Par exemple:
``` bash
kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
```
Si vous n'avez pas le jeton, vous pouvez l'obtenir en exécutant la commande suivante sur le nœud master:
``` bash
kubeadm token list
```
L'output est similaire à ceci:
``` console
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system:
signing token generated by bootstrappers:
'kubeadm init'. kubeadm:
default-node-token
```
Par défaut, les jetons expirent après 24 heures. Si vous joignez un nœud au cluster après
l’expiration du jeton actuel,
vous pouvez créer un nouveau jeton en exécutant la commande suivante sur le nœud maître:
``` bash
kubeadm token create
```
L'output est similaire à ceci:
``` console
5didvk.d09sbcov8ph2amjw
```
Si vous n'avez pas la valeur `--discovery-token-ca-cert-hash`, vous pouvez l'obtenir en
exécutant la suite de commande suivante sur le nœud master:
``` bash
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | sed 's/^.* //'
```
L'output est similaire à ceci:
``` console
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
```
{{< note >}}
Pour spécifier un tuple IPv6 pour `<maître-ip>: <maître-port>`, l'adresse IPv6 doit être placée
entre crochets, par exemple: `[fd00 :: 101]: 2073`.{{< /note >}}
Le resultat devrait ressembler à quelque chose comme:
```
[preflight] Running pre-flight checks
... (log output of join workflow) ...
Node join complete:
* Certificate signing request sent to master and response
received.
* Kubelet informed of new secure connection details.
Run 'kubectl get nodes' on the master to see this machine join.
```
Quelques secondes plus tard, vous remarquerez ce nœud dans l'output de `kubectl get
node`.
### (Optionnel) Contrôler votre cluster à partir de machines autres que le master
Afin d'utiliser kubectl sur une autre machine (par exemple, un ordinateur portable) pour communiquer avec votre
cluster, vous devez copier le fichier administrateur kubeconfig de votre master
sur votre poste de travail comme ceci:
``` bash
scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes
```
{{< note >}}
L'exemple ci-dessus suppose que l'accès SSH est activé pour root. Si ce n'est pas le cas,
vous pouvez copier le fichier `admin.conf` pour qu'il soit accessible à un autre utilisateur.
et `scp` en utilisant cet autre utilisateur à la place.
Le fichier `admin.conf` donne à l'utilisateur _superuser_ des privilèges sur le cluster.
Ce fichier doit être utilisé avec parcimonie. Pour les utilisateurs normaux, il est recommandé de
générer une information d'identification unique pour laquelle vous ajoutez des privilèges à la liste blanche
(whitelist).
Vous pouvez faire ceci avec `kubeadm alpha kubeconfig utilisateur --nom-client <CN>`.
Le resultat de cette commande génèrera un fichier KubeConfig qui sera envoyé sur STDOUT, que vous
devrez enregistrer dans un fichier et donner à votre utilisateur. Après cela, créez la whitelist des
privilèges en utilisant `kubectl create (cluster) rolebinding.`
{{< /note >}}
### (Facultatif) Proxifier l'API Server vers localhost
Si vous souhaitez vous connecter à l'API server à partir de l'éxterieur du cluster, vous pouvez utiliser
`kubectl proxy`:
```bash
scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy
```
Vous pouvez maintenant accéder à l'API server localement à `http://localhost:8001/api/v1`
## Destruction {#tear-down}
Pour annuler ce que kubeadm a fait, vous devez d’abord
[drainer le nœud](/docs/reference/generated/kubectl/kubectl-commands#drain)
et assurez-vous que le nœud est vide avant de l'arrêter.
En communiquant avec le master en utilisant les informations d'identification appropriées, exécutez:
```bash
kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
kubectl delete node <node name>
```
Ensuite, sur le nœud en cours de suppression, réinitialisez l'état de tout ce qui concerne kubeadm:
```bash
kubeadm reset
```
Le processus de réinitialisation ne réinitialise pas et ne nettoie pas les règles iptables ni les
tables IPVS. Si vous souhaitez réinitialiser iptables, vous devez le faire manuellement:
```bash
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
```
Si vous souhaitez réinitialiser les tables IPVS, vous devez exécuter la commande suivante:
```bash
ipvsadm -C
```
Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou` kubeadm join` avec les
arguments appropriés.
Plus d'options et d'informations sur la
[`commande de réinitialisation de kubeadm`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
## Maintenir un cluster {#lifecycle}
Vous trouverez des instructions pour la maintenance des clusters kubeadm (mises à niveau,
rétrogradation, etc.) [ici](/docs/tasks/administer-cluster/kubeadm)
## Explorer les autres add-ons {#other-addons}
Parcourez la [liste des add-ons](/docs/concepts/cluster-administration/addons/),
y compris des outils pour la journalisation, la surveillance, la stratégie réseau, la visualisation
et le contrôle de votre cluster Kubernetes.
## Et après ? {#whats-next}
* Vérifiez que votre cluster fonctionne correctement avec [Sonobuoy](https://github.com/heptio/sonobuoy)
* En savoir plus sur l'utilisation avancée de kubeadm dans la
[documentation de référence de kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm)
* En savoir plus sur Kubernetes [concepts](/docs/concepts/) et [`kubectl`](/docs/user-guide/kubectl-overview/).
* Configurez la rotation des logs. Vous pouvez utiliser **logrotate** pour cela. Lorsque vous utilisez Docker,
vous pouvez spécifier des options de rotation des logs pour le démon Docker, par exemple
`--log-driver = fichier_json --log-opt = taille_max = 10m --log-opt = fichier_max = 5`.
Consultez [Configurer et dépanner le démon Docker](https://docs.docker.com/engine/admin/) pour plus de détails.
## Feedback {#feedback}
* Pour les bugs, visitez [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
* Pour le support, rendez vous sur le Channel Slack kubeadm:
[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
* Le Channel Slack: General SIG Cluster Lifecycle Development:
[#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
* [SIG Cluster Lifecycle SIG information](#TODO)
* SIG Cluster Lifecycle Mailing List:
[kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
## Politique de compatibilité de versions {#version-skew-policy}
L'outil CLI kubeadm de la version vX.Y peut déployer des clusters avec un control
plane de la version vX.Y ou vX. (Y-1).
kubeadm CLI vX.Y peut également mettre à niveau un cluster existant créé par kubeadm
de la version vX. (Y-1).
Pour cette raison, nous ne pouvons pas voir plus loin, kubeadm CLI vX.Y peut ou pas être
en mesure de déployer des clusters vX. (Y + 1).
Exemple: kubeadm v1.8 peut déployer des clusters v1.7 et v1.8 et mettre à niveau des
clusters v1.7 créés par kubeadm vers
v1.8.
Ces ressources fournissent plus d'informations sur le saut de version pris en
charge entre les kubelets et le control plane, ainsi que sur d'autres composants Kubernetes:
* [politique de compatibilité de versions](/docs/setup/version-skew-policy/) de Kubernetes
* [Guide d'installation](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
spécifique à Kubeadm
## kubeadm fonctionne sur plusieurs plates-formes {#multi-platform}
Les packages et fichiers binaires de kubeadm deb/rpm sont conçus pour amd64, arm (32 bits), arm64, ppc64le et s390x
suite à la [multiplateforme proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md).
Les images de conteneur multiplatform pour le control plane et les addons sont également pris en charge depuis la v1.12.
Seuls certains fournisseurs de réseau proposent des solutions pour toutes les plateformes. Veuillez consulter la liste des
fournisseurs de réseau ci-dessus ou la documentation de chaque fournisseur pour déterminer si le fournisseur
prend en charge votre plate-forme.
## Limitations {#limitations}
Remarque: kubeadm évolue continuellement et ces limitations seront résolues en temps voulu.
* Le cluster créé ici a un seul master, avec une seule base de données etcd. Cela signifie que
si le master est irrécupérable, votre cluster peut perdre ses données et peut avoir besoin d'être recréé à
partir de zéro. L'ajout du support HA (plusieurs serveurs etcd, plusieurs API servers, etc.)
à kubeadm est encore en cours de developpement.
   Contournement: régulièrement [sauvegarder etcd](https://coreos.com/etcd/docs/latest/admin_guide.html).
le répertoire des données etcd configuré par kubeadm se trouve dans `/var/lib/etcd` sur le master.
## Diagnostic {#troubleshooting}
Si vous rencontrez des difficultés avec kubeadm, veuillez consulter nos
[troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).

81
content/fr/docs/setup/independent/ha-topology.md Normal file
View File

@ -0,0 +1,81 @@
---
title: Options pour la topologie en haute disponibilité
content_template: templates/concept
weight: 50
---
{{% capture overview %}}
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é:
- 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
de configurer un cluster en haute disponibilité.
{{% /capture %}}
{{% capture body %}}
## 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
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
`kube-controller-manager`.
Le `kube-apiserver` est exposé aux nœuds à l'aide d'un loadbalancer.
Chaque nœud du control plane crée un membre etcd local et ce membre etcd communique uniquement avec
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 à
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
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
en haute disponibilité.
C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement
sur les noeuds du control plane en utilisant `kubeadm init` et` kubeadm join --experimental-control-plane`.
Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
## 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
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
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
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.
Un minimum de trois machines pour les nœuds du control plane et de trois machines
pour les nœuds etcd est requis pour un cluster HA avec cette topologie.
Schéma de la [Topologie externe etcd](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
{{% /capture %}}
{{% capture whatsnext %}}
- [Configurer un cluster hautement disponible avec kubeadm](/docs/setup/independent/high-availability/)
{{% /capture %}}

346
content/fr/docs/setup/independent/high-availability.md Normal file
View File

@ -0,0 +1,346 @@
---
title: Création de clusters hautement disponibles avec kubeadm
content_template: templates/task
weight: 60
---
{{% capture overview %}}
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.
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.
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/)
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
[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
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
environnement Cloud, les approches documentées ici ne fonctionne ni avec des objets de type
load balancer, ni avec des volumes persistants dynamiques.
{{< /caution >}}
{{% /capture %}}
{{% capture prerequisites %}}
Pour les deux méthodes, vous avez besoin de cette infrastructure:
- Trois machines qui répondent aux pré-requis des [exigences de kubeadm](/docs/setup/independent/install-kubeadm/#before-you-begin) pour les maîtres (masters)
- Trois machines qui répondent aux pré-requis des [exigences de kubeadm](/docs/setup/independent/install-kubeadm/#before-you-begin) pour les workers
- Connectivité réseau complète entre toutes les machines du cluster (public ou réseau privé)
- Privilèges sudo sur toutes les machines
- Accès SSH d'une machine à tous les nœuds du cluster
- `kubeadm` et une `kubelet` installés sur toutes les machines. `kubectl` est optionnel.
Pour le cluster etcd externe uniquement, vous avez besoin également de:
- Trois machines supplémentaires pour les membres etcd
{{< note >}}
Les exemples suivants utilisent Calico en tant que fournisseur de réseau de Pod. Si vous utilisez un autre
CNI, pensez à remplacer les valeurs par défaut si nécessaire.
{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
## Premières étapes pour les deux méthodes
{{< note >}}
Toutes les commandes d'un control plane ou d'un noeud etcd doivent être
éxecutées en tant que root.
{{< /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
[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`.
### Créez un load balancer pour kube-apiserver
{{< note >}}
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
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
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.
- Assurez-vous que l'adresse du load balancer correspond toujours à
      l'adresse de `ControlPlaneEndpoint` de kubeadm.
1. Ajoutez les premiers nœuds du control plane au load balancer et testez la connexion:
```sh
nc -v LOAD_BALANCER_IP PORT
```
- 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
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.
### Configurer SSH
SSH est requis si vous souhaitez contrôler tous les nœuds à partir d'une seule machine.
1. Activer ssh-agent sur votre machine ayant accès à tous les autres nœuds du cluster:
```
eval $(ssh-agent)
```
1. Ajoutez votre clé SSH à la session:
```
ssh-add ~/.ssh/path_to_private_key
```
1. SSH entre les nœuds pour vérifier que la connexion fonctionne correctement.
- Lorsque vous faites un SSH sur un noeud, assurez-vous d’ajouter l’option `-A`:
```
ssh -A 10.0.0.7
```
- Lorsque vous utilisez sudo sur n’importe quel nœud, veillez à préserver l’environnement afin que le SSH forwarding fonctionne:
```
sudo -E -s
```
## Control plane empilé et nœuds etcd
### Étapes pour le premier nœud du control plane
1. Sur le premier nœud du control plane, créez un fichier de configuration appelé `kubeadm-config.yaml`:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
- `kubernetesVersion` doit représenter la version de Kubernetes à utiliser. Cet exemple utilise `stable`.
- `controlPlaneEndpoint` doit correspondre à l'adresse ou au DNS et au port du load balancer.
- Il est recommandé que les versions de kubeadm, kubelet, kubectl et kubernetes correspondent.
1. Assurez-vous que le nœud est dans un état sain:
```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
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
d’autres nœuds du control plane au cluster.
1. Activez l'extension CNI Weave:
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
1. Tapez ce qui suit et observez les pods des composants démarrer:
```sh
kubectl get pod -n kube-system -w
```
- 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
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
for host in ${CONTROL_PLANE_IPS}; do
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
scp /etc/kubernetes/admin.conf "${USER}"@$host:
done
```
{{< 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.
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 >}}
### Étapes pour le reste des nœuds du control plane
1. Déplacer les fichiers créés à l'étape précédente où `scp` était utilisé:
```sh
USER=ubuntu # customizable
mkdir -p /etc/kubernetes/pki/etcd
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
mv /home/${USER}/ca.key /etc/kubernetes/pki/
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
mv /home/${USER}/sa.key /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
```
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
donnée par` kubeadm init` sur le premier noeud. Ça devrait ressembler a quelque chose
comme ça:
```sh
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
control plane du cluster.
1. Tapez ce qui suit et observez les pods des composants démarrer:
```sh
kubectl get pod -n kube-system -w
```
1. Répétez ces étapes pour le reste des nœuds du control plane.
## Noeuds etcd externes
### Configurer le cluster etcd
- Suivez ces [instructions](/docs/setup/independent/setup-ha-etcd-with-kubeadm/)
pour configurer le cluster etcd.
### Configurer le premier nœud du control plane
1. Copiez les fichiers suivants de n’importe quel nœud du cluster etcd vers ce nœud.:
```sh
export CONTROL_PLANE="ubuntu@10.0.0.7"
+scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
```
- Remplacez la valeur de `CONTROL_PLANE` par l'`utilisateur@hostname` de cette machine.
1. Créez un fichier YAML appelé `kubeadm-config.yaml` avec le contenu suivant:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379
- https://ETCD_1_IP:2379
- https://ETCD_2_IP:2379
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
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,
c'est géré automatiquement.
- Remplacez les variables suivantes dans le modèle (template) par les valeurs appropriées
pour votre cluster:
- `LOAD_BALANCER_DNS`
- `LOAD_BALANCER_PORT`
- `ETCD_0_IP`
- `ETCD_1_IP`
- `ETCD_2_IP`
1. Lancez `kubeadm init --config kubeadm-config.yaml` sur ce nœud.
1. Ecrivez le résultat de la commande de join dans un fichier texte pour une utilisation ultérieure.
1. Appliquer le plugin CNI Weave:
```sh
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
```
### Étapes pour le reste des nœuds du control plane
Pour ajouter le reste des nœuds du control plane, suivez [ces instructions](#étapes-pour-le-reste-des-nœuds-du-control-plane).
Les étapes sont les mêmes que pour la configuration etcd empilée, à l’exception du fait qu'un membre
etcd local n'est pas créé.
Pour résumer:
- Assurez-vous que le premier nœud du control plane soit complètement initialisé.
- Copier les certificats entre le premier nœud du control plane et les autres nœuds du control plane.
- Joignez chaque nœud du control plane à l'aide de la commande de join que vous avez enregistrée dans
un fichier texte, puis ajoutez l'option `--experimental-control-plane`.
## Tâches courantes après l'amorçage du control plane
### 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
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
être ajouté aux nœuds workers.
{{% /capture %}}

259
content/fr/docs/setup/independent/install-kubeadm.md Normal file
View File

@ -0,0 +1,259 @@
---
title: Installer kubeadm
content_template: templates/task
weight: 20
---
{{% capture overview %}}
<img src="https://raw.githubusercontent.com/cncf/artwork/master/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
effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour créer un cluster](/docs/setup/independent/create-cluster-kubeadm/).
{{% /capture %}}
{{% capture prerequisites %}}
* Une ou plusieurs machines exécutant:
- Ubuntu 16.04+
- Debian 9
- CentOS 7
- RHEL 7
- Fedora 25/26 (best-effort)
- HypriotOS v1.0.1+
- Container Linux (testé avec 1800.6.0)
* 2 Go ou plus de RAM par machine (toute quantité inférieure laissera peu de place à vos applications)
* 2 processeurs ou plus
* Connectivité réseau complète entre toutes les machines du cluster (réseau public ou privé)
* Nom d'hôte, adresse MAC et product_uuid uniques pour chaque nœud. Voir [ici](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) pour plus de détails.
* Certains ports doivent êtres ouverts sur vos machines. Voir [ici](#check-required-ports) pour plus de détails.
* Swap désactivé. Vous devez impérativement désactiver le swap pour que la kubelet fonctionne correctement.
{{% /capture %}}
{{% capture steps %}}
## Vérifiez que les adresses MAC et product_uuid sont uniques pour chaque nœud {#verify-the-mac-address-and-product-uuid-are-unique-for-every-node}
* 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
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).
## 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
de cluster Kubernetes soient acheminées via la carte approprié.
## Vérifiez les ports requis {#check-required-ports}
### nœuds maîtres (masters)
| Protocole | Direction | Plage de Port | Utilisé pour | Utilisé par |
|-----------|-----------|---------------|-------------------------|-------------------------|
| TCP | Entrant | 6443* | Kubernetes API server | Tous |
| TCP | Entrant | 2379-2380 | Etcd server client API | kube-apiserver, etcd |
| TCP | Entrant | 10250 | Kubelet API | Lui-même, Control plane |
| TCP | Entrant | 10251 | kube-scheduler | Lui-même |
| TCP | Entrant | 10252 | kube-controller-manager | Lui-même |
### nœuds workers
| Protocole | Direction | Plage de Port | Utilisé pour | Utilisé par |
|-----------|-----------|---------------|---------------------|-------------------------|
| TCP | Entrant | 10250 | Kubelet API | Lui-même, Control plane |
| TCP | Entrant | 30000-32767 | NodePort Services** | Eux-mêmes |
** Plage de ports par défaut pour les [Services NodePort](/docs/concepts/services-networking/service/).
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
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
documentation des plugins sur le(s) port(s) requis(s).
## Installing runtime
Depuis la version 1.6.0, Kubernetes a activé l'utilisation de la CRI, Container Runtime Interface, par défaut.
Le moteur de runtime de conteneur utilisé par défaut est Docker, activé par le biais de la l'implémentation CRI `dockershim` intégrée à l'interieur de la `kubelet`.
Les autres runtimes basés sur la CRI incluent:
- [containerd](https://github.com/containerd/cri) (plugin CRI construit dans containerd)
- [cri-o](https://github.com/kubernetes-incubator/cri-o)
- [frakti](https://github.com/kubernetes/frakti)
Reportez-vous aux [instructions d'installation de la CRI](/docs/setup/cri) pour plus d'informations.
## Installation de kubeadm, des kubelets et de kubectl
Vous installerez ces paquets sur toutes vos machines:
* `kubeadm`: la commande pour initialiser le cluster.
* la `kubelet`: le composant qui s'exécute sur toutes les machines de votre cluster et fait des actions
comme le démarrage des pods et des conteneurs.
* `kubectl`: la ligne de commande utilisée pour parler à votre cluster.
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
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
[attention particulière lors de la mise à niveau](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/).
{{</ warning >}}
Pour plus d'informations sur les compatibilités de version, voir:
* Kubernetes [version et politique de compatibilité de version](/docs/setup/version-skew-policy/)
* Kubeadm-specific [politique de compatibilité de version](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
```bash
apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl
```
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
```bash
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
exclude=kube*
EOF
# Mettre SELinux en mode permissif (le désactiver efficacement)
setenforce 0
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
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
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
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:
```bash
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sysctl --system
```
- Assurez-vous que le module `br_netfilter` est chargé avant cette étape. Cela peut être fait en exécutant `lsmod | grep br_netfilter`. Pour le charger explicitement, lancez `modprobe br_netfilter`.
{{% /tab %}}
{{% tab name="Container Linux" %}}
Installez les plugins CNI (requis pour la plupart des réseaux de pod):
```bash
CNI_VERSION="v0.6.0"
mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
```
Installez crictl (obligatoire pour kubeadm / Kubelet Container Runtime Interface (CRI))
```bash
CRICTL_VERSION="v1.11.1"
mkdir -p /opt/bin
curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
```
Installez `kubeadm`, `kubelet`, `kubectl` et ajouter un service systemd `kubelet`:
```bash
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
mkdir -p /opt/bin
cd /opt/bin
curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
chmod +x {kubeadm,kubelet,kubectl}
curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
```
Activez et démarrez la `kubelet`:
```bash
systemctl enable --now kubelet
```
{{% /tab %}}
{{< /tabs >}}
La kubelet redémarre maintenant toutes les secondes et quelques, car elle attend dans une boucle
kubeadm, pour lui dire quoi faire.
## Configurer le driver de cgroup utilisé par la kubelet sur un nœud master
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
valeur de `cgroup-driver` comme ceci:
```bash
KUBELET_EXTRA_ARGS=--cgroup-driver=<value>
```
Ce fichier sera utilisé par `kubeadm init` et` kubeadm join` pour sourcer des arguments supplémentaires définis par l'utilisateur pour la kubelet.
Veuillez noter que vous devez **seulement** le faire si le driver de cgroupe de votre CRI
n'est pas `cgroupfs`, car c'est déjà la valeur par défaut dans la kubelet.
Il est nécessaire de redémarrer la kubelet:
```bash
systemctl daemon-reload
systemctl restart kubelet
```
## Dépannage
Si vous rencontrez des difficultés avec kubeadm, veuillez consulter notre [documentation de dépannage](/docs/setup/independent/troubleshooting-kubeadm/).
{{% capture whatsnext %}}
* [Utiliser kubeadm pour créer un cluster](/docs/setup/independent/create-cluster-kubeadm/)
{{% /capture %}}

208
content/fr/docs/setup/independent/kubelet-integration.md Normal file
View File

@ -0,0 +1,208 @@
---
title: Configuration des kubelet de votre cluster avec kubeadm
content_template: templates/concept
weight: 80
---
{{% capture overview %}}
{{< 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
[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.
Comme la kubelet est un démon, elle doit être maintenue par une sorte d'init système ou un gestionnaire
de service. Lorsque la kubelet est installée à l'aide de DEB ou de RPM,
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,
mais [kubeadm fournit maintenant un type d’API `KubeletConfiguration` pour la gestion centralisée de vos configurations de kubelets](#configure-kubelets-using-kubeadm).
{{% /capture %}}
{{% capture body %}}
## Patterns de configuration des Kubelets
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}
Vous pouvez fournir à la kubelet les valeurs par défaut à utiliser par les commandes `kubeadm init` et
` kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
définition du sous-réseau par défaut utilisé par les services.
Si vous souhaitez que vos services utilisent le sous-réseau `10.96.0.0 / 12` par défaut pour les
services, vous pouvez passer le paramètre `--service-cidr` à kubeadm:
```bash
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
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
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
cluster exprimées en une liste de valeurs pour une clé formatée en CamelCased, illustrée par l'exemple suivant:
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10
```
Pour plus de détails sur ComponentConfig, jetez un œil à [cette section](#configure-kubelets-using-kubeadm).
### 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
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
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,
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
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,
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
`--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
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
`kubeadm ... --config some-config-file.yaml`.
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)
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
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
[propager la configuration niveau cluster à chaque kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
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:
```bash
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
socket de runtime CRI (`--cri-socket`).
Après avoir rassemblé ces deux fichiers sur le disque, kubeadm tente d’exécuter ces deux commandes,
si vous utilisez systemd:
```bash
systemctl daemon-reload && systemctl restart kubelet
```
Si le rechargement et le redémarrage réussissent, le workflow normal de `kubeadm init` continue.
### Workflow en utilisant `kubeadm join`
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
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:
```bash
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
é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}
Le fichier de configuration installé par le package DEB ou RPM de kubeadm est écrit dans
`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` et est utilisé par systemd.
```none
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
```
Ce fichier spécifie les emplacements par défaut pour tous les fichiers gérés par kubeadm pour la kubelet.
- Le fichier KubeConfig à utiliser pour le TLS Bootstrap est `/etc/kubernetes/bootstrap-kubelet.conf`,
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
`/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
de conflit de paramètres.
## Fichiers binaires de Kubernetes et contenu du package
Les packages DEB et RPM fournis avec les versions de Kubernetes sont les suivants:
| Nom du paquet | Description |
|------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
| `kubeadm` | Installe l'outil CLI `/usr/bin/kubeadm` et [le fichier instantané de kubelet](#the-kubelet-drop-in-file-for-systemd) pour la kubelet. |
| `kubelet` | Installe `/usr/bin/kubelet`. |
| `kubectl` | Installe `/usr/bin/kubectl`. |
| `kubernetes-cni` | Installe les binaires officiels du CNI dans le repertoire `/opt/cni/bin`. |
| `cri-tools` | Installe `/usr/bin/crictl` à partir de [https://github.com/kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools). |
{{% /capture %}}

261
content/fr/docs/setup/independent/setup-ha-etcd-with-kubeadm.md Normal file
View File

@ -0,0 +1,261 @@
---
title: Configurer un cluster etcd en haute disponibilité avec kubeadm
content_template: templates/task
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
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.
{{% /capture %}}
{{% capture prerequisites %}}
* Trois machines pouvant communiquer entre elles via les ports 2379 et 2380. Cette 
methode utilise ces ports par défaut. Cependant, ils sont configurables via 
le fichier de configuration kubeadm.
* Chaque hôte doit avoir [docker, kubelet et kubeadm installés][toolbox].
* Certains paquets pour copier des fichiers entre les hôtes. Par exemple, `ssh` et` scp`.
[toolbox]: /docs/setup/independent/install-kubeadm/
{{% /capture %}}
{{% capture steps %}}
## Mise en place du cluster
L’approche générale consiste à générer tous les certificats sur un nœud et à ne distribuer que
les fichiers *nécessaires* aux autres nœuds.
{{< note >}}
kubeadm contient tout ce qui est nécessaire pour générer les certificats décrits ci-dessous;
aucun autre outil de chiffrement n'est requis pour cet exemple.
{{< /note >}}
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
par kubeadm.
```sh
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true
Restart=always
EOF
systemctl daemon-reload
systemctl restart kubelet
```
1. Créez des fichiers de configuration pour kubeadm.
Générez un fichier de configuration kubeadm pour chaque machine qui éxécutera un membre etcd
en utilisant le script suivant.
```sh
# Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hosts
export HOST0=10.0.0.6
export HOST1=10.0.0.7
export HOST2=10.0.0.8
# Create temp directories to store files that will end up on other hosts.
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
NAMES=("infra0" "infra1" "infra2")
for i in "${!ETCDHOSTS[@]}"; do
HOST=${ETCDHOSTS[$i]}
NAME=${NAMES[$i]}
cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
apiVersion: "kubeadm.k8s.io/v1beta1"
kind: ClusterConfiguration
etcd:
local:
serverCertSANs:
- "${HOST}"
peerCertSANs:
- "${HOST}"
extraArgs:
initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380
initial-cluster-state: new
name: ${NAME}
listen-peer-urls: https://${HOST}:2380
listen-client-urls: https://${HOST}:2379
advertise-client-urls: https://${HOST}:2379
initial-advertise-peer-urls: https://${HOST}:2380
EOF
done
```
1. Générer l'autorité de certification
Si vous avez déjà une autorité de certification, alors la seule action qui est faite copie
les fichiers `crt` et `key` de la CA dans `/etc/kubernetes/pki/etcd/ca.crt` et
`/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
avez généré les fichiers de configuration pour kubeadm).
```
kubeadm init phase certs etcd-ca
```
Cela crée deux fichiers
- `/etc/kubernetes/pki/etcd/ca.crt`
- `/etc/kubernetes/pki/etcd/ca.key`
1. Créer des certificats pour chaque membres
```sh
kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST2}/
# cleanup non-reusable certificates
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
cp -R /etc/kubernetes/pki /tmp/${HOST1}/
find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
# No need to move the certs because they are for HOST0
# clean up certs that should not be copied off this host
find /tmp/${HOST2} -name ca.key -type f -delete
find /tmp/${HOST1} -name ca.key -type f -delete
```
1. Copier les certificats et les configurations kubeadm
Les certificats ont été générés et doivent maintenant être déplacés vers leur
hôtes respectifs.
```sh
USER=ubuntu
HOST=${HOST1}
scp -r /tmp/${HOST}/* ${USER}@${HOST}:
ssh ${USER}@${HOST}
USER@HOST $ sudo -Es
root@HOST $ chown -R root:root pki
root@HOST $ mv pki /etc/kubernetes/
```
1. S'assurer que tous les fichiers attendus existent
La liste complète des fichiers requis sur `$HOST0` est la suivante:
```
/tmp/${HOST0}
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── ca.key
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
```
Sur `$HOST1`:
```
$HOME
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
```
Sur `$HOST2`:
```
$HOME
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
├── ca.crt
├── healthcheck-client.crt
├── healthcheck-client.key
├── peer.crt
├── peer.key
├── server.crt
└── server.key
```
1. Créer les manifestes de pod statiques
Maintenant que les certificats et les configurations sont en place, il est temps de créer les
manifestes. Sur chaque hôte, exécutez la commande `kubeadm` pour générer un manifeste statique
pour etcd.
```sh
root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
```
1. Facultatif: Vérifiez la santé du cluster
```sh
docker run --rm -it \
--net host \
-v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl \
--cert-file /etc/kubernetes/pki/etcd/peer.crt \
--key-file /etc/kubernetes/pki/etcd/peer.key \
--ca-file /etc/kubernetes/pki/etcd/ca.crt \
--endpoints https://${HOST0}:2379 cluster-health
...
cluster is healthy
```
- Configurez `${ETCD_TAG}` avec la version de votre image etcd. Par exemple `v3.2.24`.
- Configurez `${HOST0}` avec l'adresse IP de l'hôte que vous testez.
{{% /capture %}}
{{% capture whatsnext %}}
Une fois que vous avez un cluster de 3 membres etcd qui fonctionne, vous pouvez continuer à
configurer un control plane hautement disponible utilisant la
[méthode etcd externe avec kubeadm](/docs/setup/independent/high-availability/).
{{% /capture %}}

285
content/fr/docs/setup/independent/troubleshooting-kubeadm.md Normal file
View File

@ -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 %}}