Kubernetes pentru oameni care trebuie să-l ruleze

Tutorialele Kubernetes te învață cum să implementezi un pod. Nimeni nu te învață ce să faci atunci când un nod dispare tăcut din starea Ready la 3 dimineața și telefonul tău de on-call nu încetează să buzuie. Aceasta este vorba despre a doua parte.

Cererile și limitele de resurse nu sunt opționale

Dacă ignori resources.requests și resources.limits pe containerele tale, scheduler-ul ghicește, iar kubelet-ul nu știe ce să evacueze mai întâi atunci când un nod rămâne fără memorie. Setează cererile la ceea ce containerul folosește efectiv sub sarcina normală, nu la ceea ce speri că folosește. Setează limitele de memorie aproape de cereri deoarece pod-urile ucise de OOM se repornesc curat, dar limitele CPU ar trebui să fie în general mai flexibile sau absente decât dacă lupți cu vecini gălăgioși, deoarece throttling-ul CPU sub o limită strictă provoacă creșteri de latenție care sunt groaznice de debogat. Rulează kubectl top pods -n your-namespace regulat și compară cu ceea ce ai declarat. Nepotrivirile se acumulează rapid în clustere cu mai mult de câteva servicii.

etcd este întreg clusterul, tratează-l în felul acesta

Tot ceea ce știe Kubernetes trăiește în etcd. Pierde-l și pierzi starea clusterului tău, nu doar niște metadate. Rulează etcdctl snapshot save /backup/etcd-snapshot.db conform unui program, și testează cu adevărat restaurarea acestuia pe un cluster scratch cel puțin o dată. Am văzut echipe cu backup-uri nocturn care s-au dovedit a fi corupte timp de trei luni pentru că nimeni nu le-a verificat. Dacă ești pe un plan de control gestionat (EKS, GKE, AKS), nu gestionezi etcd direct, dar ar trebui totuși să cunoști povestea de backup și restore a furnizorului tău înainte de a avea nevoie, nu în timpul unui incident.

Sondele de viață și disponibilitate trebuie să nu fi de acord uneori

O greșeală comună este utilizarea aceluiași endpoint pentru ambele sonde de viață și disponibilitate. Viața ar trebui să răspundă