Kubeadm (Français)

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: #Requis devrait probablement être renomé en "Installation", des liens sont dans les titres de sections, probablement d'autres détails mineurs à ajuster. (Discuss in Talk:Kubeadm (Français))

This article or section needs expansion.

Reason: Article en cours de rédaction (Discuss in Talk:Kubeadm (Français))

Kubeadm est un outil pour installer et configurer un nœud Kubernetes en utilisant la distribution officielle.

Requis

Le service kubelet doit être installé et démarré sur chaque ordinateur participant à la grappe Kubernetes. Il permet le démarrage des composants de contrôle à partir des définitions entreposées dans le dossier /etc/kubernetes/manifest. Il est le contrôleur local et communique avec l’API pour recevoir les instructions de création et destruction de Pod.

Le programme kubeadm doit être installé sur chaque ordinateur pour l’installation, la mise à jour des composants ou un changement de la configuration. La configuration est sauvegardée directement dans Kubernetes et kubeadm permet de la récupérer et de l’installer sur chaque machine.

Configuration

La configuration des composants utilise un fichier de déclaration lu par kubeadm pour générer des fichiers de configuration et les arguments de lancement des services (kubelet). Tous les « documents » YAML peuvent être réunis dans un même fichier, séparés par « --- », pour simplifier les commandes à un seul paramètres --config=options.yaml.

ClusterConfiguration

Il faut choisir deux plages d’adresses IP que les composants Kubernetes pourront utiliser pour communiquer entre eux. Ces plages d’adresses ne doivent pas se superposer à d’autres plages d’adresses utilisées sur le réseau. Les Pods recevront une adresse parmi celles fournies par controllerManager.extraArgs.cluster-cidr qui définit un sous-ensemble de podSubnet.

serviceSubnet et podSubnet: sont des plages d’adresses séparées par des virgules.
dnsDomain: est le domaine DNS associé à la grappe Kubernetes. Il est alimenté automatiquement mais doit avoir un nom dissociable des DNS existants.
apiServer.certSANs: permet d’ajouter le nom DNS de la machine contenant le serveur d’API à son certificat. Cela simplifie la configuration des outils voulant communiquer avec l’API Kubernetes.

cluster.yaml

clusterName: "Kube"
networking:
  serviceSubnet: "10.84.0.0/16"
  podSubnet: "10.85.0.0/16"
  dnsDomain: "cluster.local"
controllerManager:
  extraArgs:
    allocate-node-cidrs: true
    cluster-cidr: "10.85.0.0/16"
    node-cidr-mask-size-ipv4: "24"

Tip: Un réseau IPv4 et un réseau IPv6 peuvent coexister à condition qu’une plage d’adresse soit disponible pour chacun.

Pour un réseau privilégiant IPv6, les subnet doivent contenir en premier une plage IPv6 et tous les services utiliser bind-address: '::'. Une configuration complète est disponible ici.

KubeletConfiguration

Ce fichier contient les options commune à tous les kubelet de la grappe. Elle est publiée sur etcd pour être accessible de chaque nœud. En cas de modification, il faut manuellement (kubeadm) installer la nouvelle configuration sur chaque machine.

Les options importantes sont

failSwapOn (note): (bool) autorise la présence de swap. La présence de swap fausse la mesure de la mémoire utilisée par les processus.
systemReserved: mesure la quantité de ressources système en moins utilisable par Kubernetes.
kubeReserved: mesure la quantité de ressources restantes réservées aux composants centraux de Kubernetes.

kubelet.yaml

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
systemReserved:
  cpu: "1"
  memory: "1G"
kubeReserved:
  cpu: "500m"
  memory: "500M"

Pour un réseau privilégiant IPv6, les options suivantes doivent contenir une adresse IPv6 :

address: "::"
clusterDNS: [...] est une liste d’adresses appartenant à l’intervalle définie par cluster-cidr.
healthzBindAddress: "::1" sert d’entrée dans un Pod pour les tests de réponse du service.

Warning: Il est possible qu’un service ne soit pas compatible IPv6. Si healthzBindAddress est une adresse IPv6 alors le Pod sera toujours considéré comme anormal car sans connexion établie. Mais la plupart des services écoutent sur les deux types d’IP en même temps.

Démarrage Kubernetes

Premier Nœud

Le premier nœud installe les composants du control-plane (apiserver, etcd, controler-manager, scheduler), génère des certificats x509 pour les communication et démarre les premiers modules dans Kubernetes (coredns, kube-proxy). Suivre ce tutoriel pour utiliser ses propres certificats.

La commande kubeadm init ne s’utilise que sur le premier nœud et se divise en plusieurs phases. Par défaut toutes les phases sont réalisées dans l’ordre et sans modifier les fichiers déjà présents sur la machine. Il est possible de demander une phase en particulier mais elle échouera si ses dépendances ne sont pas complètes.

InitConfiguration

Le groupe nodeRegistration contient les options faisant le lien entre un nœud, son matériel et le monde extérieur.

criSocket: (ex unix:///run/crio/crio.sock) dépend du contrôleur de conteneur installé sur la machine. Ce sera généralement cri-o et containerd.
name: est le nom donné à ce nœud. Chaque nœud doit posséder un nom différent.
kubeletExtraArgs: complète KubeletConfiguration avec les options individuelles, comme node-ip qui est la liste des adresses publiques à lesquelles joindre ce nœud.

Tip: Certains CNI comme cilium proposent de remplacer kube-proxy. Pour ne pas ajouter kube-proxy durant l’installation, il suffit d’ajouter « kube-proxy » à la liste skipPhases

Autres Nœuds

Pour ajouter des nœuds à la grappe, ils doivent mettre en place une relation de confiance à double sens avec le control-plane. La méthode du jeton utilise un jeton temporaire créé par le maître que le nouvel arrivant doit présenter pour prouver que l’administrateur a bien accès à l’API Kubernetes. Pour vérifier que la première connexion n’a pas été détournée, kubeadm join utilise le hash de la clé publique utilisée par le maître.

La commande kubeadm token create, utilisée depuis une session avec accès à l’API, génère un jeton. La commande kubeadm join --discovery-token=<token> --discovery-token-ca-cert-hash="<hash-type>:<hex-encoded-value>" <master-IP>:6443 génère les certificats du nœud, configure kubelet et le démarre puis l’enregistre dans la grappe.

Personnalisation du control-plane

Kubeadm installe les définitions pour kube-apiserver, kube-controller-manager et kube-scheduler dans le dossier /etc/kubernetes/manifests du nœud principal. À la moindre modification, le service kubelet éteint et redémarre les Pods correspondants pour appliquer les modifications.

La méthode conseillée pour appliquer des modifications est d’utiliser Kubeadm avec des correctifs. Ces correctifs peuvent être appliqués à l’initialisation d’un nœud ou pendant sa mise à jour: kubeadm upgrade apply --patches PATCHES. PATCHES est un dossier contenant des fichiers de correctifs nommés selon le schéma target[suffix][+patchtype]. Sans nécessités particulières, ces fichiers peuvent être nommés directement avec le nom du composant à modifier.

kube-apiserver.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
    - name: kube-apiserver
      env:
        - name: GOMAXPROCS
          valueFrom:
            resourceFieldRef:
              resource: limits.cpu
        - name: GOMEMLIMIT
          valueFrom:
            resourceFieldRef:
              resource: requests.memory
      resources:
        requests:
          cpu: "100m"
          memory: "600Mi"
        limits:
          cpu: "4"
          memory: "700Mi"
      readinessProbe:
        periodSeconds: 15

Cet exemple diminue la fréquence du test readiness, réserve et limite la mémoire et informe le programme Go de ces nouvelles limitations. GOMEMLIMIT est une limite douce.

Outils supplémentaires

Les composants de base Kubernetes ne gèrent que l’orchestration et le démarrage des Pods. Il faut ensuite installer un certain nombre de composants supplémentaires dans Kubernetes pour un fonctionnement complet.

Réseau

La communication réseau entre Pods et entre Nodes nécessite des programmes et configurations supplémentaires sur chaque machine. Tout cela est géré par le Container Runtime Interface' comme Cilium, Calico ou Flannel.

Kubernetes propose une configuration unifiée pour les Ingress (obsolète) et les Gateway. Il existe de nombreux programme pour réaliser ces tâches, dont traefik, ingress, Cilium, envoy.

GPUs

L’utilisation des GPUs comme ressource matérielle au même titre que les CPUs et la RAM n’est pas supportée par le Kubernetes Scheduler basique. Cette ressource est contrôlée par un device-plugin (voir cette documentation).