Kubernetes استعمال کرتے وقت 10 عام غلطیاں

نوٹ. ترجمہ: اس مضمون کے مصنفین ایک چھوٹی سی چیک کمپنی پائپ ٹیل کے انجینئر ہیں۔ وہ کبرنیٹس کلسٹرز کے آپریشن سے متعلق بہت ہی پریشان کن مسائل اور غلط فہمیوں کی [کبھی کبھی عام، لیکن پھر بھی] ایک شاندار فہرست جمع کرنے میں کامیاب رہے۔

Kubernetes استعمال کرنے کے سالوں کے دوران، ہم نے بڑی تعداد میں کلسٹرز کے ساتھ کام کیا ہے (منظم اور غیر منظم دونوں - GCP، AWS اور Azure پر)۔ وقت گزرنے کے ساتھ، ہم نے محسوس کرنا شروع کیا کہ کچھ غلطیاں مسلسل دہرائی گئیں۔ تاہم، اس میں کوئی شرم کی بات نہیں ہے: ہم نے ان میں سے زیادہ تر خود کیے ہیں!

مضمون میں سب سے عام غلطیاں ہیں اور ان کو درست کرنے کا طریقہ بھی بتایا گیا ہے۔

1. وسائل: درخواستیں اور حدود

یہ آئٹم یقینی طور پر قریب ترین توجہ اور فہرست میں پہلی جگہ کا مستحق ہے۔

CPU کی درخواست عام طور پر یا تو بالکل متعین نہیں ہے یا اس کی قدر بہت کم ہے۔ (ہر نوڈ پر زیادہ سے زیادہ پھلیاں رکھنے کے لیے)۔ اس طرح، نوڈس اوورلوڈ ہو جاتے ہیں. زیادہ بوجھ کے وقت، نوڈ کی پروسیسنگ پاور کو پوری طرح سے استعمال کیا جاتا ہے اور ایک خاص کام کا بوجھ صرف وہی حاصل کرتا ہے جو اس کی طرف سے "درخواست" کی جاتی ہے۔ سی پی یو تھروٹلنگ. یہ درخواست میں تاخیر، ٹائم آؤٹ اور دیگر ناخوشگوار نتائج کا باعث بنتا ہے۔ (اس کے بارے میں ہمارے دوسرے حالیہ ترجمہ میں مزید پڑھیں:CPU کی حدیں اور Kubernetes میں جارحانہ تھروٹلنگ" - تقریبا. ترجمہ)

بہترین کوشش (انتہائی کوئی تجویز کردہ):

resources: {}

انتہائی کم CPU درخواست (انتہائی کوئی تجویز کردہ):

   resources:
      Requests:
        cpu: "1m"

دوسری طرف، سی پی یو کی حد کی موجودگی پوڈز کے ذریعے گھڑی کے چکروں کو غیر معقول طور پر چھوڑنے کا باعث بن سکتی ہے، چاہے نوڈ پروسیسر مکمل طور پر لوڈ نہ ہو۔ ایک بار پھر، اس سے تاخیر میں اضافہ ہو سکتا ہے۔ پیرامیٹر کے ارد گرد تنازعہ جاری ہے CPU CFS کوٹہ لینکس کرنل اور سی پی یو تھروٹلنگ میں مقررہ حدود کے ساتھ ساتھ سی ایف ایس کوٹہ کو غیر فعال کرنا... افسوس، سی پی یو کی حدیں اس سے کہیں زیادہ مسائل پیدا کر سکتی ہیں جتنا وہ حل کر سکتے ہیں۔ اس بارے میں مزید معلومات نیچے دیے گئے لنک پر دیکھی جا سکتی ہیں۔

ضرورت سے زیادہ انتخاب (زیادہ ذمہ داری) یادداشت کے مسائل بڑے مسائل کا باعث بن سکتے ہیں۔ CPU کی حد تک پہنچنے میں گھڑی کے چکروں کو چھوڑنا پڑتا ہے، جبکہ میموری کی حد تک پہنچنے سے پوڈ کو ختم کرنا پڑتا ہے۔ آپ نے کبھی مشاہدہ کیا ہے؟ OOMkill? ہاں، بالکل وہی ہے جس کے بارے میں ہم بات کر رہے ہیں۔

کیا آپ اس کے ہونے کے امکان کو کم کرنا چاہتے ہیں؟ میموری کو زیادہ مختص نہ کریں اور میموری کی درخواست کو حد تک سیٹ کرکے گارنٹیڈ QoS (سروس کا معیار) استعمال کریں (جیسا کہ ذیل کی مثال میں)۔ اس بارے میں مزید پڑھیں ہیننگ جیکبز پریزنٹیشنز (لیڈ انجینئر زلینڈو)۔

پھٹنے والا (OOM ہلاک ہونے کا زیادہ امکان):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ضمانت:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

وسائل قائم کرتے وقت کیا ممکنہ طور پر مدد کرے گا؟

کے ساتھ میٹرکس سرور آپ پوڈز (اور ان کے اندر کنٹینرز) کے ذریعہ موجودہ CPU وسائل کی کھپت اور میموری کا استعمال دیکھ سکتے ہیں۔ زیادہ امکان ہے، آپ اسے پہلے ہی استعمال کر رہے ہیں۔ بس درج ذیل کمانڈز چلائیں:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

تاہم، وہ صرف موجودہ استعمال کو ظاہر کرتے ہیں۔ یہ آپ کو طول و عرض کی ترتیب کا اندازہ دے سکتا ہے، لیکن بالآخر آپ کو ضرورت ہوگی۔ وقت کے ساتھ میٹرکس میں تبدیلیوں کی تاریخ (سوالوں کے جواب دینے کے لیے جیسے: "سی پی یو کا چوٹی کا بوجھ کیا تھا؟"، "کل صبح لوڈ کیا تھا؟"، وغیرہ)۔ اس کے لیے آپ استعمال کر سکتے ہیں۔ Prometheus, ڈیٹا ڈاگ اور دیگر اوزار. وہ صرف میٹرکس سرور سے میٹرکس حاصل کرتے ہیں اور انہیں اسٹور کرتے ہیں، اور صارف ان سے استفسار کر سکتا ہے اور اس کے مطابق پلاٹ کر سکتا ہے۔

عمودی پوڈ آٹو اسکیلر کی اجازت دیتا ہے خودکار یہ عمل. یہ CPU اور میموری کے استعمال کی تاریخ کو ٹریک کرتا ہے اور اس معلومات کی بنیاد پر نئی درخواستیں اور حدود مرتب کرتا ہے۔

کمپیوٹنگ پاور کو موثر طریقے سے استعمال کرنا کوئی آسان کام نہیں ہے۔ یہ ہر وقت ٹیٹریس کھیلنے کی طرح ہے۔ اگر آپ کم اوسط کھپت کے ساتھ کمپیوٹ پاور کے لیے بہت زیادہ ادائیگی کر رہے ہیں (کہیں ~10%)، تو ہم تجویز کرتے ہیں کہ AWS Fargate یا Virtual Kubelet پر مبنی پروڈکٹس دیکھیں۔ وہ سرور لیس/پے-فی-استعمال بلنگ ماڈل پر بنائے گئے ہیں، جو اس طرح کے حالات میں سستا ہو سکتا ہے۔

2. زندہ دلی اور تیاری کی تحقیقات

پہلے سے طے شدہ طور پر، کوبرنیٹس میں زندہ دلی اور تیاری کی جانچ کو فعال نہیں کیا جاتا ہے۔ اور کبھی کبھی وہ ان کو آن کرنا بھول جاتے ہیں...

لیکن کسی مہلک خرابی کی صورت میں آپ سروس کو دوبارہ کیسے شروع کر سکتے ہیں؟ اور لوڈ بیلنس کرنے والا کیسے جانتا ہے کہ ایک پوڈ ٹریفک کو قبول کرنے کے لیے تیار ہے؟ یا یہ زیادہ ٹریفک کو سنبھال سکتا ہے؟

یہ ٹیسٹ اکثر ایک دوسرے کے ساتھ الجھ جاتے ہیں:

• جیونت - "بقا" چیک، جو پوڈ کو دوبارہ شروع کرتا ہے اگر یہ ناکام ہوجاتا ہے؛
• تیاری - تیاری کی جانچ پڑتال، اگر یہ ناکام ہو جاتا ہے، تو یہ پوڈ کو کوبرنیٹس سروس سے منقطع کر دیتا ہے (اس کا استعمال کرکے چیک کیا جا سکتا ہے kubectl get endpoints) اور ٹریفک اس تک نہیں پہنچتی جب تک کہ اگلی چیک کامیابی سے مکمل نہ ہو جائے۔

یہ دونوں چیک پوڈ کی پوری زندگی کے چکر کے دوران پرفارم کیا گیا۔. یہ بہت اہم ہے.

ایک عام غلط فہمی یہ ہے کہ ریڈی نیس پروبس صرف اسٹارٹ اپ پر چلائی جاتی ہیں تاکہ بیلنس کرنے والا جان سکے کہ پوڈ تیار ہے (Ready) اور ٹریفک پر کارروائی شروع کر سکتے ہیں۔ تاہم، یہ ان کے استعمال کے اختیارات میں سے صرف ایک ہے۔

ایک اور یہ معلوم کرنے کا امکان ہے کہ پھلی پر ٹریفک ضرورت سے زیادہ ہے اور اسے اوورلوڈ کرتا ہے۔ (یا پوڈ وسائل سے بھرپور حساب کتاب کرتا ہے)۔ اس صورت میں، تیاری کی جانچ میں مدد ملتی ہے پھلی پر بوجھ کو کم کریں اور اسے "ٹھنڈا" کریں۔. مستقبل میں تیاری کی جانچ کی کامیاب تکمیل کی اجازت دیتا ہے۔ پوڈ پر دوبارہ بوجھ بڑھائیں. اس صورت میں (اگر تیاری کا امتحان ناکام ہو جاتا ہے)، زندہ رہنے کے ٹیسٹ میں ناکامی بہت نقصان دہ ہو گی۔ ایک پوڈ کو دوبارہ شروع کیوں کریں جو صحت مند اور محنتی ہو؟

لہذا، بعض صورتوں میں، غلط طریقے سے تشکیل شدہ پیرامیٹرز کے ساتھ ان کو فعال کرنے سے بہتر نہیں ہے کہ کوئی بھی جانچ پڑتال نہ کریں۔ جیسا کہ اوپر بتایا گیا ہے، اگر زندہ دلی کی جانچ کی کاپیاں تیاری کی جانچتو آپ بڑی مصیبت میں ہیں. ممکنہ آپشن ترتیب دینا ہے۔ صرف تیاری کا امتحاناور خطرناک زندگی ایک طرف چھوڑ دو.

دونوں قسم کے چیکس کو ناکام نہیں ہونا چاہیے جب عام انحصار ناکام ہو جائے، بصورت دیگر یہ تمام پوڈز کے جھرنے (برفانی تودے کی طرح) کی ناکامی کا باعث بنے گا۔ دوسرے الفاظ میں، اپنے آپ کو نقصان نہ پہنچاؤ.

3. ہر HTTP سروس کے لیے لوڈ بیلنسر

زیادہ امکان ہے کہ، آپ کے کلسٹر میں HTTP خدمات ہیں جنہیں آپ باہر کی دنیا میں بھیجنا چاہیں گے۔

اگر آپ اس سروس کو کھولتے ہیں۔ type: LoadBalancer، اس کا کنٹرولر (خدمت فراہم کرنے والے پر منحصر ہے) ایک بیرونی لوڈ بیلنس فراہم کرے گا اور بات چیت کرے گا (ضروری نہیں کہ L7 پر چل رہا ہو، بلکہ L4 پر بھی)، اور اس سے لاگت (بیرونی جامد IPv4 ایڈریس، کمپیوٹنگ پاور، فی سیکنڈ بلنگ) متاثر ہو سکتی ہے۔ اس طرح کے وسائل کی ایک بڑی تعداد پیدا کرنے کی ضرورت کی وجہ سے۔

اس صورت میں، یہ ایک بیرونی لوڈ بیلنس استعمال کرنے کے لئے بہت زیادہ منطقی ہے، خدمات کو کھولنے کے طور پر type: NodePort. یا ابھی تک بہتر، کچھ اس طرح پھیلائیں۔ nginx-ingress-controller (یا ٹریفک)، جو صرف ایک ہو گا۔ نوڈ پورٹ اختتامی نقطہ بیرونی لوڈ بیلنسر کے ساتھ منسلک ہے اور کلسٹر میں ٹریفک کو استعمال کرتے ہوئے روٹ کرے گا۔ داخل کرنا-Kubernetes وسائل۔

دیگر انٹرا کلسٹر (مائیکرو) خدمات جو ایک دوسرے کے ساتھ تعامل کرتی ہیں وہ خدمات کا استعمال کرکے "مواصلات" کر سکتی ہیں جیسے کلسٹر آئی پی اور DNS کے ذریعے ایک بلٹ ان سروس دریافت کرنے کا طریقہ کار۔ بس ان کا عوامی DNS/IP استعمال نہ کریں، کیونکہ یہ تاخیر کو متاثر کر سکتا ہے اور کلاؤڈ سروسز کی قیمت میں اضافہ کر سکتا ہے۔

4. کسی کلسٹر کی خصوصیات کو مدنظر رکھے بغیر خودکار اسکیل کرنا

نوڈس کو شامل کرتے وقت اور انہیں کلسٹر سے ہٹاتے وقت، آپ کو ان نوڈس پر CPU کے استعمال جیسے کچھ بنیادی میٹرکس پر انحصار نہیں کرنا چاہیے۔ پھلی کی منصوبہ بندی بہت سے اکاؤنٹ میں لے جانا چاہئے پابندیاں، جیسے پوڈ/نوڈ وابستگی، داغداریاں اور برداشت، وسائل کی درخواستیں، QoS، وغیرہ۔ ایک بیرونی آٹو اسکیلر کا استعمال جو ان باریکیوں کو مدنظر نہیں رکھتا مسائل کا باعث بن سکتا ہے۔

تصور کریں کہ ایک مخصوص پوڈ کو شیڈول کیا جانا چاہئے، لیکن تمام دستیاب سی پی یو پاور کی درخواست کی جاتی ہے / الگ کردی جاتی ہے اور پوڈ حالت میں پھنس جاتا ہے۔ Pending. بیرونی آٹو اسکیلر اوسط موجودہ CPU بوجھ دیکھتا ہے (درخواست کردہ نہیں) اور توسیع شروع نہیں کرتا (اسکیل آؤٹ) - دوسرا نوڈ شامل نہیں کرتا ہے۔ نتیجے کے طور پر، یہ پوڈ شیڈول نہیں کیا جائے گا.

اس صورت میں، ریورس سکیلنگ (اسکیل ان) - کلسٹر سے نوڈ کو ہٹانا ہمیشہ سے زیادہ مشکل ہوتا ہے۔ تصور کریں کہ آپ کے پاس ایک اسٹیٹفول پوڈ ہے (مسلسل اسٹوریج کے ساتھ منسلک)۔ مستقل حجم عام طور پر سے تعلق رکھتے ہیں مخصوص دستیابی زون اور خطے میں نقل نہیں کیے جاتے ہیں۔ اس طرح، اگر کوئی بیرونی آٹو اسکیلر اس پوڈ کے ساتھ ایک نوڈ کو حذف کرتا ہے، تو شیڈیولر اس پوڈ کو کسی اور نوڈ پر شیڈول نہیں کر سکے گا، کیونکہ یہ صرف دستیابی کے علاقے میں کیا جا سکتا ہے جہاں مستقل اسٹوریج واقع ہے۔ پھلی ریاست میں پھنس جائے گی۔ Pending.

Kubernetes کمیونٹی میں بہت مشہور ہے۔ کلسٹر آٹو اسکیلر. یہ کلسٹر پر چلتا ہے، بڑے کلاؤڈ فراہم کنندگان سے APIs کو سپورٹ کرتا ہے، تمام پابندیوں کو مدنظر رکھتا ہے اور مندرجہ بالا معاملات میں اسکیل کر سکتا ہے۔ یہ تمام متعین حدود کو برقرار رکھتے ہوئے اسکیل ان کرنے کے قابل بھی ہے، اس طرح رقم کی بچت ہوتی ہے (جو دوسری صورت میں غیر استعمال شدہ صلاحیت پر خرچ کی جائے گی)۔

5. IAM/RBAC صلاحیتوں کو نظر انداز کرنا

کے لیے مسلسل راز رکھنے والے IAM صارفین کو استعمال کرنے سے ہوشیار رہیں مشینیں اور ایپلی کیشنز. رولز اور سروس اکاؤنٹس کا استعمال کرتے ہوئے عارضی رسائی کو منظم کریں۔ (سروس اکاؤنٹس).

ہمیں اکثر اس حقیقت کا سامنا کرنا پڑتا ہے کہ ایپلیکیشن کنفیگریشن میں رسائی کیز (اور راز) کو ہارڈ کوڈ کیا جاتا ہے، نیز کلاؤڈ IAM تک رسائی کے باوجود رازوں کی گردش کو نظر انداز کیا جاتا ہے۔ جہاں مناسب ہو صارفین کے بجائے IAM رولز اور سروس اکاؤنٹس استعمال کریں۔

kube2iam کے بارے میں بھول جائیں اور سروس اکاؤنٹس کے لیے سیدھے IAM رولز پر جائیں (جیسا کہ میں بیان کیا گیا ہے۔ اسی نام کا نوٹ Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ایک تشریح۔ اتنا مشکل نہیں، ٹھیک ہے؟

اس کے علاوہ، سروس اکاؤنٹس اور مثالی پروفائلز کی مراعات نہ دیں۔ admin и cluster-adminاگر انہیں اس کی ضرورت نہیں ہے۔ خاص طور پر RBAC K8s میں اس کو لاگو کرنا قدرے مشکل ہے، لیکن یقینی طور پر کوشش کے قابل ہے۔

6. پھلیوں کے لیے خودکار اینٹی وابستگی پر انحصار نہ کریں۔

تصور کریں کہ آپ کے پاس نوڈ پر کچھ تعیناتی کی تین نقلیں ہیں۔ نوڈ گرتا ہے، اور اس کے ساتھ تمام نقلیں. ناخوشگوار صورتحال، ٹھیک ہے؟ لیکن تمام نقلیں ایک ہی نوڈ پر کیوں تھیں؟ کیا Kubernetes کو اعلی دستیابی (HA) فراہم نہیں کرنا چاہئے؟!

بدقسمتی سے، Kubernetes شیڈیولر، اپنی ہی پہل پر، علیحدہ وجود کے قوانین کی تعمیل نہیں کرتا ہے۔ (مخالف تعلق) پھلیوں کے لئے. انہیں واضح طور پر بیان کیا جانا چاہئے:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

بس۔ اب پوڈز کو مختلف نوڈس پر شیڈول کیا جائے گا (یہ حالت صرف شیڈولنگ کے دوران چیک کی جاتی ہے، لیکن ان کے آپریشن کے دوران نہیں - لہذا requiredDuringSchedulingIgnoredDuringExecution).

یہاں ہم بات کر رہے ہیں۔ podAntiAffinity مختلف نوڈس پر: topologyKey: "kubernetes.io/hostname", - اور مختلف دستیابی زونز کے بارے میں نہیں۔ ایک مکمل HA کو نافذ کرنے کے لیے، آپ کو اس موضوع میں گہرائی میں جانا پڑے گا۔

7. PodDisruption Budgets کو نظر انداز کرنا

تصور کریں کہ آپ کے پاس کبرنیٹس کلسٹر پر پیداوار کا بوجھ ہے۔ وقتاً فوقتاً، نوڈس اور کلسٹر کو خود اپ ڈیٹ کرنا پڑتا ہے (یا ختم کرنا پڑتا ہے)۔ PodDisruptionBudget (PDB) کلسٹر ایڈمنسٹریٹرز اور صارفین کے درمیان سروس گارنٹی کے معاہدے کی طرح ہے۔

PDB آپ کو نوڈس کی کمی کی وجہ سے سروس کی رکاوٹوں سے بچنے کی اجازت دیتا ہے:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

اس مثال میں، آپ، کلسٹر کے صارف کے طور پر، منتظمین سے کہتے ہیں: "ارے، میرے پاس چڑیا گھر کی خدمت ہے، اور اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کچھ بھی کرتے ہیں، میں اس سروس کی کم از کم 2 نقلیں ہمیشہ دستیاب رکھنا چاہوں گا۔"

آپ اس بارے میں مزید پڑھ سکتے ہیں۔ یہاں.

8. ایک مشترکہ کلسٹر میں متعدد صارفین یا ماحول

Kubernetes نام کی جگہیں۔ (نام کی جگہیں) مضبوط موصلیت فراہم نہ کریں.

ایک عام غلط فہمی یہ ہے کہ اگر آپ نان پروڈ لوڈ کو ایک نیم اسپیس میں اور پروڈ لوڈ کو دوسری جگہ پر لگاتے ہیں، تو وہ ایک دوسرے پر اثر انداز نہیں ہوں گے۔... تاہم، وسائل کی درخواستوں/حدودوں، کوٹوں کی ترتیب، اور ترجیحی کلاسز کو ترتیب دے کر تنہائی کی ایک خاص سطح حاصل کی جا سکتی ہے۔ ڈیٹا جہاز میں کچھ "جسمانی" تنہائی وابستگیوں، رواداریوں، داغداروں (یا نوڈ سلیکٹرز) کے ذریعہ فراہم کی جاتی ہے، لیکن اس طرح کی علیحدگی کافی حد تک ہے۔ مشکل لاگو

جن کو ایک ہی کلسٹر میں دونوں قسم کے کام کے بوجھ کو یکجا کرنے کی ضرورت ہے انہیں پیچیدگی کا سامنا کرنا پڑے گا۔ اگر ایسی کوئی ضرورت نہیں ہے، اور آپ اسے حاصل کرنے کے متحمل ہوسکتے ہیں۔ ایک اور کلسٹر (کہیں، عوامی بادل میں)، پھر ایسا کرنا بہتر ہے۔ یہ موصلیت کی ایک بہت زیادہ سطح حاصل کرے گا.

9. بیرونی ٹریفک پالیسی: کلسٹر

اکثر ہم دیکھتے ہیں کہ کلسٹر کے اندر تمام ٹریفک نوڈ پورٹ جیسی سروس کے ذریعے آتی ہے، جس کے لیے ڈیفالٹ پالیسی سیٹ ہوتی ہے۔ externalTrafficPolicy: Cluster... اسکا مطب ہے نوڈ پورٹ کلسٹر میں ہر نوڈ پر کھلا ہے، اور آپ ان میں سے کسی کو بھی مطلوبہ سروس (پڈس کا سیٹ) کے ساتھ تعامل کے لیے استعمال کر سکتے ہیں۔

ایک ہی وقت میں، مذکورہ نوڈ پورٹ سروس سے وابستہ اصلی پوڈز عام طور پر صرف ایک مخصوص پر دستیاب ہوتے ہیں۔ ان نوڈس کا سب سیٹ. دوسرے لفظوں میں، اگر میں کسی ایسے نوڈ سے جڑتا ہوں جس میں مطلوبہ پوڈ نہیں ہوتا ہے، تو یہ ٹریفک کو دوسرے نوڈ پر بھیج دے گا، ایک ہاپ شامل کرنا اور تاخیر میں اضافہ (اگر نوڈس مختلف دستیابی زونز/ڈیٹا سینٹرز میں واقع ہیں، تو تاخیر کافی زیادہ ہوسکتی ہے؛ اس کے علاوہ، ایگریس ٹریفک کے اخراجات بڑھ جائیں گے)۔

دوسری طرف، اگر ایک مخصوص Kubernetes سروس کی پالیسی سیٹ ہے۔ externalTrafficPolicy: Local، پھر NodePort صرف ان نوڈس پر کھلتا ہے جہاں درکار پوڈز دراصل چل رہے ہیں۔ بیرونی لوڈ بیلنسر استعمال کرتے وقت جو ریاست کو چیک کرتا ہے۔ (صحت کی جانچ) اختتامی نقطہ (یہ کیسے کرتا ہے AWS ELB۔)، وہ ٹریفک صرف ضروری نوڈس پر بھیجے گا۔، جس کا تاخیر، کمپیوٹنگ کی ضروریات، ایگریس بلز پر فائدہ مند اثر پڑے گا (اور عقل بھی یہی حکم دیتی ہے)۔

اس بات کا بہت زیادہ امکان ہے کہ آپ پہلے سے ہی کچھ استعمال کر رہے ہیں۔ ٹریفک یا nginx-ingress-controller HTTP انگریس ٹریفک کو روٹ کرنے کے لیے نوڈ پورٹ اینڈ پوائنٹ (یا LoadBlancer، جو NodePort بھی استعمال کرتا ہے) کے طور پر، اور اس آپشن کو ترتیب دینے سے اس طرح کی درخواستوں کے لیے تاخیر کو نمایاں طور پر کم کیا جا سکتا ہے۔

В اس اشاعت آپ externalTrafficPolicy، اس کے فوائد اور نقصانات کے بارے میں مزید جان سکتے ہیں۔

10. جھرمٹ میں بندھے ہوئے نہ ہوں اور کنٹرول طیارے کا غلط استعمال نہ کریں۔

پہلے، سرورز کو مناسب ناموں سے پکارنے کا رواج تھا: انتون, HAL9000 اور Colossus... آج ان کی جگہ تصادفی طور پر تیار کردہ شناخت کنندگان نے لے لی ہے۔ تاہم، عادت باقی رہی، اور اب مناسب نام کلسٹر میں چلے جاتے ہیں۔

ایک عام کہانی (حقیقی واقعات پر مبنی): یہ سب تصور کے ثبوت کے ساتھ شروع ہوا، اس لیے کلسٹر کا ایک قابل فخر نام تھا۔ ٹیسٹنگ… سال گزر چکے ہیں اور یہ اب بھی پیداوار میں استعمال ہوتا ہے، اور ہر کوئی اسے چھونے سے ڈرتا ہے۔

کلسٹروں کے پالتو جانوروں میں تبدیل ہونے میں کوئی مزہ نہیں ہے، لہذا ہم مشق کرتے وقت انہیں وقتا فوقتا ہٹانے کی تجویز کرتے ہیں۔ تباہی سےبحالی (یہ مدد کرے گا افراتفری انجینئرنگ - تقریبا. ترجمہ). اس کے علاوہ، کنٹرول پرت پر کام کرنے سے تکلیف نہیں ہوگی۔ (کنٹرول طیارہ). اسے چھونے سے ڈرنا اچھی علامت نہیں ہے۔ وغیرہ مردہ لوگ، آپ واقعی مصیبت میں ہیں!

دوسری طرف، آپ کو اس میں ہیرا پھیری سے پریشان نہیں ہونا چاہیے۔ وقت کے ساتھ کنٹرول پرت سست ہو سکتی ہے۔. زیادہ تر امکان ہے کہ، اس کی وجہ بڑی تعداد میں اشیاء کو ان کی گردش کے بغیر تخلیق کیا جا رہا ہے (ایک عام صورت حال جب ہیلم کو ڈیفالٹ سیٹنگز کے ساتھ استعمال کرتے ہیں، یہی وجہ ہے کہ کنفیگ میپس/سیکرٹس میں اس کی حالت کو اپ ڈیٹ نہیں کیا جاتا ہے - نتیجتاً، ہزاروں اشیاء جمع ہو جاتی ہیں۔ کنٹرول لیئر) یا kube-api اشیاء کی مستقل ترمیم کے ساتھ (خودکار پیمانے کے لیے، CI/CD کے لیے، نگرانی کے لیے، ایونٹ لاگ، کنٹرولرز وغیرہ)۔

اس کے علاوہ، ہم منظم Kubernetes فراہم کنندہ کے ساتھ SLA/SLO معاہدوں کو چیک کرنے اور ضمانتوں پر توجہ دینے کی تجویز کرتے ہیں۔ دکاندار ضمانت دے سکتا ہے۔ کنٹرول پرت کی دستیابی (یا اس کے ذیلی اجزاء)، لیکن درخواستوں کی p99 تاخیر سے نہیں جو آپ اسے بھیجتے ہیں۔ دوسرے الفاظ میں، آپ داخل کر سکتے ہیں kubectl get nodes، اور صرف 10 منٹ کے بعد جواب موصول کریں، اور یہ سروس کے معاہدے کی شرائط کی خلاف ورزی نہیں ہوگی۔

11. بونس: تازہ ترین ٹیگ کا استعمال کرتے ہوئے

لیکن یہ پہلے سے ہی ایک کلاسک ہے. حال ہی میں ہم نے اس تکنیک کو کم ہی دیکھا ہے، کیونکہ بہت سے لوگوں نے تلخ تجربے سے سیکھ کر ٹیگ کا استعمال بند کر دیا ہے۔ :latest اور ورژن پن کرنا شروع کر دیا۔ ہورے!

ایسیآر تصویری ٹیگز کی تبدیلی کو برقرار رکھتا ہے۔; ہم تجویز کرتے ہیں کہ آپ اس قابل ذکر خصوصیت سے اپنے آپ کو واقف کرائیں۔

خلاصہ

ہر چیز راتوں رات کام کرنے کی توقع نہ کریں: Kubernetes کوئی علاج نہیں ہے۔ خراب ایپ یہاں تک کہ Kubernetes میں بھی اسی طرح رہے گا۔ (اور یہ شاید بدتر ہو جائے گا)۔ لاپرواہی ضرورت سے زیادہ پیچیدگی، کنٹرول پرت کے سست اور دباؤ والے کام کا باعث بنے گی۔ مزید برآں، آپ کو تباہی کی بحالی کی حکمت عملی کے بغیر چھوڑے جانے کا خطرہ ہے۔ Kubernetes سے توقع نہ کریں کہ وہ باکس سے باہر تنہائی اور اعلیٰ دستیابی فراہم کرے گا۔ اپنی ایپلیکیشن کو واقعی کلاؤڈ مقامی بنانے میں کچھ وقت گزاریں۔

میں مختلف ٹیموں کے ناکام تجربات سے آپ واقف ہو سکتے ہیں۔ کہانیوں کا یہ مجموعہ ہیننگ جیکبز کے ذریعہ۔

جو لوگ اس مضمون میں دی گئی غلطیوں کی فہرست میں شامل کرنا چاہتے ہیں وہ ہم سے ٹویٹر پر رابطہ کر سکتے ہیں۔@MarekBartik, @MstrsObserver).

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes کلسٹرز کی ڈیزائننگ: کتنے ہونے چاہئیں؟؛ "
• «کبرنیٹس میں سیکیورٹی کا اے بی سی: توثیق، اجازت، آڈیٹنگ؛ "
• «Kubernetes میں آٹو اسکیلنگ اور وسائل کا انتظام"(جائزہ اور ویڈیو رپورٹ)؛
• «Kubernetes میں ConfigMaps: باریکیوں کے بارے میں جاننے کے قابل'.

ماخذ: www.habr.com