Kubernetes per chi deve gestirlo

I tutorial su Kubernetes ti insegnano come fare il deploy di un pod. Nessuno ti insegna cosa fare quando un nodo sparisce silenziosamente dallo stato Ready alle 3 del mattino e il telefono della tua reperibilità non smette di squillare. Questo parla della seconda parte.

Le resource requests e limits non sono opzionali

Se salti resources.requests e resources.limits sui tuoi container, lo scheduler sta indovinando, e il kubelet non ha idea di cosa evincere per primo quando un nodo rimane a corto di memoria. Imposta requests a quello che il container usa effettivamente sotto carico normale, non a quello che speri usi. Imposta i limiti di memoria vicini alle requests poiché i pod eliminati per OOM si riavviano correttamente, ma i limiti di CPU dovrebbero generalmente essere più laschi o assenti a meno che non stia combattendo vicini rumorosi, perché il throttling della CPU sotto un limite rigido causa picchi di latenza che sono miseri da debuggare. Esegui kubectl top pods -n your-namespace regolarmente e confronta con quello che hai dichiarato. Le discrepanze si accumulano velocemente nei cluster con più di un pugno di servizi.

etcd è l'intero cluster, trattalo così

Tutto quello che Kubernetes conosce vive in etcd. Perderlo e perdi lo stato del tuo cluster, non solo alcuni metadati. Esegui etcdctl snapshot save /backup/etcd-snapshot.db secondo una pianificazione, e verifica effettivamente il ripristino su un cluster scratch almeno una volta. Ho visto team con backup notturni che si sono rivelati corrotti per tre mesi perché nessuno li verificava. Se sei su un control plane gestito (EKS, GKE, AKS), non gestisci etcd direttamente, ma dovresti comunque conoscere la storia di backup e ripristino del tuo provider prima di averne bisogno, non durante un incidente.

I probe di liveness e readiness a volte devono essere diversi

Un errore comune è usare lo stesso endpoint per entrambi i probe di liveness e readiness. Liveness dovrebbe rispondere