Kubernetes pour ceux qui doivent l'exécuter

Les tutoriels Kubernetes vous enseignent à déployer un pod. Personne ne vous enseigne quoi faire quand un nœud disparaît silencieusement de l'état Ready à 3h du matin et que votre téléphone d'astreinte ne cesse de sonner. C'est sur la deuxième partie qu'il s'agit.

Les demandes de ressources et les limites ne sont pas optionnelles

Si vous omettez resources.requests et resources.limits sur vos conteneurs, le scheduler devine, et le kubelet n'a aucune idée de ce qu'il faut évincer en premier quand un nœud manque de mémoire. Définissez les requests sur ce que le conteneur utilise réellement sous charge normale, pas sur ce que vous espérez qu'il utilise. Définissez les limites de mémoire proches des requests puisque les pods tués par OOM redémarrent proprement, mais les limites de CPU devraient généralement être plus souples ou absentes sauf si vous combattez des voisins bruyants, car la limitation de CPU sous une limite stricte provoque des pics de latence qui sont misérables à déboguer. Exécutez kubectl top pods -n your-namespace régulièrement et comparez avec ce que vous avez déclaré. Les divergences s'accumulent rapidement dans les clusters avec plus qu'une poignée de services.

etcd est le cluster entier, traitez-le de cette façon

Tout ce que Kubernetes connaît vit dans etcd. Le perdre et vous perdez votre état de cluster, pas juste des métadonnées. Exécutez etcdctl snapshot save /backup/etcd-snapshot.db selon un planning, et testez réellement sa restauration sur un cluster temporaire au moins une fois. J'ai vu des équipes avec des sauvegardes quotidiennes qui s'avéraient corrompues pendant trois mois parce que personne ne les avait vérifiées. Si vous êtes sur un plan de contrôle géré (EKS, GKE, AKS), vous ne gérez pas etcd directement, mais vous devriez quand même connaître l'histoire de sauvegarde et restauration de votre fournisseur avant d'en avoir besoin, pas pendant un incident.

Les sondes de vivacité et de disponibilité doivent parfois être en désaccord

Une erreur courante est d'utiliser le même endpoint pour les deux sondes de vivacité et de disponibilité. La vivacité devrait répondre