آموزش Kubernetes - قسمت هفتم (Pod Healthcheck & Resouce Management)

در این پست با دو مفهوم در رابطه با پادها یعنی Pod Healthcheck و Pod Resource Management صحبت خواهم کرد.

اما قبل از اینکه به آنها بپردازم توجه شما را به چند نکته و دستور در کوبرنتیز جلب می کنم:

اگر به هر دلیل یکی از نودهای شما دچار مشکل شد و در حالت Not Ready بود در بسیاری از موارد، اجرای دستور زیر روی آن نود مشکل را برطرف می کند.

iptables -F ; systemctl restart containerd ; systemctl restart kubelet

مشاهده لیست namespace ها:

$ kubectl get ns
NAME              STATUS   AGE
cilium-secrets    Active   73d
default           Active   73d
kube-node-lease   Active   73d
kube-public       Active   73d
kube-system       Active   73d

ایجاد namespace جدید:

$ kubectl create ns newnamespace

$ kubectl create ns test-ns
namespace/test-ns created

Show Labels:

kubectl get po --show-labels
kubectl get po --selector=app=web

How to export/import images from/into containerd:

ctr -n k8s.io images import k8s-v1.35-all.tar
ctr -n k8s.io images export scheduler.tar registry.k8s.io/kube-scheduler:v1.35.0

نمونه ای از فایل pod manifest و نحوه apply کردن آن:

time-exporter.yaml

apiVersion: v1
kind: Pod
metadata:
 name: time-exporter
 labels:
   app: time
 namespace: time-app
spec:
 volumes:
  - name: time
    emptyDir: {}
 containers:
  - name: nginx
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    volumeMounts:
     - name: time
       mountPath: /usr/share/nginx/html

  - name: time-app
    image: mytime-exporter:v3.0.0
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - name: time
        mountPath: /export

apply کردن فایل manifest:

kubectl create ns time-app
kubectl apply -f time-exporter.yaml
kubectl expose pod -n time-app time-exporter --type=NodePort --port=80
kubectl get svc -n time-app

Pod Healthcheck

1. Liveness Probe

اگر fail شود، کوبر پاد را ریستارت می کند. یعنی برنامه نویس باید Endpoint ی را دراختیار ما قرار دهد که با fail شدن آن، کوبر برنامه را ریستارت کند و با ریستارت شدن برنامه، مشکل برطرف شود.

2. Readiness Probe

اگر fail شود کوبر درخواستی را به پاد نمی فرستد. یعنی برنامه نویس باید Endpoint ی را در اختیار ما قرار دهد که با fail شدن آن، کوبر ترافیکی را به سمت برنامه نفرستد و وقتی که true شد مجددا کوبر، ترافیک را سمت برنامه بفرستد و مشکل برطرف شده باشد.

3. Startup Probe

اگر fail شود یعنی هنوز برنامه به طور کامل بالا نیامده است.

برای چک کردن liveness سه روش وجود دارد:

1.1 Liveness Command:

یعنی ما داخل پاد، یک اسکریپتی را مثلا هر 5 ثانیه یکبار اجرا کنیم و اگر با موفقیت اجرا نشد (خروجی اجرا صفر نشد) یعنی برنامه مشکل دارد و باید ریستارت شود.

apiVersion: v1
kind: Pod
metadata:
 name: livenessprobe
 labels:
  app: sample
spec:
 containers:
  - name: liveness
    image: busybox:latest
    args:
     - /bin/sh
     - -c
     - touch /tmp/healthy ; sleep 30 ; rm -f /tmp/healthy ; sleep 600
    livenessProbe:
     exec:
      command:
       - cat
       - /tmp/healthy
     initialDelaySeconds: 5
     periodSeconds: 5

• args یا command بعد از بالا آمدن کانتینر اجرا می شوند. اگر در داکرفایل، CMD وجود نداشته باشد یا اینکه بخواهیم آن را override کنیم از args یا command استفاده می کنیم.

• دستور touch در لینوکس فایل می سازد.

• در مثال بالا، بعد از بالا آمدن کانتینر، یک فایل در مسیر tmp/healthy ایجاد می شود و 30 ثانیه بعد آن فایل حذف می شود.

• liveness command بعد از یک تاخیر 5 ثانیه ای در ابتدای کار، هر 5 ثانیه فایل tmp/healthy را می خواند، اگر نتواند فایل را بخواند خروجی ناموفق (غیر صفر) برمی گرداند. یعنی ما توقع داریم ابتدا liveness probe موفقیت آمیز باشد اما بعد از گذشت 30 ثانیه که فایل مذکور حذف شد، liveness probe ناموفق بوده و کوبرنتیز، پاد را ریستارت کند.

1.2 HttpGet

Response Code: 200~399 => ok

Response Code >= 400 => not ok

یعنی برنامه نویس آدرس یک endpoint را در اختیار کوبرنتیز قرار می دهد؛ اگر کوبر آن آدرس را فراخوانی کند و کد وضعیت 200 یا 300 برگردد همه چیز خوب است. ولی اگر کد وضعیت 400 یا 500 برگردد مشکلی در اجرا بوجود آمده است و پاد باید ریستارت شود.

apiVersion: v1
kind: Pod
metadata:
 name: liveness
 labels:
  app: v1
spec:
 containers:
  - name: myapp
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
     - liveness
    livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
       httpHeaders:
         - name: Custom-Header
           value: Awesome
     initialDelaySeconds: 3
     periodSeconds: 3

• registry.k8s.io/e2e-test-images/agnhost یک ایمیج آموزشی است که سایت کوبرنتیز منتشر کرده است.

• در فراخوانی httpGet می توانیم هدر مشخصی را هم ارسال کنیم و httpGet فقط به درخواستهایی پاسخ می دهد که این هدر را داشته باشند. این کار برای این منظور است که httpGet فقط توسط liveness probe فراخوانی شود.

1.3 Check port

درست مانند httpGet است منتها در این روش بجای چک کردن یک endpoint، یک پورت چک می شود. اگر listen می کرد یعنی همه چیز خوب است ولی اگر listen نمی کرد یعنی مشکلی در اجرای برنامه رخ داده است و پاد باید ریستارت شود.

apiVersion: v1
kind: Pod
metadata:
 name: liveness
 labels:
  app: v1
spec:
 containers:
  - name: myapp
    image: registry.k8s.io/goproxy:0.1
    ports:
     - containerPort: 8080
    livenessProbe:
     tcpSocket:
       port: 8080
     initialDelaySeconds: 15
     periodSeconds: 10

نحوه تنظیم readiness دقیقا همانند liveness می باشد فقط بجای livenessProbe از عبارت readinessProbe استفاده می کنیم. یک کانتینر می تواند یکی از این دو را و یا هر دو را همزمان داشته باشد.

Pod Resouce Management

• requests.memory

• requests.cpu

• limits.memory

• limits.cpu

مقدار request مقداری است که حتما باید در اختیار کانتینر قرار داده شود و کوبر آن را گارانتی می کند. حتی اگر مصرف کانتینر کمتر از مقدار request هم باشد باز هم مقدار request برای کانتینر رزرو شده است.

کوبر موقعی که کانتنر را بالا می آورد به دنبال نودی می گردد که منابع درخواست شده به میزان Request را داشته باشد و پاد را روی آن بالا می آورد. اگر منابع به میزان request روی هیچ نودی وجود نداشته باشد، کوبر نمی تواند پاد را بالا بیاورد و منتظر آزاد شدن منابع می ماند.

مقدار limit مقداری است که بیشتر از آن در اختیار کانتینر قرار داده نمی شود. یعنی حداکثر مقدار منابعی است که کوبر در اختیار کانتینر قرار می دهد.

توجه داشته باشید که اگر یک برنامه تمام memory خود را استفاده کرده باشد به احتمال زیاد crash خواهد کرد چون قادر نیست پارامتر جدیدی را ایجاد کند و حافظه به آن تخصیص دهد. موقعی که یک کانتینر تمام memory تخصیص داده شده به خود را مصرف کند کوبر خطای OOM(Out Of Memory) می دهد.

apiVersion: v1
kind: Pod
metadata:
 name: nginx
 labels:
  app: web
spec:
 containers:
  - name: webapp
    image: docker.arvancloud.ir/nginx:latest
    imagePullPolicy: IfNotPresent
    resources:
     requests:
       memory: "512Mi"
       cpu: "500m"
     limits:
       memory: "1Gi"
       cpu: "1000m"

//m: milli core

* واحدها دو نوع‌اند:

دودویی (Binary)

• Ki = 1024 bytes (Kibibyte)

• Mi = 1024² bytes (Mebibyte)

• Gi = 1024³ bytes (Gibibyte)

ده‌دهی (Decimal)

• KB = 1000 bytes

• MB = 1000² bytes

• GB = 1000³ bytes

در تعیین منابع پادها ما باید به SLI و SLO و SLA توجه داشته باشیم.

این سه اصطلاح مربوط به Site Reliability Engineering (SRE) و مدیریت کیفیت سرویس هستند.

1. SLI

SLI = Service Level Indicator

یک شاخص قابل اندازه‌گیری برای سنجش عملکرد یا کیفیت سرویس است.

یعنی من خودم در نرم افزارم یکسری شاخص داشته باشم که مثلا اگر گفتند سیستم کند است من با مراجعه به آن شاخص ها بفهم کجا و چرا کند است.

مثال‌ها:

• درصد موفقیت درخواست‌ها

• زمان پاسخ (latency)

• نرخ خطا (error rate)

• availability

مثال:

99.95% of requests succeed

2. SLO

SLO = Service Level Objective

یک هدف مشخص برای SLI است؛ یعنی می‌گوییم مقدار شاخص باید در چه سطحی باشد.

یعنی خودمان بین تیم ها یک سری مواردی مشخص کنیم مثلا  Response time همه وب سرویسها باید حداکثر 200 میلی ثانیه باشد.

مثال:

99.9% availability per month

3. SLA

SLA = Service Level Agreement

SLA یعنی توافق‌نامه سطح خدمات؛ یک قرارداد رسمی و قانونی بین ارائه‌دهنده سرویس و مشتری که مشخص می‌کند:

• سرویس چه کیفیتی باید داشته باشد

• اگر کیفیت رعایت نشد، چه جریمه‌ها یا خسارت‌هایی پرداخت می‌شود

به زبان ساده: SLA یک قرارداد رسمی است، در حالی که SLO یک هدف داخلی برای تیم مهندسی است.

SLA شامل موارد زیر است:

• حداقل آپ‌تایم (Availability) تضمین‌شده

• حداکثر Latency قابل قبول

• میزان نرخ خطا (Error rate) مجاز

• زمان پاسخگویی پشتیبانی (Support response time)

• سیاست‌های جبران خسارت (Refunds / Credits)

مثال:

SLA: سرویس باید 99.9٪ در دسترس باشد،

وگرنه به ازای هر 1٪ کاهش آپ‌تایم، 10٪ اعتبار به مشتری بازگردانده می‌شود.