Dans la première partie de cette série dédiée à Cluster API, on a posé les éléments plutôt théoriques : la logique de réconciliation, les différents Providers, mais aussi l’intérêt de piloter son infrastructure comme on crée des Pods : de manière immuable.
Néanmoins, il reste une question importante laissée en suspens : comment crée-t-on le tout premier cluster, aussi appelé cluster de Management ou Management cluster, capable d’exécuter Cluster API ?
Bingo ! C’est ce que va couvrir cette deuxième partie !
Le rôle central du cluster de Management#
Le cluster de Management n’est pas un cluster Kubernetes comme les autres. Son but n’est pas d’héberger des applications métier, ni de rendre disponible des charges de travail de production pour vos utilisateurs. Son seul et unique but est de piloter le cycle de vie d’autres clusters Kubernetes, appelés Workload clusters.
D’un point de vue un peu plus technique, c’est lui qui contiendra toute la logique de réconciliation pour interagir avec les Providers dont on a parlé dans la partie 1 : le Core Provider, le Control Plane Provider, le Bootstrap Provider et l’Infrastructure Provider. Ce sont ces derniers qui transforment un simple fichier YAML en machines virtuelles opérationnelles, tout cela en interrogeant votre plateforme cible et en générant la configuration nécessaire au démarrage de chaque nœud.
Toute la mécanique repose sur les fameuses Custom Resource Definitions (CRD). Un objet Cluster, un autre Machine ou encore un MachineDeployment ne sont que des déclarations d’état désiré, stockées au sein de Kubernetes et donc, du cluster de Management. Chaque Provider observe en continu ces objets via sa propre boucle de réconciliation : il compare l’état désiré à l’état courant de l’infrastructure, et agit en conséquence pour réduire l’écart entre les deux. On retrouve exactement le même principe que pour un Deployment classique, sauf que l’objet réconcilié n’est plus un Pod mais une configuration de machine virtuelle.
C’est justement là que se situe la différence fondamentale avec un Workload cluster. Sur ce dernier, vous consommez des ressources Kubernetes classiques (Deployment, Service, Ingress) pour exécuter vos applications. Sur le cluster de Management, vous consommez des ressources spécifiques provenant de Cluster API pour rendre opérationnel d’autres clusters Kubernetes. Le premier permet de consommer des services, le second sert votre plateforme.
Le paradoxe de l’œuf et la poule#
“Cluster API a besoin d’un cluster Kubernetes pour créer et gérer d’autres clusters Kubernetes”
Vous trouvez ça étrange ? Je dois dire que moi aussi la première fois…
Autrement dit, comme tout se fait dans Kubernetes, il est forcément nécessaire d’avoir un cluster Kubernetes déjà prêt à l’emploi notamment pour installer l’opérateur Cluster API.
Néanmoins, ce paradoxe pose une question intéressante : comment générer ce tout premier cluster ? Effectivement, au vu de la criticité du rôle du cluster de Management, il est crucial d’avoir des fondations solides, maintenables, tout en évitant de retomber dans des installations manuelles.
L’objectif est clairement d’avoir une approche fiable et reproductible permettant de déployer cette toute première brique, avant de pouvoir lui déléguer la suite des opérations.
Quelques pistes pour aller de l’avant#
De mon point de vue, deux grandes approches se dégagent pour résoudre cette problématique d’initialisation.
La première consiste à s’appuyer sur des outils de déploiement éprouvés et très réputés, comme Kubespray ou pourquoi pas, Kubeadm, dans l’objectif de déployer ce cluster de Management. L’avantage est axé sur l’efficacité : le cluster obtenu est prêt à l’emploi rapidement. Néanmoins, il y a un inconvénient majeur : c’est que l’on introduit une rupture dans la philosophie décrite jusque maintenant. Ce cluster de Management, contrairement aux Workload clusters qu’il pilotera, ne sera pas lui-même géré par Cluster API. Il faudra donc maintenir deux façons différentes de gérer le cycle de vie de vos clusters selon qu’il s’agisse du cluster de Management ou des clusters qu’il supervise. C’est beaucoup de complexité pour pas grand chose…
La seconde piste consiste à créer un cluster éphémère, généralement en utilisant une solution comme Kind, pour amorcer l’infrastructure. On y installe temporairement l’opérateur Cluster API avec l’ensemble des Providers nécessaires, on déclare depuis ce cluster éphémère le futur cluster de Management cible, puis on migre l’ensemble des ressources Cluster API vers ce dernier une fois qu’il est prêt et fonctionnel. Cette opération de migration porte un nom précis dans l’écosystème CAPI : le pivot, notamment en utilisant la commande clusterctl move que l’on introduira plus tard.
Je recommande clairement l’option numéro 2, et pour une raison assez simple : elle permet de conserver une philosophie de bout en bout avec Cluster API. Le cluster de Management est lui-même créé et sera géré par Cluster API, exactement comme n’importe quel cluster de Workload. On garde ainsi une seule et unique méthode pour l’ensemble de la flotte Kubernetes, tout en évitant de maintenir deux procédures distinctes pour deux rôles de clusters.
L’heure de vérité : cheminement pas à pas#
C’est l’heure de mettre les mains dans le cambouis !
Avant de rentrer dans le vif du sujet, un rapide rappel des prérequis techniques, déjà évoqués dans la fin de la partie 1. Côté virtualisation, je vais utiliser Proxmox, et côté système d’exploitation et distribution Kubernetes, Talos Linux, pour les raisons de sécurité et d’immuabilité évoquées précédemment.
Les Providers#
Pour que cette combinaison fonctionne, il faut assembler ces providers façon puzzle. Chacun a un rôle bien précis et aucun n’est réellement optionnel :
CAPMOX, l’Infrastructure Provider qui dialogue directement avec l’API Proxmox VE. C’est lui qui traduit les objets
ProxmoxClusteretProxmoxMachineTemplateen appels concrets : création des machines virtuelles, injection de la configuration Talos, attribution des VM ID, gestion du placement sur les nœuds Proxmox ;CABPT, le Bootstrap Provider Talos. Là où un Bootstrap Provider classique génère habituellement du cloud-init pour une distribution Linux traditionnelle, CABPT génère une configuration machine au format propre à Talos Linux. Il produit également les secrets partagés du cluster (CA, talosconfig) nécessaires à l’authentification auprès de l’API Talos une fois les nœuds démarrés ;
CACPPT, le Control Plane Provider Talos. Il s’appuie sur CABPT pour piloter spécifiquement le cycle de vie du Control Plane, c’est-à-dire
kube-apiserver,etcdetkube-controller-manager, en orchestrant les opérations directement via l’API gRPC de Talos plutôt qu’en SSH ou en scripts d’initialisation. C’est ce Provider qui expose la ressourceTalosControlPlaneutilisée dans les manifestes.Cluster API IPAM Provider In Cluster, requis par CAPMOX pour attribuer des adresses IP statiques aux machines virtuelles depuis un pool défini dans le cluster lui-même, sans dépendre d’un serveur DHCP externe. C’est un prérequis implicite mais bloquant : sans ce Provider actif, CAPMOX ne parvient tout simplement pas à finaliser la configuration réseau des machines virtuelles qu’il provisionne.
Assez de théorie pour le moment, il est temps de commencer le déploiement !
Avant de commencer…#
L’ensemble des commandes et des fichiers YAML se trouvent au sein de ce dépôt de code GitHub, n’hésitez pas à le consulter directement :
Voici la liste des outils dont on se servira tout au long de ce processus :
- Un serveur Proxmox VE avec les droits d’administration ;
- Kind pour le cluster éphémère ;
- Un moteur de conteneurisation comme Docker ou Podman ;
- Le binaire
clusterctlpour les opérations liées à Cluster API et notamment exécuter quelques commandes pour s’assurer de la santé des clusters déployés.
De plus, deux étapes préalables sont nécessaires côté Proxmox, avant même de toucher à Cluster API :
- Un template de machine virtuelle avec la version cible de Talos Linux. Pour aller plus vite, je vous ai donné un script prêt à l’emploi à lancer dans le shell de Proxmox ;
L’idée est de télécharger une image depuis le site Talos Linux Image Factory en récupérant le format Nocloud pour en faire un template prêt à l’emploi qui sera utilisé pour créer une machine virtuelle.
En plus de la version 1.13.7 de base, j’ai ajouté l’extension qemu-guest-agent pour faire le lien avec l’hyperviseur.
- Un compte de service pour Cluster API avec un ensemble de rôles pour lui permettre d’effectuer ses actions.
Voici les quelques commandes à exécuter dans le shell de Proxmox pour l’obtenir :
pveum user add capi@pve --comment "Cluster API Service Account"
pveum acl modify / --user capi@pve --role PVEVMAdmin
pveum acl modify / --user capi@pve --role PVEDatastoreAdmin
pveum acl modify / --user capi@pve --role PVEAuditor
pveum acl modify / --user capi@pve --role PVESDNAdmin
pveum user token add capi@pve capi-token --privsep 0L’ID et le token générés par la dernière commande doivent ensuite être stockés dans différentes variables d’environnement, d’ailleurs, en parlant de ça, en voici quelques-unes à initialiser :
export PROXMOX_URL= # https://...
export PROXMOX_TOKEN_ID= # xxx@yyy!zzz
export PROXMOX_TOKEN_SECRET=Tout bon ? C’est parti !
Le cluster éphémère#
On peut désormais créer le cluster éphémère avec kind, celui qui va temporairement héberger les controllers Cluster API le temps de déployer le vrai :
kind create cluster --name ephemeral-cluster
kubectl cluster-infoPour utiliser clusterctl sans risque, il est recommandé de créer le fichier ~/.cluster-api/clusterctl.yaml pour définir les Providers et leur version :
providers:
# https://github.com/ionos-cloud/cluster-api-provider-proxmox/releases
- name: "proxmox"
type: "InfrastructureProvider"
url: "https://github.com/ionos-cloud/cluster-api-provider-proxmox/releases/v0.9.0/infrastructure-components.yaml"
# https://github.com/siderolabs/cluster-api-bootstrap-provider-talos/releases/
- name: "talos"
type: "BootstrapProvider"
url: "https://github.com/siderolabs/cluster-api-bootstrap-provider-talos/releases/v0.6.12/bootstrap-components.yaml"
# https://github.com/siderolabs/cluster-api-control-plane-provider-talos/releases/
- name: "talos"
type: "ControlPlaneProvider"
url: "https://github.com/siderolabs/cluster-api-control-plane-provider-talos/releases/v0.5.13/control-plane-components.yaml"
# https://github.com/kubernetes-sigs/cluster-api-ipam-provider-in-cluster/releases
- name: "in-cluster"
type: "IPAMProvider"
url: "https://github.com/kubernetes-sigs/cluster-api-ipam-provider-in-cluster/releases/v1.1.0/ipam-components.yaml"On initialise ensuite Cluster API et l’ensemble de la pile de Providers vue plus haut :
clusterctl init \
--core cluster-api \
--infrastructure proxmox \
--bootstrap talos \
--control-plane talos \
--ipam in-clusterOn vérifie que tout fonctionne correctement :
kubectl get pods -A | grep -E "capi|capmox|cabpt|cacppt"Chaque namespace doit contenir un Pod, ce qui montre le bon déploiement de l’ensemble des controllers ! Comme ceci :
cabpt-system cabpt-controller-manager-cfbb65994-zqggz 1/1 Running 0 98s
cacppt-system cacppt-controller-manager-9df6b5b8d-mq9hr 1/1 Running 0 98s
capi-ipam-in-cluster-system capi-ipam-in-cluster-controller-manager-85d66d4bff-xl59h 1/1 Running 0 98s
capi-system capi-controller-manager-6bc7467f69-zg6r7 1/1 Running 0 99s
capmox-system capmox-controller-manager-6f764849cc-mhprx 1/1 Running 0 98sOn crée ensuite un namespace dédié, KMGT (oui, j’ai pas beaucoup d’imagination), qui portera l’ensemble des ressources liées au futur cluster de Management. L’idée est d’avoir un cluster par namespace pour faciliter la répartition des ressources :
kubectl create namespace kmgtCAPMOX a besoin de connaître les identifiants Proxmox pour pouvoir provisionner les machines virtuelles. On les stocke dans un Secret, déposé dans le namespace capmox-system.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: proxmox-credentials
namespace: capmox-system
labels:
platform.ionos.com/secret-type: "proxmox-credentials"
stringData:
url: ${PROXMOX_URL}
token: ${PROXMOX_TOKEN_ID}
secret: ${PROXMOX_TOKEN_SECRET}
EOFAttention à ne pas oublier le label platform.ionos.com/secret-type: "proxmox-credentials" qui permet à CAPMOX de récupérer le secret.
STOP ! Avant de créer les ressources du cluster de Management, il est temps de comprendre comment tout cela s’articule.
Voici déjà un schéma sur les ressources nécessaires et leurs dépendances :
Le
Clustercontient la configuration de Kubernetes, il permet de définir les plages réseau pour lesPodsetServices, cette ressource générique permet également de lier ce qui va être utilisé pour créer l’infrastructure (ProxmoxCluster) mais aussi le type de Control Plane (TalosControlPlane) ;Le
ProxmoxClustercontient les caractéristiques du réseau physique, il y a certainement des choses à adapter en fonction de votre infrastructure. Prenez le temps de vérifier les champsipv4ConfigetdnsServerspour utiliser des plages routables par rapport à votre infrastructure. Le champschedulerHints.memoryAdjustmentà 0 permet de dépasser l’allocation mémoire de votre hyperviseur Proxmox, intéressant quand on fait un lab de ce type. Dernier point,controlPlaneEndpointest ce qui sera utilisé par Cluster API pour joindre votre cluster et vérifier si celui-ci est correctement déployé, cela correspond à la VIP de Talos Linux qui est décrite juste après ;Le
TalosControlPlaneregroupe laversionde Kubernetes qui sera utilisée, mais aussi le nombre de replicas. Il attache unProxmoxMachineTemplatepour les caractéristiques de la machine virtuelle. Enfin, lecontrolPlaneConfigpermet de surcharger la configuration de base de Talos Linux en ajoutant différents types de caractéristiques :
machine:
install:
disk: /dev/sda # Installe l'OS sur le premier disque
extraKernelArgs:
- net.ifnames=0 # Permet d'éviter le renommage des interfaces
network:
interfaces:
- deviceSelector:
busPath: "0*" # Sélectionne la première interface valide pour désactiver le DHCP
dhcp: false
vip: # La VIP est un élément clé de Talos Linux, elle permet de garantir la haute disponibilité en basculant de machine en machine
ip: 192.168.1.150
kubelet:
extraArgs:
cloud-provider: external # Permet d'installer un Cloud Controller Manager à posteriori
rotate-server-certificates: true # Active la rotation des certificats avec le Cloud Controller Manager
features:
kubernetesTalosAPIAccess: # Utile pour le Cloud Controller Manager, ce sera expliqué un peu plus tard
enabled: true
allowedRoles:
- os:reader
allowedKubernetesNamespaces:
- kube-system
cluster:
network:
cni:
name: none # Désactive l'installation de la couche réseau pour en installer une proprement avec Helm
proxy:
disabled: true # Utile pour Cilium sans kube-proxy
allowSchedulingOnControlPlanes: true # Permet d'avoir des Pods sur le Control Plane
externalCloudProvider:
enabled: true # Permet d'installer un Cloud Controller Manager à posterioriÇa fait pas mal de choses… Pour en savoir plus sur la VIP, je vous invite à consulter la documentation officielle.
- Dernier point, le
ProxmoxMachineTemplateici dédié aux Control Planes, permet de définir pas mal de caractéristiques sur la machine virtuelle : cpu, mémoire, réseau, espace disque, mais surtout le template avectemplateIDqui a été créé avec le script. D’autres points nécessitent une attention particulière :
checks:
skipCloudInitStatus: true # Désactive l'utilisation de Cloud Init, inutile pour Talos Linux
skipQemuGuestAgent: false # Permet d'attendre le QEMU agent pour valider le bon fonctionnement de la machine virtuelle
metadataSettings:
providerIDInjection: true # Injecte le providerID dans les métadonnées de la machine virtuelleTout compris ? Reste à créer cet ensemble de ressources :
kubectl -n kmgt create -f ./clusters/kmgt/config.yamlLes providers CAPMOX, CABPT et CACPPT prennent alors le relais pour provisionner les machines virtuelles et générer la configuration Talos nécessaire.
Vous pouvez suivre la création de chaque ressource avec les commandes dédiées. Même si j’ai une petite préférence pour celle avec clusterctl pour avoir une vue synthétique !
kubectl -n kmgt get cluster
kubectl -n kmgt get machines
kubectl -n kmgt get proxmoxmachines
kubectl -n kmgt get taloscontrolplanes
clusterctl -n kmgt describe cluster kmgtUne fois les machines à l’état Ready, on récupère à la fois le kubeconfig du nouveau cluster et son talosconfig, ce dernier permettant de dialoguer directement avec l’API Talos de chaque nœud.
cd clusters/kmgt
kubectl -n kmgt get secrets kmgt-kubeconfig -o=jsonpath='{.data.value}' | base64 -d > ./kubeconfig.yaml
kubectl -n kmgt get secrets kmgt-talosconfig -o=jsonpath='{.data.talosconfig}' | base64 -d > ./talosconfig.yaml
cd -
export KUBECONFIG=./clusters/kmgt/kubeconfig.yamlQuelques minutes d’attente plus tard… Un nœud sauvage apparaît !
kubectl get nodesNAME STATUS ROLES AGE VERSION
kmgtcp-l8vsk NotReady control-plane 3s v1.36.2NotReady ??? Mais pourquoi ?
À ce stade, le cluster existe, mais il lui manque encore le réseau de Pods et l’intégration avec Proxmox. On installe donc Cilium comme CNI, ainsi que le Cloud Controller Manager de Talos, qui synchronise les métadonnées Proxmox notamment le fameux providerID, indispensable pour finaliser le processus de Cluster API.
C’est notamment le message que vous devriez obtenir en faisant clusterctl -n kmgt describe cluster kmgt depuis le cluster éphémère :
NodeHealthy: Waiting for a Node with spec.providerID
proxmox://xxx-xxx-xxx to existAllez, on passe à l’installation :
helm install \
cilium \
oci://quay.io/cilium/charts/cilium \
--version 1.19.6 \
--namespace kube-system \
--values ./clusters/kmgt/charts/cilium.yaml \
--wait
helm install \
talos-cloud-controller-manager \
oci://ghcr.io/siderolabs/charts/talos-cloud-controller-manager \
--version 0.5.5 \
--namespace kube-system \
--values ./clusters/kmgt/charts/cloud-controller-manager.yaml \
--waitLes fichiers values des charts correspondent aux besoins pour Cilium afin de s’exécuter sur Talos Linux. Quant au talos-cloud-controller-manager, deux controllers sont uniquement activés : cloud-node pour les métadonnées et node-csr-approval pour le renouvellement des certificats.
D’ailleurs c’est lui qui a besoin de ce bout de configuration dans le TalosControlPlane :
features:
kubernetesTalosAPIAccess:
enabled: true
allowedRoles:
- os:reader
allowedKubernetesNamespaces:
- kube-systemSans ça, il n’y a pas de compte de service avec les permissions suffisantes pour lire les ressources du cluster.
Un dernier kubectl get nodes permet de confirmer que le nœud est bien passé à l’état Ready.
kubectl get nodesNAME STATUS ROLES AGE VERSION
kmgtcp-l8vsk Ready control-plane 12m v1.36.2Pas mal non ?
Configurer le cluster de Management#
Le cluster de Management existe, mais il est vide. Plutôt que de répéter un clusterctl init classique, on passe cette fois par le Cluster API Operator, qui offre une façon déclarative pour configurer les Providers avec Helm. Cela permet d’avoir un historique en cas de problème et offre la possibilité de revenir en arrière facilement !
Cert Manager est un prérequis pour l’opérateur, on commence donc par l’installer :
helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.21.0 \
--set crds.enabled=true \
--waitPuis, on installe ensuite le Cluster API Operator lui-même :
helm repo add cluster-api-operator https://kubernetes-sigs.github.io/cluster-api-operator
helm repo update
helm install \
cluster-api-operator \
cluster-api-operator/cluster-api-operator \
--version 0.28.0 \
--namespace capi-operator-system \
--create-namespace \
--values ./clusters/kmgt/charts/cluster-api-operator.yaml \
--waitSans grande surprise, les Providers sont les mêmes mais dans un format différent cette fois au sein du fichier clusters/kmgt/charts/cluster-api-operator.yaml :
infrastructure:
proxmox:
namespace: capmox-system
createNamespace: true
version: v0.9.0
configSecret:
name: proxmox-credentials
fetchConfig:
url: https://github.com/ionos-cloud/cluster-api-provider-proxmox/releases/v0.8.1/infrastructure-components.yaml
bootstrap:
talos:
namespace: cabpt-system
createNamespace: true
version: v0.6.12
fetchConfig:
url: https://github.com/siderolabs/cluster-api-bootstrap-provider-talos/releases/v0.6.11/bootstrap-components.yaml
[...]Comme sur le cluster éphémère, CAPMOX a besoin des identifiants Proxmox pour fonctionner. On recrée donc le même Secret que précédemment, cette fois dans le namespace capmox-system du cluster de Management.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: proxmox-credentials
namespace: capmox-system
labels:
platform.ionos.com/secret-type: "proxmox-credentials"
stringData:
url: ${PROXMOX_URL}
token: ${PROXMOX_TOKEN_ID}
secret: ${PROXMOX_TOKEN_SECRET}
EOFOn vérifie enfin que l’ensemble des Pods des namespaces Cluster API sont bien démarrés sur ce cluster :
kubectl get pods -A | grep -E "capi|capmox|cabpt|cacppt"Le cluster de Management est prêt à l’emploi, c’est le moment de basculer !
Le pivot#
La partie sur laquelle on va se concentrer ici, consiste à migrer les ressources Kubernetes depuis le cluster éphémère, c’est ce que l’on appelle : le pivot.
On recrée d’abord le namespace kmgt sur le cluster cible, à l’identique de celui du cluster éphémère :
kubectl create namespace kmgtLa migration se fait ici en deux temps, via un répertoire temporaire, plutôt qu’en une seule commande clusterctl move directe entre les deux clusters. Pourquoi ? Car la façon dont la commande clusterctl init et l’opérateur Cluster API gèrent les Providers n’est pas du tout la même malheureusement, c’est une limitation connue.
On repasse d’abord sur le contexte du cluster éphémère pour exporter les ressources du namespace kmgt vers un répertoire temporaire :
unset KUBECONFIG
mkdir tmp
clusterctl move --namespace kmgt --to-directory tmp/On bascule ensuite sur le cluster de Management pour y réimporter ces mêmes ressources :
export KUBECONFIG=./clusters/kmgt/kubeconfig.yaml
clusterctl move --namespace kmgt --from-directory tmp/C’est le moment de vérifier que tout est bien migré :
kubectl -n kmgt get cluster
kubectl -n kmgt get machines
kubectl -n kmgt get proxmoxmachines
kubectl -n kmgt get taloscontrolplanesPareil avec la commande clusterctl :
clusterctl -n kmgt describe cluster kmgtNAME REPLICAS AVAILABLE READY UP TO DATE STATUS REASON SINCE MESSAGE
Cluster/kmgt 1/1 1 True Available 52s
├─ClusterInfrastructure - ProxmoxCluster/kmgt True InfoReported 55s
└─ControlPlane - TalosControlPlane/kmgtcp 1/1 1 True NoReasonReported 54s
└─Machine/kmgtcp-l8vsk 1 1 1 0 True Ready 53sTout est parfait !
Ultime étape, couper définitivement le cordon avec le cluster éphémère :
kind delete cluster --name ephemeral-clusterEt voilà comment donner naissance à un cluster de Management tout beau, tout propre.
Opérations Day 2 et gestion du cycle de vie#
Le cluster de Management est opérationnel ! Reste maintenant la question du cycle de vie et de sa maintenance. En effet, il y a deux choses à distinguer : mettre à jour la partie Talos Linux côté image de machine virtuelle, mais aussi Kubernetes.
Le plus simple : la montée de version Kubernetes, il suffit de remplacer la version dans le fichier YAML dédié :
apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
kind: TalosControlPlane
metadata:
name: kmgtcp
namespace: kmgt
spec:
version: v1.36.2 # C'est ici que l'on viendra déclencher la mise à jour
[...]Par contre pour Talos Linux, cela demande de créer un nouveau MachineTemplate avec le nouvel identifiant du template comprenant la version cible de celui-ci, car ce dernier est immuable :
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: ProxmoxMachineTemplate
metadata:
name: kmgtcp-XXX # Nom unique pour le template
namespace: kmgt
spec:
template:
spec:
templateID: XXX # ID du template cible dans Proxmox
[...]Sans oublier de changer la référence dans le TalosControlPlane :
apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
kind: TalosControlPlane
metadata:
name: kmgtcp
namespace: kmgt
spec:
[...]
infrastructureTemplate:
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: ProxmoxMachineTemplate
name: kmgtcp-XXX # Référence à faire évoluer lors des mises à jour
namespace: kmgtEn ce qui concerne le cluster de Management, deux stratégies s’offrent à vous :
La première est le self update : le cluster de Management se met à jour lui-même, en appliquant les mêmes principes de rolling update que pour n’importe quel Workload cluster qu’il gère. C’est cohérent avec la philosophie Cluster API évoquée plus haut, mais cela demande une vigilance particulière puisque les controllers de l’opérateur pilotant l’opération, s’exécutent sur l’infrastructure qu’ils sont en train de faire évoluer. L’opérateur Cluster API doit donc être configuré en mode haute disponibilité et le cluster de Management doit lui-même disposer d’un nombre de nœuds permettant la résilience de ce dernier (3 voire 5) pour rebasculer les composants Cluster API durant la mise à jour.
La seconde est une approche Blue/Green : on provisionne un nouveau cluster de Management à jour, en parallèle de l’ancien, puis on effectue un nouveau pivot pour transférer l’ensemble des ressources Cluster API vers ce nouveau cluster, avant de démanteler l’ancien. Cette approche réduit le risque suite à une coquille dans la configuration du cluster de Management, au prix d’une complexité opérationnelle supplémentaire et d’une infrastructure temporairement dupliquée.
C’est clairement à vous de voir quel est le chemin que vous souhaitez prendre pour assurer la maintenance de ce dernier.
Dans l’objectif de limiter le risque de perte d’un cluster à la suite d’une mise à jour, n’oubliez pas d’activer les backups notamment dans Proxmox ou dans l’hyperviseur de votre choix.
De plus, si vous souhaitez extraire les données d’etcd avant cette opération critique, Siderolabs met à disposition talos-backup pour sauvegarder dans un S3 distant tout en permettant de chiffrer les données avec une clé age. Essentiel dans des contextes de production !
Dernier point à ne pas oublier : la mise à jour de l’opérateur Cluster API et de l’ensemble des Providers suit également son propre cycle, indépendant de celui des clusters qu’ils gèrent. Que ce soit via le chart officiel ou avec la commande clusterctl upgrade, il est fortement recommandé de consulter les notes de version de chaque Provider avant toute montée en version, certains changements pouvant nécessiter des ajustements dans vos fichiers YAML existants.
Et maintenant ? Place aux Workloads clusters !#
À ce stade, les fondations sont posées. On dispose d’un cluster de Management entièrement piloté par Cluster API, créé selon un processus totalement reproductible grâce au mécanisme de pivot, et dont le cycle de vie peut être entièrement géré sans utiliser d’autres solutions ou outils.
Reste la partie la plus concrète : déployer et gérer des clusters de Workload, qui se chargeront d’héberger réellement vos applications.
Ce sera l’objet de la troisième partie de cette série, où l’on couplera Cluster API à Argo CD pour automatiser de bout en bout le déploiement de ces clusters dits de Workload, avec une approche totalement GitOps.
