Kubernetes dla tych, którzy go uruchamiają

Tutoriale Kubernetes uczą jak wdrożyć pod. Nikt nie uczy cię co robić, gdy node cicho wypadnie ze stanu Ready o 3 nad ranem, a telefon on-call nie przestaje dzwonić. To dotyczy drugiej części.

Resource requests i limits nie są opcjonalne

Jeśli pominąłeś resources.requests i resources.limits na swoich kontenerach, scheduler zgaduje, a kubelet nie ma pojęcia co usunąć najpierw, gdy node zaczyna brakować pamięci. Ustaw requests na to, co kontener faktycznie zużywa przy normalnym obciążeniu, a nie na to, co masz nadzieję że zużywa. Ustaw memory limits blisko requests, ponieważ OOM-killed pody restartują się czyszczą, ale CPU limits powinny być generalnie luźniejsze lub nieobecne, chyba że walczysz z głośnymi sąsiadami, bo CPU throttling pod twardym limitem powoduje piki opóźnień, które są uciążliwe do debugowania. Uruchamiaj kubectl top pods -n your-namespace regularnie i porównuj z tym co zadeklarowałeś. Rozbieżności się kumulują szybko w klastrach z więcej niż kilkoma serwisami.

etcd to cały klaster, traktuj to tak

Wszystko co Kubernetes wie żyje w etcd. Stracisz to i stracisz stan klastra, nie tylko jakieś metadane. Uruchamiaj etcdctl snapshot save /backup/etcd-snapshot.db według harmonogramu, i faktycznie testuj przywracanie go na scratch klastrze przynajmniej raz. Widziałem zespoły z nocnymi kopiami zapasowymi, które okazały się uszkodzone przez trzy miesiące, ponieważ nikt ich nie weryfikował. Jeśli jesteś na managed control plane (EKS, GKE, AKS), nie zarządzasz etcd bezpośrednio, ale powinieneś znać historia backupu i przywracania twojego dostawcy zanim jej potrzebujesz, nie podczas incydentu.

Liveness i readiness probes muszą czasem się nie zgodzić

Częsty błąd to używanie tego samego endpointu dla obu liveness i readiness probes. Liveness powinno odpowiadać