دليل مرئي لاستكشاف أخطاء Kubernetes وإصلاحها

ملحوظة. ترجمة.: هذه المقالة جزء من مواد المشروع المتاحة مجانًا Learn8sالذي يعلم الشركات والمسؤولين الأفراد كيفية العمل مع Kubernetes. في ذلك ، يشارك دانييل بولينسيك ، قائد المشروع ، دليلًا مرئيًا حول الخطوات التي يجب اتخاذها إذا كانت هناك مشاكل عامة مع التطبيقات التي تعمل على مجموعة K8s.

TL ؛ DR: فيما يلي رسم تخطيطي لمساعدتك في تصحيح أخطاء نشر Kubernetes:

مخطط انسيابي للبحث عن الأخطاء وإصلاحها في مجموعة. الأصل (باللغة الإنجليزية) متاح في PDF и كصورة.

عند نشر تطبيق على Kubernetes ، هناك عادةً ثلاثة مكونات يجب تحديدها:

• قابل للفتح - هذه وصفة لإنشاء نسخ من التطبيق ، تسمى القرون ؛
• العطاء - موازن تحميل داخلي يوزع حركة المرور عبر القرون ؛
• دخول - وصف لكيفية انتقال حركة المرور من العالم الخارجي إلى الخدمة.

فيما يلي ملخص رسومي قصير:

1) في Kubernetes ، تتلقى التطبيقات حركة المرور من العالم الخارجي من خلال طبقتين من موازين التحميل: داخلية وخارجية.

2) يسمى الموازن الداخلي الخدمة ، أما الخارجي فهو الدخول.

3) يُنشئ النشر البودات ويراقبها (لا يتم إنشاؤها يدويًا).

لنفترض أنك تريد نشر تطبيق بسيط على غرار la مرحبا يا عالم. سيبدو تكوين YAML الخاص به كما يلي:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

التعريف طويل جدًا ومن السهل الخلط حول كيفية ارتباط المكونات ببعضها البعض.

على سبيل المثال:

• متى يجب علي استخدام المنفذ 80 ومتى يجب علي استخدام 8080؟
• هل يجب إنشاء منفذ جديد لكل خدمة حتى لا تتعارض؟
• هل أسماء العلامات مهمة؟ هل يجب أن يكونوا هم نفس الشيء في كل مكان؟

قبل أن نركز على تصحيح الأخطاء ، دعنا نلخص كيفية ارتباط المكونات الثلاثة ببعضها البعض. لنبدأ بالنشر والخدمة.

العلاقة بين النشر والخدمة

ستندهش ، لكن عمليات النشر والخدمات ليست متصلة بأي شكل من الأشكال. بدلاً من ذلك ، تشير الخدمة مباشرة إلى السنفات ، متجاوزة النشر.

وبالتالي ، فنحن مهتمون بكيفية ارتباط البودات والخدمات ببعضها البعض. ثلاثة أشياء يجب تذكرها:

1. محدد (selector) للخدمة يجب أن تتطابق مع تسمية Pod واحدة على الأقل.
2. targetPort يجب أن تتطابق containerPort حاوية داخل الجراب.
3. port يمكن أن تكون Service'a أي شيء. يمكن للخدمات المختلفة استخدام نفس المنفذ لأن لديهم عناوين IP مختلفة.

يمثل الرسم البياني التالي كل ما سبق في شكل رسومي:

1) تخيل أن الخدمة ترسل حركة المرور إلى حجرة معينة:

2) عند إنشاء جراب ، يجب عليك ضبط containerPort لكل وعاء في القرون:

3) عند إنشاء خدمة ، يجب أن تحدد port и targetPort. ولكن من خلال أي منهم يتم الاتصال بالحاوية؟

4) من خلال targetPort. يجب أن تتطابق مع containerPort.

5) لنفترض أن المنفذ 3000 مفتوح في الحاوية ثم القيمة targetPort يجب أن تكون هي نفسها.

في ملف YAML ، يتم استخدام الملصقات و ports / targetPort يجب أن تتطابق مع:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

ماذا عن الملصق track: canary في الجزء العلوي من قسم النشر؟ هل يجب أن تتطابق؟

هذه التسمية خاصة بالنشر ولا تستخدمها الخدمة لتوجيه حركة المرور. بمعنى آخر ، يمكن إزالته أو تعيين قيمة مختلفة له.

ماذا عن المحدد matchLabels?

يجب أن تتطابق دائمًا مع تسميات Pod، حيث يتم استخدامه بواسطة Deployment لتتبع القرون.

لنفترض أنك أجريت التعديلات الصحيحة. كيف تتحقق منها؟

يمكنك التحقق من ملصق الكبسولات باستخدام الأمر التالي:

kubectl get pods --show-labels

أو ، إذا كانت الكبسولات مملوكة لتطبيقات متعددة:

kubectl get pods --selector any-name=my-app --show-labels

حيث any-name=my-app هو تسمية any-name: my-app.

هل بقيت أي صعوبات؟

يمكنك الاتصال بجراب! لهذا تحتاج إلى استخدام الأمر port-forward في kubectl. يتيح لك الاتصال بالخدمة والتحقق من الاتصال.

kubectl port-forward service/<service name> 3000:80

هنا:

• service/<service name> - اسم الخدمة؛ في حالتنا هو my-service;
• 3000 هو المنفذ الذي تريد فتحه على الكمبيوتر ؛
• 80 - المنفذ المحدد في المجال port خدمة.

إذا تم إنشاء الاتصال بنجاح ، فستكون الإعدادات صحيحة.

إذا تعذر إنشاء الاتصال ، فهناك مشكلة في الملصقات أو أن المنافذ غير متطابقة.

العلاقة بين الخدمة والدخول

تتعلق الخطوة التالية في توفير الوصول إلى التطبيق بإعداد الدخول. يحتاج Ingress إلى معرفة كيفية العثور على الخدمة ، ثم العثور على الكبسولات وإرسال حركة المرور إليها. يجد Ingress الخدمة المطلوبة بالاسم والمنفذ المفتوح.

في وصف الدخول والخدمة ، يجب أن تتطابق معلمتان:

1. servicePort يجب أن يطابق Ingress المعلمة port في الخدمة؛
2. serviceName في Ingress يجب أن تتطابق مع الحقل name في الخدمة.

يلخص الرسم البياني التالي اتصالات المنفذ:

1) كما تعلم بالفعل ، تستمع الخدمة إلى البعض port:

2) Ingress له معلمة تسمى servicePort:

3) هذه المعلمة (servicePort) يجب أن تتطابق دائمًا port في تعريف الخدمة:

4) إذا تم تحديد المنفذ 80 في الخدمة ، فمن الضروري ذلك servicePort كانت أيضًا تساوي 80:

من الناحية العملية ، عليك الانتباه إلى الأسطر التالية:

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

كيف تتحقق مما إذا كان Ingress يعمل؟

يمكنك استخدام الطريقة مع kubectl port-forward، ولكن بدلاً من الخدمة ، تحتاج إلى الاتصال بوحدة التحكم في الدخول.

تحتاج أولاً إلى معرفة اسم الكبسولة باستخدام وحدة التحكم في الدخول:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

ابحث عن حجرة Ingress (قد تكون في مساحة اسم مختلفة) وقم بتشغيل الأمر describeلمعرفة أرقام المنافذ:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

أخيرًا ، اتصل بالجراب:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

الآن في كل مرة ترسل فيها طلبًا إلى المنفذ 3000 على الجهاز ، ستتم إعادة توجيهه إلى المنفذ 80 من جراب Ingress. الذهاب الى http://localhost:3000، يجب أن تشاهد الصفحة التي تم إنشاؤها بواسطة التطبيق.

ملخص حسب الموانئ

لنتذكر مرة أخرى المنافذ والتسميات التي يجب أن تتطابق:

1. يجب أن يتطابق المحدد في تعريف الخدمة مع تسمية الحجرة ؛
2. targetPort في تعريف الخدمة يجب أن يتطابق containerPort حاوية داخل جراب
3. port في تعريف الخدمة يمكن أن يكون أي شيء. يمكن للخدمات المختلفة استخدام نفس المنفذ لأن لديهم عناوين IP مختلفة ؛
4. servicePort يجب أن يتطابق الدخول port في تعريف الخدمة ؛
5. يجب أن يتطابق اسم الخدمة مع الحقل serviceName في الدخول.

للأسف ، لا يكفي معرفة كيفية هيكلة تكوين YAML بشكل صحيح.

ماذا يحدث عندما يحدث خطأ ما؟

قد لا يبدأ الكبسولة أو قد يتعطل.

3 خطوات لاستكشاف أخطاء التطبيقات في Kubernetes وإصلاحها

قبل أن تبدأ في تصحيح أخطاء النشر ، يجب أن يكون لديك فهم جيد لكيفية عمل Kubernetes.

نظرًا لوجود ثلاثة مكونات في كل تطبيق تم تنزيله في K8s ، قم بتصحيحها بترتيب معين ، بدءًا من الأسفل.

1. تحتاج أولاً إلى التأكد من عمل الكبسولات ، ثم ...
2. تحقق مما إذا كانت الخدمة تنقل حركة المرور إلى البودات ، ثم ...
3. تحقق مما إذا تم تكوين Ingress بشكل صحيح.

التمثيل المرئي:

1) ابدأ في البحث عن المشاكل من الأسفل. تأكد أولاً من أن البودات لها حالات Ready и Running:

2) إذا كانت الكبسولات جاهزة (Ready) ، يجب عليك معرفة ما إذا كانت الخدمة توزع حركة المرور بين القرون:

3) أخيرًا ، تحتاج إلى تحليل العلاقة بين الخدمة والدخول:

1. جراب التشخيص

في معظم الحالات ، تتعلق المشكلة بالجراب. تأكد من أن الكبسولات مدرجة باسم Ready и Running. يمكنك التحقق من ذلك باستخدام الأمر:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

في إخراج الأمر أعلاه ، يتم سرد آخر جراب باسم Running и Ready، ولكن هذا ليس هو الحال بالنسبة للاثنين الآخرين.

كيف نفهم الخطأ الذي حدث؟

هناك أربعة أوامر مفيدة لتشخيص القرون:

1. kubectl logs <имя pod'а> يسمح لك باستخراج السجلات من الحاويات في حجرة ؛
2. kubectl describe pod <имя pod'а> يسمح لك بمشاهدة قائمة الأحداث المرتبطة بالجراب ؛
3. kubectl get pod <имя pod'а> يسمح لك بالحصول على تهيئة YAML لحجرة مخزنة في Kubernetes ؛
4. kubectl exec -ti <имя pod'а> bash يسمح لك بتشغيل قذيفة أوامر تفاعلية في إحدى حاويات الكبسولة

أي واحد تختار؟

الحقيقة هي أنه لا توجد قيادة عالمية. يجب استخدام مزيج منهم.

مشاكل البود الشائعة

هناك نوعان رئيسيان من أخطاء البود: أخطاء بدء التشغيل وأخطاء وقت التشغيل.

أخطاء التشغيل:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

أخطاء وقت التشغيل:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

بعض الأخطاء أكثر شيوعًا من غيرها. فيما يلي بعض الأخطاء الأكثر شيوعًا وكيفية إصلاحها.

ImagePullBackOff

يحدث هذا الخطأ عندما يتعذر على Kubernetes الحصول على صورة لإحدى حاويات الكبسولة. فيما يلي الأسباب الثلاثة الأكثر شيوعًا لذلك:

1. اسم الصورة غير صحيح - على سبيل المثال ، أخطأت فيها ، أو أن الصورة غير موجودة ؛
2. تم تحديد علامة غير صالحة للصورة ؛
3. الصورة مخزنة في سجل خاص وليس لدى Kubernetes إذن للوصول إليها.

من السهل إصلاح السببين الأولين - ما عليك سوى إصلاح اسم الصورة والعلامة. في حالة الأخير ، من الضروري إدخال بيانات اعتماد للسجل الخاص في السر وإضافة روابط إليه في الكبسولات. في وثائق Kubernetes هناك مثال كيف يمكن القيام بذلك.

حلقة تحطم التراجع

Kubenetes يرمي خطأ CrashLoopBackOffإذا لم تتمكن الحاوية من البدء. يحدث هذا عادة عندما:

1. التطبيق به خطأ يمنعه من العمل ؛
2. حاوية تم تكوينه بشكل غير صحيح;
3. فشل اختبار الحياة مرات عديدة.

من الضروري محاولة الوصول إلى السجلات من الحاوية لمعرفة سبب فشلها. إذا كان الوصول إلى السجلات صعبًا بسبب إعادة تشغيل الحاوية بسرعة كبيرة ، يمكنك استخدام الأمر التالي:

kubectl logs <pod-name> --previous

يقوم بطباعة رسائل خطأ من التناسخ السابق للحاوية.

خطأ في تشغيل الحاوية

يحدث هذا الخطأ عندما يتعذر بدء تشغيل الحاوية. إنه يتوافق مع اللحظة التي تسبق بدء التطبيق. عادة ما يكون ناتجًا عن خطأ في التكوين ، مثل:

• محاولة تحميل وحدة تخزين غير موجودة مثل ConfigMap أو Secrets ؛
• محاولة تركيب وحدة تخزين للقراءة فقط للقراءة والكتابة.

الأمر مناسب تمامًا لتحليل مثل هذه الأخطاء. kubectl describe pod <pod-name>.

السنفات في حالة الانتظار

بعد الخلق ، يبقى الكبسولة في الحالة Pending.

لماذا يحدث هذا؟

فيما يلي الأسباب المحتملة (أفترض أن المجدول يعمل بشكل جيد):

1. لا تملك الكتلة موارد كافية ، مثل طاقة المعالجة والذاكرة ، لتشغيل الكبسولة.
2. يتم تعيين كائن في مساحة الاسم المناسبة ResourceQuota وسيؤدي إنشاء حجرة إلى خروج مساحة الاسم عن الحصة.
3. جراب مرتبط في انتظار PersistentVolumeClaim.

في هذه الحالة ، يوصى باستخدام الأمر kubectl describe وتحقق من القسم Events:

kubectl describe pod <pod name>

في حالة وجود أخطاء متعلقة ب ResourceQuotas، يوصى بعرض سجلات الكتلة باستخدام الأمر

kubectl get events --sort-by=.metadata.creationTimestamp

البودات ليست جاهزة

إذا كان الجراب مدرجًا باسم Running، ولكن ليس في الدولة Ready، يعني التحقق من جاهزيتها (مسبار الجاهزية) فشل.

عندما يحدث هذا ، لا يتصل الكبسولة بالخدمة ولا يتم إرسال أي حركة مرور إليها. فشل اختبار الجاهزية ناتج عن مشاكل في التطبيق. في هذه الحالة ، للعثور على الخطأ ، تحتاج إلى تحليل القسم Events في إخراج الأمر kubectl describe.

2. تشخيص الخدمة

إذا تم سرد البودات كـ Running и Ready، ولكن لا يوجد حتى الآن أي رد من التطبيق ، يجب عليك التحقق من إعدادات الخدمة.

تشارك الخدمات في توجيه حركة المرور إلى البودات اعتمادًا على تسمياتها. لذلك ، فإن أول شيء يجب فعله هو التحقق من عدد الكبسولات التي تعمل مع الخدمة. للقيام بذلك ، يمكنك التحقق من نقاط النهاية في الخدمة:

kubectl describe service <service-name> | grep Endpoints

نقطة النهاية هي زوج من قيم النموذج <IP-адрес:порт>، ويجب أن يكون زوج واحد على الأقل موجودًا في الإخراج (أي ، على الأقل جراب واحد يعمل مع الخدمة).

إذا القسم Endpoins فارغ ، هناك خياران:

1. لا توجد كبسولات تحمل التسمية الصحيحة (تلميح: تحقق مما إذا كانت مساحة الاسم صحيحة) ؛
2. هناك خطأ في تسميات الخدمة في المحدد.

إذا رأيت قائمة بنقاط النهاية ولكنك لا تزال غير قادر على الوصول إلى التطبيق ، فإن الجاني المحتمل هو خطأ في targetPort في وصف الخدمة.

كيف تتحقق مما إذا كانت الخدمة تعمل؟

بغض النظر عن نوع الخدمة ، يمكنك استخدام الأمر kubectl port-forward للاتصال به:

kubectl port-forward service/<service-name> 3000:80

هنا:

• <service-name> - اسم الخدمة؛
• 3000 هو المنفذ الذي تفتحه على الكمبيوتر ؛
• 80 - منفذ على جانب الخدمة.

3. تشخيص الدخول

إذا كنت قد قرأت هذا حتى الآن ، فحينئذٍ:

• يتم سرد القرون على أنها Running и Ready;
• توزع الخدمة بنجاح حركة المرور بين القرون.

ومع ذلك ، لا يزال يتعذر عليك "الوصول" إلى التطبيق.

هذا يعني أن وحدة التحكم في الدخول قد تم تكوينها بشكل خاطئ على الأرجح. نظرًا لأن وحدة التحكم Ingress عنصر طرف ثالث في الكتلة ، فهناك طرق تصحيح مختلفة اعتمادًا على نوعها.

ولكن قبل اللجوء إلى مساعدة الأدوات الخاصة لتكوين Ingress'a ، يمكنك القيام بشيء بسيط للغاية. يستخدم الدخول serviceName и servicePort للاتصال بالخدمة. تحتاج إلى التحقق مما إذا تم تكوينها بشكل صحيح. يمكنك القيام بذلك باستخدام الأمر:

kubectl describe ingress <ingress-name>

إذا كان العمود Backend فارغ ، هناك احتمال كبير لحدوث خطأ في التكوين. إذا كانت الخلفيات في مكانها ، ولكن التطبيق لا يزال يتعذر الوصول إليه ، فقد تكون المشكلة متعلقة بما يلي:

• الدخول إلى إعدادات الوصول من الإنترنت العام ؛
• مجموعة إعدادات الوصول من الإنترنت العام.

يمكنك تحديد مشاكل البنية التحتية عن طريق الاتصال مباشرة بحجرة Ingress. للقيام بذلك ، ابحث أولاً عن الكبسولة الخاصة بوحدة التحكم في الدخول (قد تكون في مساحة اسم مختلفة):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

استخدم الفريق describeلتعيين المنفذ:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

أخيرًا ، اتصل بالجراب:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

سيتم الآن إعادة توجيه جميع الطلبات الموجودة على المنفذ 3000 على الكمبيوتر إلى المنفذ 80 من الحجرة.

هل يعمل الآن؟

• إذا كان الأمر كذلك ، فإن المشكلة تكمن في البنية التحتية. من الضروري معرفة بالضبط كيف يتم توجيه حركة المرور إلى الكتلة.
• إذا لم يكن الأمر كذلك ، فإن المشكلة تكمن في وحدة التحكم في الدخول.

إذا لم تتمكن من تشغيل وحدة التحكم في Ingress ، فسيتعين عليك تصحيحها.

هناك العديد من أنواع أجهزة التحكم في الدخول. الأكثر شيوعًا هي Nginx و HAProxy و Traefik وما إلى ذلك. (لمزيد من المعلومات حول الحلول الحالية ، راجع مراجعتنا - تقريبا. ترجمة.) راجع دليل استكشاف الأخطاء وإصلاحها في الوثائق الخاصة بوحدة التحكم المناسبة. بسبب ال دخول Nginx هي وحدة التحكم الأكثر شيوعًا في Ingress ، وقد قمنا بتضمين بعض النصائح حول كيفية التعامل معها في هذه المقالة.

تصحيح أخطاء وحدة تحكم دخول Nginx

مشروع Ingress-nginx لديه مسؤول المساعد لـ kubectl. فريق kubectl ingress-nginx يمكن استخدامها ل:

• تحليل السجلات والخلفيات والشهادات وما إلى ذلك ؛
• اتصال Ingress'u ؛
• فحص التكوين الحالي.

ستساعدك الأوامر الثلاثة التالية في هذا:

• kubectl ingress-nginx lint - الفحوصات nginx.conf;
• kubectl ingress-nginx backend - يستكشف الخلفية (على غرار kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - يتحقق من السجلات.

يرجى ملاحظة أنه في بعض الحالات قد يكون من الضروري تحديد مساحة الاسم الصحيحة لوحدة التحكم في الدخول باستخدام العلم --namespace <name>.

ملخص

يمكن أن يكون استكشاف أخطاء Kubernetes وإصلاحها أمرًا صعبًا إذا كنت لا تعرف من أين تبدأ. يجب دائمًا التعامل مع المشكلة من الأسفل إلى الأعلى: ابدأ بالقرون ، ثم انتقل إلى الخدمة والدخول. يمكن تطبيق أساليب التصحيح الموضحة في المقالة على كائنات أخرى ، مثل:

• وظائف الخمول و CronJobs ؛
• StatefulSets و DaemonSets.

أعبر عن امتناني جيرجيلي ريسو, دانيال ويبل и تشارلز كريستيراج للتعليقات والإضافات القيمة.

PS من المترجم

اقرأ أيضًا على مدونتنا:

• «kubectl-debug plugin لتصحيح الأخطاء في كبسولات Kubernetes"؛
• «6 أخطاء نظام مسلية في تشغيل Kubernetes [وحلها]"؛
• «أدوات لمطوري التطبيقات التي تعمل على Kubernetes"؛
• «6 قصص عملية من حياتنا اليومية SRE ".

المصدر: www.habr.com