Kubernetes उन लोगों के लिए जिन्हें इसे चलाना है

Kubernetes tutorials आपको एक pod deploy करना सिखाते हैं। कोई नहीं सिखाता कि क्या करें जब एक node 3am में चुपचाप Ready state से बाहर आ जाए और आपका on-call phone बजना बंद नहीं करेगा। यह दूसरे part के बारे में है।

Resource requests और limits optional नहीं हैं

अगर आप अपने containers पर resources.requests और resources.limits को छोड़ते हैं, तो scheduler अनुमान लगा रहा है, और kubelet को कोई idea नहीं है कि जब एक node memory में कम हो जाए तो पहले क्या evict करना है। Requests को उस पर सेट करें जो container actually normal load के तहत use करता है, जो आप hope करते हैं उसे नहीं। Memory limits को requests के करीब सेट करें क्योंकि OOM-killed pods cleanly restart होते हैं, लेकिन CPU limits आम तौर पर looser होने चाहिए या absent होने चाहिए जब तक आप noisy neighbors से fight नहीं कर रहे हैं, क्योंकि एक hard limit के तहत CPU throttling latency spikes का कारण बनता है जो debug करने के लिए miserable हैं। kubectl top pods -n your-namespace को नियमित रूप से चलाएं और compare करें जो आपने declare किया है। Mismatches एक handful से ज्यादा services वाले clusters में fast जमा हो जाते हैं।

etcd पूरा cluster है, इसे उस तरह treat करें

सब कुछ जो Kubernetes जानता है वह etcd में रहता है। इसे खो दें और आप अपनी cluster state खो देते हैं, सिर्फ कुछ metadata नहीं। एक schedule पर etcdctl snapshot save /backup/etcd-snapshot.db चलाएं, और actually इसे एक scratch cluster पर कम से कम एक बार restore करने के लिए test करें। मैंने उन teams को देखा है जिनके पास nightly backups थे जो तीन महीने के लिए corrupt निकले क्योंकि किसी ने उन्हें verify नहीं किया। अगर आप एक managed control plane पर हैं (EKS, GKE, AKS), तो आप etcd को directly manage नहीं करते हैं, लेकिन आपको अपने provider की backup और restore story को पहले से पता होना चाहिए, एक incident के दौरान नहीं।

Liveness और readiness probes को कभी-कभी disagree करने की जरूरत होती है

एक common mistake है liveness और readiness dोनों probes के लिए same endpoint का use करना। Liveness को answer देना चाहिए