🥇راهنمای تصویری عیب یابی Kubernetes

توجه داشته باشید. ترجمه: این مقاله بخشی از مطالب پروژه منتشر شده در حوزه عمومی است Learnk8s، آموزش شرکت ها و مدیران فردی برای کار با Kubernetes. در آن، Daniele Polencic، مدیر پروژه، دستورالعمل‌های بصری را در مورد اقداماتی که در صورت بروز مشکلات عمومی در برنامه‌های در حال اجرا در کلاستر K8s باید انجام داد، به اشتراک می‌گذارد.

TL;DR: در اینجا نموداری وجود دارد که به شما کمک می کند استقرار در Kubernetes را اشکال زدایی کنید:

فلوچارت برای یافتن و رفع خطاها در یک خوشه. اصل (به زبان انگلیسی) در دسترس است PDF и همانند تصویر.

هنگام استقرار یک برنامه در Kubernetes، معمولاً سه مؤلفه وجود دارد که باید تعریف کنید:

گسترش - این یک نوع دستور العمل برای ایجاد کپی از برنامه است که به آن pods گفته می شود.
محصولات - متعادل کننده بار داخلی که ترافیک را بین غلاف ها توزیع می کند.
ورود - شرحی از نحوه انتقال ترافیک از دنیای خارج به سرویس.

در اینجا یک خلاصه گرافیکی سریع آمده است:

1) در Kubernetes، برنامه‌ها ترافیک را از دنیای بیرون از طریق دو لایه متعادل کننده بار دریافت می‌کنند: داخلی و خارجی.

2) متعادل کننده داخلی Service نامیده می شود و خارجی به نام Ingress.

3) Deployment پادها را ایجاد می کند و آنها را نظارت می کند (به صورت دستی ایجاد نمی شوند).

فرض کنید می خواهید یک برنامه کاربردی ساده را به صورت یک لا اجرا کنید سلام جهان. پیکربندی 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 استفاده کرد؟
آیا باید برای هر سرویس یک پورت جدید ایجاد کنم تا تداخل نداشته باشند؟
آیا نام برچسب مهم است؟ آیا آنها باید همه جا یکسان باشند؟

قبل از تمرکز بر اشکال زدایی، بیایید به یاد بیاوریم که این سه مؤلفه چگونه با یکدیگر ارتباط دارند. بیایید با Deployment and Service شروع کنیم.

رابطه بین استقرار و سرویس

تعجب خواهید کرد، اما استقرار و سرویس به هیچ وجه به هم مرتبط نیستند. در عوض، Service مستقیماً به Pods اشاره می‌کند و Deployment را دور می‌زند.

بنابراین، ما علاقه مند هستیم که Pods و Services چگونه با یکدیگر مرتبط هستند. سه چیز را باید به خاطر بسپارید:

انتخابگر (selector) برای سرویس باید حداقل با یک برچسب Pod مطابقت داشته باشد.
targetPort باید مطابقت داشته باشد containerPort ظرف داخل غلاف
port خدمات می تواند هر چیزی باشد. سرویس های مختلف می توانند از یک پورت استفاده کنند زیرا آدرس های 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 در بالای بخش Deployment؟ آیا باید مطابقت داشته باشد؟

این برچسب مخصوص استقرار است و توسط سرویس برای مسیریابی ترافیک استفاده نمی شود. به عبارت دیگر، می توان آن را حذف کرد یا مقدار متفاوتی را به آن اختصاص داد.

در مورد انتخابگر چطور matchLabels?

همیشه باید با برچسب های Pod مطابقت داشته باشد، زیرا توسط Deployment برای ردیابی پادها استفاده می شود.

بیایید فرض کنیم شما ویرایش های صحیح را انجام داده اید. چگونه آنها را بررسی کنیم؟

با دستور زیر می توانید برچسب pod را بررسی کنید:

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 port-forward service/<service name> 3000:80

در اینجا:

service/<service name> - نام سرویس؛ در مورد ما اینطور است my-service;
3000 پورتی است که باید روی کامپیوتر باز شود.
80 - پورت مشخص شده در فیلد port خدمات

اگر اتصال برقرار شد، پس تنظیمات درست است.

اگر اتصال قطع شود، برچسب ها مشکل دارد یا پورت ها مطابقت ندارند.

رابطه بین سرویس و ورودی

گام بعدی در ارائه دسترسی به برنامه شامل راه اندازی Ingress است. Ingress باید بداند چگونه یک سرویس را پیدا کند، سپس پادها را بیابد و ترافیک را به سمت آنها هدایت کند. Ingress سرویس مورد نیاز را با نام و پورت باز پیدا می کند.

در توضیحات Ingress و Service دو پارامتر باید مطابقت داشته باشند:

servicePort در Ingress باید با پارامتر مطابقت داشته باشد port در خدمت؛
serviceName در Ingress باید با زمینه مطابقت داشته باشد name در خدمت.

نمودار زیر اتصالات پورت را خلاصه می کند:

1) همانطور که می دانید، سرویس به یک مورد خاص گوش می دهد port:

2) Ingress یک پارامتر به نام دارد servicePort:

3) این پارامتر (servicePort) همیشه باید مطابقت داشته باشد port در تعریف سرویس:

4) اگر پورت 80 در Service مشخص شده باشد، لازم است که 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، اما به جای سرویس باید به کنترلر Ingress متصل شوید.

ابتدا باید نام غلاف را با کنترلر 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

Ingress pod را پیدا کنید (ممکن است در فضای نام دیگری باشد) و دستور را اجرا کنید 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 روی رایانه خود ارسال می کنید، با کنترلر Ingress به پورت 80 پاد ارسال می شود. با رفتن به http://localhost:3000، باید صفحه تولید شده توسط برنامه را ببینید.

خلاصه پورت ها

بیایید یک بار دیگر به یاد داشته باشیم که کدام پورت ها و برچسب ها باید مطابقت داشته باشند:

انتخابگر در تعریف سرویس باید با برچسب غلاف مطابقت داشته باشد.
targetPort در تعریف سرویس باید مطابقت داشته باشد containerPort ظرف داخل غلاف؛
port در تعریف سرویس می تواند هر چیزی باشد. سرویس های مختلف می توانند از یک پورت استفاده کنند زیرا آدرس های IP متفاوتی دارند.
servicePort ورود باید مطابقت داشته باشد port در تعریف خدمات؛
نام سرویس باید با فیلد مطابقت داشته باشد serviceName در ورود.

متأسفانه، دانستن چگونگی ساختار صحیح پیکربندی YAML کافی نیست.

چه اتفاقی می‌افتد وقتی همه چیز اشتباه می‌شود؟

غلاف ممکن است شروع نشود یا ممکن است خراب شود.

3 مرحله برای تشخیص مشکلات برنامه در Kubernetes

قبل از شروع اشکال زدایی استقرار خود، باید درک خوبی از نحوه عملکرد Kubernetes داشته باشید.

از آنجایی که هر برنامه دانلود شده در K8s دارای سه مؤلفه است، باید با ترتیب خاصی از پایین شروع شود.

ابتدا باید مطمئن شوید که غلاف ها کار می کنند، سپس ...
بررسی کنید که آیا سرویس ترافیک را به پادها می رساند یا خیر، و سپس...
بررسی کنید که آیا Ingress به درستی پیکربندی شده است.

نمایش تصویری:

1) باید از پایین به دنبال مشکلات باشید. ابتدا بررسی کنید که پادها دارای وضعیت هستند Ready и Running:

2) اگر غلاف ها آماده هستند (Ready، باید دریابید که آیا سرویس ترافیک را بین پادها توزیع می کند یا خیر:

3) در نهایت، باید ارتباط بین سرویس و Ingress را تجزیه و تحلیل کنید:

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اما در مورد دو مورد دیگر اینطور نیست.

چگونه بفهمیم چه اشتباهی رخ داده است؟

چهار دستور مفید برای تشخیص غلاف وجود دارد:

kubectl logs <имя pod'а> به شما امکان می دهد سیاهههای مربوط را از ظروف در یک غلاف استخراج کنید.
kubectl describe pod <имя pod'а> به شما امکان می دهد لیستی از رویدادهای مرتبط با غلاف را مشاهده کنید.
kubectl get pod <имя pod'а> به شما امکان می دهد پیکربندی YAML یک pod ذخیره شده در Kubernetes را دریافت کنید.
kubectl exec -ti <имя pod'а> bash به شما اجازه می دهد تا یک پوسته فرمان تعاملی را در یکی از کانتینرهای غلاف راه اندازی کنید

کدام را باید انتخاب کنید؟

واقعیت این است که هیچ فرمان جهانی وجود ندارد. ترکیبی از اینها باید استفاده شود.

مشکلات غلاف معمولی

دو نوع اصلی از خطاهای پاد وجود دارد: خطاهای راه اندازی و خطاهای زمان اجرا.

خطاهای راه اندازی:

ImagePullBackoff
ImageInspectError
ErrImagePull
ErrImageNeverPull
RegistryUnavailable
InvalidImageName

خطاهای زمان اجرا:

CrashLoopBackOff
RunContainerError
KillContainerError
VerifyNonRootError
RunInitContainerError
CreatePodSandboxError
ConfigPodSandboxError
KillPodSandboxError
SetupNetworkError
TeardownNetworkError

برخی از خطاها بیشتر از بقیه هستند. در اینجا برخی از رایج ترین خطاها و نحوه رفع آنها آورده شده است.

ImagePullBackOff

این خطا زمانی رخ می دهد که Kubernetes قادر به دریافت تصویر برای یکی از کانتینرهای غلاف نباشد. در اینجا سه دلیل رایج برای این امر آورده شده است:

نام تصویر نادرست است - به عنوان مثال، شما در آن اشتباه کرده اید، یا تصویر وجود ندارد.
یک تگ ناموجود برای تصویر مشخص شد.
تصویر در یک رجیستری خصوصی ذخیره می شود و Kubernetes اجازه دسترسی به آن را ندارد.

حذف دو دلیل اول آسان است - فقط نام و برچسب تصویر را اصلاح کنید. در مورد دومی، باید اعتبارنامه های رجیستری بسته شده را در Secret وارد کنید و پیوندهایی را به آن در پادها اضافه کنید. در اسناد Kubernetes یک مثال وجود دارد چگونه می توان این کار را انجام داد.

Crash Loop Back Off

Kubenetes خطا می دهد CrashLoopBackOff، اگر ظرف نمی تواند راه اندازی شود. این معمولا زمانی اتفاق می افتد که:

یک اشکال در برنامه وجود دارد که از راه اندازی آن جلوگیری می کند.
ظرف به اشتباه پیکربندی شده است;
تست Liveness بارها شکست خورده است.

باید سعی کنید از ظرف به سیاهههای مربوط برسید تا دلیل خرابی آن را بیابید. اگر دسترسی به گزارش‌ها دشوار است، زیرا کانتینر خیلی سریع راه‌اندازی مجدد می‌شود، می‌توانید از دستور زیر استفاده کنید:

kubectl logs <pod-name> --previous

این پیام های خطا را از تجسم قبلی ظرف نمایش می دهد.

RunContainerError

این خطا زمانی رخ می دهد که کانتینر شروع به کار نمی کند. این مربوط به لحظه قبل از راه اندازی برنامه است. معمولاً به دلیل تنظیمات نادرست ایجاد می شود، به عنوان مثال:

تلاش برای نصب یک حجم ناموجود مانند ConfigMap یا Secrets.
تلاش برای نصب یک حجم فقط خواندنی به عنوان خواندن و نوشتن.

این تیم برای تجزیه و تحلیل چنین خطاهایی مناسب است kubectl describe pod <pod-name>.

Pods در حالت معلق هستند

پس از ایجاد، غلاف در حالت باقی می ماند Pending.

چرا این اتفاق می افتد؟

در اینجا دلایل احتمالی وجود دارد (من فرض می کنم زمانبندی خوب کار می کند):

خوشه منابع کافی مانند قدرت پردازش و حافظه برای اجرای پاد ندارد.
شی در فضای نام مناسب نصب شده است ResourceQuota و ایجاد یک پاد باعث می شود که فضای نام از حد نصاب خارج شود.
پاد به حالت در انتظار است 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 خالی، دو گزینه ممکن است:

هیچ غلاف با برچسب صحیح وجود ندارد (نکته: بررسی کنید که آیا فضای نام به درستی انتخاب شده است).
خطایی در برچسب های سرویس در انتخابگر وجود دارد.

اگر لیستی از نقاط پایانی را می بینید اما هنوز نمی توانید به برنامه دسترسی داشته باشید، مقصر احتمالی یک اشکال است targetPort در توضیحات خدمات

چگونه عملکرد سرویس را بررسی کنیم؟

صرف نظر از نوع سرویس، می توانید از دستور استفاده کنید kubectl port-forward برای اتصال به آن:

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

در اینجا:

<service-name> - نام سرویس؛
3000 پورتی است که روی کامپیوتر باز می کنید.
80 - پورت در سمت سرویس.

3. تشخیص ورودی

اگر تا اینجا خوانده اید، پس:

غلاف ها به عنوان فهرست شده اند Running и Ready;
این سرویس با موفقیت ترافیک را بین پادها توزیع می کند.

با این حال، هنوز نمی توانید به برنامه دسترسی پیدا کنید.

این بدان معنی است که کنترل کننده Ingress به احتمال زیاد به درستی پیکربندی نشده است. از آنجایی که کنترلر Ingress یک جزء شخص ثالث در کلاستر است، بسته به نوع آن، روش های اشکال زدایی مختلفی وجود دارد.

اما قبل از اینکه به استفاده از ابزارهای ویژه برای پیکربندی Ingress متوسل شوید، می توانید کاری بسیار ساده انجام دهید. Ingress استفاده می کند serviceName и servicePort برای اتصال به سرویس باید بررسی کنید که آیا آنها به درستی پیکربندی شده اند یا خیر. با استفاده از دستور زیر می توانید این کار را انجام دهید:

kubectl describe ingress <ingress-name>

اگر ستون Backend خالی، احتمال خطای پیکربندی زیاد است. اگر پشتیبان ها در جای خود هستند، اما برنامه هنوز قابل دسترسی نیست، ممکن است مشکل مربوط به موارد زیر باشد:

ورود به تنظیمات دسترسی از اینترنت عمومی؛
تنظیمات دسترسی خوشه ای از اینترنت عمومی

با اتصال مستقیم به Ingress pod می توانید مشکلات زیرساخت را شناسایی کنید. برای انجام این کار، ابتدا غلاف Ingress Controller را پیدا کنید (ممکن است در فضای نام دیگری باشد):

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 است.

اگر نمی توانید کنترلر Ingress را به کار بیاندازید، باید آن را اشکال زدایی کنید.

انواع مختلفی از کنترلرهای Ingress وجود دارد. محبوب ترین ها Nginx، HAProxy، Traefik و غیره هستند. (برای اطلاعات بیشتر در مورد راه حل های موجود، رجوع کنید به بررسی ما - تقریبا ترجمه.) باید به راهنمای عیب یابی در مستندات کنترلر مربوطه مراجعه کنید. از آنجا که Ingress Nginx محبوب ترین کنترلر Ingress است که برای حل مشکلات مربوط به آن نکاتی را در مقاله قرار داده ایم.

اشکال زدایی کنترلر Ingress Nginx

پروژه Ingress-nginx دارای رسمی است پلاگین برای کوبکتل. تیم kubectl ingress-nginx قابل استفاده برای:

تجزیه و تحلیل لاگ ها، باطن ها، گواهی ها و غیره؛
اتصالات به Ingress؛
مطالعه پیکربندی فعلی

سه دستور زیر به شما در این امر کمک می کند:

kubectl ingress-nginx lint - چک ها nginx.conf;
kubectl ingress-nginx backend - باطن را کاوش می کند (مشابه با kubectl describe ingress <ingress-name>);
kubectl ingress-nginx logs - سیاهههای مربوط را بررسی می کند.

توجه داشته باشید که در برخی موارد ممکن است لازم باشد فضای نام صحیحی را برای کنترلر Ingress با استفاده از پرچم مشخص کنید --namespace <name>.

خلاصه

اگر نمی دانید از کجا شروع کنید، عیب یابی Kubernetes می تواند چالش برانگیز باشد. همیشه باید به مشکل از پایین به بالا برخورد کنید: با پادها شروع کنید و سپس به سرویس و Ingress بروید. تکنیک های اشکال زدایی شرح داده شده در این مقاله را می توان برای اشیاء دیگر مانند:

بیکار Jobs و CronJobs.
StatefulSets و DaemonSets.

من تشکر می کنم گرگلی ریسکو, دانیل وایبل и چارلز کریستراج برای نظرات و اضافات ارزشمند

PS از مترجم

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

راهنمای تصویری برای عیب یابی Kubernetes