Kubernetes ان لوگوں کے لیے جو اسے چلانا پڑتا ہے

Kubernetes tutorials آپ کو pod deploy کرنا سکھاتے ہیں۔ کوئی آپ کو نہیں بتاتا کہ جب کوئی node خاموشی سے Ready state سے باہر نکل جائے رات 3 بجے اور آپ کا on-call فون بند نہ ہونے والا ہو تو کیا کریں۔ یہ دوسرے حصے کے بارے میں ہے۔

Resource requests اور limits اختیاری نہیں ہیں

اگر آپ اپنے containers پر resources.requests اور resources.limits چھوڑ دیں، تو scheduler اندازہ لگا رہا ہے، اور kubelet کو پتا نہیں کہ جب node میموری میں کم ہو تو پہلے کیا evict کرے۔ Requests کو اس میں سیٹ کریں جو container عام بوجھ میں حقیقت میں استعمال کرتا ہے، جو آپ کو امید ہے نہیں۔ Memory limits کو requests کے قریب رکھیں کیونکہ OOM-killed pods صاف صاف دوبارہ شروع ہوتے ہیں، لیکن CPU limits عام طور پر زیادہ ڈھیلے ہونے چاہیں یا نہ ہوں جب تک کہ آپ noisy neighbors سے لڑ نہیں رہے ہیں، کیونکہ CPU throttling سخت limit کے تحت latency spikes کا سبب بنتی ہے جو debug کرنا بہت مشکل ہے۔ kubectl top pods -n your-namespace باقاعدگی سے چلائیں اور اس کے ساتھ موازنہ کریں جو آپ نے declare کیا ہے۔ Mismatches کچھ ہی services والے clusters میں تیزی سے جمع ہو جاتے ہیں۔

etcd پورا cluster ہے، اسے اسی طرح سلوک کریں

ہر چیز جو Kubernetes جانتا ہے etcd میں رہتی ہے۔ اسے کھو دیں اور آپ اپنا cluster state کھو دیتے ہیں، صرف کچھ metadata نہیں۔ etcdctl snapshot save /backup/etcd-snapshot.db کو schedule پر چلائیں، اور اسے واقعی scratch cluster پر کم از کم ایک بار restore کرنے کی جانچ کریں۔ میں نے ایسی teams دیکھی ہیں جن کے پاس نہ رات کے backups تھے جو تین ماہ سے corrupt نکلے کیونکہ کسی نے انہیں verify نہیں کیا۔ اگر آپ managed control plane (EKS, GKE, AKS) پر ہیں، تو آپ etcd کو براہ راست manage نہیں کرتے، لیکن آپ کو اپنے provider کی backup اور restore کی کہانی ابھی جاننی چاہیے، incident کے دوران نہیں۔

Liveness اور readiness probes کو کبھی کبھی اختلاف کرنے کی ضرورت ہے

ایک عام غلطی liveness اور readiness دونوں probes کے لیے ایک جیسا endpoint استعمال کرنا ہے۔ Liveness کو جواب دینا چاہیے