Déploiement d'un cluster avec kubeadm

• 1: Installer kubeadm
• 2: Dépannage de kubeadm
• 3: Création d’un cluster avec kubeadm
• 4: Personnaliser les composants avec l’API kubeadm
• 5: Options pour une topologie hautement disponible
• 6: Création de clusters hautement disponibles avec kubeadm
• 7: Mise en place d’un cluster etcd haute disponibilité avec kubeadm
• 8: Configuration de chaque kubelet dans votre cluster avec kubeadm
• 9: Support dual-stack avec kubeadm

1 - Installer kubeadm

Cette page vous apprend comment installer la boîte à outils kubeadm. Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez effectué ce processus d'installation, voir la page: Utiliser kubeadm pour créer un cluster.

Pré-requis

• Une ou plusieurs machines exécutant:
  • Ubuntu 16.04+
  • Debian 9+
  • CentOS 7
  • Red Hat Enterprise Linux (RHEL) 7
  • Fedora 25+
  • HypriotOS v1.0.1+
  • Flatcar Container Linux (testé avec 2512.3.0)
• 2 Go ou plus de RAM par machine (toute quantité inférieure laissera peu de place à vos applications)
• 2 processeurs ou plus
• Connectivité réseau complète entre toutes les machines du cluster (réseau public ou privé)
• Nom d'hôte, adresse MAC et product_uuid uniques pour chaque nœud. Voir ici pour plus de détails.
• Certains ports doivent êtres ouverts sur vos machines. Voir ici pour plus de détails.
• Swap désactivé. Vous devez impérativement désactiver le swap pour que la kubelet fonctionne correctement.

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

• Vous pouvez obtenir l'adresse MAC des interfaces réseau en utilisant la commande ip link ou ifconfig -a
• Le product_uuid peut être vérifié en utilisant la commande sudo cat /sys/class/dmi/id/product_uuid

Il est très probable que les périphériques matériels aient des adresses uniques, bien que certaines machines virtuelles puissent avoir des valeurs identiques. Kubernetes utilise ces valeurs pour identifier de manière unique les nœuds du cluster. Si ces valeurs ne sont pas uniques à chaque nœud, le processus d'installation peut échouer.

Vérifiez les cartes réseaux

Si vous avez plusieurs cartes réseaux et que vos composants Kubernetes ne sont pas accessibles par la route par défaut, nous vous recommandons d’ajouter une ou plusieurs routes IP afin que les adresses de cluster Kubernetes soient acheminées via la carte approprié.

Permettre à iptables de voir le trafic ponté

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

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

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

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

Vérifiez les ports requis

nœuds maîtres (masters)

nœuds workers

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

Tous les numéros de port marqués d'un * sont écrasables. Vous devrez donc vous assurer que les ports personnalisés que vous utilisez sont également ouverts.

Bien que les ports etcd soient inclus dans les nœuds masters, vous pouvez également héberger votre propre cluster etcd en externe ou sur des ports personnalisés.

Le plug-in de réseau de pod que vous utilisez (voir ci-dessous) peut également nécessiter certains ports à ouvrir. Étant donné que cela diffère d’un plugin à l’autre, veuillez vous reporter à la documentation des plugins sur le(s) port(s) requis(s).

Installation du runtime

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

• Linux nodes
• autres systèmes d'exploitation

Installation de kubeadm, des kubelets et de kubectl

Vous installerez ces paquets sur toutes vos machines:

• kubeadm: la commande pour initialiser le cluster.

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

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

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

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

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

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

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

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

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

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

sudo systemctl enable --now kubelet

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

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

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

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

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

sudo systemctl enable --now kubelet

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

Configurer le driver de cgroup utilisé par la kubelet sur un nœud master

Lorsque vous utilisez Docker, kubeadm détecte automatiquement le pilote ( driver ) de cgroup pour kubelet et le configure dans le fichier /var/lib/kubelet/config.yaml lors de son éxecution.

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

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

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

Veuillez noter que vous devez seulement le faire si le driver de cgroupe de votre CRI n'est pas cgroupfs, car c'est déjà la valeur par défaut dans la kubelet.

Il est nécessaire de redémarrer la kubelet:

sudo systemctl daemon-reload
sudo systemctl restart kubelet

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

Dépannage

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

A suivre

• Utiliser kubeadm pour créer un cluster

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

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

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

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:

• Mettez à niveau vers une version plus récente de Docker.

• Désactivez SELinux.

• Modifiez le déploiement coredns pour définir allowPrivilegeEscalation sur true :

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

une autre raison pour laquelle CoreDNS peut se retrouver dans l'état CrashLoopBackOff est lorsqu'un Pod de CoreDNS déployé dans Kubernetes détecte une boucle. Un certain nombre de solutions de contournement sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s'arrête.

Les pods etcd redémarrent continuellement

Si vous rencontrez l'erreur suivante:

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

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

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

• Revenir à une version antérieure de Docker, telle que la 1.13.1-75:

yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64

• Installez l'une des versions les plus récentes recommandées, telles que la 18.06:

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install docker-ce-18.06.1.ce-3.el7.x86_64

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.

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.

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.

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.

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"

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.

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.

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

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

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>

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 :

• Ajout de nœuds workers Linux
• Ajout de nœuds workers Windows

(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

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

• Effectuer régulièrement des sauvegardes etcd. Le répertoire de données etcd configuré par kubeadm se trouve sur le nœud du plan de contrôle à /var/lib/etcd.

• Utiliser plusieurs nœuds de plan de contrôle. Vous pouvez consulter Options de topologie hautement disponible pour choisir une topologie de cluster offrant une haute disponibilité.

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

• Vérifiez que votre cluster fonctionne correctement avec Sonobuoy
• Consultez Mise à niveau des clusters kubeadm pour mettre à jour votre cluster avec kubeadm
• Apprenez l’utilisation avancée de kubeadm dans la documentation de référence kubeadm
• Découvrez les concepts Kubernetes et kubectl
• Consultez la page Réseau du cluster pour une liste complète des add-ons réseau de Pods
• Consultez la liste des add-ons pour explorer d’autres add-ons (logs, monitoring, politiques réseau, visualisation et contrôle du cluster)
• Configurez la gestion des logs des événements du cluster et des applications dans les Pods. Voir Architecture de logging

Feedback

• Pour les bugs, visitez le tracker GitHub kubeadm
• Pour du support, rejoignez le canal Slack #kubeadm
• Canal Slack SIG Cluster Lifecycle : #sig-cluster-lifecycle
• Informations SIG Cluster Lifecycle : https://github.com/kubernetes/community/tree/main/sig-cluster-lifecycle#readme
• Liste de diffusion SIG Cluster Lifecycle : https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle

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.

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

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

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

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.

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.

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.

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

A suivre

• Configurer un cluster hautement disponible avec kubeadm

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.

Pré-requis

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

• Stacked etcd
• External etcd

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

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.

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
   

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

É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
   

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
   

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.

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.

8 - Configuration de chaque kubelet dans votre cluster avec kubeadm

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 :

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

9 - Support dual-stack avec kubeadm

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.

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.

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

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

• Valider le dual-stack IPv4/IPv6
• En savoir plus sur le réseau de cluster Dual-stack
• Découvrir le format de configuration kubeadm configuration kubeadm