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.