Version imprimable multipages. Cliquer ici pour imprimer.

Retour à la version par défaut.

Installer Kubernetes avec des outils de déploiement

Il existe de nombreuses méthodes et outils pour configurer votre propre cluster Kubernetes en production. Par exemple :

  • kubeadm

  • Cluster API : un sous-projet Kubernetes centré sur la fourniture d’API déclaratives et d’outils pour simplifier le provisionnement, les mises à jour et l’exploitation de plusieurs clusters Kubernetes.

  • kops : un outil automatisé de provisionnement de clusters.
    Pour des tutoriels, bonnes pratiques, options de configuration et des informations pour rejoindre la communauté, veuillez consulter le site de kOps pour plus de détails.

  • kubespray : une composition de playbooks Ansible, d’inventaires, d’outils de provisioning et de connaissances métier pour la gestion générique de la configuration de clusters OS/Kubernetes.
    Vous pouvez rejoindre la communauté sur le canal Slack #kubespray.

1 - Déploiement d'un cluster avec kubeadm

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)

ProtocoleDirectionPlage de PortUtilisé pourUtilisé par
TCPEntrant6443*Kubernetes API serverTous
TCPEntrant2379-2380Etcd server client APIkube-apiserver, etcd
TCPEntrant10250Kubelet APILui-même, Control plane
TCPEntrant10251kube-schedulerLui-même
TCPEntrant10252kube-controller-managerLui-même

nœuds workers

ProtocoleDirectionPlage de PortUtilisé pourUtilisé par
TCPEntrant10250Kubelet APILui-même, Control plane
TCPEntrant30000-32767NodePort Services**Eux-mêmes

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

Par défaut, Kubernetes utilise le Container Runtime Interface (CRI) pour s'interfacer avec votre environnement d'exécution de conteneur choisi.

Si vous ne spécifiez pas de runtime, kubeadm essaie automatiquement de détecter un Runtime de conteneur en parcourant une liste de sockets de domaine Unix bien connus. Le tableau suivant répertorie les environnements d'exécution des conteneurs et leurs chemins de socket associés:

Les environnements d'exécution des conteneurs et leurs chemins de socket
RuntimeChemin vers le socket de domaine Unix
Docker/var/run/docker.sock
containerd/run/containerd/containerd.sock
CRI-O/var/run/crio/crio.sock

Si Docker et containerd sont détectés, Docker est prioritaire. C'est nécessaire car Docker 18.09 est livré avec containerd et les deux sont détectables même si vous installez Docker. Si deux autres environnements d'exécution ou plus sont détectés, kubeadm se ferme avec une erreur.

Le kubelet s'intègre à Docker via l'implémentation CRI intégrée de dockershim.

Voir runtimes de conteneur pour plus d'informations.

Par défaut, kubeadm utilise Docker comme environnement d'exécution du conteneur. Le kubelet s'intègre à Docker via l'implémentation CRI intégrée de dockershim.

Voir runtimes de conteneur pour plus d'informations.

Installation de kubeadm, des kubelets et de kubectl

Vous installerez ces paquets sur toutes vos machines:

  • kubeadm: la commande pour initialiser le cluster.

  • la kubelet: le composant qui s'exécute sur toutes les machines de votre cluster et fait des actions comme le démarrage des pods et des conteneurs.

  • kubectl: la ligne de commande utilisée pour parler à votre cluster.

kubeadm n'installera pas ni ne gèrera les kubelet ou kubectl pour vous. Vous devez vous assurer qu'ils correspondent à la version du control plane de Kubernetes que vous souhaitez que kubeadm installe pour vous. Si vous ne le faites pas, vous risquez qu'une erreur de version se produise, qui pourrait conduire à un comportement inattendu. Cependant, une version mineure entre les kubelets et le control plane est pris en charge, mais la version de la kubelet ne doit jamais dépasser la version de l'API server. Par exemple, les kubelets exécutant la version 1.7.0 devraient être entièrement compatibles avec un API server en 1.8.0, mais pas l'inverse.

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

Attention:

Ces instructions excluent tous les packages Kubernetes de toutes les mises à niveau du système d'exploitation. C’est parce que kubeadm et Kubernetes ont besoin d'une attention particulière lors de la mise à niveau.

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

Les instructions suivantes sont pour Kubernetes v1.36.

  1. Mettez à jour l'index de package apt et installez les dépendances suivantes nécessaires au dépôt apt Kubernetes:

    sudo apt-get update
# apt-transport-https n'est plus utile; vous pouvez l'ignorez
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

  2. Téléchargez la clé publique pour les dépôts de paquets Kubernetes. La même clé de signature est utilisée pour tous les dépôts, vous pouvez donc ne pas tenir compte de la version dans l’URL.

    # Si le répertoire `/etc/apt/keyrings` n'existe pas, vous devez le créer avant la curl, avec la commande ci-dessous par exemple.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.36/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

  3. Ajoutez le dépôt apt approprié pour Kubernetes. Veuillez noter que ce dépôt contient uniquement les paquets pour Kubernetes 1.36; pour d'autres versions mineures de Kubernetes, vous devez modifier la version mineure dans l'URL afin qu'elle corresponde à la version souhaitée.

    # Cette commande écrase toute configuration préexistante du fichier `/etc/apt/sources.list.d/kubernetes.list`
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

  4. Mettez à jour l'index de package apt puis installez kubelet, kubeadm et kubectl. Puis verrouillez leurs version:

    sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

  5. (Optionnel) Démarrez le service kubelet avant de démarrer kubeadm:

    sudo systemctl enable --now kubelet

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

Note:

  • Mettre SELinux en mode permissif en lançant setenforce 0 et sed ... le désactive efficacement. C'est nécessaire pour permettre aux conteneurs d'accéder au système de fichiers hôte, qui est nécessaire par exemple pour les réseaux de pod. Vous devez le faire jusqu'à ce que le support de SELinux soit amélioré dans Kubelet.

  • Vous pouvez laisser SELinux activé si vous savez comment le configurer, mais il peut nécessiter des paramètres qui ne sont pas pris en charge par kubeadm.

Installez les plugins CNI (requis pour la plupart des réseaux de pods) :

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

Définissez le répertoire pour télécharger les fichiers de commande

Note:

La variable DOWNLOAD_DIR doit être définie sur un répertoire accessible en écriture. Si vous exécutez Flatcar Container Linux, définissez DOWNLOAD_DIR=/opt/bin
DOWNLOAD_DIR=/usr/local/bin
sudo mkdir -p $DOWNLOAD_DIR

Installez crictl (requis pour Kubeadm / Kubelet Container Runtime Interface (CRI))

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

Installez kubeadm, kubelet, kubectl et ajoutez un service systemd kubelet:

RELEASE_VERSION="v0.6.0"

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

Activez et démarrez kubelet :

sudo systemctl enable --now kubelet

Note:

La distribution Linux Flatcar Container monte le répertoire /usr comme un système de fichiers en lecture seule. Avant de démarrer votre cluster, vous devez effectuer des étapes supplémentaires pour configurer un répertoire accessible en écriture. Consultez le Guide de dépannage de Kubeadm pour savoir comment configurer un répertoire accessible en écriture.

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.

Note:

Depuis que le paramètre --cgroup-driver est obsolète par kubelet, si vous l'avez dans/var/lib/kubelet/kubeadm-flags.env ou /etc/default/kubelet(/etc/sysconfig/kubelet pour les RPM), veuillez le supprimer et utiliser à la place KubeletConfiguration (stocké dans/var/lib/kubelet/config.yaml par défaut).

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

1.2 - Dépannage de 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:

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

Impossible de joindre un nœud v1.18 à un cluster v1.17 en raison d’un RBAC manquant

Dans la version v1.18, kubeadm a ajouté une protection empêchant l’ajout d’un nœud au cluster si un nœud portant le même nom existe déjà. Cela a nécessité l’ajout de règles RBAC permettant à l’utilisateur bootstrap-token de faire une requête GET sur un objet Node.

Cependant, cela provoque un problème : une commande kubeadm join depuis la version v1.18 ne peut pas rejoindre un cluster créé avec kubeadm v1.17.

Pour contourner ce problème, vous avez deux options :

Exécutez kubeadm init phase bootstrap-token sur un nœud du plan de contrôle avec kubeadm v1.18. Notez que cela active également les autres permissions liées au bootstrap-token.

ou

Appliquez manuellement le contrôle d'accès basé sur les rôles (RBAC) suivant à l'aide de la commande kubectl apply -f ... :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubeadm:get-nodes
rules:
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubeadm:get-nodes
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubeadm:get-nodes
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:bootstrappers:kubeadm:default-node-token

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 courants sont :

  • des problèmes de connexion réseau. Vérifiez que votre machine dispose d’une connectivité réseau complète avant de continuer.
  • le pilote cgroup du runtime de conteneur est différent de celui du kubelet. Pour comprendre comment le configurer correctement, consultez Configurer un pilote cgroup.
  • les conteneurs du plan de contrôle sont en boucle de redémarrage (crashloop) ou bloqués. Vous pouvez le vérifier en exécutant docker ps et en inspectant chaque conteneur avec docker logs. Pour d’autres runtimes de conteneurs, voir Déboguer les nœuds Kubernetes avec crictl.

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

Cela peut se produire si le runtime de conteneurs s’arrête et ne supprime aucun conteneur géré 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 runtime de conteneurs, puis à relancer kubeadm reset. Vous pouvez également utiliser crictl pour déboguer l’état du runtime de conteneurs. Voir Déboguer les nœuds Kubernetes avec crictl.

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.

coredns est bloqué à l’état Pending

Ceci est prévu et fait partie du design. kubeadm est indépendant du fournisseur de réseau, ainsi l'administrateur devrait installer la solution réseau pod de son 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 l’add-on réseau pour savoir si ces fonctionnalités sont prises en charge.

Les fournisseurs de CNI Calico, Canal, et Flannel sont validés pour supporter HostPort.

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

Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, vous devrez peut-être utiliser la fonction NodePort des 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 mode hairpin, 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 --decode permet de décoder le certificat et la commande openssl x509 -text -noout permet d'afficher les informations du certificat.

  • Désactivez la variable d’environnement KUBECONFIG en utilisant :

    unset KUBECONFIG

    Ou définissez-la vers l’emplacement par défaut de KUBECONFIG :

    export KUBECONFIG=/etc/kubernetes/admin.conf

  • Une autre solution consiste à écraser le kubeconfig existant pour l'utilisateur " admin ":

    mv $HOME/.kube $HOME/.kube.bak
mkdir $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Échec de la rotation du certificat client kubelet

Par défaut, kubeadm configure le kubelet avec une rotation automatique des certificats clients en utilisant le lien symbolique /var/lib/kubelet/pki/kubelet-client-current.pem défini dans /etc/kubernetes/kubelet.conf.

Si ce processus de rotation échoue, vous pouvez voir des erreurs telles que x509: certificate has expired or is not yet valid dans les logs du kube-apiserver. Pour corriger ce problème, vous devez suivre les étapes suivantes :

  1. Sauvegardez puis supprimez /etc/kubernetes/kubelet.conf et /var/lib/kubelet/pki/kubelet-client* sur le nœud concerné.
  2. Depuis un nœud du plan de contrôle fonctionnel du cluster qui possède /etc/kubernetes/pki/ca.key, exécutez : kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf. $NODE doit être défini comme le nom du nœud défaillant existant dans le cluster. Modifiez ensuite manuellement le fichier kubelet.conf généré afin d’ajuster le nom du cluster et le point de terminaison du serveur, ou passez l’option kubeconfig user --config (voir Générer des fichiers kubeconfig pour des utilisateurs supplémentaires).

Si votre cluster ne dispose pas de ca.key, vous devez signer les certificats intégrés dans kubelet.conf de manière externe.

  1. Copiez ce fichier kubelet.conf généré vers /etc/kubernetes/kubelet.conf sur le nœud défaillant.

  2. Redémarrez le kubelet (systemctl restart kubelet) sur le nœud défaillant et attendez que /var/lib/kubelet/pki/kubelet-client-current.pem soit recréé.

  3. Modifiez manuellement kubelet.conf pour pointer vers les certificats client kubelet renouvelés, en remplaçant client-certificate-data et client-key-data par :

    client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

  4. Redémarrez le kubelet.

  5. Assurez-vous que le nœud passe à l’état Ready.

Interface réseau (NIC) par défaut lors de l’utilisation de flannel comme réseau de pods 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 réseau 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 utilisée pour le trafic externe via NAT.

  Cela peut entraîner des problèmes avec Flannel, qui utilise par défaut la première interface sur un hôte. Cela conduit tous les hôtes à penser 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 NodeRegistrationOptions structure peut être utilisée pour cela.

    Puis redémarrer 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:

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.

Attention:

Désactiver SELinux ou paramètrer allowPrivilegeEscalation sur true peut compromettre la sécurité de votre cluster.

Les pods etcd redémarrent continuellement

Si vous rencontrez l'erreur suivante:

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

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

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

  • 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

Impossible de passer une liste de valeurs séparées par des virgules dans l’argument --component-extra-args

Les options de kubeadm init telles que --component-extra-args permettent de passer des arguments personnalisés à un composant du plan de contrôle, comme le kube-apiserver. Cependant, ce mécanisme est limité en raison du type utilisé pour l’analyse des valeurs (mapStringString).

Si vous essayez de passer un argument acceptant plusieurs valeurs séparées par des virgules, comme :

--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"

cela échouera avec l’erreur :

flag: malformed pair, expect string=string

Cela se produit car la liste d’arguments pour --apiserver-extra-args attend des paires clé=valeur, et dans ce cas NamespaceExists est interprété comme une clé sans valeur.

Vous pouvez également essayer de séparer les paires clé=valeur comme ceci :

--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"

mais cela aura pour effet que la clé enable-admission-plugins ne conservera que la valeur NamespaceExists.

Une solution de contournement connue consiste à utiliser le fichier de configuration kubeadm.

kube-proxy programmé avant l’initialisation du nœud par le cloud-controller-manager

Dans les scénarios avec fournisseur cloud, kube-proxy peut être programmé sur de nouveaux nœuds worker avant que le cloud-controller-manager n’ait initialisé les adresses du nœud. Cela empêche kube-proxy de récupérer correctement l’adresse IP du nœud et entraîne des effets secondaires sur la gestion du load balancing par le proxy.

L’erreur suivante peut apparaître dans les Pods kube-proxy :

server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP

Une solution connue consiste à patcher le DaemonSet kube-proxy afin de permettre sa planification sur les nœuds du plan de contrôle, indépendamment de leurs conditions, tout en l’empêchant de s’exécuter sur les autres nœuds jusqu’à ce que leurs conditions de protection initiales disparaissent :

kubectl -n kube-system patch ds kube-proxy -p='{
  "spec": {
    "template": {
      "spec": {
        "tolerations": [
          {
            "key": "CriticalAddonsOnly",
            "operator": "Exists"
          },
          {
            "effect": "NoSchedule",
            "key": "node-role.kubernetes.io/control-plane"
          }
        ]
      }
    }
  }
}'

Le ticket de suivi de ce problème se trouve ici.

/usr monté en lecture seule sur les nœuds

Sur des distributions Linux comme Fedora CoreOS ou Flatcar Container Linux, le répertoire /usr est monté en système de fichiers en lecture seule. Pour le support des flex-volumes, les composants Kubernetes comme le kubelet et le kube-controller-manager utilisent par défaut le chemin /usr/libexec/kubernetes/kubelet-plugins/volume/exec/, mais le répertoire des flex-volumes doit être accessible en écriture pour que la fonctionnalité fonctionne.

Note:

FlexVolume est déprécié depuis la version Kubernetes v1.23.

Pour contourner ce problème, vous pouvez configurer le répertoire flex-volume via le fichier de configuration kubeadm :

configuration file.

Sur le nœud du plan de contrôle principal (créé avec kubeadm init), passez le fichier suivant avec --config :

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
  extraArgs:
  - name: "flex-volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

Sur les nœuds qui rejoignent le cluster :

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
nodeRegistration:
  kubeletExtraArgs:
  - name: "volume-plugin-dir"
    value: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"

Sinon, vous pouvez modifier /etc/fstab pour rendre le montage /usr accessible en écriture, mais veuillez noter que cela modifie un principe de conception de la distribution Linux.

kubeadm upgrade plan affiche l’erreur context deadline exceeded

Ce message d’erreur apparaît lors de la mise à niveau d’un cluster Kubernetes avec kubeadm dans le cas où un etcd externe est utilisé. Ce n’est pas un bug critique et cela se produit parce que les anciennes versions de kubeadm effectuent une vérification de version sur le cluster etcd externe. Vous pouvez continuer avec kubeadm upgrade apply ....

Ce problème est corrigé à partir de la version 1.19.

kubeadm reset démonte /var/lib/kubelet

Si /var/lib/kubelet est monté, l’exécution de kubeadm reset le démontera effectivement.

Pour contourner ce problème, remontez le répertoire /var/lib/kubelet après avoir exécuté kubeadm reset.

Il s’agit d’une régression introduite dans kubeadm 1.15. Le problème est corrigé en version 1.20.

Impossible d’utiliser metrics-server de manière sécurisée dans un cluster kubeadm

Dans un cluster kubeadm, le metrics-server peut être utilisé de manière non sécurisée en passant l’option --kubelet-insecure-tls. Cela n’est pas recommandé pour les clusters de production.

Si vous souhaitez utiliser TLS entre metrics-server et le kubelet, un problème se pose, car kubeadm déploie un certificat auto-signé pour le kubelet. Cela peut provoquer les erreurs suivantes du côté de metrics-server :

x509: certificate signed by unknown authority
x509: certificate is valid for IP-foo not IP-bar

Voir Activer les certificats de service kubelet signés pour comprendre comment configurer les kubelets dans un cluster kubeadm afin d’obtenir des certificats de service correctement signés.

Voir également Comment exécuter metrics-server de manière sécurisée.

Échec de la mise à niveau dû à un hash etcd qui ne change pas

Applicable uniquement lors de la mise à niveau d’un nœud du plan de contrôle avec un binaire kubeadm v1.28.3 ou ultérieur, lorsque le nœud est actuellement géré par kubeadm en version v1.28.0, v1.28.1 ou v1.28.2.

Voici le message d’erreur que vous pouvez rencontrer :

[upgrade/etcd] Failed to upgrade etcd: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
[upgrade/etcd] Waiting for previous etcd to become available
I0907 10:10:09.109104    3704 etcd.go:588] [etcd] attempting to see if all cluster endpoints ([https://172.17.0.6:2379/ https://172.17.0.4:2379/ https://172.17.0.3:2379/]) are available 1/10
[upgrade/etcd] Etcd was rolled back and is now available
static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.rollbackOldManifests
	cmd/kubeadm/app/phases/upgrade/staticpods.go:525
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.upgradeComponent
	cmd/kubeadm/app/phases/upgrade/staticpods.go:254
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.performEtcdStaticPodUpgrade
	cmd/kubeadm/app/phases/upgrade/staticpods.go:338
...

La raison de cet échec est que les versions concernées génèrent un fichier de manifeste etcd avec des valeurs par défaut non souhaitées dans le PodSpec. Cela entraîne une différence lors de la comparaison du manifeste, et kubeadm s’attend alors à un changement du hash du Pod, mais le kubelet ne met jamais ce hash à jour.

Il existe deux façons de contourner ce problème si vous le rencontrez dans votre cluster :

  • La mise à niveau d’etcd peut être ignorée entre les versions affectées et v1.28.3 (ou ultérieure) en utilisant :

    kubeadm upgrade {apply|node} [version] --etcd-upgrade=false

Cette méthode n’est pas recommandée dans le cas où une nouvelle version d’etcd aurait été introduite par une version corrective ultérieure de v1.28.

  • Avant la mise à niveau, corrigez le manifeste du pod statique etcd afin de supprimer les attributs par défaut problématiques :
  diff --git a/etc/kubernetes/manifests/etcd_defaults.yaml b/etc/kubernetes/manifests/etcd_origin.yaml
  index d807ccbe0aa..46b35f00e15 100644
  --- a/etc/kubernetes/manifests/etcd_defaults.yaml
  +++ b/etc/kubernetes/manifests/etcd_origin.yaml
  @@ -43,7 +43,6 @@ spec:
          scheme: HTTP
        initialDelaySeconds: 10
        periodSeconds: 10
  -      successThreshold: 1
        timeoutSeconds: 15
      name: etcd
      resources:
  @@ -59,26 +58,18 @@ spec:
          scheme: HTTP
        initialDelaySeconds: 10
        periodSeconds: 10
  -      successThreshold: 1
        timeoutSeconds: 15
  -    terminationMessagePath: /dev/termination-log
  -    terminationMessagePolicy: File
      volumeMounts:
      - mountPath: /var/lib/etcd
        name: etcd-data
      - mountPath: /etc/kubernetes/pki/etcd
        name: etcd-certs
  -  dnsPolicy: ClusterFirst
  -  enableServiceLinks: true
    hostNetwork: true
    priority: 2000001000
    priorityClassName: system-node-critical
  -  restartPolicy: Always
  -  schedulerName: default-scheduler
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  -  terminationGracePeriodSeconds: 30
    volumes:
    - hostPath:
        path: /etc/kubernetes/pki/etcd

Vous trouverez plus d’informations dans le ticket de suivi de ce bug.

1.3 - Création d’un cluster avec kubeadm

Avec kubeadm, vous pouvez créer un cluster Kubernetes minimal viable conforme aux bonnes pratiques. En fait, vous pouvez utiliser kubeadm pour configurer un cluster qui réussit les Kubernetes Conformance tests. kubeadm prend également en charge d’autres fonctions du cycle de vie du cluster, telles que les jetons d’amorçage (bootstrap tokens) et les mises à niveau de cluster.

L’outil kubeadm est adapté si vous avez besoin de :

  • Une manière simple de tester Kubernetes, éventuellement pour la première fois.
  • Un moyen pour les utilisateurs existants d’automatiser la création d’un cluster et de tester leurs applications.
  • Un composant de base dans d’autres outils d’écosystème et/ou installateurs ayant un périmètre plus large.

Vous pouvez installer et utiliser kubeadm sur différentes machines : votre ordinateur portable, un ensemble de serveurs cloud, un Raspberry Pi, etc. Que vous déployiez dans le cloud ou sur site, vous pouvez intégrer kubeadm dans des systèmes de provisionnement tels qu’Ansible ou Terraform.

Pré-requis

Pour suivre ce guide, vous avez besoin de :

  • Une ou plusieurs machines exécutant un système Linux compatible deb/rpm ; par exemple : Ubuntu ou CentOS.
  • 2 Gio ou plus de RAM par machine — moins laisserait peu de place pour vos applications.
  • Au moins 2 CPU sur la machine utilisée comme nœud de plan de contrôle.
  • Une connectivité réseau complète entre toutes les machines du cluster. Vous pouvez utiliser un réseau public ou privé.

Vous devez également utiliser une version de kubeadm capable de déployer la version de Kubernetes que vous souhaitez utiliser dans votre nouveau cluster.

La politique de support des versions et du décalage de versions de Kubernetes s’applique à kubeadm ainsi qu’à Kubernetes dans son ensemble. Consultez cette politique pour connaître les versions de Kubernetes et de kubeadm prises en charge. Cette page est écrite pour Kubernetes v1.36.

L’état global des fonctionnalités de kubeadm est en disponibilité générale (GA). Certaines sous-fonctionnalités sont encore en cours de développement. L’implémentation de la création de cluster peut légèrement évoluer au fil du temps, mais l’approche globale reste stable.

Note:

Toutes les commandes sous kubeadm alpha sont, par définition, prises en charge au niveau alpha.

Objectifs

  • Installer un cluster Kubernetes avec un seul nœud de plan de contrôle
  • Installer un réseau de Pods sur le cluster afin que vos Pods puissent communiquer entre eux

Instructions

Préparation des hôtes

Installation des composants

Installez un runtime de conteneur et kubeadm sur tous les hôtes. Pour les instructions détaillées et autres prérequis, voir Installer kubeadm.

Note:

Si vous avez déjà installé kubeadm, consultez les deux premières étapes du document Mise à niveau des nœuds Linux pour savoir comment mettre kubeadm à jour.

Lors d’une mise à niveau, le kubelet redémarre toutes les quelques secondes en attendant dans une boucle de crash que kubeadm lui indique quoi faire. Ce comportement est attendu et normal. Après l’initialisation du plan de contrôle, le kubelet fonctionne normalement.

Configuration réseau

Comme les autres composants Kubernetes, kubeadm essaie de trouver une adresse IP utilisable sur les interfaces réseau associées à une passerelle par défaut sur l’hôte. Cette adresse IP est ensuite utilisée pour l’annonce et/ou l’écoute effectuée par un composant.

Pour trouver cette adresse sur un hôte Linux, vous pouvez utiliser :

ip route show # Rechercher une ligne commençant par "default via"

Note:

Si deux passerelles par défaut ou plus sont présentes sur l’hôte, un composant Kubernetes essaiera d’utiliser la première qu’il rencontre ayant une adresse IP unicast globale adaptée. Lors de ce choix, l’ordre exact des passerelles peut varier selon les systèmes d’exploitation et les versions du noyau.

Les composants Kubernetes n’acceptent pas la sélection d’une interface réseau personnalisée comme option. Par conséquent, une adresse IP personnalisée doit être passée en argument à toutes les instances de composants nécessitant une telle configuration.

Note:

Si l’hôte ne possède pas de passerelle par défaut et qu’aucune adresse IP personnalisée n’est fournie à un composant Kubernetes, celui-ci peut se terminer avec une erreur.

Pour configurer l’adresse d’annonce de l’API server sur les nœuds de plan de contrôle créés avec init et join, le flag --apiserver-advertise-address peut être utilisé. Idéalement, cette option peut être définie dans l’API kubeadm via InitConfiguration.localAPIEndpoint et JoinConfiguration.controlPlane.localAPIEndpoint.

Pour les kubelets sur tous les nœuds, l’option --node-ip peut être passée dans .nodeRegistration.kubeletExtraArgs dans un fichier de configuration kubeadm (InitConfiguration ou JoinConfiguration).

Pour le support dual-stack, voir : Support dual-stack avec kubeadm.

Les adresses IP assignées aux composants du plan de contrôle font partie des champs SAN (subject alternative name) des certificats X.509. Modifier ces adresses IP nécessiterait de signer de nouveaux certificats et de redémarrer les composants concernés afin que les changements soient pris en compte. Voir Régénération manuelle des certificats pour plus de détails.

Attention:

Le projet Kubernetes déconseille cette approche (configurer toutes les instances de composants avec des adresses IP personnalisées). Les mainteneurs recommandent plutôt de configurer le réseau de l’hôte afin que la passerelle par défaut soit celle détectée automatiquement et utilisée par Kubernetes. Sur les nœuds Linux, vous pouvez utiliser des commandes comme ip route pour configurer le réseau ; votre système d’exploitation peut également fournir des outils de gestion réseau plus avancés. Si la passerelle par défaut de votre nœud est une adresse IP publique, vous devez configurer un filtrage de paquets ou d’autres mesures de sécurité pour protéger les nœuds et le cluster.

Préparation des images de conteneurs requises

Cette étape est optionnelle et ne s’applique que si vous souhaitez que kubeadm init et kubeadm join ne téléchargent pas les images de conteneurs par défaut hébergées sur registry.k8s.io.

Kubeadm fournit des commandes permettant de pré-télécharger les images nécessaires lors de la création d’un cluster sans connexion Internet sur les nœuds. Voir Exécuter kubeadm sans connexion Internet pour plus de détails.

Kubeadm permet également d’utiliser un registre d’images personnalisé pour les images requises. Voir Utilisation d’images personnalisées pour plus de détails.

Initialisation du nœud de plan de contrôle

Le nœud de plan de contrôle est la machine où s’exécutent les composants du plan de contrôle, notamment etcd (la base de données du cluster) et le serveur API, avec lequel l’outil en ligne de commande kubectl communique.

  1. (Recommandé) Si vous prévoyez de faire évoluer ce cluster kubeadm à nœud unique vers une haute disponibilité, vous devez spécifier --control-plane-endpoint pour définir un endpoint partagé pour tous les nœuds de plan de contrôle. Cet endpoint peut être un nom DNS ou une adresse IP d’un load balancer.

  2. Choisissez un add-on de réseau de Pods et vérifiez s’il nécessite des arguments supplémentaires à passer à kubeadm init. Selon le fournisseur tiers choisi, vous devrez peut-être définir --pod-network-cidr avec une valeur spécifique. Voir Installation d’un add-on réseau de Pods.

  3. (Optionnel) kubeadm tente de détecter le runtime de conteneur via une liste de points de terminaison connus. Pour utiliser un runtime différent ou s’il y en a plusieurs installés sur le nœud provisionné, spécifiez l’argument --cri-socket à kubeadm. Voir Installation d’un runtime.

Pour initialiser le nœud de plan de contrôle, exécutez :

kubeadm init <args>

Considérations sur apiserver-advertise-address et ControlPlaneEndpoint

Alors que --apiserver-advertise-address peut être utilisé pour définir l’adresse annoncée par le serveur API de ce nœud de plan de contrôle spécifique, --control-plane-endpoint peut être utilisé pour définir un endpoint partagé pour tous les nœuds du plan de contrôle.

--control-plane-endpoint accepte à la fois des adresses IP et des noms DNS pouvant être résolus en adresses IP. Veuillez contacter votre administrateur réseau pour évaluer les solutions possibles concernant ce type de résolution.

Voici un exemple de correspondance :

192.168.0.102 cluster-endpoint

Dans cet exemple, 192.168.0.102 est l’adresse IP de ce nœud et cluster-endpoint est un nom DNS personnalisé qui pointe vers cette adresse IP. Cela vous permet de passer --control-plane-endpoint=cluster-endpoint à kubeadm init et d’utiliser le même nom DNS pour kubeadm join. Plus tard, vous pouvez modifier cluster-endpoint pour qu’il pointe vers l’adresse de votre load balancer dans un scénario de haute disponibilité.

Transformer un cluster à un seul plan de contrôle créé sans --control-plane-endpoint en un cluster hautement disponible n’est pas pris en charge par kubeadm.

Plus d’informations

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

Pour configurer kubeadm init avec un fichier de configuration, voir Utiliser kubeadm init avec un fichier de configuration.

Pour personnaliser les composants du plan de contrôle, y compris l’ajout optionnel d’IPv6 pour les probes de liveness des composants du plan de contrôle et du serveur etcd, fournissez des arguments supplémentaires à chaque composant comme décrit dans arguments personnalisés.

Pour reconfigurer un cluster déjà créé, voir Reconfiguration d’un cluster kubeadm.

Pour relancer kubeadm init, vous devez d’abord supprimer le cluster.

Si vous ajoutez un nœud d’une architecture différente à votre cluster, assurez-vous que vos DaemonSets déployés prennent en charge les images de conteneurs pour cette 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 affichent des avertissements et arrêtent l’exécution en cas d’erreur. Ensuite, kubeadm init télécharge et installe les composants du plan de contrôle du cluster. Cela peut prendre plusieurs minutes. Une fois terminé, vous devriez voir :

Your Kubernetes control-plane 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:
  /docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Pour que kubectl fonctionne avec un utilisateur non root, exécutez les commandes suivantes, qui font également partie de la sortie de 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

Sinon, si vous êtes l'utilisateur root, vous pouvez exécuter :

export KUBECONFIG=/etc/kubernetes/admin.conf

Attention:

Le fichier kubeconfig admin.conf généré par kubeadm init contient un certificat avec Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin. Le groupe kubeadm:cluster-admins est lié au ClusterRole intégré cluster-admin. Ne partagez pas le fichier admin.conf avec qui que ce soit.

kubeadm init génère également un fichier kubeconfig super-admin.conf qui contient un certificat avec Subject: O = system:masters, CN = kubernetes-super-admin. system:masters est un groupe super-utilisateur de type “break-glass” qui contourne la couche d’autorisation (par exemple RBAC). Ne partagez pas le fichier super-admin.conf. Il est recommandé de le déplacer vers un emplacement sécurisé.

Voir Générer des fichiers kubeconfig pour des utilisateurs supplémentaires pour savoir comment utiliser kubeadm kubeconfig user afin de générer des kubeconfig pour des utilisateurs additionnels.

Conservez une copie de la commande kubeadm join affichée par kubeadm init. Vous en aurez besoin pour ajouter des nœuds à votre cluster.

Le token est utilisé pour l’authentification mutuelle entre le nœud du plan de contrôle et les nœuds rejoignant le cluster. Le token inclus ici est secret. Conservez-le en lieu sûr, car toute personne disposant de ce token peut ajouter des nœuds authentifiés à votre cluster. Ces tokens 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 de Pods

Avertissement:

Cette section contient des informations importantes sur la configuration réseau et l’ordre de déploiement. Lisez attentivement ces recommandations avant de continuer.

Vous devez déployer un add-on réseau de Pods basé sur Container Network Interface (CNI) afin que vos Pods puissent communiquer entre eux. Le DNS du cluster (CoreDNS) ne démarrera pas tant qu’un réseau n’est pas installé.

  • Assurez-vous que votre réseau de Pods ne chevauche aucun réseau hôte : des problèmes peuvent survenir en cas de chevauchement. (Si vous détectez une collision entre le CIDR réseau de votre plugin et un réseau hôte, choisissez un autre bloc CIDR et utilisez-le avec --pod-network-cidr lors de kubeadm init, ainsi que dans la configuration YAML du plugin réseau.)

  • Par défaut, kubeadm configure votre cluster pour utiliser et appliquer RBAC (contrôle d’accès basé sur les rôles). Assurez-vous que votre plugin réseau de Pods supporte RBAC, ainsi que tous les manifestes utilisés pour le déployer.

  • Si vous souhaitez utiliser IPv6 (réseau dual-stack ou IPv6 uniquement), assurez-vous que votre plugin réseau de Pods le supporte. Le support IPv6 a été ajouté à CNI en v0.6.0.

Note:

Kubeadm doit rester agnostique vis-à-vis de CNI et la validation des fournisseurs CNI est hors du périmètre des tests e2e actuels. Si vous rencontrez un problème lié à un plugin CNI, veuillez ouvrir un ticket dans son tracker respectif plutôt que dans les trackers kubeadm ou Kubernetes.

Plusieurs projets externes fournissent des réseaux de Pods Kubernetes via CNI, certains prenant également en charge les politiques réseau.

Voir la liste des add-ons qui implémentent le modèle réseau Kubernetes.

Veuillez consulter la page Installation des add-ons pour une liste non exhaustive des plugins réseau supportés par Kubernetes.

Vous pouvez installer un add-on réseau de Pods avec la commande suivante sur le nœud du plan de contrôle ou sur un nœud disposant des identifiants kubeconfig :

kubectl apply -f <add-on.yaml>

Note:

Seuls quelques plugins CNI prennent en charge Windows. Plus de détails et des instructions de configuration sont disponibles dans Ajout de nœuds workers Windows.

Vous ne pouvez installer qu’un seul réseau de Pods par cluster.

Une fois un réseau de Pods installé, vous pouvez vérifier qu’il fonctionne en contrôlant que le Pod CoreDNS est à l’état Running dans la sortie de kubectl get pods --all-namespaces. Une fois le Pod CoreDNS en cours d’exécution, vous pouvez continuer en ajoutant vos nœuds au cluster.

Si votre réseau ne fonctionne pas ou si CoreDNS n’est pas à l’état Running, consultez le guide de dépannage pour kubeadm.

Labels des nœuds gérés

Par défaut, kubeadm active le contrôleur d’admission NodeRestriction qui limite les labels pouvant être appliqués automatiquement par les kubelets lors de l’enregistrement d’un nœud. La documentation du contrôleur d’admission décrit les labels autorisés avec l’option kubelet --node-labels.

Le label node-role.kubernetes.io/control-plane fait partie des labels restreints et kubeadm l’applique manuellement à l’aide d’un client privilégié après la création d’un nœud. Pour faire cela manuellement, vous pouvez utiliser kubectl label et vous assurer d’utiliser un kubeconfig privilégié tel que celui géré par kubeadm : /etc/kubernetes/admin.conf.

Isolation du nœud de plan de contrôle

Par défaut, votre cluster ne planifie pas de Pods sur les nœuds du plan de contrôle pour des raisons de sécurité. Si vous souhaitez autoriser l’exécution de Pods sur les nœuds du plan de contrôle, par exemple pour un cluster Kubernetes sur une seule machine, exécutez :

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Le résultat ressemblera à ceci :

node "test-01" untainted
...

Cela supprimera le taint node-role.kubernetes.io/control-plane:NoSchedule sur tous les nœuds qui le possèdent, y compris les nœuds du plan de contrôle, ce qui permettra ensuite au planificateur (scheduler) de planifier des Pods sur tous les nœuds.

De plus, vous pouvez exécuter la commande suivante pour supprimer le label node.kubernetes.io/exclude-from-external-load-balancers du nœud du plan de contrôle, ce qui l’exclut de la liste des serveurs backend :

kubectl label nodes --all node.kubernetes.io/exclude-from-external-load-balancers-

Ajout de nœuds de plan de contrôle supplémentaires

Voir Créer des clusters hautement disponibles avec kubeadm pour les étapes permettant de créer un cluster kubeadm hautement disponible en ajoutant plusieurs nœuds de plan de contrôle.

Ajout de nœuds workers

Les nœuds workers sont ceux où s’exécutent vos workloads.

Les pages suivantes expliquent comment ajouter des nœuds workers Linux et Windows au cluster en utilisant la commande kubeadm join :

(Optionnel) Contrôler votre cluster depuis des machines autres que le nœud de plan de contrôle

Afin d’utiliser kubectl depuis une autre machine (par exemple un ordinateur portable) pour communiquer avec votre cluster, vous devez copier le fichier kubeconfig administrateur depuis votre nœud de plan de contrôle vers votre poste de travail comme ceci :

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

Note:

L’exemple ci-dessus suppose que l’accès SSH est activé pour l’utilisateur root. Si ce n’est pas le cas, vous pouvez copier le fichier admin.conf pour qu’il soit accessible par un autre utilisateur, puis utiliser scp avec cet autre utilisateur.

Le fichier admin.conf donne à l’utilisateur des privilèges superutilisateur sur le cluster. Ce fichier doit être utilisé avec précaution. Pour les utilisateurs normaux, il est recommandé de générer des identifiants uniques auxquels vous accordez des permissions spécifiques. Vous pouvez le faire avec la commande kubeadm kubeconfig user --client-name <CN>. Cette commande affiche un fichier KubeConfig sur la sortie standard (STDOUT) que vous devez enregistrer dans un fichier et distribuer à l’utilisateur. Ensuite, accordez les privilèges avec kubectl create (cluster)rolebinding.

(Optionnel) Proxy du serveur API vers localhost

Si vous souhaitez vous connecter au serveur API depuis l’extérieur du cluster, vous pouvez utiliser kubectl proxy :

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

Vous pouvez désormais accéder au serveur API localement à l’adresse http://localhost:8001/api/v1

Nettoyage

Si vous avez utilisé des serveurs jetables pour votre cluster de test, vous pouvez simplement les éteindre sans effectuer de nettoyage supplémentaire. Vous pouvez utiliser kubectl config delete-cluster pour supprimer vos références locales au cluster.

Cependant, si vous souhaitez désactiver votre cluster de manière plus propre, vous devez d’abord drainer le nœud et vous assurer que le nœud est vide, puis désconfigurer le nœud.

Supprimer le nœud

En vous connectant au nœud du plan de contrôle avec les identifiants appropriés, exécutez :

kubectl drain <node name> --delete-emptydir-data --force --ignore-daemonsets

Avant de supprimer le nœud, réinitialisez l'état installé par kubeadm :

kubeadm reset

La procédure de réinitialisation ne supprime ni ne réinitialise les règles iptables ni les tables IPVS. Pour réinitialiser iptables, vous devez le faire manuellement.

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

Pour réinitialiser les tables IPVS, vous devez exécuter la commande suivante :

ipvsadm -C

Supprimez maintenant le nœud :

kubectl delete node <node name>

Si vous souhaitez recommencer, exécutez kubeadm init ou kubeadm join avec les arguments appropriés.

Nettoyage du plan de contrôle

Vous pouvez utiliser kubeadm reset sur l’hôte du plan de contrôle pour effectuer un nettoyage au mieux des efforts.

Voir la documentation de référence kubeadm reset pour plus d’informations sur cette sous-commande et ses options.

Politique de décalage de versions

Bien que kubeadm autorise un décalage de versions avec certains composants qu’il gère, il est recommandé de faire correspondre la version de kubeadm avec celles des composants du plan de contrôle, de kube-proxy et du kubelet.

Décalage de kubeadm par rapport à la version de Kubernetes

kubeadm peut être utilisé avec des composants Kubernetes ayant la même version que kubeadm ou une version plus ancienne. La version de Kubernetes peut être spécifiée à kubeadm via le flag --kubernetes-version de kubeadm init ou via le champ ClusterConfiguration.kubernetesVersion lorsque vous utilisez --config.

Cette option contrôle les versions de kube-apiserver, kube-controller-manager, kube-scheduler et kube-proxy.

Exemple :

  • kubeadm est en version 1.36
  • kubernetesVersion doit être en 1.36 ou 1.35

Décalage de kubeadm par rapport au kubelet

De manière similaire à la version de Kubernetes, kubeadm peut être utilisé avec une version de kubelet identique ou jusqu’à trois versions mineures plus anciennes.

Exemple :

  • kubeadm est en version 1.36
  • le kubelet sur l’hôte doit être en 1.36, 1.35, 1.34 ou 1.33

Décalage de kubeadm par rapport à kubeadm

Il existe certaines limitations sur la manière dont les commandes kubeadm peuvent opérer sur des nœuds existants ou des clusters entièrement gérés par kubeadm.

Si de nouveaux nœuds rejoignent le cluster, le binaire kubeadm utilisé pour kubeadm join doit correspondre à la dernière version de kubeadm utilisée pour créer le cluster avec kubeadm init ou pour mettre à jour ce même nœud avec kubeadm upgrade. Des règles similaires s’appliquent aux autres commandes kubeadm, à l’exception de kubeadm upgrade.

Exemple pour kubeadm join :

  • kubeadm en version 1.36 a été utilisé pour créer un cluster avec kubeadm init
  • Les nœuds rejoignant le cluster doivent utiliser kubeadm en version 1.36

Les nœuds en cours de mise à jour doivent utiliser une version de kubeadm correspondant à la même version MINOR ou à une version MINOR supérieure à celle utilisée pour gérer le nœud.

Exemple pour kubeadm upgrade :

  • kubeadm en version 1.35 a été utilisé pour créer ou mettre à jour le nœud
  • La version de kubeadm utilisée pour la mise à jour doit être en 1.35 ou 1.36

Pour en savoir plus sur le décalage de versions entre les différents composants Kubernetes, voir la politique de décalage de versions.

Limitations

Résilience du cluster

Le cluster créé ici possède un seul nœud de plan de contrôle, avec une seule base de données etcd qui y est exécutée. Cela signifie que si le nœud du plan de contrôle tombe en panne, votre cluster peut perdre des données et devoir être recréé depuis zéro.

Solutions possibles :

Compatibilité des plateformes

Les packages deb/rpm et les binaires kubeadm sont construits pour amd64, arm (32 bits), arm64, ppc64le et s390x conformément à la proposition multi-plateforme.

Les images de conteneurs multiplateformes pour le plan de contrôle et les add-ons sont également prises en charge depuis la version v1.12.

Seuls certains fournisseurs réseau proposent des solutions pour toutes les plateformes. Veuillez consulter la liste des fournisseurs réseau ou leur documentation pour vérifier la compatibilité avec votre plateforme.

Dépannage

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

A suivre

Feedback

1.4 - Personnaliser les composants avec l’API kubeadm

Cette page explique comment personnaliser les composants déployés par kubeadm. Pour les composants du plan de contrôle (control plane), vous pouvez utiliser des flags dans la structure ClusterConfiguration ou des patches par nœud. Pour le kubelet et kube-proxy, vous pouvez utiliser respectivement KubeletConfiguration et KubeProxyConfiguration.

Toutes ces options sont disponibles via l’API de configuration kubeadm.
Pour plus de détails sur chaque champ de la configuration, vous pouvez consulter nos pages de référence API.

Note:

Pour reconfigurer un cluster déjà créé, consultez Reconfigurer un cluster kubeadm.

Personnaliser le plan de contrôle avec des flags dans ClusterConfiguration

L’objet ClusterConfiguration de kubeadm expose un moyen pour les utilisateurs de remplacer les flags par défaut passés aux composants du plan de contrôle tels que l’APIServer, le ControllerManager, le Scheduler et etcd.

Les composants sont définis à l’aide des structures suivantes :

  • apiServer
  • controllerManager
  • scheduler
  • etcd

Ces structures contiennent un champ commun extraArgs, composé de paires nom / valeur.

Pour remplacer un flag d’un composant du plan de contrôle :

  1. Ajoutez les extraArgs appropriés à votre configuration.
  2. Ajoutez les flags dans le champ extraArgs.
  3. Exécutez kubeadm init avec --config <VOTRE FICHIER YAML>.

Note:

Vous pouvez générer un objet ClusterConfiguration avec des valeurs par défaut en exécutant kubeadm config print init-defaults et en enregistrant la sortie dans un fichier de votre choix.

Note:

L’objet ClusterConfiguration est actuellement global dans les clusters kubeadm. Cela signifie que tous les flags que vous ajoutez s’appliqueront à toutes les instances du même composant sur différents nœuds. Pour appliquer une configuration individuelle par composant sur différents nœuds, vous pouvez utiliser des patches.

Note:

Les flags dupliqués (clés identiques), ou le passage multiple du même flag --foo, ne sont actuellement pas pris en charge.
Pour contourner cela, vous devez utiliser des patches.

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/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
  extraArgs:
  - name: "enable-admission-plugins"
    value: "AlwaysPullImages,DefaultStorageClass"
  - name: "audit-log-path"
    value: "/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/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
  extraArgs:
  - name: "cluster-signing-key-file"
    value: "/home/johndoe/keys/ca.key"
  - name: "deployment-controller-sync-period"
    value: "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/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
  extraArgs:
  - name: "config"
    value: "/etc/kubernetes/scheduler-config.yaml"
  extraVolumes:
    - name: schedulerconfig
      hostPath: /home/johndoe/schedconfig.yaml
      mountPath: /etc/kubernetes/scheduler-config.yaml
      readOnly: true
      pathType: "File"

Flags d’Etcd

Pour plus de détails, consultez la documentation du serveur etcd.

Exemple d’utilisation :

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
    - name: "election-timeout"
      value: 1000

Personnalisation avec des patches

FEATURE STATE: Kubernetes v1.22 [beta]

Kubeadm vous permet de passer un répertoire contenant des fichiers de patchs à InitConfiguration, JoinConfiguration et UpgradeConfiguration, sur des nœuds individuels. Ces patchs peuvent être utilisés comme dernière étape de personnalisation avant que la configuration des composants ne soit écrite sur le disque.

Vous pouvez transmettre ce fichier à kubeadm init avec --config <VOTRE FICHIER DE CONFIGURATION YAML> :

apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
patches:
  directory: /home/user/somedir

Note:

Pour kubeadm init, vous pouvez fournir un fichier contenant à la fois une ClusterConfiguration et une InitConfiguration séparées par ---.

Vous pouvez transmettre ce fichier à kubeadm join avec --config <VOTRE FICHIER DE CONFIGURATION YAML> :

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
patches:
  directory: /home/user/somedir

Si vous utilisez kubeadm upgrade apply et kubeadm upgrade node pour mettre à niveau vos nœuds kubeadm, vous devez à nouveau fournir les mêmes patches afin que la personnalisation soit conservée après la mise à niveau.

apiVersion: kubeadm.k8s.io/v1beta4
kind: UpgradeConfiguration
apply:
  patches:
    directory: /home/user/somedir

apiVersion: kubeadm.k8s.io/v1beta4
kind: UpgradeConfiguration
node:
  patches:
    directory: /home/user/somedir

Le répertoire doit contenir des fichiers nommés target[suffix][+patchtype].extension.
Par exemple : kube-apiserver0+merge.yaml ou simplement etcd.json.

  • target peut être l’un des suivants : kube-apiserver, kube-controller-manager, kube-scheduler, etcd, kubeletconfiguration et corednsdeployment.
  • suffix est une chaîne optionnelle qui peut être utilisée pour déterminer l’ordre d’application des patches (ordre alphanumérique).
  • patchtype peut être strategic, merge ou json, et doit correspondre aux formats de patch pris en charge par kubectl. Le patchtype par défaut est strategic.
  • extension doit être soit json soit yaml.

Personnalisation du kubelet

Pour personnaliser le kubelet, vous pouvez ajouter une KubeletConfiguration à côté de ClusterConfiguration ou InitConfiguration, séparée par --- dans le même fichier de configuration. Ce fichier peut ensuite être passé à kubeadm init, et kubeadm appliquera la même KubeletConfiguration de base à tous les nœuds du cluster.

Pour appliquer une configuration spécifique à une instance au-dessus de la configuration de base KubeletConfiguration, vous pouvez utiliser la cible de patch kubeletconfiguration.

Sinon, vous pouvez utiliser les flags du kubelet comme surcharges en les passant dans le champ nodeRegistration.kubeletExtraArgs, pris en charge par InitConfiguration et JoinConfiguration. Certains flags du kubelet sont obsolètes, vérifiez leur statut dans la documentation de référence du kubelet avant de les utiliser.

Pour plus de détails, voir Configurer chaque kubelet du cluster avec kubeadm.

Personnalisation de kube-proxy

Pour personnaliser kube-proxy, vous pouvez passer une KubeProxyConfiguration à côté de ClusterConfiguration ou InitConfiguration à kubeadm init, séparée par ---.

Pour plus de détails, consultez les pages de référence de l’API.

Note:

kubeadm déploie kube-proxy sous forme de DaemonSet, ce qui signifie que la KubeProxyConfiguration s’applique à toutes les instances de kube-proxy dans le cluster.

Personnalisation de CoreDNS

kubeadm permet de personnaliser le Deployment CoreDNS via des patches appliqués à la cible corednsdeployment.

Les patches pour d’autres objets API liés à CoreDNS comme le ConfigMap kube-system/coredns ne sont pas encore pris en charge. Vous devez les modifier manuellement avec kubectl et recréer ensuite les Pods CoreDNS.

Sinon, vous pouvez désactiver le déploiement CoreDNS de kubeadm en ajoutant l’option suivante dans votre ClusterConfiguration :

dns:
  disabled: true

De plus, en exécutant la commande suivante :

kubeadm init phase addon coredns --print-manifest --config my-config.yaml

vous pouvez obtenir le fichier manifeste que kubeadm créerait pour CoreDNS dans votre configuration.

1.5 - Options pour une topologie hautement disponible

Cette page explique les deux options pour configurer la topologie de vos clusters Kubernetes hautement disponibles (HA).

Vous pouvez configurer un cluster HA :

  • Avec des nœuds de plan de contrôle empilés (stacked), où les nœuds etcd sont co-localisés avec les nœuds du plan de contrôle
  • Avec des nœuds etcd externes, où etcd s’exécute sur des nœuds séparés des nœuds du plan de contrôle

Vous devez soigneusement comparer les avantages et inconvénients de chaque topologie avant de configurer un cluster HA.

Note:

kubeadm initialise le cluster etcd de manière statique. Consultez le Guide de clustering etcd pour plus de détails.

Topologie etcd empilée (stacked)

Un cluster HA empilé est une topologie dans laquelle le cluster de stockage distribué fourni par etcd est empilé sur le cluster formé par les nœuds gérés par kubeadm qui exécutent les composants du plan de contrôle.

Chaque nœud du plan de contrôle exécute une instance de kube-apiserver, kube-scheduler et kube-controller-manager. Le kube-apiserver est exposé aux nœuds workers via un load balancer.

Chaque nœud du plan de contrôle crée un membre etcd local, et ce membre etcd communique uniquement avec le kube-apiserver de ce même nœud. Il en va de même pour les instances locales de kube-controller-manager et kube-scheduler.

Cette topologie couple les composants du plan de contrôle et les membres etcd sur les mêmes nœuds. Elle est plus simple à mettre en place qu’un cluster avec etcd externe, et plus simple à gérer pour la réplication.

Cependant, cette approche comporte un risque de couplage de défaillance. Si un nœud tombe, un membre etcd et une instance du plan de contrôle sont perdus, ce qui réduit la redondance. Vous pouvez atténuer ce risque en ajoutant davantage de nœuds de plan de contrôle.

Il est donc recommandé d’exécuter au minimum trois nœuds de plan de contrôle empilés pour un cluster HA.

C’est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement sur les nœuds du plan de contrôle lors de l’utilisation de kubeadm init et kubeadm join --control-plane.

Topologie etcd empilée

Topologie etcd externe

Un cluster HA avec etcd externe est une topologie dans laquelle le cluster de stockage distribué fourni par etcd est externe au cluster formé par les nœuds exécutant les composants du plan de contrôle.

Comme dans la topologie empilée, chaque nœud du plan de contrôle exécute une instance de kube-apiserver, kube-scheduler et kube-controller-manager. Le kube-apiserver est exposé aux nœuds workers via un load balancer. Cependant, les membres etcd s’exécutent sur des hôtes séparés, et chaque hôte etcd communique avec le kube-apiserver de chaque nœud du plan de contrôle.

Cette topologie découple le plan de contrôle et etcd. Elle permet donc une meilleure résilience : la perte d’un nœud du plan de contrôle ou d’un membre etcd a moins d’impact sur la redondance du cluster.

Cependant, cette topologie nécessite deux fois plus de machines que la topologie empilée. Un minimum de trois nœuds pour le plan de contrôle et trois nœuds pour etcd est requis pour un cluster HA avec cette topologie.

Topologie etcd externe

A suivre

1.6 - Création de clusters hautement disponibles avec kubeadm

Cette page explique deux approches pour configurer un cluster Kubernetes hautement disponible (HA) à l’aide de kubeadm :

  • Avec des nœuds de plan de contrôle empilés (stacked control plane). Cette approche nécessite moins d’infrastructure. Les membres etcd et les nœuds de plan de contrôle sont co-localisés.
  • Avec un cluster etcd externe. Cette approche nécessite plus d’infrastructure. Les nœuds de plan de contrôle et les membres etcd sont séparés.

Avant de continuer, vous devez soigneusement choisir l’approche qui correspond le mieux aux besoins de vos applications et de votre environnement. La page Options de topologie hautement disponible décrit les avantages et inconvénients de chaque approche.

Si vous rencontrez des problèmes lors de la configuration du cluster HA, veuillez les signaler dans le système de tickets kubeadm.

Voir également la documentation de mise à niveau.

Avertissement:

Cette page ne couvre pas les déploiements sur un fournisseur cloud. Dans un environnement cloud, aucune des approches décrites ici ne fonctionne correctement avec les objets Service de type LoadBalancer, ni avec les volumes persistants dynamiques.

Pré-requis

Les prérequis dépendent de la topologie choisie pour le plan de contrôle :

Vous avez besoin de :

  • Trois machines ou plus répondant aux exigences minimales de kubeadm pour les nœuds du plan de contrôle. Avoir un nombre impair de nœuds de plan de contrôle peut aider lors de l’élection du leader en cas de défaillance d’une machine ou d’une zone.
  • Trois machines ou plus répondant aux exigences minimales de kubeadm pour les workers
    • incluant un runtime de conteneurs, déjà installé et fonctionnel
  • Une connectivité réseau complète entre toutes les machines du cluster (réseau public ou privé)
  • Des privilèges superutilisateur sur toutes les machines via sudo
    • Vous pouvez utiliser un autre outil ; ce guide utilise sudo dans les exemples.
  • Un accès SSH depuis une machine vers tous les nœuds du système
  • kubeadm et kubelet déjà installés sur toutes les machines.

Voir la topologie etcd empilée pour le contexte.

Vous avez besoin de :

  • Trois machines ou plus répondant aux exigences minimales de kubeadm pour les nœuds du plan de contrôle. Avoir un nombre impair de nœuds de plan de contrôle peut aider lors de l’élection du leader en cas de défaillance d’une machine ou d’une zone.
  • Trois machines ou plus répondant aux exigences minimales de kubeadm pour les workers
    • incluant un runtime de conteneurs, déjà configuré et fonctionnel
  • Une connectivité réseau complète entre toutes les machines du cluster (réseau public ou privé)
  • Des privilèges superutilisateur sur toutes les machines via sudo
    • Vous pouvez utiliser un autre outil ; ce guide utilise sudo dans les exemples.
  • Un accès SSH depuis une machine vers tous les nœuds du système
  • kubeadm et kubelet déjà installés sur toutes les machines.

Et vous avez également besoin de :

  • Trois machines supplémentaires ou plus, qui deviendront des membres du cluster etcd. Avoir un nombre impair de membres dans le cluster etcd est une exigence pour obtenir un quorum de vote optimal.
    • Ces machines doivent également avoir kubeadm et kubelet installés.
    • Ces machines nécessitent aussi un runtime de conteneurs, déjà configuré et fonctionnel.

Voir la topologie etcd externe pour le contexte.

Images de conteneurs

Chaque hôte doit avoir accès en lecture et pouvoir récupérer les images depuis le registre d’images de conteneurs Kubernetes, registry.k8s.io. Si vous souhaitez déployer un cluster hautement disponible dont les hôtes n’ont pas accès pour télécharger les images, c’est possible. Vous devez alors vous assurer par d’autres moyens que les bonnes images de conteneurs sont déjà disponibles sur les hôtes concernés.

Interface en ligne de commande

Pour gérer Kubernetes une fois votre cluster configuré, vous devez installer kubectl sur votre ordinateur. Il est également utile d’installer l’outil kubectl sur chaque nœud du plan de contrôle, car cela peut être utile pour le dépannage.

Premières étapes pour les deux méthodes

Création d’un load balancer pour kube-apiserver

Note:

Il existe de nombreuses configurations possibles pour les load balancers. L’exemple suivant n’est qu’une option parmi d’autres. Les exigences de votre cluster peuvent nécessiter une configuration différente.

  1. Créer un load balancer pour le kube-apiserver avec un nom qui résout via DNS.

    • Dans un environnement cloud, vous devez placer vos nœuds du plan de contrôle derrière un load balancer TCP. Ce load balancer distribue le trafic vers tous les nœuds du plan de contrôle en bonne santé présents dans sa liste de cibles. Le contrôle de santé (health check) pour l’API server est une vérification TCP sur le port utilisé par le kube-apiserver (valeur par défaut :6443).

    • Il n’est pas recommandé d’utiliser directement une adresse IP dans un environnement cloud.

    • Le load balancer doit pouvoir communiquer avec tous les nœuds du plan de contrôle sur le port de l’API server. Il doit également autoriser le trafic entrant sur son port d’écoute.

    • Assurez-vous que l’adresse du load balancer correspond toujours à l’adresse définie dans le ControlPlaneEndpoint de kubeadm.

    • Consultez le guide Options for Software Load Balancing pour plus de détails.

  2. Ajouter le premier nœud du plan de contrôle au load balancer, et tester la connexion :

    nc -zv -w 2 <LOAD_BALANCER_IP> <PORT>

    Une erreur de type connection refused est attendue car le serveur API n’est pas encore en cours d’exécution. En revanche, un timeout signifie que le load balancer ne peut pas communiquer avec le nœud du plan de contrôle. Si un timeout se produit, reconfigurez le load balancer afin qu’il puisse communiquer avec le nœud du plan de contrôle.

  3. Ajouter les autres nœuds du plan de contrôle au groupe de cibles du load balancer.

Nœuds du plan de contrôle et etcd empilés (stacked)

Étapes pour le premier nœud du plan de contrôle

  1. Initialiser le plan de contrôle :

    sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs

    • Vous pouvez utiliser l’option --kubernetes-version pour définir la version de Kubernetes à utiliser. Il est recommandé que les versions de kubeadm, kubelet, kubectl et Kubernetes soient identiques.

    • L’option --control-plane-endpoint doit être définie avec l’adresse (ou le DNS) et le port du load balancer.

    • L’option --upload-certs est utilisée pour téléverser les certificats qui doivent être partagés entre toutes les instances du plan de contrôle dans le cluster. Si vous préférez copier les certificats manuellement entre les nœuds du plan de contrôle ou utiliser des outils d’automatisation, supprimez cette option et référez-vous à la section Distribution manuelle des certificats ci-dessous.

    Note:

    Les flags --config et --certificate-key de kubeadm init ne peuvent pas être utilisés ensemble. Par conséquent, si vous souhaitez utiliser la configuration kubeadm, vous devez ajouter le champ certificateKey aux emplacements appropriés (dans InitConfiguration et JoinConfiguration: controlPlane).

    Note:

    Certains plugins réseau CNI nécessitent une configuration supplémentaire, par exemple la définition du CIDR des pods, tandis que d’autres n’en ont pas besoin. Consultez la documentation CNI. Pour ajouter un CIDR de pods, utilisez le flag --pod-network-cidr, ou si vous utilisez un fichier de configuration kubeadm, définissez le champ podSubnet dans l’objet networking de ClusterConfiguration.

    La sortie ressemble à :

    ...
Vous pouvez maintenant joindre autant de nœuds du plan de contrôle que vous le souhaitez en exécutant la commande suivante sur chacun en tant que root :
    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07

Veuillez noter que la certificate-key donne accès à des données sensibles du cluster, gardez-la secrète ! 
Par mesure de sécurité, les certificats téléversés seront supprimés au bout de deux heures. Si nécessaire, vous pouvez utiliser `kubeadm init phase upload-certs` pour recharger les certificats par la suite.

Ensuite, vous pouvez joindre autant de nœuds workers que vous le souhaitez en exécutant la commande suivante sur chacun en tant que root :
    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

    • Copiez cette sortie dans un fichier texte. Vous en aurez besoin plus tard pour ajouter des nœuds du plan de contrôle et des nœuds workers au cluster.

    • Lorsque l’option --upload-certs est utilisée avec kubeadm init, les certificats du plan de contrôle principal sont chiffrés et envoyés dans le Secret kubeadm-certs.

    • Pour ré-envoyer les certificats et générer une nouvelle clé de déchiffrement, utilisez la commande suivante sur un nœud du plan de contrôle déjà joint au cluster :

      sudo kubeadm init phase upload-certs --upload-certs

    • Vous pouvez également spécifier une clé personnalisée --certificate-key lors de l’exécution de init, qui pourra ensuite être utilisée par join. Pour générer une telle clé, vous pouvez utiliser la commande suivante :

      kubeadm certs certificate-key

    La clé de certificat est une chaîne encodée en hexadécimal correspondant à une clé AES de 32 octets.

    Note:

    Le Secret kubeadm-certs ainsi que la clé de déchiffrement expirent après deux heures.

    Avertissement:

    Comme indiqué dans la sortie de la commande, la clé de certificat donne accès à des données sensibles du cluster. Gardez-la secrète !

  2. Appliquez le plugin CNI de votre choix : Suivez ces instructions pour installer un fournisseur CNI. Assurez-vous que la configuration correspond au CIDR des Pods défini dans le fichier de configuration kubeadm (le cas échéant).

    Note:

    Vous devez choisir un plugin réseau adapté à votre cas d’usage et l’installer avant de passer à l’étape suivante. Si ce n’est pas fait, vous ne pourrez pas démarrer correctement votre cluster.

  3. Tapez la commande suivante et observez le démarrage des Pods des composants du plan de contrôle :

    kubectl get pod -n kube-system -w

Étapes pour les autres nœuds du plan de contrôle

Pour chaque nœud de plan de contrôle supplémentaire, vous devez :

  1. Exécutez la commande de jointure qui vous a été fournie précédemment par la sortie de kubeadm init sur le premier nœud. Elle devrait ressembler à ceci :

    sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
    • L’option --control-plane indique à kubeadm join de créer un nouveau plan de contrôle.
    • L’option --certificate-key ... permet de télécharger les certificats du plan de contrôle depuis le Secret kubeadm-certs du cluster, puis de les déchiffrer à l’aide de la clé fournie.

Note:

Comme les nœuds du cluster sont généralement initialisés de manière séquentielle, il est probable que les pods CoreDNS s’exécutent tous sur le premier nœud du plan de contrôle. Pour assurer une meilleure disponibilité, veuillez rééquilibrer les pods CoreDNS avec la commande kubectl -n kube-system rollout restart deployment coredns après qu’au moins un nouveau nœud a été rejoint.

Nœuds etcd externes

La configuration d’un cluster avec des nœuds etcd externes est similaire à celle du mode stacked etcd, à l’exception du fait que vous devez d’abord configurer etcd, puis fournir les informations etcd dans le fichier de configuration kubeadm.

Mise en place du cluster etcd

  1. Suivez ces instructions pour configurer le cluster etcd.

  2. Configurez SSH comme décrit ici.

  3. Copiez les fichiers suivants depuis n’importe quel nœud etcd du cluster vers le premier nœud du plan de contrôle :

    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}":
    • Replace the value of CONTROL_PLANE with the user@host of the first control-plane node.

Configuration du premier nœud du plan de contrôle

  1. Créez un fichier nommé kubeadm-config.yaml avec le contenu suivant :

    ---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
etcd:
  external:
    endpoints:
      - https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately
      - https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately
      - https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately
    caFile: /etc/kubernetes/pki/etcd/ca.crt
    certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
    keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key

Note:

La différence entre etcd empilé (stacked etcd) et etcd externe ici est que la configuration etcd externe nécessite un fichier de configuration avec les endpoints etcd sous l’objet external de etcd. Dans le cas de la topologie etcd empilée, cela est géré automatiquement.

  • Remplacez les variables suivantes dans le modèle de configuration avec les valeurs appropriées de votre cluster :

    • LOAD_BALANCER_DNS
    • LOAD_BALANCER_PORT
    • ETCD_0_IP
    • ETCD_1_IP
    • ETCD_2_IP

Les étapes suivantes sont similaires à la configuration etcd empilée :

  1. Exécutez sudo kubeadm init --config kubeadm-config.yaml --upload-certs sur ce nœud.

  2. Enregistrez les commandes de jointure affichées dans un fichier texte pour une utilisation ultérieure.

  3. Appliquez le plugin réseau CNI de votre choix.

Note:

Vous devez choisir un plugin réseau adapté à votre cas d’usage et le déployer avant de passer à l’étape suivante. Sinon, vous ne pourrez pas démarrer correctement votre cluster.

Étapes pour les autres nœuds du plan de contrôle

Les étapes sont les mêmes que pour la configuration etcd empilée :

  • Assurez-vous que le premier nœud du plan de contrôle est entièrement initialisé.
  • Joignez chaque nœud de plan de contrôle avec la commande de jointure que vous avez enregistrée dans un fichier texte. Il est recommandé de les joindre un par un.
  • N’oubliez pas que la clé de déchiffrement --certificate-key expire par défaut après deux heures.

Tâches courantes après le démarrage du plan de contrôle

Ajouter des workers

Les nœuds worker peuvent être ajoutés au cluster avec la commande que vous avez précédemment enregistrée lors de la sortie de kubeadm init :

sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

Distribution manuelle des certificats

Si vous choisissez de ne pas utiliser kubeadm init avec le flag --upload-certs, cela signifie que vous devrez copier manuellement les certificats depuis le nœud principal du plan de contrôle vers les nœuds du plan de contrôle qui rejoignent le cluster.

Il existe plusieurs façons de faire cela. L’exemple suivant utilise ssh et scp :

SSH est requis si vous souhaitez contrôler tous les nœuds depuis une seule machine.

  1. Activez ssh-agent sur votre machine principale qui a accès à tous les autres nœuds du système :

    eval $(ssh-agent)

  2. Ajoutez votre identité SSH à la session :

    ssh-add ~/.ssh/path_to_private_key

  3. Effectuez une connexion SSH entre les nœuds pour vérifier que la connexion fonctionne correctement.

    • Lorsque vous vous connectez en SSH à un nœud, ajoutez l’option -A. Cette option permet au nœud sur lequel vous êtes connecté via SSH d’accéder à l’agent SSH de votre PC. Envisagez des méthodes alternatives si vous ne faites pas entièrement confiance à la sécurité de votre session utilisateur sur le nœud.

      ssh -A 10.0.0.7

    • Lorsque vous utilisez sudo sur un nœud, assurez-vous de préserver l’environnement afin que la redirection SSH (SSH forwarding) fonctionne :

      sudo -E -s

  4. Après avoir configuré SSH sur tous les nœuds, vous devez exécuter le script suivant sur le premier nœud du plan de contrôle après avoir exécuté kubeadm init. Ce script va copier les certificats depuis le premier nœud du plan de contrôle vers les autres nœuds du plan de contrôle :

    Dans l’exemple suivant, remplacez CONTROL_PLANE_IPS par les adresses IP des autres nœuds du plan de contrôle.

    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
    # Skip the next line if you are using external etcd
    scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
done

Avertissement:

Copiez uniquement les certificats listés ci-dessus. kubeadm se chargera de générer le reste des certificats avec les SAN (Subject Alternative Name) requis pour les instances de plan de contrôle qui rejoignent le cluster. Si vous copiez tous les certificats par erreur, la création de nouveaux nœuds peut échouer en raison de l’absence des SAN requis.

  1. Ensuite, sur chaque nœud du plan de contrôle qui rejoint le cluster, vous devez exécuter le script suivant avant d’exécuter kubeadm join. Ce script déplacera les certificats précédemment copiés depuis le répertoire home vers /etc/kubernetes/pki :

    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
# Skip the next line if you are using external etcd
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key

1.7 - Mise en place d’un cluster etcd haute disponibilité avec kubeadm

Par défaut, kubeadm exécute une instance locale d’etcd sur chaque nœud du plan de contrôle. Il est également possible de considérer le cluster etcd comme externe et de provisionner des instances etcd sur des hôtes séparés. Les différences entre ces deux approches sont détaillées dans la page Options pour une topologie hautement disponible.

Cette tâche décrit le processus de création d’un cluster etcd externe haute disponibilité composé de trois membres, qui peut être utilisé par kubeadm lors de la création du cluster.

Pré-requis

  • Trois hôtes capables de communiquer entre eux via les ports TCP 2379 et 2380. Ce document utilise ces ports par défaut, mais ils peuvent être configurés via le fichier de configuration kubeadm.
  • Chaque hôte doit disposer de systemd et d’un shell compatible bash.
  • Chaque hôte doit avoir un runtime de conteneurs, kubelet et kubeadm installés.
  • Chaque hôte doit pouvoir accéder au registre d’images Kubernetes (registry.k8s.io) ou lister/télécharger l’image etcd requise avec kubeadm config images list/pull. Ce guide configure les instances etcd en tant que pods statiques gérés par kubelet.
  • Une infrastructure permettant de copier des fichiers entre les hôtes. Par exemple, ssh et scp peuvent être utilisés.

Configuration du cluster

L’approche générale consiste à générer tous les certificats sur un seul nœud, puis à distribuer uniquement les fichiers nécessaires aux autres nœuds.

Note:

kubeadm inclut toute la mécanique cryptographique nécessaire pour générer les certificats décrits ci-dessous ; aucun autre outil cryptographique n’est requis pour cet exemple.

Note:

Les exemples ci-dessous utilisent des adresses IPv4, mais vous pouvez également configurer kubeadm, kubelet et etcd pour utiliser des adresses IPv6. Le mode dual-stack est pris en charge par certaines options Kubernetes, mais pas par etcd. Pour plus de détails sur le support dual-stack dans Kubernetes, consultez Support dual-stack avec kubeadm.

  1. Configurer le kubelet pour qu’il serve de gestionnaire de service pour etcd.

    Note:

    Vous devez effectuer cette étape sur chaque hôte où etcd doit être exécuté.

    Comme etcd a été créé en premier, vous devez remplacer la priorité du service en créant un nouveau fichier d’unité ayant une priorité plus élevée que le fichier d’unité kubelet fourni par kubeadm.

    cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
# Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
# Replace the value of "containerRuntimeEndpoint" for a different container runtime if needed.
#
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: false
authorization:
  mode: AlwaysAllow
cgroupDriver: systemd
address: 127.0.0.1
containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
staticPodPath: /etc/kubernetes/manifests
EOF

cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
Restart=always
EOF

systemctl daemon-reload
systemctl restart kubelet

    Vérifiez l’état du kubelet pour vous assurer qu’il est en cours d’exécution.

    systemctl status kubelet

  2. Créez les fichiers de configuration pour kubeadm.

    Générez un fichier de configuration kubeadm pour chaque hôte qui exécutera un membre etcd en utilisant le script suivant.

    # Update HOST0, HOST1 and HOST2 with the IPs of your hosts
export HOST0=10.0.0.6
export HOST1=10.0.0.7
export HOST2=10.0.0.8

# Update NAME0, NAME1 and NAME2 with the hostnames of your hosts
export NAME0="infra0"
export NAME1="infra1"
export NAME2="infra2"

# Create temp directories to store files that will end up on other hosts
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/

HOSTS=(${HOST0} ${HOST1} ${HOST2})
NAMES=(${NAME0} ${NAME1} ${NAME2})

for i in "${!HOSTS[@]}"; do
HOST=${HOSTS[$i]}
NAME=${NAMES[$i]}
cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
---
apiVersion: "kubeadm.k8s.io/v1beta4"
kind: InitConfiguration
nodeRegistration:
    name: ${NAME}
localAPIEndpoint:
    advertiseAddress: ${HOST}
---
apiVersion: "kubeadm.k8s.io/v1beta4"
kind: ClusterConfiguration
etcd:
    local:
        serverCertSANs:
        - "${HOST}"
        peerCertSANs:
        - "${HOST}"
        extraArgs:
        - name: initial-cluster
          value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
        - name: initial-cluster-state
          value: new
        - name: name
          value: ${NAME}
        - name: listen-peer-urls
          value: https://${HOST}:2380
        - name: listen-client-urls
          value: https://${HOST}:2379
        - name: advertise-client-urls
          value: https://${HOST}:2379
        - name: initial-advertise-peer-urls
          value: https://${HOST}:2380
EOF
done

  3. Générez l’autorité de certification (CA).

    Si vous possédez déjà une CA, la seule action consiste à copier les fichiers crt et key de la CA vers : /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 encore de CA, exécutez cette commande sur $HOST0 (où vous avez généré les fichiers de configuration 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. Copiez les certificats et les fichiers de configuration kubeadm.

    Les certificats ont été générés et doivent maintenant être déplacés vers leurs 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. Assurez-vous 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éez les manifests de pods statiques.

    Maintenant que les certificats et les fichiers de configuration sont en place, il est temps de créer les manifests. Sur chaque hôte, exécutez la commande kubeadm pour générer un manifest 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. Optionnel : Vérifiez l’état de santé du cluster.

    Si etcdctl n’est pas disponible, vous pouvez exécuter cet outil dans une image de conteneur. Vous pouvez le faire directement avec votre runtime de conteneurs en utilisant un outil tel que crictl run, et non via Kubernetes.

    ETCDCTL_API=3 etcdctl \
--cert /etc/kubernetes/pki/etcd/peer.crt \
--key /etc/kubernetes/pki/etcd/peer.key \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--endpoints https://${HOST0}:2379 endpoint health
...
https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
    • Définissez ${HOST0} avec l’adresse IP de l’hôte que vous testez.

A suivre

Une fois que vous disposez d’un cluster etcd avec 3 membres fonctionnels, vous pouvez continuer à mettre en place un plan de contrôle haute disponibilité en utilisant la méthode etcd externe avec kubeadm.

1.8 - Configuration de chaque kubelet dans votre cluster avec kubeadm

Note: Dockershim has been removed from the Kubernetes project as of release 1.24. Read the Dockershim Removal FAQ for further details.
FEATURE STATE: Kubernetes v1.11 [stable]

Le cycle de vie de l’outil CLI kubeadm est découplé du kubelet, qui est un daemon s’exécutant sur chaque nœud au sein du cluster Kubernetes. L’outil CLI kubeadm est exécuté par l’utilisateur lors de l’initialisation ou de la mise à niveau de Kubernetes, tandis que le kubelet fonctionne en permanence en arrière-plan.

Étant donné que le kubelet est un daemon, il doit être géré par un système d’initialisation (init system) ou un gestionnaire de services. Lorsque le kubelet est installé via des paquets DEB ou RPM, systemd est configuré pour gérer le kubelet. Vous pouvez utiliser un autre gestionnaire de services, mais vous devrez le configurer manuellement.

Certaines configurations du kubelet doivent être identiques sur tous les kubelets du cluster, tandis que d’autres doivent être définies individuellement pour chaque kubelet afin de s’adapter aux caractéristiques spécifiques d’une machine (comme le système d’exploitation, le stockage et le réseau). Vous pouvez gérer la configuration des kubelets manuellement, mais kubeadm fournit désormais un type d’API KubeletConfiguration pour centraliser la gestion des configurations du kubelet.

Modèles de configuration du kubelet

Les sections suivantes décrivent des modèles de configuration du kubelet simplifiés grâce à kubeadm, plutôt que de gérer manuellement la configuration de chaque nœud.

Propagation de la configuration au niveau du cluster vers chaque kubelet

Vous pouvez fournir au kubelet des valeurs par défaut utilisées par les commandes kubeadm init et kubeadm join. Parmi les exemples intéressants, on peut citer l’utilisation d’un runtime de conteneurs 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, vous pouvez passer le paramètre --service-cidr à kubeadm :

kubeadm init --service-cidr 10.96.0.0/12

Les adresses IP virtuelles des services sont désormais allouées à partir de ce sous-réseau. Vous devez également définir l’adresse DNS utilisée par le kubelet, à l’aide de l’option --cluster-dns. Ce paramètre doit être identique pour tous les kubelets de tous les nœuds du plan de contrôle et des nœuds du cluster.

Le kubelet fournit un objet d’API structuré et versionné permettant de configurer la plupart de ses paramètres et de diffuser cette configuration à chaque kubelet en cours d’exécution dans le cluster. Cet objet est appelé KubeletConfiguration.

Le KubeletConfiguration permet à l’utilisateur de spécifier des options telles que les adresses IP du DNS du cluster, exprimées sous forme de liste de valeurs associées à une clé en camelCase, comme illustré dans l’exemple suivant :

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10

Pour plus de détails sur le KubeletConfiguration, consultez cette section.

Fournir des configurations spécifiques à une instance

Certains hôtes nécessitent des configurations kubelet spécifiques en raison de différences de matériel, de système d’exploitation, de réseau ou d’autres paramètres propres à chaque machine. La liste suivante fournit quelques exemples :

  • Le chemin du fichier de résolution DNS, spécifié par l’option --resolv-conf du kubelet, peut varier selon les systèmes d’exploitation ou selon l’utilisation de systemd-resolved. Si ce chemin est incorrect, la résolution DNS échouera sur le nœud dont le kubelet est mal configuré.

  • L’objet Node API .metadata.name est défini par défaut avec le nom d’hôte de la machine, sauf si vous utilisez un fournisseur cloud. Vous pouvez utiliser l’option --hostname-override pour remplacer ce comportement si vous devez définir un nom de nœud différent du nom d’hôte de la machine.

  • Actuellement, le kubelet ne peut pas détecter automatiquement le driver cgroup utilisé par le runtime de conteneurs, mais la valeur de --cgroup-driver doit correspondre à celle utilisée par le runtime pour garantir le bon fonctionnement du kubelet.

  • Pour spécifier le runtime de conteneurs, vous devez définir son endpoint avec l’option --container-runtime-endpoint=<path>.

La méthode recommandée pour appliquer ce type de configuration spécifique à une instance consiste à utiliser les patchs KubeletConfiguration.

Configurer les kubelets avec kubeadm

Il est possible de configurer le kubelet que kubeadm va démarrer si un objet API personnalisé KubeletConfiguration est fourni via un fichier de configuration comme suit : kubeadm ... --config some-config-file.yaml.

En exécutant kubeadm config print init-defaults --component-configs KubeletConfiguration, vous pouvez voir toutes les valeurs par défaut de cette structure.

Il est également possible d’appliquer des patchs spécifiques à une instance par-dessus la configuration de base KubeletConfiguration. Consultez Personnaliser le kubelet pour plus de détails.

Workflow lors de l’utilisation de kubeadm init

Lorsque vous exécutez kubeadm init, la configuration du kubelet est sérialisée sur le disque dans /var/lib/kubelet/config.yaml, et également téléversée dans une ConfigMap kubelet-config dans le namespace kube-system du cluster.

En outre, l’outil kubeadm détecte le socket CRI sur le nœud et écrit ses détails (y compris le chemin du socket) dans une configuration locale /var/lib/kubelet/instance-config.yaml.

Un fichier de configuration kubelet est également écrit dans /etc/kubernetes/kubelet.conf, contenant la configuration de base commune à tous les kubelets du cluster. Ce fichier de configuration pointe vers les certificats clients permettant au kubelet de communiquer avec le serveur API. Cela répond au besoin de propager la configuration au niveau du cluster vers chaque kubelet.

Pour répondre au second modèle de fourniture de paramètres spécifiques à une instance, kubeadm écrit un fichier d’environnement dans /var/lib/kubelet/kubeadm-flags.env, qui contient une liste de paramètres à passer au kubelet lors de son démarrage. Les flags sont présentés dans ce fichier comme suit :

KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."

En plus des options utilisées lors du démarrage du kubelet, ce fichier contient également des paramètres dynamiques tels que le driver cgroup.

Après avoir écrit ces deux fichiers sur le disque, kubeadm tente d’exécuter les deux commandes suivantes si vous utilisez systemd :

systemctl daemon-reload && systemctl restart kubelet

Si le rechargement et le redémarrage réussissent, le flux normal de kubeadm init continue.

Workflow lors de l’utilisation de kubeadm join

Lorsque vous exécutez kubeadm join, kubeadm utilise le jeton de bootstrap (Bootstrap Token) pour effectuer un bootstrap TLS, qui récupère les identifiants nécessaires pour télécharger la ConfigMap kubelet-config, puis l’écrit dans /var/lib/kubelet/config.yaml.

En outre, l’outil kubeadm détecte le socket CRI sur le nœud et écrit ses détails (y compris le chemin du socket) dans une configuration locale /var/lib/kubelet/instance-config.yaml.

Le fichier d’environnement dynamique est généré exactement de la même manière que pour kubeadm init.

Ensuite, kubeadm exécute les deux commandes suivantes pour charger la nouvelle configuration dans le kubelet :

systemctl daemon-reload && systemctl restart kubelet

Après que le kubelet a chargé la nouvelle configuration, kubeadm écrit le fichier KubeConfig /etc/kubernetes/bootstrap-kubelet.conf, qui contient un certificat CA et un Bootstrap Token. Ces éléments sont utilisés par le kubelet pour effectuer le bootstrap TLS et obtenir une identité unique, qui est ensuite stockée dans /etc/kubernetes/kubelet.conf.

Une fois que le fichier /etc/kubernetes/kubelet.conf est écrit, le kubelet a terminé le bootstrap TLS. Kubeadm supprime le fichier /etc/kubernetes/bootstrap-kubelet.conf après la fin de ce processus.

Le fichier drop-in du kubelet pour systemd

kubeadm fournit la configuration indiquant comment systemd doit exécuter le kubelet. Notez que la commande kubeadm ne modifie jamais ce fichier drop-in.

Ce fichier de configuration installé par le paquet kubeadm est écrit dans /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf et est utilisé par systemd. Il complète le fichier de base kubelet.service.

Si vous souhaitez aller plus loin et le surcharger, vous pouvez créer le répertoire /etc/systemd/system/kubelet.service.d/ (et non /usr/lib/systemd/system/kubelet.service.d/) et y placer vos propres personnalisations. Par exemple, vous pouvez ajouter un fichier local /etc/systemd/system/kubelet.service.d/local-overrides.conf pour remplacer les paramètres de l’unité configurés par kubeadm.

Voici ce que vous trouverez probablement dans /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf :

Note:

Le contenu ci-dessous est uniquement un exemple. Si vous ne souhaitez pas utiliser un gestionnaire de paquets, suivez le guide décrit dans la section (Sans gestionnaire de paquets).
[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" generate 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

[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"
# Ceci est un fichier que "kubeadm init" et "kubeadm join" génèrent au moment de l’exécution,
# en remplissant dynamiquement la variable KUBELET_KUBEADM_ARGS
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# Ceci est un fichier que l’utilisateur peut utiliser pour des surcharges des arguments du kubelet en dernier recours.
# Idéalement, l’utilisateur devrait utiliser l’objet .NodeRegistration.KubeletExtraArgs dans les fichiers de configuration à la place.
# KUBELET_EXTRA_ARGS doit être lu depuis ce fichier.
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 de tous les fichiers gérés par kubeadm pour le kubelet.

  • Le fichier KubeConfig utilisé 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 contenant l’identité unique du kubelet est /etc/kubernetes/kubelet.conf.
  • Le fichier contenant le ComponentConfig du kubelet est /var/lib/kubelet/config.yaml.
  • Le fichier d’environnement dynamique contenant KUBELET_KUBEADM_ARGS est chargé depuis /var/lib/kubelet/kubeadm-flags.env.
  • Le fichier pouvant contenir des options définies par l’utilisateur via KUBELET_EXTRA_ARGS est chargé depuis /etc/default/kubelet (pour les paquets DEB), ou /etc/sysconfig/kubelet (pour les RPM). KUBELET_EXTRA_ARGS est en dernier dans la chaîne des paramètres et a la plus haute priorité en cas de conflit.

Binaires Kubernetes et contenu des paquets

Les paquets DEB et RPM fournis avec les versions de Kubernetes sont :

Nom du paquetDescription
kubeadmInstalle l’outil CLI /usr/bin/kubeadm et le fichier drop-in du kubelet.
kubeletInstalle le binaire /usr/bin/kubelet.
kubectlInstalle le binaire /usr/bin/kubectl.
cri-toolsInstalle le binaire /usr/bin/crictl depuis le dépôt cri-tools.
kubernetes-cniInstalle les binaires /opt/cni/bin depuis le dépôt plugins.

1.9 - Support dual-stack avec kubeadm

FEATURE STATE: Kubernetes v1.23 [stable]

Votre cluster Kubernetes inclut le support du dual-stack, ce qui signifie que le réseau du cluster permet d’utiliser l’une ou l’autre famille d’adresses IP. Dans un cluster, le plan de contrôle peut attribuer à la fois une adresse IPv4 et une adresse IPv6 à un seul Pod ou à un Service.

Pré-requis

Vous devez avoir installé l’outil kubeadm, en suivant les étapes de Installation de kubeadm.

Pour chaque serveur que vous souhaitez utiliser comme nœud, assurez-vous que le forwarding IPv6 est activé.

Activer le forwarding des paquets IPv6

Pour vérifier si le forwarding IPv6 est activé :

sysctl net.ipv6.conf.all.forwarding

Si la sortie est net.ipv6.conf.all.forwarding = 1, le transfert de paquets IPv6 est déjà activé.

Sinon, il n'est pas encore activé.

Pour activer manuellement le transfert de paquets IPv6 :

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee -a /etc/sysctl.d/k8s.conf
net.ipv6.conf.all.forwarding = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

Vous devez disposer d’une plage d’adresses IPv4 et IPv6 à utiliser. Les opérateurs de cluster utilisent généralement des plages d’adresses privées pour IPv4. Pour IPv6, un opérateur de cluster choisit généralement un bloc d’adresses unicast global dans 2000::/3, en utilisant une plage attribuée à l’opérateur. Vous n’avez pas besoin de router les plages d’adresses IP du cluster vers Internet.

La taille des allocations d’adresses IP doit être adaptée au nombre de Pods et de Services que vous prévoyez d’exécuter.

Note:

Si vous mettez à niveau un cluster existant avec la commande kubeadm upgrade, kubeadm ne prend pas en charge la modification de la plage d’adresses IP des Pods (“cluster CIDR”) ni de la plage d’adresses des Services (“Service CIDR”) du cluster.

Créer un cluster dual-stack

Pour créer un cluster dual-stack avec kubeadm init, vous pouvez passer des arguments en ligne de commande similaires à l’exemple suivant :

# These address ranges are examples
kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112

Pour plus de clarté, voici un exemple de fichier de configuration kubeadm configuration kubeadm kubeadm-config.yaml pour le nœud principal du plan de contrôle en dual-stack.

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16,2001:db8:42:0::/56
  serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::2"

advertiseAddress dans InitConfiguration spécifie l’adresse IP sur laquelle le serveur API annonce qu’il écoute. La valeur de advertiseAddress correspond au flag --apiserver-advertise-address de kubeadm init.

Exécutez kubeadm pour initialiser le nœud du plan de contrôle en dual-stack :

kubeadm init --config=kubeadm-config.yaml

Les flags du kube-controller-manager --node-cidr-mask-size-ipv4 et --node-cidr-mask-size-ipv6 sont définis avec des valeurs par défaut. Voir configurer le dual-stack IPv4/IPv6.

Note:

Le flag --apiserver-advertise-address ne prend pas en charge le dual-stack.

Joindre un nœud à un cluster dual-stack

Avant de joindre un nœud, assurez-vous que celui-ci dispose d’une interface réseau IPv6 routable et que le forwarding IPv6 est activé.

Voici un exemple de fichier de configuration kubeadm configuration kubeadm kubeadm-config.yaml pour ajouter un nœud worker au cluster.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.100.0.1:6443
    token: "clvldh.vjjwg16ucnhp94qr"
    caCertHashes:
    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
    # change auth info above to match the actual token and CA certificate hash for your cluster
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::3"

Voici également un exemple de fichier de configuration kubeadm configuration kubeadm kubeadm-config.yaml pour ajouter un autre nœud de plan de contrôle au cluster.

apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
controlPlane:
  localAPIEndpoint:
    advertiseAddress: "10.100.0.2"
    bindPort: 6443
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.100.0.1:6443
    token: "clvldh.vjjwg16ucnhp94qr"
    caCertHashes:
    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
    # change auth info above to match the actual token and CA certificate hash for your cluster
nodeRegistration:
  kubeletExtraArgs:
  - name: "node-ip"
    value: "10.100.0.2,fd00:1:2:3::4"

advertiseAddress dans JoinConfiguration.controlPlane spécifie l'adresse IP sur laquelle le serveur API annoncera son écoute. La valeur de advertiseAddress correspond à l'option --apiserver-advertise-address de kubeadm join.

kubeadm join --config=kubeadm-config.yaml

Créer un cluster mono-stack

Note:

Le support du dual-stack ne signifie pas que vous devez obligatoirement utiliser un adressage dual-stack. Vous pouvez déployer un cluster mono-stack avec la fonctionnalité de dual-stack réseau activée.

Pour plus de clarté, voici un exemple de fichier de configuration kubeadm configuration kubeadm kubeadm-config.yaml pour un nœud de plan de contrôle en mono-stack.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/16

A suivre