Jump to content

# Kubeadm (Français)

From ArchWiki

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

Related articles

- Kubernetes

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

Il permet de configurer kubelet — interface entre la machine hôte et l’amas Kubernetes — et d’installer kube-apiserver, kube-controller-manager, kube-scheduler et etcd statiquement sur le nœud maître.

## 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/manifests. 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

### Nœud Maître

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. Ces fichiers peuvent être modifiés pour mettre à jour les pods correspondants. À 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.

## Dépannage

Les erreurs réseau qui ne concernent pas api-server et les autres composants du control-plane sont causées par un dysfonctionnement du réseau entre les machines ou du plugin CNI utilisé. Kubeadm ne peut rien faire.

### Control Plane

Les pods du control-plane ne sont pas enregistrés dans etcd et ne sont pas contrôlés par le controller-manager. Si les fichiers de définition sont absents ou invalides, ils peuvent être régénérés par kubeadm sur le nœud maître avec la commande `kubeadm init phase control-plane` ou `kubeadm upgrade node control-plane`.

### Kubelet

- La configuration /var/lib/kubelet/config.yaml est invalide
- kubelet ne communique pas avec cri-o/containerd

Sa configuration peut être mise à jour depuis la définition commune stockée dans la ConfigMap kube-system/kubelet-config. La commande `kubeadm upgrade node phase kubelet-config` récupère la configuration et l’installe sur la machine. Il n’est pas nécessaire que le nœud soit fonctionnel pour effectuer cette action.

Pour changer de Container Runtime Interface, le nœud doit être détruit puis créé à nouveau.

### Renouvellement des certificats

- Kubectl ne peut pas se connecter à l’API
- Les pods ne sont pas détruits et les nouveaux ne sont pas créés. Les deployments ne démarrent pas.

Le controller-manager ne parvient pas à communiquer avec l’API.

Les certificats auto-signés utilisés pour les communications internes sont générés par kubeadm avec une période de validité de 365 jours par défaut. Ils sont automatiquement renouvelés si besoin par `kubeadm upgrade`.

Les certificats de connexion sont également à renouveler. Le fichier /etc/kubernetes/admin.conf est mis à jour avec les autres certificats.

Pour forcer le redémarrage des pods du control-plane, il faut déplacer les fichiers hors du dossier /etc/kubernetes/manifests, attendre que kubelet détruise les pods correspondants, puis remettre les fichiers à leurs places.

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

Category:

- Virtualization (Français)

Hidden categories:

- Pages or sections flagged with Template:Style
- Pages or sections flagged with Template:Expansion

Kubeadm (Français)
Add topic