Kubernetes 1.0 a été lancé il y a environ un an. Son idée centrale me plaît : déclarer un état désiré, puis laisser des contrôleurs réduire continuellement l’écart avec la réalité. On ne démarre pas seulement trois conteneurs; on demande trois réplicas d’une version.

L’API server reçoit les objets. etcd garde l’état du cluster. Le scheduler choisit un nœud pour chaque Pod. Le kubelet du nœud démarre les conteneurs. Des contrôleurs recréent un Pod disparu, tandis qu’un Service fournit une adresse stable vers les Pods prêts.

Déployer sans envoyer le trafic trop tôt

Pour une application Web :

1. un Deployment demande trois réplicas;
2. le scheduler place les Pods selon ressources;
3. chaque conteneur démarre et charge sa configuration;
4. la readiness probe vérifie une fonction;
5. le Service route seulement vers les Pods prêts;
6. une nouvelle image arrive graduellement;
7. le contrôleur garde l’ancienne capacité jusqu’à la santé;
8. un échec déclenche arrêt ou rollback.

La liveness probe ne doit pas tuer une application seulement parce que sa base est lente. Sinon tous les Pods redémarrent pendant une panne externe et ajoutent de la charge. Readiness retire le trafic; liveness détecte un processus réellement bloqué.

Les requêtes CPU et mémoire guident le placement. Sans limites, un conteneur peut affamer le nœud. Avec une limite mémoire trop basse, il est tué en boucle. Les valeurs viennent d’une mesure de charge, puis sont revues.

Le cluster devient une plateforme critique

etcd doit être sauvegardé et restauré; perdre son quorum bloque les changements. Les certificats, DNS, réseau overlay et registre sont des dépendances. Un Pod est temporaire : la base nécessite volumes, réplication et procédure spécifique. Mettre SQL dans un Pod ne délègue pas sa cohérence à Kubernetes.

Les secrets ne devraient pas être dans une image ou un manifeste public. Les comptes de service ont des permissions minimales et le réseau limite les flux. L’API d’administration exige authentification forte, audit et accès restreint. Une compromission du cluster touche plusieurs applications.

Les logs et métriques quittent les Pods. On suit échecs de scheduling, redémarrages, saturation nœud et parcours utilisateur. Un drain de nœud en heure contrôlée vérifie que budgets de disruption et réplication fonctionnent.

Restaurer l’état du cluster dans un laboratoire

Une sauvegarde etcd doit correspondre à une version et être chiffrée. Je créerais un cluster isolé, restaurerais l’instantané, puis vérifierais Deployments, Services, ConfigMaps et références de secrets. Les volumes applicatifs suivent une procédure séparée; l’objet Kubernetes restauré ne recrée pas le contenu du disque par magie. Les adresses externes et certificats sont réémis pour ne pas toucher la production. Le test mesure le temps et documente l’ordre entre contrôle, réseau et charges. Il révèle aussi les ressources créées manuellement sans manifeste. Une restauration réussie signifie que l’API peut reprendre et que les applications retrouvent leurs propres données, pas seulement que etcd accepte le fichier.

Je commencerais avec un service stateless, tuerais Pods et nœud, puis restaurerais etcd dans un laboratoire. Si l’équipe ne peut pas expliquer scheduler, probes, stockage et contrôle d’accès, l’orchestrateur arrive trop tôt. Kubernetes automatise l’écart entre état désiré et réel; l’organisation doit encore définir le bon état et savoir le récupérer.