Kubernetes m'a semblé plus facile une fois que j'ai compris ces bases

Je n'ai pas encore vraiment déployé Kubernetes dans un vrai projet, comme la plupart de ce que je sais sur le software design en .NET : regardé, compris, pas encore appliqué. Mais les bases ont arrêté de ressembler à un mur de YAML une fois que j'ai eu un modèle mental de ce que chaque pièce faisait vraiment.

Pods, Deployments, Services, fichiers YAML, ConfigMaps, Secrets, probes, clusters, et des dizaines de commandes. En tant que développeur .NET junior, je n'arrêtais pas de penser : pourquoi aurais-je besoin de tout ça juste pour faire tourner une API ASP.NET Core ?

C'est devenu plus facile une fois que j'ai compris quelques idées de base.

Kubernetes fait tourner des containers

Kubernetes ne build pas mon application C#. Elle doit d'abord être publiée et empaquetée dans une image Docker :

ASP.NET Core API
→ Docker image
→ Kubernetes

Si l'application ne fonctionne pas dans Docker, Kubernetes ne la réparera pas.

Les Pods font tourner l'application

Un Pod, c'est là où un container tourne. Un Pod peut contenir une instance d'une API ASP.NET Core.

Les Pods sont temporaires. Ils peuvent être supprimés, redémarrés, ou remplacés, donc rien d'important ne devrait vivre à l'intérieur d'un Pod. Le database, les sessions, et les fichiers importants restent en dehors du Pod.

Les Deployments gèrent les Pods

Un Deployment décrit combien d'instances d'une application devraient tourner :

spec:
  replicas: 2

Si un Pod plante, Kubernetes en crée un autre pour le remplacer. C'est l'idée centrale : vous décrivez l'état désiré, et Kubernetes essaie de le maintenir.

Les Services exposent l'application

Les Pods peuvent changer d'adresse IP quand ils sont recréés. Un Service donne à l'application une adresse stable et route les requests vers n'importe quel Pod disponible :

Client
→ Service
→ Pod
→ ASP.NET Core API

Sans Service, les clients devraient connaître l'adresse de chaque Pod individuel.

La configuration devrait être externe

Les connection strings et les paramètres d'environnement ne devraient pas être hardcodés dans l'image. Les ConfigMaps et les Secrets s'en occupent à la place, et ASP.NET Core les lit comme des environment variables :

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

C'est ce qui permet à la même image container de tourner en development, testing, et production avec des paramètres différents.

Les health checks comptent

Kubernetes peut vérifier si une API est en bonne santé. Une readiness probe demande si l'application peut recevoir du trafic. Une liveness probe demande si elle tourne encore correctement. ASP.NET Core expose ça via un health endpoint :

builder.Services.AddHealthChecks();

app.MapHealthChecks("/health");

Kubernetes utilise ça pour décider si un Pod devrait recevoir du trafic ou être redémarré.

Les commandes qui comptent le plus

La poignée de commandes kubectl qui reviennent constamment dans chaque walkthrough :

kubectl get pods
kubectl get services
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl apply -f deployment.yaml

Le flux de debugging est presque toujours le même : get pods, puis describe pod, puis vérifier les logs.

Où j'en suis vraiment avec ça

Je comprends le modèle mental : Docker empaquette l'application, les Pods la font tourner, les Deployments gèrent les Pods, les Services les exposent, les ConfigMaps et les Secrets gèrent la configuration, les probes vérifient la santé. Ce que je n'ai pas encore, c'est un vrai projet qui tourne réellement sur Kubernetes. C'est le même écart que j'ai avec pas mal de concepts de software design : compris assez bien pour l'expliquer, pas encore quelque chose que j'ai dû faire fonctionner dans des conditions réelles. C'est la prochaine étape.