Kubernetes voor mensen die het moeten runnen

Kubernetes tutorials leren je hoe je een pod deployt. Niemand leert je wat je moet doen als een node om 3 uur 's nachts stil uit Ready state verdwijnt en je on-call telefoon maar niet stopt met zoemen. Dit gaat over het tweede deel.

Resource requests en limits zijn niet optioneel

Als je resources.requests en resources.limits op je containers overslaat, is de scheduler aan het gissen, en de kubelet heeft geen idee wat het eerst moet verwijderen als een node weinig geheugen heeft. Stel requests in op wat de container echt gebruikt onder normale belasting, niet op wat je hoopt dat het gebruikt. Stel geheugenlimieten dicht bij requests, omdat OOM-killed pods netjes opnieuw starten, maar CPU-limieten moeten meestal losser zijn of afwezig, tenzij je tegen lawaaierige buren vecht, omdat CPU-beperking onder een harde limiet latency spikes veroorzaakt die verschrikkelijk zijn om op te sporen. Voer kubectl top pods -n your-namespace regelmatig uit en vergelijk met wat je hebt aangegeven. Verschillen stapelen zich snel op in clusters met meer dan een handvol services.

etcd is de hele cluster, behandel het zo

Alles wat Kubernetes weet leeft in etcd. Verlies het en je verliest je cluster state, niet alleen wat metadata. Voer etcdctl snapshot save /backup/etcd-snapshot.db volgens een schema uit, en test het herstellen op een scratch cluster minstens een keer. Ik heb teams gezien met nachtelijke backups die bleken corrupt te zijn gedurende drie maanden omdat niemand ze verificeerde. Als je op een managed control plane bent (EKS, GKE, AKS), beheer je etcd niet rechtstreeks, maar je moet nog steeds het backup- en restore-verhaal van je provider kennen voordat je het nodig hebt, niet tijdens een incident.

Liveness en readiness probes moeten soms het oneens zijn

Een veelgemaakte fout is het gebruiken van hetzelfde endpoint voor zowel liveness als readiness probes. Liveness zou moeten antwoorden