Bien démarrer

• 1: Environnement d’apprentissage
• 1.1: Installer Kubernetes avec Minikube
• 2: Environnement de production
• 2.1: Installer Kubernetes avec les outils de déploiement
• 2.1.1: Déploiement d'un cluster avec kubeadm
• 2.1.1.1: Installer kubeadm
• 2.1.1.2: Création d'un Cluster à master unique avec kubeadm
• 2.1.1.3: Personnalisation de la configuration du control plane avec kubeadm
• 2.1.1.4: Options pour la topologie en haute disponibilité
• 2.1.1.5: Création de clusters hautement disponibles avec kubeadm
• 2.1.1.6: Configurer un cluster etcd en haute disponibilité avec kubeadm
• 2.1.1.7: Configuration des kubelet de votre cluster avec kubeadm
• 2.1.1.8: Dépanner kubeadm
• 2.2: Solutions Cloud clés en main
• 2.3: Windows dans Kubernetes
• 3: Bonnes pratiques
• 3.1: Considérations pour les grands clusters
• 3.2: Exécution sur plusieurs zones
• 3.3: Valider la configuration du nœud
• 3.4: Application des standards de sécurité des Pods
• 3.5: Certificats PKI et exigences

1 - Environnement d’apprentissage

Si vous apprenez Kubernetes, vous avez besoin d’un environnement pour pratiquer. Cette page explique les différentes options pour configurer un environnement Kubernetes dans lequel vous pouvez expérimenter et apprendre.

Installation de kubectl

Avant de configurer un cluster, vous devez disposer de l’outil en ligne de commande kubectl. Cet outil vous permet de communiquer avec un cluster Kubernetes et d’exécuter des commandes sur celui-ci.

Consultez Installer et configurer kubectl pour les instructions d’installation.

Configuration d’environnements Kubernetes locaux

Exécuter Kubernetes localement vous offre un environnement sûr pour apprendre et expérimenter. Vous pouvez créer et supprimer des clusters sans vous soucier des coûts ni affecter des systèmes de production.

kind

kind (Kubernetes IN Docker) exécute des clusters Kubernetes en utilisant des conteneurs Docker comme nœuds. Il est léger et conçu spécifiquement pour tester Kubernetes lui-même, mais fonctionne également très bien pour l’apprentissage.

Pour commencer avec kind, consultez le guide kind Quick Start.

minikube

minikube exécute un cluster Kubernetes à nœud unique sur votre machine locale. Il prend en charge plusieurs runtimes de conteneurs et fonctionne sur Linux, macOS et Windows.

Pour commencer avec minikube, consultez le guide minikube Get Started.

Autres options locales

Il existe plusieurs outils tiers capables d’exécuter Kubernetes localement. Kubernetes ne fournit pas de support pour ces outils, mais ils peuvent convenir à vos besoins d’apprentissage :

• Docker Desktop peut exécuter un cluster Kubernetes local
• Podman Desktop peut exécuter un cluster Kubernetes local
• Rancher Desktop fournit Kubernetes sur votre poste de travail
• MicroK8s exécute un cluster Kubernetes léger
• Red Hat CodeReady Containers (CRC) exécute localement un cluster OpenShift minimal (OpenShift est conforme à Kubernetes)

Consultez la documentation de chaque outil pour les instructions d’installation et le support.

Utiliser des environnements de test en ligne

Les environnements de test Kubernetes en ligne vous permettent d’essayer Kubernetes sans rien installer sur votre ordinateur. Ces environnements s’exécutent dans votre navigateur web :

• Killercoda fournit des scénarios Kubernetes interactifs ainsi qu’un environnement de test

Ces plateformes sont utiles pour des expérimentations rapides et pour suivre des tutoriels sans configuration locale.

Pratiquer avec des clusters proches de la production

Si vous souhaitez pratiquer la configuration d’un cluster plus proche d’un environnement de production, vous pouvez utiliser kubeadm. Configurer un cluster avec kubeadm est une tâche avancée qui nécessite plusieurs machines (physiques ou virtuelles) ainsi qu’une configuration minutieuse.

Pour en savoir plus sur les environnements de production, consultez Environnement de production.

A suivre

• Suivez le tutoriel Hello Minikube pour déployer votre première application
• Découvrez les composants Kubernetes
• Explorez les commandes kubectl

1.1 - Installer Kubernetes avec Minikube

Minikube est un outil facilitant l’exécution locale de Kubernetes. Minikube exécute un cluster Kubernetes à nœud unique dans une machine virtuelle (VM) de votre ordinateur portable pour les utilisateurs qui souhaitent essayer Kubernetes ou le développer au quotidien.

Fonctionnalités de Minikube

Minikube prend en charge les fonctionnalités Kubernetes suivantes:

• DNS
• NodePorts
• ConfigMaps et Secrets
• Dashboards
• Container Runtime: Docker, CRI-O, et containerd
• Activation de la CNI (Container Network Interface)
• Ingress

Installation

Consultez Installation de Minikube.

Démarrage rapide

Cette brève démonstration vous explique comment démarrer, utiliser et supprimer les minikube localement. Suivez les étapes ci-dessous pour commencer et explorer Minikube.

1. Lancez Minikube et créez un cluster:

   minikube start
   

   Le résultat est similaire à ceci:

   Starting local Kubernetes cluster...
   Running pre-create checks...
   Creating machine...
   Starting local Kubernetes cluster...
   

   Pour plus d'informations sur le démarrage de votre cluster avec une version spécifique de Kubernetes, une machine virtuelle ou un environnement de conteneur, voir Démarrage d'un cluster.

2. Vous pouvez maintenant interagir avec votre cluster à l'aide de kubectl. Pour plus d'informations, voir Interagir avec votre cluster.

   Créons un déploiement Kubernetes en utilisant une image existante nommée echoserver, qui est un serveur HTTP, et exposez-la sur le port 8080 à l’aide de --port.

   kubectl create deployment hello-minikube --image=registry.k8s.io/echoserver:1.10
   

   Le résultat est similaire à ceci:

   deployment.apps/hello-minikube created
   

3. Pour accéder au Deployment hello-minikube, exposez-le comme un Service:

   kubectl expose deployment hello-minikube --type=NodePort --port=8080
   

   L'option --type=NodePort spécifie le type du Service.

   Le résultat est similaire à ceci:

   service/hello-minikube exposed
   

4. Le Pod hello-minikube est maintenant lancé, mais vous devez attendre que le Pod soit opérationnel avant d'y accéder via le Service.

   Vérifiez si le Pod est opérationnel:

   kubectl get pod
   

   Si la sortie affiche le STATUS comme ContainerCreating, le Pod est toujours en cours de création:

   NAME                              READY     STATUS              RESTARTS   AGE
   hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
   

   Si la sortie indique le statut STATUS comme Running, le Pod est maintenant opérationnel:

   NAME                              READY     STATUS    RESTARTS   AGE
   hello-minikube-3383150820-vctvh   1/1       Running   0          13s
   

5. Obtenez l'URL du Service exposé pour afficher les détails du service:

   minikube service hello-minikube --url
   

6. Pour afficher les détails de votre cluster local, copiez et collez l’URL que vous avez obtenue en tant que sortie dans votre navigateur.

   Le résultat est similaire à ceci:

   Hostname: hello-minikube-7c77b68cff-8wdzq
   
   Pod Information:
       -no pod information available-
   
   Server values:
       server_version=nginx: 1.13.3 - lua: 10008
   
   Request Information:
       client_address=172.17.0.1
       method=GET
       real path=/
       query=
       request_version=1.1
       request_scheme=http
       request_uri=http://192.168.99.100:8080/
   
   Request Headers:
       accept=*/*
       host=192.168.99.100:30674
       user-agent=curl/7.47.0
   
   Request Body:
       -no body in request-
   

   Si vous ne souhaitez plus que le service et le cluster s'exécutent, vous pouvez les supprimer.

7. Supprimez le Service hello-minikube:

    kubectl delete services hello-minikube
   

   Le résultat est similaire à ceci:

   service "hello-minikube" deleted
   

8. Supprimez le Deployment hello-minikube:

   kubectl delete deployment hello-minikube
   

   Le résultat est similaire à ceci:

   deployment.extensions "hello-minikube" deleted
   

9. Arrêtez le cluster de minikube local:

   minikube stop
   

   Le résultat est similaire à ceci:

   Stopping "minikube"...
   "minikube" stopped.
   

   Pour plus d'informations, voir Arrêt d'un cluster.

10. Supprimez le cluster de minikube local:

    minikube delete
    

    Le résultat est similaire à ceci:

    Deleting "minikube" ...
    The "minikube" cluster has been deleted.
    

    Pour plus d'informations, voir Suppression d'un cluster.

Gérer votre cluster

Démarrer un cluster

La commande minikube start peut être utilisée pour démarrer votre cluster. Cette commande crée et configure une machine virtuelle qui exécute un cluster Kubernetes à un seul nœud. Cette commande configure également kubectl pour communiquer avec ce cluster.

https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24

Spécifier la version de Kubernetes

Vous pouvez spécifier la version de Kubernetes pour Minikube à utiliser en ajoutant la chaîne --kubernetes-version à la commande minikube start. Par exemple, pour exécuter la version 1.36.0, procédez comme suit:

minikube start --kubernetes-version v1.36.0

Spécification du pilote de machine virtuelle

Vous pouvez changer le pilote de machine virtuelle en ajoutant l'indicateur --vm-driver=<nom_du_pilote> à minikube start. Par exemple, la commande serait:

minikube start --vm-driver=<nom_du_pilote>

Minikube prend en charge les pilotes suivants:

• virtualbox
• vmwarefusion
• kvm2 (installation du pilote)
• hyperkit (installation du pilote)
• hyperv (installation du pilote) Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec minikube ip.
• vmware (installation du pilote) (VMware unified driver)
• none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker (docker installer) et un environnement Linux)

Démarrage d'un cluster sur des exécutions de conteneur alternatives

Vous pouvez démarrer Minikube aux exécutions de conteneurs suivantes.

• containerd
• CRI-O

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=containerd \
    --bootstrapper=kubeadm

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
    --bootstrapper=kubeadm

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=cri-o \
    --bootstrapper=kubeadm

minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
    --bootstrapper=kubeadm

Utiliser des images locales en réutilisant le démon Docker

Lorsque vous utilisez une seule machine virtuelle pour Kubernetes, il est utile de réutiliser le démon Docker intégré de Minikube. La réutilisation du démon intégré signifie que vous n’avez pas besoin de créer un registre Docker sur votre ordinateur hôte et d’y insérer l’image. Au lieu de cela, vous pouvez créer le même démon Docker que Minikube, ce qui accélère les expériences locales.

Pour travailler avec le démon Docker sur votre hôte Mac/Linux, utilisez la commande docker-env dans votre shell:

eval $(minikube docker-env)

Vous pouvez maintenant utiliser Docker sur la ligne de commande de votre ordinateur hôte Mac/Linux pour communiquer avec le démon Docker dans la VM Minikube:

docker ps

Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory

< DOCKER_CERT_PATH=/etc/docker
---
> if [ -z "${DOCKER_CERT_PATH}" ]; then
>   DOCKER_CERT_PATH=/etc/docker
> fi

Configuration de Kubernetes

Minikube a une fonction de "configurateur" qui permet aux utilisateurs de configurer les composants Kubernetes avec des valeurs arbitraires. Pour utiliser cette fonctionnalité, vous pouvez utiliser l'indicateur --extra-config de la commande minikube start.

Cet indicateur est répété, vous pouvez donc le transmettre plusieurs fois avec plusieurs valeurs différentes pour définir plusieurs options.

Cet indicateur prend une chaîne de la forme composant.key=valeur, où composant est l'une des chaînes de la liste ci-dessous, key est une valeur de la structure de configuration et valeur est la valeur à définir.

Des clés valides peuvent être trouvées en examinant la documentation de Kubernetes composantconfigs pour chaque composant. Voici la documentation pour chaque configuration prise en charge:

• kubelet
• apiserver
• proxy
• controller-manager
• etcd
• scheduler

Exemples

Pour changer le paramètre MaxPods en 5 sur le Kubelet, passez cet indicateur: --extra-config=kubelet.MaxPods=5.

Cette fonctionnalité prend également en charge les structures imbriquées. Pour modifier le paramètre LeaderElection.LeaderElect sur true sur le planificateur, transmettez cet indicateur: --extra-config=scheduler.LeaderElection.LeaderElect=true.

Pour définir le AuthorizationMode du apiserver sur RBAC, vous pouvez utiliser: --extra-config=apiserver.authorization-mode=RBAC.

Arrêter un cluster

La commande minikube stop peut être utilisée pour arrêter votre cluster. Cette commande arrête la machine virtuelle Minikube, mais conserve tout l'état et les données du cluster. Le redémarrage du cluster le restaurera à son état précédent.

Suppression d'un cluster

La commande minikube delete peut être utilisée pour supprimer votre cluster. Cette commande ferme et supprime la machine virtuelle Minikube. Aucune donnée ou état n'est conservé.

Mise à niveau de minikube

Voir upgrade minikube

Interagir avec votre cluster

Kubectl

La commande minikube start crée un contexte kubectl appelé "minikube". Ce contexte contient la configuration pour communiquer avec votre cluster Minikube.

Minikube définit automatiquement ce contexte par défaut, mais si vous devez y revenir ultérieurement, exécutez:

kubectl config use-context minikube,

Ou passez le contexte sur chaque commande comme ceci: kubectl get pods --context=minikube.

Dashboard

Pour accéder au Kubernetes Dashboard, lancez cette commande dans un shell après avoir lancé Minikube pour obtenir l'adresse:

minikube dashboard

Services

Pour accéder à un service exposé via un port de nœud, exécutez cette commande dans un shell après le démarrage de Minikube pour obtenir l'adresse:

minikube service [-n NAMESPACE] [--url] NAME

La mise en réseau

La machine virtuelle Minikube est exposée au système hôte via une adresse IP routable uniquement depuis le hôte, qui peut être obtenue à l'aide de la commande minikube ip. Tous les services de type NodePort sont accessibles via cette adresse IP, sur le NodePort.

Pour déterminer le NodePort pour votre service, vous pouvez utiliser une commande kubectl comme celle-ci:

kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'

Volumes persistants

Minikube supporte les PersistentVolumes de type hostPath. Ces volumes persistants sont mappés vers un répertoire à l'intérieur de la VM Minikube.

La machine virtuelle Minikube démarre dans un fichier tmpfs, de sorte que la plupart des répertoires ne seront pas conservés lors des redémarrages avec (minikube stop). Toutefois, Minikube est configuré pour conserver les fichiers stockés dans les répertoires d’hôte suivants:

• /data
• /var/lib/minikube
• /var/lib/docker

Voici un exemple de configuration PersistentVolume permettant de conserver des données dans le répertoire /data:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 5Gi
  hostPath:
    path: /data/pv0001/

Dossiers hôtes montés

Certains pilotes vont monter un dossier hôte dans la VM afin de pouvoir facilement partager des fichiers entre la VM et l'hôte. Celles-ci ne sont pas configurables pour le moment et diffèrent selon le pilote et le système d'exploitation que vous utilisez.

Registres de conteneurs privés

Pour accéder à un registre de conteneurs privé, suivez les étapes de cette page.

Nous vous recommandons d'utiliser ImagePullSecrets, mais si vous souhaitez configurer l'accès sur la VM Minikube, vous pouvez placer le .dockercfg dans le repertoire /home/docker ou le config.json dans le repertoire /home/docker/.docker.

Add-ons

Pour que Minikube puisse démarrer ou redémarrer correctement des addons personnalisés, placez les addons que vous souhaitez lancer avec Minikube dans le répertoire ~/.minikube/addons. Les extensions de ce dossier seront déplacées vers la VM Minikube et lancées à chaque démarrage ou redémarrage de Minikube.

Utilisation de Minikube avec un proxy HTTP

Minikube crée une machine virtuelle qui inclut Kubernetes et un démon Docker. Lorsque Kubernetes tente de planifier des conteneurs à l'aide de Docker, le démon Docker peut nécessiter un accès réseau externe pour extraire les conteneurs.

Si vous êtes derrière un proxy HTTP, vous devrez peut-être fournir à Docker les paramètres de proxy. Pour ce faire, transmettez les variables d’environnement requises en tant qu’indicateurs lors de la création de minikube start.

Par exemple:

minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
                 --docker-env https_proxy=https://$YOURPROXY:PORT

Si l'adresse de votre machine virtuelle est 192.168.99.100, il est probable que vos paramètres de proxy empêcheront kubectl de l'atteindre directement. Pour contourner la configuration du proxy pour cette adresse IP, vous devez modifier vos paramètres no_proxy. Vous pouvez le faire avec:

export no_proxy=$no_proxy,$(minikube ip)

Problèmes connus

Les fonctionnalités nécessitant plusieurs nœuds ne fonctionneront pas dans Minikube.

Conception

Minikube utilise libmachine pour le provisionnement de machines virtuelles, et kubeadm mettre en service un cluster Kubernetes.

Pour plus d'informations sur Minikube, voir la proposition.

Liens supplémentaires

• Objectifs et non-objectifs: Pour les objectifs et non-objectifs du projet Minikube, veuillez consulter notre roadmap.
• Guide de développement: Voir CONTRIBUTING.md pour avoir un aperçu de comment envoyer des pull requests.
• Construire Minikube: Pour obtenir des instructions sur la création / test de Minikube à partir des sources, voir le guide de build.
• Ajout d'une nouvelle dépendance: Pour savoir comment ajouter une nouvelle dépendance à Minikube, voir la section guide d'ajout de dépendances.
• Ajout d'un nouvel addon: Pour savoir comment ajouter un nouvel addon pour Minikube, reportez-vous au Ajout d’un addon.
• MicroK8s: Les utilisateurs de Linux qui souhaitent éviter d’exécuter une machine virtuelle peuvent envisager MicroK8s.

Communauté

Les contributions, questions et commentaires sont les bienvenus et sont encouragés ! Les développeurs de minikube sont dans le canal #minikube du Slack de Kubernetes (recevoir une invitation ici). Nous avons également la liste de diffusion dev@kubernetes Google Groupes. Si vous publiez sur la liste, veuillez préfixer votre sujet avec "minikube:".

2 - Environnement de production

2.1 - Installer Kubernetes avec les outils de déploiement

2.1.1 - Déploiement d'un cluster avec kubeadm

2.1.1.1 - Installer kubeadm

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.

Pré-requis

• Une ou plusieurs machines exécutant:
  • Ubuntu 16.04+
  • Debian 9+
  • CentOS 7
  • Red Hat Enterprise Linux (RHEL) 7
  • Fedora 25+
  • HypriotOS v1.0.1+
  • Flatcar Container Linux (testé avec 2512.3.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 pour plus de détails.
• Certains ports doivent êtres ouverts sur vos machines. Voir ici pour plus de détails.
• Swap désactivé. Vous devez impérativement désactiver le swap pour que la kubelet fonctionne correctement.

Vérifiez que les adresses MAC et product_uuid sont uniques pour chaque nœud

• 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.

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é.

Permettre à iptables de voir le trafic ponté

Assurez-vous que le module br_netfilter est chargé. Cela peut être fait en exécutant lsmod | grep br_netfilter. Pour le charger explicitement, appelez sudo modprobe br_netfilter.

Pour que les iptables de votre nœud Linux voient correctement le trafic ponté, vous devez vous assurer que net.bridge.bridge-nf-call-iptables est défini sur 1 dans votre configuration sysctl, par ex.

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

Pour plus de détails, veuillez consulter la page Configuration requise pour le plug-in réseau.

Vérifiez les ports requis

nœuds maîtres (masters)

nœuds workers

** Plage de ports par défaut pour les Services NodePort.

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).

Installation du runtime

Pour exécuter des conteneurs dans des pods, Kubernetes utilise un container runtime.

• Linux nodes
• autres systèmes d'exploitation

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.

For information about installing kubectl, see Installation et configuration kubectl.

Pour plus d'informations sur les compatibilités de version, voir:

• Kubernetes version et politique de compatibilité de version
• Kubeadm-specific politique de compatibilité de version

• Distributions basées sur Debian
• Distributions basées sur Red Hat
• Sans gestionnaire de paquets

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF

# Mettre SELinux en mode permissif (le désactiver efficacement)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

sudo systemctl enable --now kubelet

CNI_VERSION="v0.8.2"
ARCH="amd64"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz

DOWNLOAD_DIR=/usr/local/bin
sudo mkdir -p $DOWNLOAD_DIR

CRICTL_VERSION="v1.22.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}

curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

sudo systemctl enable --now kubelet

Kubelet redémarre maintenant toutes les quelques secondes, car il attend les instructions de kubeadm dans une boucle de crash.

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 kubelet et le configure dans le fichier /var/lib/kubelet/config.yaml lors de son éxecution.

Si vous utilisez un autre CRI, vous devez passer votre valeur cgroupDriver avec kubeadm init, comme ceci :

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: <value>

Pour plus de détails, veuillez lire Utilisation de kubeadm init avec un fichier de configuration.

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:

sudo systemctl daemon-reload
sudo systemctl restart kubelet

La détection automatique du pilote cgroup pour d'autres runtimes de conteneur comme CRI-O et containerd est un travail en cours.

Dépannage

Si vous rencontrez des difficultés avec kubeadm, veuillez consulter notre documentation de dépannage.

A suivre

• Utiliser kubeadm pour créer un cluster

2.1.1.2 - Création d'un Cluster à master unique avec kubeadm

kubeadm vous aide à démarrer un cluster Kubernetes minimum, viable et conforme aux meilleures pratiques. Avec kubeadm, votre cluster doit passer les tests de Conformité Kubernetes. 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.

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, 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

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.

Pré-requis

• 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é.

Objectifs

• Installer un cluster Kubernetes à master unique ou un cluster à haute disponibilité
• 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".

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.
2. (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
3. (Optional) Lancez kubeadm config images pull avant de faire kubeadm init pour vérifier la connectivité aux registres gcr.io.

Maintenant, lancez:

kubeadm init <args>

Plus d'information

Pour plus d'informations sur les arguments de kubeadm init, voir le guide de référence kubeadm.

Pour une liste complète des options de configuration, voir la documentation du fichier de configuration.

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.

Pour lancer encore une fois kubeadm init, vous devez d'abord détruire le cluster.

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 à:

[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/fr/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:

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:

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.

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.

Installation d'un add-on réseau

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. Allez voir la page des add-ons pour une liste complète des add-ons réseau disponibles.

• Le support IPv6 a été ajouté dans CNI v0.6.0.
• CNI bridge et local-ipam 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. 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:

kubectl apply -f <add-on.yaml>

Vous ne pouvez installer qu'un seul réseau de pod par cluster.

• Choisissez-en un...
• Calico
• Canal
• Cilium
• Flannel
• Kube-router
• Romana
• Weave Net
• JuniperContrail/TungstenFabric

kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml

kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml

kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-

kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml

$ kubectl get pods -n kube-system --selector=k8s-app=cilium
NAME           READY   STATUS    RESTARTS   AGE
cilium-drxkl   1/1     Running   0          18m

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml

kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

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.

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:

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

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:

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:

kubeadm token list

L'output est similaire à ceci:

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:

kubeadm token create

L'output est similaire à ceci:

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:

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:

8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78

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:

scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

(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:

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

Pour annuler ce que kubeadm a fait, vous devez d’abord drainer le nœud 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:

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:

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:

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:

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.

Maintenir un cluster

Vous trouverez des instructions pour la maintenance des clusters kubeadm (mises à niveau, rétrogradation, etc.) ici

Explorer les autres add-ons

Parcourez la liste des add-ons, 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 ?

• Vérifiez que votre cluster fonctionne correctement avec Sonobuoy
• En savoir plus sur l'utilisation avancée de kubeadm dans la documentation de référence de kubeadm
• En savoir plus sur Kubernetes concepts et kubectl.
• 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 pour plus de détails.

Feedback

• Pour les bugs, visitez kubeadm GitHub issue tracker
• Pour le support, rendez vous sur le Channel Slack kubeadm: #kubeadm
• Le Channel Slack: General SIG Cluster Lifecycle Development: #sig-cluster-lifecycle
• SIG Cluster Lifecycle SIG information
• SIG Cluster Lifecycle Mailing List: kubernetes-sig-cluster-lifecycle

Politique de compatibilité de versions

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 de Kubernetes
• Guide d'installation spécifique à Kubeadm

kubeadm fonctionne sur plusieurs plates-formes

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.

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

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. le répertoire des données etcd configuré par kubeadm se trouve dans /var/lib/etcd sur le master.

Diagnostic

Si vous rencontrez des difficultés avec kubeadm, veuillez consulter nos troubleshooting docs.

2.1.1.3 - Personnalisation de la configuration du control plane avec kubeadm

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.

Paramètres pour l'API Server

Pour plus de détails, voir la documentation de référence pour kube-apiserver.

Exemple d'utilisation:

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.

Exemple d'utilisation:

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.

Example usage:

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
metadata:
  name: 1.13-sample
scheduler:
  extraArgs:
    bind-address: 0.0.0.0
    config: /home/johndoe/schedconfig.yaml
    kubeconfig: /home/johndoe/kubeconfig.yaml

2.1.1.4 - Options pour la topologie en haute disponibilité

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é.

Topologie etcd empilée

Un cluster HA empilé est une topologie réseau 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

Topologie etcd externe

Un cluster haute disponibilité avec un etcd externe est une topologie réseau où le cluster de stockage de données distribuées 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. Elle 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

A suivre

• Configurer un cluster hautement disponible avec kubeadm

2.1.1.5 - Création de clusters hautement disponibles avec kubeadm

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 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.

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.

Pré-requis

Pour les deux méthodes, vous avez besoin de cette infrastructure:

• Trois machines qui répondent aux pré-requis des exigences de kubeadm pour les maîtres (masters)
• Trois machines qui répondent aux pré-requis des exigences de kubeadm 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

Premières étapes pour les deux méthodes

• 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. 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

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 peut être utilisé comme load balancer.

   • Assurez-vous que l'adresse du load balancer correspond toujours à       l'adresse de ControlPlaneEndpoint de kubeadm.

2. Ajoutez les premiers nœuds du control plane au load balancer et testez la connexion:

   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.

3. 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)
   

2. Ajoutez votre clé SSH à la session:

   ssh-add ~/.ssh/path_to_private_key
   

3. 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.

2. Assurez-vous que le nœud est dans un état sain:

   sudo kubeadm init --config=kubeadm-config.yaml
   

   Vous devriez voir quelque chose comme:

   ...
   

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.

2. Activez l'extension CNI Weave:

   kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
   

3. Tapez ce qui suit et observez les pods des composants démarrer:

   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.

4. 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.

   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
   

É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é:

   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.

2. 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:

   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.

3. Tapez ce qui suit et observez les pods des composants démarrer:

   kubectl get pod -n kube-system -w
   

4. Répétez ces étapes pour le reste des nœuds du control plane.

Noeuds etcd externes

Configurer le cluster etcd

• Suivez ces instructions 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.:

   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.

2. 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

3. Lancez kubeadm init --config kubeadm-config.yaml sur ce nœud.

4. Ecrivez le résultat de la commande de join dans un fichier texte pour une utilisation ultérieure.

5. Appliquer le plugin CNI Weave:

   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. 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 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.

2.1.1.6 - Configurer un cluster etcd en haute disponibilité avec kubeadm

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.

Pré-requis

• 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.
• Certains paquets pour copier des fichiers entre les hôtes. Par exemple, ssh et scp.

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.

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.

   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
   Restart=always
   EOF
   
   systemctl daemon-reload
   systemctl restart kubelet
   

2. 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.

   # 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
   

3. 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

4. Créer des certificats pour chaque membre

   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
   

5. 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.

   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/
   

6. 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
   

7. 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.

   root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
   root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   

8. Facultatif: Vérifiez la santé du cluster

   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.

A suivre

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.

2.1.1.7 - Configuration des kubelet de votre cluster avec kubeadm

Le cycle de vie de l’outil CLI kubeadm est découplé de celui de la 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.

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

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:

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:

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.

Fournir des détails de configuration spécifiques à l'instance

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

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 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.

Pour répondre au besoin de fournir des détails de configuration spécifiques à l'instance de kubelet, 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:

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:

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:

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

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.

[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:

2.1.1.8 - Dépanner kubeadm

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

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

• Si vous pensez que votre problème est un bug avec kubeadm:

  • Aller à github.com/kubernetes/kubeadm et rechercher les problèmes existants.
  • Si aucune issue n'existe, veuillez en ouvrir une et suivez le modèle ( template ) d'issue

• Si vous ne savez pas comment fonctionne kubeadm, vous pouvez demander sur Slack dans le canal #kubeadm, ou posez une questions sur StackOverflow. Merci d'ajouter les tags pertinents comme #kubernetes et #kubeadm, ainsi on pourra vous aider.

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

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

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

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

• 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:

[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:

  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.
2. Changez manuellement la configuration de la kubelet pour correspondre au driver Docker cgroup, vous pouvez vous référer à     Configurez le driver de cgroupe utilisé par la kubelet sur le Nœud Master pour des instruction détaillées.

• 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:

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

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

sudo systemctl restart docker.service
sudo kubeadm reset

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

journalctl -ul docker

Pods dans l'état RunContainerError, CrashLoopBackOff ou Error

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

• 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 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.

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

Les pods ne sont pas accessibles via leur IP de service

• De nombreux add-ons réseau ne permettent pas encore hairpin mode qui permet aux pods d’accéder à eux-mêmes via leur IP de service. Ceci est un problème lié au CNI. 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 par exemple.

Erreurs de certificats TLS

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

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

• 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 ":

  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:

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:

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:

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

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

  Puis redémarrer la kubelet:

  systemctl daemon-reload
  systemctl restart kubelet
  

Les pods coredns sont en é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.
• Désactiver SELinux.
• Modifiez le déploiement de coredns pour définir allowPrivilegeEscalation à true:

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 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.

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:

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

2.2 - Solutions Cloud clés en main

2.3 - Windows dans Kubernetes

3 - Bonnes pratiques

3.1 - Considérations pour les grands clusters

Un cluster est un ensemble de nœuds (machines physiques ou virtuelles) exécutant des agents Kubernetes, et gérés par le plan de contrôle. Kubernetes v1.36 prend en charge des clusters allant jusqu’à 5 000 nœuds. Plus précisément, Kubernetes est conçu pour s’adapter à des configurations respectant toutes les conditions suivantes :

• Pas plus de 110 pods par nœud
• Pas plus de 5 000 nœuds
• Pas plus de 150 000 pods au total
• Pas plus de 300 000 conteneurs au total

Vous pouvez faire évoluer votre cluster en ajoutant ou en supprimant des nœuds. La manière de procéder dépend de la façon dont votre cluster est déployé.

Quotas de ressources des fournisseurs cloud

Pour éviter les problèmes de quotas des fournisseurs cloud lors de la création d’un cluster comportant de nombreux nœuds, il faut envisager :

• Demander une augmentation de quota pour les ressources cloud telles que :
  • Instances de calcul
  • CPU
  • Volumes de stockage
  • Adresses IP utilisées
  • Règles de filtrage de paquets
  • Nombre de load balancers
  • Sous-réseaux
  • Flux de logs
• Réguler les opérations de mise à l’échelle du cluster afin de créer les nouveaux nœuds par lots, avec une pause entre chaque lot, car certains fournisseurs cloud appliquent des limites de débit sur la création d’instances.

Composants du plan de contrôle

Pour un cluster de grande taille, vous avez besoin d’un plan de contrôle disposant de ressources de calcul suffisantes.

En général, vous exécutez une ou deux instances du plan de contrôle par zone de défaillance, en les faisant évoluer verticalement en premier lieu, puis horizontalement une fois les gains de performance devenus marginaux.

Vous devez exécuter au moins une instance par zone de défaillance pour assurer la tolérance aux pannes. Les nœuds Kubernetes n’orientent pas automatiquement le trafic vers les points de terminaison du plan de contrôle situés dans la même zone de défaillance ; cependant, votre fournisseur cloud peut proposer ses propres mécanismes pour cela.

Par exemple, avec un load balancer géré, vous pouvez configurer celui-ci pour diriger le trafic provenant du kubelet et des Pods situés dans la zone de défaillance A uniquement vers les serveurs du plan de contrôle également situés dans la zone A. Si un seul serveur du plan de contrôle ou un endpoint de la zone A devient indisponible, tout le trafic du plan de contrôle de cette zone sera redirigé entre zones. Avoir plusieurs serveurs du plan de contrôle par zone réduit ce risque.

Stockage etcd

Pour améliorer les performances des grands clusters, vous pouvez stocker les objets Event dans une instance etcd dédiée et séparée.

Lors de la création d’un cluster, vous pouvez (via des outils personnalisés) :

• démarrer et configurer une instance etcd supplémentaire
• configurer le serveur API pour y stocker les événements

Voir Opérer des clusters etcd pour Kubernetes et Configurer un cluster etcd haute disponibilité avec kubeadm pour plus de détails sur la configuration et la gestion d’etcd dans un grand cluster.

Ressources des addons

Les limites de ressources Kubernetes permettent de limiter l’impact des fuites mémoire et d’autres problèmes pouvant affecter les pods et conteneurs sur les autres composants. Ces limites s’appliquent également aux ressources des addons de la même manière qu’aux charges applicatives.

Par exemple, vous pouvez définir des limites CPU et mémoire pour un composant de logging :

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Les limites par défaut des addons sont généralement basées sur des données issues de l’expérience d’exécution de chaque addon sur des clusters Kubernetes de petite ou moyenne taille. Lorsqu’ils sont exécutés sur de grands clusters, les addons consomment souvent davantage de ressources que ce que permettent leurs limites par défaut. Si un grand cluster est déployé sans ajuster ces valeurs, les addons peuvent être constamment redémarrés car ils atteignent la limite mémoire. Alternativement, ils peuvent fonctionner mais avec de mauvaises performances en raison des restrictions de partage du temps CPU.

Pour éviter les problèmes de ressources liés aux addons du cluster lors de la création d’un cluster comportant de nombreux nœuds, il faut considérer les points suivants :

• Certains addons sont scalés verticalement — il n’existe qu’une seule réplique de l’addon pour tout le cluster ou pour une zone de défaillance entière. Pour ces addons, il faut augmenter les requests et les limits lors de la montée en charge du cluster.
• De nombreux addons sont scalés horizontalement — la capacité est augmentée en ajoutant des pods — mais dans les très grands clusters, il peut également être nécessaire d’augmenter légèrement les limites CPU ou mémoire. Le Vertical Pod Autoscaler peut fonctionner en mode recommender afin de proposer des valeurs recommandées pour les requests et limits.
• Certains addons s’exécutent en une copie par nœud, contrôlés par un DaemonSet : par exemple, un agrégateur de logs au niveau des nœuds. Comme dans le cas des addons scalés horizontalement, il peut également être nécessaire d’augmenter légèrement les limites CPU ou mémoire.

Priorisation des composants essentiels du cluster

Pour garantir que les composants essentiels du cluster (tels que CoreDNS, metrics-server et autres addons critiques) soient planifiés avant les autres charges de travail et ne soient pas préemptés par des pods de priorité plus faible, exécutez-les avec une PriorityClass système, telle que system-cluster-critical ou system-node-critical.

A suivre

• VerticalPodAutoscaler est une ressource personnalisée que vous pouvez déployer dans votre cluster afin de gérer les requests et limits des pods.
  Apprenez-en plus sur le Vertical Pod Autoscaler et sur la manière de l’utiliser pour scaler les composants du cluster, y compris les addons critiques.

• Consultez l’autoscaling des nœuds

• Le addon resizer vous aide à redimensionner automatiquement les addons lorsque la taille du cluster évolue.

3.2 - Exécution sur plusieurs zones

Cette page décrit l’exécution de Kubernetes sur plusieurs zones.

Contexte

Kubernetes est conçu pour qu’un seul cluster Kubernetes puisse fonctionner sur plusieurs zones de défaillance, généralement regroupées au sein d’une entité logique appelée une région. Les principaux fournisseurs cloud définissent une région comme un ensemble de zones de défaillance (également appelées zones de disponibilité) qui offrent un ensemble cohérent de fonctionnalités : dans une région, chaque zone expose les mêmes API et services.

Les architectures cloud typiques visent à réduire au maximum le risque qu’une panne dans une zone affecte également les services d’une autre zone.

Comportement du plan de contrôle

Tous les composants du plan de contrôle peuvent fonctionner comme un ensemble de ressources interchangeables, répliquées par composant.

Lors du déploiement d’un plan de contrôle Kubernetes, placez les réplicas des composants du plan de contrôle sur plusieurs zones de défaillance. Si la disponibilité est un critère important, sélectionnez au moins trois zones de défaillance et répliquez chaque composant du plan de contrôle (API server, scheduler, etcd, controller manager) sur au moins trois zones de défaillance. Si vous utilisez un cloud controller manager, vous devez également le répliquer dans toutes les zones sélectionnées.

Comportement des nœuds

Kubernetes répartit automatiquement les Pods des ressources de charge de travail (telles que Deployment ou StatefulSet) sur différents nœuds du cluster. Cette répartition permet de réduire l’impact des défaillances.

Lors de leur démarrage, les kubelets sur chaque nœud ajoutent automatiquement des labels à l’objet Node représentant ce kubelet dans l’API Kubernetes. Ces labels peuvent inclure des informations de zone (zone information).

Si votre cluster s’étend sur plusieurs zones ou régions, vous pouvez utiliser ces labels avec des contraintes de répartition topologique des Pods pour contrôler la distribution des Pods entre les domaines de défaillance : régions, zones et même nœuds spécifiques. Ces indications permettent au scheduler de placer les Pods de manière à améliorer la disponibilité et réduire le risque qu’une panne corrélée affecte l’ensemble de votre charge de travail.

Par exemple, vous pouvez définir une contrainte pour vous assurer que les 3 réplicas d’un StatefulSet sont répartis sur des zones différentes lorsque cela est possible. Cela peut être défini de manière déclarative sans avoir à spécifier explicitement les zones utilisées pour chaque workload.

Répartition des nœuds entre les zones

Le cœur de Kubernetes ne crée pas de nœuds pour vous ; vous devez le faire vous-même, ou utiliser un outil comme le Cluster API pour gérer les nœuds à votre place.

Avec des outils comme Cluster API, vous pouvez définir des ensembles de machines exécutées comme nœuds de travail répartis sur plusieurs domaines de défaillance, ainsi que des règles permettant de réparer automatiquement le cluster en cas de panne complète d’une zone.

Attribution manuelle des zones aux Pods

Vous pouvez appliquer des sélecteurs de nœuds aux Pods que vous créez, ainsi qu’aux templates de Pods dans les ressources de type Deployment, StatefulSet ou Job.

Accès au stockage par zone

Lors de la création de volumes persistants, Kubernetes ajoute automatiquement des labels de zone aux PersistentVolumes liés à une zone spécifique. Le scheduler s’assure ensuite, via le prédicat NoVolumeZoneConflict, que les pods utilisant un PersistentVolume donné sont planifiés uniquement dans la même zone que ce volume.

Notez que la manière d’ajouter ces labels dépend du fournisseur cloud et du provisionneur de stockage utilisé. Consultez toujours la documentation de votre environnement pour garantir une configuration correcte.

Vous pouvez spécifier une StorageClass qui définit les domaines de défaillance (zones) dans lesquels le stockage peut être créé. Pour en savoir plus, consultez les topologies autorisées.

Réseau

Kubernetes n’intègre pas nativement de prise en charge du réseau par zone. Vous pouvez utiliser un plugin réseau pour configurer la connectivité du cluster, et cette solution peut inclure des éléments dépendant des zones. Par exemple, si votre fournisseur cloud prend en charge les Services de type LoadBalancer, le load balancer peut diriger le trafic uniquement vers les Pods situés dans la même zone que l’instance traitant la connexion.

Consultez la documentation de votre fournisseur cloud pour plus de détails.

Pour les déploiements sur site ou personnalisés, des considérations similaires s’appliquent. Le comportement des Service et Ingress, notamment en matière de zones, dépend de la configuration de votre cluster.

Récupération en cas de panne

Lors de la configuration du cluster, vous devez également envisager la manière dont votre système peut restaurer le service si toutes les zones d’une région deviennent indisponibles simultanément. Par exemple, votre système dépend-il de la présence d’au moins un nœud actif dans une zone ?

Assurez-vous que les opérations de réparation critiques ne dépendent pas de la disponibilité d’un nœud sain dans le cluster. Par exemple, si tous les nœuds sont défaillants, vous devrez peut-être exécuter une tâche de réparation avec une tolérance spéciale afin de permettre la remise en service d’au moins un nœud.

Kubernetes ne fournit pas de solution complète à ce problème, mais il s’agit d’un point important à prendre en compte.

A suivre

Pour comprendre comment le scheduler place les Pods dans un cluster en respectant les contraintes configurées, consultez la section Planification et éviction.

3.3 - Valider la configuration du nœud

Test de conformité des nœuds

Le test de conformité des nœuds est un framework de test conteneurisé qui fournit une vérification système ainsi qu’un test fonctionnel d’un nœud. Ce test permet de vérifier si le nœud respecte les exigences minimales de Kubernetes ; un nœud qui réussit ce test est considéré comme apte à rejoindre un cluster Kubernetes.

Prérequis du nœud

Pour exécuter le test de conformité des nœuds, un nœud doit satisfaire les mêmes prérequis qu’un nœud Kubernetes standard. Au minimum, le nœud doit disposer des daemons suivants installés :

• Des runtimes de conteneurs compatibles CRI tels que Docker, containerd et CRI-O
• kubelet

Exécution du test de conformité des nœuds

Pour exécuter le test de conformité des nœuds, procédez comme suit :

1. Déterminez la valeur de l’option --kubeconfig du kubelet ; par exemple : --kubeconfig=/var/lib/kubelet/config.yaml.

   Comme le framework de test démarre un plan de contrôle local pour tester le kubelet, utilisez http://localhost:8080 comme URL de l’API server.

   Vous pouvez également utiliser certains autres paramètres en ligne de commande du kubelet :

   • --cloud-provider : si vous utilisez --cloud-provider=gce, vous devez supprimer ce flag pour exécuter le test.

2. Exécutez le test de conformité des nœuds avec la commande suivante :

   # $CONFIG_DIR est le chemin des manifests pods du kubelet.
   # $LOG_DIR est le répertoire de sortie des logs du test.
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     registry.k8s.io/node-test:0.2
   

Exécution du test de conformité des nœuds sur d’autres architectures

Kubernetes fournit également des images Docker de test de conformité des nœuds pour d’autres architectures :

Exécution de tests sélectionnés

Pour exécuter des tests spécifiques, remplacez la variable d’environnement FOCUS par l’expression régulière des tests que vous souhaitez exécuter.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Exécute uniquement le test MirrorPod
  registry.k8s.io/node-test:0.2

Le test de conformité des nœuds est une version conteneurisée des tests e2e des nœuds. Par défaut, il exécute tous les tests de conformité.

En théorie, vous pouvez exécuter n’importe quel test e2e des nœuds si vous configurez correctement le conteneur et montez les volumes requis. Cependant, il est fortement recommandé de n’exécuter que les tests de conformité, car l’exécution de tests non conformes nécessite une configuration beaucoup plus complexe.

Limitations

• Le test laisse certaines images Docker sur le nœud, notamment l’image du test de conformité des nœuds ainsi que les images des conteneurs utilisés dans les tests fonctionnels.
• Le test laisse des conteneurs arrêtés sur le nœud. Ces conteneurs sont créés pendant les tests fonctionnels.

3.4 - Application des standards de sécurité des Pods

Cette page fournit une vue d’ensemble des bonnes pratiques concernant l’application des Pod Security Standards.

Utilisation du contrôleur d’admission Pod Security intégré

Le contrôleur d’admission Pod Security est destiné à remplacer les PodSecurityPolicies, désormais obsolètes.

Configurer tous les namespaces du cluster

Les namespaces qui ne possèdent aucune configuration doivent être considérés comme des failles importantes dans le modèle de sécurité de votre cluster. Nous recommandons de prendre le temps d’analyser les types de charges de travail présents dans chaque namespace, puis, en vous basant sur les Pod Security Standards, de définir un niveau approprié pour chacun d’eux. Les namespaces non étiquetés doivent uniquement indiquer qu’ils n’ont pas encore été évalués.

Dans le cas où toutes les charges de travail de tous les namespaces ont les mêmes exigences de sécurité, nous fournissons un exemple illustrant comment appliquer les labels PodSecurity en masse.

Adopter le principe du moindre privilège

Dans un monde idéal, chaque pod dans chaque namespace respecterait les exigences de la politique restricted. Cependant, cela n’est ni toujours possible ni pratique, car certaines charges de travail nécessitent des privilèges élevés pour des raisons légitimes.

• Les namespaces autorisant des workloads privileged doivent définir et appliquer des contrôles d’accès appropriés.
• Pour les workloads exécutés dans ces namespaces permissifs, il est important de maintenir une documentation sur leurs exigences de sécurité spécifiques. Lorsque cela est possible, il faut envisager de réduire davantage ces exigences.

Adopter une stratégie multi-mode

Les modes audit et warn du contrôleur d’admission Pod Security Standards facilitent la collecte d’informations de sécurité importantes sur vos pods sans interrompre les workloads existants.

Il est recommandé d’activer ces modes pour tous les namespaces, en les configurant au niveau et à la version cibles que vous souhaitez éventuellement enforce. Les avertissements et annotations d’audit générés à cette étape peuvent vous guider vers cet état. Si vous attendez des auteurs de workloads qu’ils adaptent leurs ressources, activez le mode warn. Si vous souhaitez utiliser les logs d’audit pour surveiller ou piloter les changements, activez le mode audit.

Lorsque le mode enforce est défini au niveau souhaité, ces modes restent utiles de plusieurs façons :

• En définissant warn au même niveau que enforce, les clients recevront des avertissements lorsqu’ils tenteront de créer des Pods (ou des ressources contenant des templates de Pods) qui ne respectent pas la validation. Cela les aidera à rendre leurs ressources conformes.
• Dans les namespaces qui verrouillent enforce à une version spécifique (non la dernière), définir audit et warn au même niveau que enforce, mais avec la version latest, permet de détecter les paramètres qui étaient autorisés dans les anciennes versions mais qui ne respectent plus les bonnes pratiques actuelles.

Alternatives tierces

D’autres alternatives pour appliquer des profils de sécurité sont en cours de développement dans l’écosystème Kubernetes :

• Kubewarden
• Kyverno
• OPA Gatekeeper

Le choix entre une solution intégrée (comme le contrôleur d’admission PodSecurity) et un outil tiers dépend entièrement de votre contexte. Lors de l’évaluation d’une solution, la confiance dans votre chaîne d’approvisionnement est essentielle. Au final, utiliser n’importe laquelle de ces approches est toujours préférable à ne rien faire.

3.5 - Certificats PKI et exigences

Kubernetes nécessite des certificats PKI pour l’authentification via TLS. Si vous installez Kubernetes avec kubeadm, les certificats requis par votre cluster sont générés automatiquement. Vous pouvez également générer vos propres certificats — par exemple, pour mieux sécuriser vos clés privées en évitant de les stocker sur le serveur API. Cette page explique les certificats nécessaires à votre cluster.

Utilisation des certificats par votre cluster

Kubernetes utilise la PKI pour les opérations suivantes :

Certificats serveur

• Certificat serveur pour le point de terminaison du serveur API
• Certificat serveur pour le serveur etcd
• Certificats serveur pour chaque kubelet (chaque nœud exécute un kubelet)
• Certificat serveur optionnel pour le front-proxy

Certificats client

• Certificats client pour chaque kubelet, utilisés pour s’authentifier auprès du serveur API en tant que client de l’API Kubernetes
• Certificat client pour chaque serveur API, utilisé pour s’authentifier auprès d’etcd
• Certificat client pour le controller manager afin de communiquer de manière sécurisée avec le serveur API
• Certificat client pour le scheduler afin de communiquer de manière sécurisée avec le serveur API
• Certificats client, un pour chaque nœud, pour que kube-proxy s’authentifie auprès du serveur API
• Certificats client optionnels pour les administrateurs du cluster afin de s’authentifier auprès du serveur API
• Certificat client optionnel pour le front-proxy

Certificats serveur et client du kubelet

Pour établir une connexion sécurisée et s’authentifier auprès du kubelet, le serveur API nécessite une paire certificat/clé client.

Dans ce scénario, deux approches sont possibles :

• Certificats partagés : le kube-apiserver peut utiliser la même paire certificat/clé que celle utilisée pour authentifier ses clients. Cela signifie que les certificats existants, comme apiserver.crt et apiserver.key, peuvent être utilisés pour communiquer avec les serveurs kubelet.

• Certificats distincts : le kube-apiserver peut générer une nouvelle paire certificat/clé client pour s’authentifier auprès des serveurs kubelet. Dans ce cas, un certificat distinct nommé kubelet-client.crt ainsi que sa clé privée kubelet-client.key sont créés.

etcd implémente également le TLS mutuel pour authentifier les clients et les pairs.

Emplacement des certificats

Si vous installez Kubernetes avec kubeadm, la plupart des certificats sont stockés dans /etc/kubernetes/pki. Tous les chemins de cette documentation sont relatifs à ce répertoire, à l’exception des certificats des comptes utilisateurs que kubeadm place dans /etc/kubernetes.

Configuration manuelle des certificats

Si vous ne souhaitez pas que kubeadm génère les certificats requis, vous pouvez les créer en utilisant une seule autorité de certification (CA) racine ou en fournissant tous les certificats. Voir Certificats pour plus de détails. Voir également Gestion des certificats avec kubeadm.

CA racine unique

Vous pouvez créer une CA racine unique, contrôlée par un administrateur. Cette CA peut ensuite créer plusieurs CA intermédiaires.

CA requises :

En plus des autorités de certification mentionnées ci-dessus, il est également nécessaire d'obtenir une paire de clés publique/privée pour la gestion des comptes de service : les fichiers sa.key et sa.pub. L'exemple suivant illustre les fichiers de clé et de certificat de l'autorité de certification présentés dans le tableau précédent :

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

Tous les certificats

Vous pouvez générer tous les certificats vous-même si vous ne souhaitez pas copier les clés privées de la CA.

Certificats requis :

où kind correspond à une ou plusieurs utilisations de la clé x509, également documentées dans le fichier .spec.usages d'une CertificateSigningRequest type :

Chemins des certificats

Les certificats doivent être placés dans un chemin recommandé (comme utilisé par kubeadm). Les chemins doivent être spécifiés à l’aide des arguments indiqués, quel que soit leur emplacement.

Les mêmes considérations s’appliquent à la paire de clés des comptes de service :

L’exemple suivant illustre les chemins des fichiers issus des tableaux précédents que vous devez fournir si vous générez vous-même l’ensemble de vos clés et certificats :

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

Configuration des certificats pour les comptes utilisateurs

Vous devez configurer manuellement les comptes administrateurs et les comptes de service :

1. Pour chaque configuration, générez une paire certificat/clé x509 avec le Common Name (CN) et l’Organization (O) indiqués.

2. Exécutez kubectl comme suit pour chaque configuration :

   KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
   KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
   KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
   KUBECONFIG=<filename> kubectl config use-context default-system
   

   Ces fichiers sont utilisés comme suit :

Les fichiers suivants illustrent les chemins complets des fichiers listés dans le tableau précédent :

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf