Bootstrap Kubernetes

Une fois Talos installé, l’étape suivante c’est de bootstrapper Kubernetes. C’est le moment où ton serveur devient un cluster.

Le bootstrap

Avec Talos, le bootstrap c’est une commande :

# Configurer talosctl pour parler au node
export TALOSCONFIG=./talosconfig

# Vérifier que le node est prêt
talosctl -n 192.168.1.100 health

# Bootstrap le cluster
talosctl -n 192.168.1.100 bootstrap

Tu lances ça et… tu attends. Talos initialise etcd, démarre le control plane, configure tout.

Ça prend 2-3 minutes. Quand c’est fini, t’as un cluster Kubernetes fonctionnel.

Récupérer le kubeconfig

# Générer le kubeconfig
talosctl -n 192.168.1.100 kubeconfig ./kubeconfig

# L'utiliser
export KUBECONFIG=./kubeconfig

# Vérifier
kubectl get nodes

Et là, magie :

NAME              STATUS   ROLES           AGE   VERSION
r430-k8s-master   Ready    control-plane   1m    v1.29.1

Mon premier cluster Kubernetes. Sur mon propre hardware. Je dois avouer que j’ai fait un petit screenshot.

Premier pod

Évidemment, faut tester :

kubectl run nginx --image=nginx
kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          10s

Un pod qui tourne ! Bon ok c’est juste un nginx, mais quand même.

Comprendre ce qui tourne

Sur un cluster Talos fresh, t’as déjà pas mal de trucs qui tournent :

kubectl get pods -n kube-system
NAME                                      READY   STATUS    
coredns-5dd5756b68-xxxxx                  1/1     Running   
coredns-5dd5756b68-yyyyy                  1/1     Running   
kube-apiserver-r430-k8s-master            1/1     Running   
kube-controller-manager-r430-k8s-master   1/1     Running   
kube-flannel-xxxxx                        1/1     Running   
kube-proxy-xxxxx                          1/1     Running   
kube-scheduler-r430-k8s-master            1/1     Running
  • kube-apiserver : L’API Kubernetes
  • etcd : La base de données du cluster
  • kube-scheduler : Décide où placer les pods
  • kube-controller-manager : Gère l’état du cluster
  • coredns : DNS interne
  • kube-flannel : Le réseau overlay
  • kube-proxy : Le proxy réseau

Single node vs Multi node

J’ai un seul serveur, donc un seul node. C’est pas “production ready” (pas de HA), mais pour un homelab c’est parfait.

Le control plane et les workloads tournent sur la même machine. Si j’avais plusieurs serveurs, je pourrais avoir des masters séparés des workers.

Les premières commandes utiles

# Voir tous les pods
kubectl get pods -A

# Voir les logs d'un pod
kubectl logs nginx

# Entrer dans un pod
kubectl exec -it nginx -- /bin/bash

# Décrire une ressource
kubectl describe pod nginx

# Supprimer un pod
kubectl delete pod nginx

Ce qui manque encore

À ce stade, j’ai un cluster qui tourne mais :

  • Pas de LoadBalancer : Les services de type LoadBalancer restent en “pending”
  • Pas de storage persistant : Les PVCs marchent pas
  • Pas d’ingress : Pas de moyen d’exposer des services en HTTP

C’est les prochaines étapes.

La fierté du premier cluster

Y’a un truc satisfaisant à voir kubectl get nodes et voir ton propre serveur. C’est pas un cluster managé sur le cloud, c’est ta machine, ton réseau, ta config.

Maintenant faut le rendre utile.

Prochain article : MetalLB et le réseau - LoadBalancer sur bare metal.