Kubernetes v1.11 [stable]Le cycle de vie de l’outil CLI kubeadm est découplé du kubelet, qui est un daemon s’exécutant sur chaque nœud au sein du cluster Kubernetes. L’outil CLI kubeadm est exécuté par l’utilisateur lors de l’initialisation ou de la mise à niveau de Kubernetes, tandis que le kubelet fonctionne en permanence en arrière-plan.
Étant donné que le kubelet est un daemon, il doit être géré par un système d’initialisation (init system) ou un gestionnaire de services. Lorsque le kubelet est installé via des paquets DEB ou RPM, systemd est configuré pour gérer le kubelet. Vous pouvez utiliser un autre gestionnaire de services, mais vous devrez le configurer manuellement.
Certaines configurations du kubelet doivent être identiques sur tous les kubelets du cluster, tandis que d’autres doivent être définies individuellement pour chaque kubelet afin de s’adapter aux caractéristiques spécifiques d’une machine (comme le système d’exploitation, le stockage et le réseau). Vous pouvez gérer la configuration des kubelets manuellement, mais kubeadm fournit désormais un type d’API KubeletConfiguration pour
centraliser la gestion des configurations du kubelet.
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.
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.
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.
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.
kubeadm initLorsque 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.
kubeadm joinLorsque 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.
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.
/etc/kubernetes/bootstrap-kubelet.conf,
mais il n’est utilisé que si /etc/kubernetes/kubelet.conf n’existe pas./etc/kubernetes/kubelet.conf./var/lib/kubelet/config.yaml.KUBELET_KUBEADM_ARGS est chargé depuis /var/lib/kubelet/kubeadm-flags.env.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.Les paquets DEB et RPM fournis avec les versions de Kubernetes sont :
| Nom du paquet | Description |
|---|---|
kubeadm | Installe l’outil CLI /usr/bin/kubeadm et le fichier drop-in du kubelet. |
kubelet | Installe le binaire /usr/bin/kubelet. |
kubectl | Installe le binaire /usr/bin/kubectl. |
cri-tools | Installe le binaire /usr/bin/crictl depuis le dépôt cri-tools. |
kubernetes-cni | Installe les binaires /opt/cni/bin depuis le dépôt plugins. |