Talos Linux : Linux designed for Kubernetes

Talos Linux est une Linux conçue pour Kubernetes - sécurisée, immuable et minimale.

• Prend en charge les plateformes cloud, bare metal et les plateformes de virtualisation.
• Toute la gestion du système se fait via une API. Pas de SSH, de shell ou de console
• Prêt pour la production : prend en charge certains des plus grands clusters Kubernetes au monde.
• Projet open source de l'équipe de Sidero Labs

Introduction

Créer un cluster Kubernetes à partir de zéro peut rapidement devenir une tâche complexe. Les procédures varient souvent d'une version à l'autre, rendant certaines méthodes obsolètes avec le temps. Bien qu'ANSIBLE permette d'automatiser une partie du processus, ses limites se font vite sentir, notamment lorsqu'on vise un haut niveau d'automatisation. Monter un cluster Kubernetes est déjà un défi, mais cela devient encore plus ardu lorsqu'il faut gérer la mise à jour des nœuds. C’est dans ce contexte qu’intervient une distribution Linux spécialement conçue pour Kubernetes. Avec elle, plus besoin de SSH, ni de playbooks ANSIBLE : les mises à jour s'effectuent simplement en changeant l'ISO. Le système fonctionne en live, avec un disque dédié pour la persistance des données.

L'object de cet article est de :

1. Créer un template cloudinit de Talos Linux sur Proxmox
2. Démonstration de la création d'un cluster

Contrairement à Linux traditionnel, Talos Linux n'est pas configuré en se connectant au serveur par SSH et en lançant des commandes. Au lieu de cela, l'état complet de la machine est défini par un fichier de configuration de la machine qui est transmis au serveur. Cela permet de gérer les machines de manière déclarative et se prête à GitOps et aux paradigmes opérationnels modernes. L'état d'une machine est entièrement défini par le fichier de configuration de la machine et peut être reproduit à partir de celui-ci.

Préparation

Génération d'un ISO pour Proxmox avec qemu-guest-agent

Aller sur le site suivant : factory.talos.dev

Puis :

On selectionne notre version :

Bien selectionner "NoCloud" :

Notre architecture "amd64" :

Cette partie est importante, on ajoute les "drivers" ou autre :

Récupérer l'URL de l'ISO pour Proxmox :

Téléchargement de l'ISO

On va télécharger l'ISO sur notre Proxmox :

Création du template

Voici ma configuration :

To Do : Vérifier l'extension du disque au niveau de l'OS invité se fait comme sur cloudinit-debian.

Le récapitulatif :

Il faut ajouter le disque "Cloud Init" :

On édite le "Boot Order" pour démarrer sur l'ISO :

Vérification

1. Clonner la VM créer
2. Editer le cloudinit afin de SET une @IP statique
3. Lancer la VM

Le résultat attendu est le suivant. Si atteint, alors la VM template en Convert to template.

Initialisation d'un premier cluster

Clonner 6 VM du template de "cloudinit-talos-1.9.2".

Le plan d'adressage sera le suivant :

Subnet : 172.16.30.0/24

• Pour les masters : 10 à 22
• Pour les workers : 20 à 22

Installer talosctl

L'outil talosctl sert d'implémentation de référence pour l'API Talos, mais il gère également de nombreuses commodités pour l'utilisation de Talos et de ses clusters.

Comme kubectl, talosctl utilise le concept de contextes de configuration, de sorte que n'importe quel nombre de clusters Talos peut être géré avec un seul fichier de configuration. Il est également livré avec un outil intelligent pour gérer la fusion de nouveaux contextes dans la configuration. L'opération par défaut est une fusion non destructive, où si un contexte du même nom existe déjà dans le fichier, le contexte à ajouter est renommé en ajoutant un numéro d'index. Il est également possible d'écraser le contexte à la place.

Les points d'extrémité sont les points d'extrémité de communication avec lesquels le client communique directement. Il peut s'agir d'équilibreurs de charge, de noms d'hôtes DNS, d'une liste d'adresses IP, etc. Si plusieurs points d'extrémité sont spécifiés, le client va automatiquement équilibrer la charge et basculer entre eux. Il est recommandé que ces points pointent vers l'ensemble des nœuds du plan de contrôle, soit directement, soit par l'intermédiaire d'un équilibreur de charge.

Chaque point d'extrémité acheminera automatiquement les demandes destinées à un autre nœud par son intermédiaire, de sorte qu'il n'est pas nécessaire de modifier la configuration du point d'extrémité simplement parce que vous souhaitez communiquer avec un nœud différent au sein de la grappe.

Les points d'extrémité doivent cependant être membres du même cluster Talos que le nœud cible, car ces connexions proxy répondent à une authentification basée sur un certificat.

Le nœud est le nœud cible sur lequel vous souhaitez effectuer l'appel API. Bien que vous puissiez configurer le nœud cible (ou même un ensemble de nœuds cibles) dans le fichier de configuration 'talosctl', il est recommandé de ne pas le faire, mais de déclarer explicitement le(s) nœud(s) cible(s) en utilisant le paramètre de ligne de commande -n ou --nodes.

Suivre la documentation suivante : www.talos.dev

talosctl initialiser le cluster

Pour générer les configurations des machines d'un cluster, exécutez cette commande sur le poste de travail où vous avez installé talosctl :

talosctl gen config <cluster-name> <cluster-endpoint>

cluster-name est un nom arbitraire, utilisé comme étiquette dans la configuration de votre client local. Il doit être unique dans la configuration de votre poste de travail local.

cluster-endpoint est le point de terminaison Kubernetes que vous avez construit à partir de l'adresse IP ou du nom DNS du nœud du plan de contrôle ci-dessus. Il doit s'agir d'une URL complète, avec https:// et le port.

Dans notre cas :

talosctl gen config talos-demo https://172.16.30.10:6443

Sortie :

[administrator@pc-administration talos-test]$ talosctl gen config talos-demo https://172.16.30.10:6443
generating PKI and tokens
Created /home/administrator/DEV/talos-test/controlplane.yaml
Created /home/administrator/DEV/talos-test/worker.yaml
Created /home/administrator/DEV/talos-test/talosconfig
[administrator@pc-administration talos-test]$ tree ./
./
├── controlplane.yaml
├── talosconfig
└── worker.yaml

0 directories, 3 files
[administrator@pc-administration talos-test]$

Lorsque vous exécutez cette commande, trois fichiers sont créés dans votre répertoire courant :

• controlplane.yaml
• worker.yaml
• talosconfig

Les fichiers .yaml sont des Configs de machine : ils décrivent tout, du disque sur lequel Talos doit être installé, aux paramètres réseau. Le fichier controlplane.yaml décrit également comment Talos doit former un cluster Kubernetes.

Le fichier talosconfig est votre fichier de configuration client local, utilisé pour se connecter et authentifier l'accès au cluster.

Pour appliquer les Configs Machine, vous devez connaître les adresses IP des machines.

Documentation : ici

Une fois que vous avez l'adresse IP, vous pouvez appliquer la configuration correcte. Appliquez le fichier controlplane.yaml au nœud du plan de contrôle et le fichier worker.yaml à tous les nœuds de travail.

L'option --insecure est nécessaire car l'infrastructure PKI n'a pas encore été mise à la disposition du nœud. Remarque : la connexion sera cryptée, mais non authentifiée.

Sur le master-00 :

talosctl apply-config --insecure --nodes 172.16.30.10 --file controlplane.yam

Sur la console vous devriez voir ceci :

Sur les noeuds master-01 et master-02 :

talosctl apply-config --insecure --nodes 172.16.30.11 --file controlplane.yam

La sortie :

talosctl apply-config --insecure --nodes 172.16.30.12 --file controlplane.yam

La sortie :

Sur les noeuds workers worker-00 worker-01 et worker-02 :

talosctl apply-config --insecure --nodes 172.16.30.20 --file worker.yaml

talosctl apply-config --insecure --nodes 172.16.30.21 --file worker.yaml

talosctl apply-config --insecure --nodes 172.16.30.22 --file worker.yaml

Lors de la prise en main, une erreur fréquente consiste à référencer un contexte de configuration pour un cluster différent, ce qui entraîne des échecs d'authentification ou de connexion. Il est donc recommandé de passer explicitement dans le fichier de configuration pendant que l'on se familiarise avec Talos Linux.

Le démarrage de votre cluster Kubernetes avec Talos est aussi simple que d'appeler talosctl bootstrap sur votre nœud de plan de contrôle :

talosctl bootstrap --nodes 172.16.30.10 --endpoints 172.16.30.10 --talosconfig=./talosconfig

L'opération debootsrap ne doit être appelée qu'UNE SEULE fois sur un SEUL nœud de plan de contrôle. (Si vous avez plusieurs nœuds de plan de contrôle, le nœud sur lequel vous lancez la commande de bootsrap n'a pas d'importance).

A ce stade, Talos va former un cluster etcd, et démarrer les composants du plan de contrôle Kubernetes.

Après quelques instants, vous pourrez télécharger votre configuration client Kubernetes et démarrer :

talosctl kubeconfig --nodes 172.16.30.10 --endpoints 172.16.30.10 --talosconfig=./talosconfig

Vous devriez maintenant pouvoir vous connecter à Kubernetes et voir vos nœuds :

kubectl get nodes

La sortie :

NAME        STATUS   ROLES           AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION   CONTAINER-RUNTIME
master-00   Ready    control-plane   3m40s   v1.32.0   172.16.30.10   <none>        Talos (v1.9.2)   6.12.9-talos     containerd://2.0.2
master-01   Ready    control-plane   3m41s   v1.32.0   172.16.30.11   <none>        Talos (v1.9.2)   6.12.9-talos     containerd://2.0.2
master-02   Ready    control-plane   3m39s   v1.32.0   172.16.30.12   <none>        Talos (v1.9.2)   6.12.9-talos     containerd://2.0.2
worker-00   Ready    <none>          3m45s   v1.32.0   172.16.30.20   <none>        Talos (v1.9.2)   6.12.9-talos     containerd://2.0.2
worker-01   Ready    <none>          3m39s   v1.32.0   172.16.30.22   <none>        Talos (v1.9.2)   6.12.9-talos     containerd://2.0.2
worker-02   Ready    <none>          3m44s   v1.32.0   172.16.30.21   <none>        Talos (v1.9.2)   6.12.9-talos     containerd://2.0.2

Cheatsheet

export TALOSCONFIG="talosconfig"
talosctl config endpoint 172.16.30.10
talosctl config node 172.16.30.10