آموزش کوبرنتیز؛ شب دهم: Probeهای Startup، Readiness و Liveness¶

امشب هر Probe را برای هدف درستش به کار می‌بریم و ثابت می‌کنیم Podی که Ready نیست، هیچ ترافیکی از Service دریافت نمی‌کند.

سه پرسش متفاوت¶

Readiness برای کنترل ترافیک است، نه Restart. Liveness آخرین راه بازیابی است، نه ابزار پایش Dependency. اگر Liveness دیتابیس را بررسی کند، یک رخداد دیتابیس می‌تواند همهٔ Podهای سالم برنامه را نیز Restart کند.

زمان Probe تقریباً از این رابطه پیروی می‌کند:

initial delay + (failure threshold × period)

به‌جای کپی کردن مقدارهای تصادفی، Timeout و رفتار واقعی برنامه را در محاسبه در نظر بگیرید.

Manifest برنامه¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: course-night-10
spec:
  replicas: 2
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - name: http
              containerPort: 80
          startupProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 2
            failureThreshold: 15
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 3
            failureThreshold: 2
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
            failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: course-night-10
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: http

استقرار و مشاهده¶

kubectl create namespace course-night-10
kubectl apply -f app.yaml
kubectl rollout status deployment/web --namespace course-night-10
kubectl get pods --namespace course-night-10
kubectl describe pod <pod-name> --namespace course-night-10
kubectl get endpointslices --namespace course-night-10 \
  -l kubernetes.io/service-name=web -o yaml

همهٔ Podهای Ready باید به‌صورت Endpoint آماده دیده شوند.

اثبات کنترل ترافیک با Readiness¶

فقط در readinessProbe.httpGet.path مسیر / را با /not-ready جایگزین کنید:

kubectl diff -f app.yaml
kubectl apply -f app.yaml
kubectl rollout status deployment/web --namespace course-night-10 --timeout=45s
kubectl get pods --namespace course-night-10
kubectl describe pod <new-pod-name> --namespace course-night-10
kubectl get endpointslices --namespace course-night-10 \
  -l kubernetes.io/service-name=web -o yaml

Containerهای جدید اجرا می‌شوند، اما Readiness با HTTP 404 شکست می‌خورد. با maxUnavailable: 0، Podهای قدیمی و Ready در Rollout متوقف‌شده باقی می‌مانند. بررسی کنید کدام IPها به‌عنوان Endpoint آماده ثبت شده‌اند؛ Pod جدیدی که Ready نیست نباید میان آن‌ها باشد.

مسیر را تعمیر و کامل شدن Rollout را بررسی کنید:

kubectl apply -f app.yaml
kubectl rollout status deployment/web --namespace course-night-10

تمرین خرابی Liveness¶

فقط مسیر Liveness را به /not-live تغییر دهید، Apply کنید و نتیجه را ببینید:

kubectl apply -f app.yaml
kubectl get pods --namespace course-night-10 --watch

پس از چند شکست متوالی، مقدار RESTARTS افزایش می‌یابد. Watch را متوقف و وضعیت Container قبلی را بررسی کنید:

kubectl describe pod <pod-name> --namespace course-night-10
kubectl logs <pod-name> --namespace course-night-10 --previous

یک HTTP Server که عمداً خطا برمی‌گرداند واقعاً از کار نیفتاده است؛ این تمرین نشان می‌دهد Liveness بیش‌ازحد سخت‌گیرانه چگونه می‌تواند خودش قطعی بسازد. مسیر را فوراً تعمیر و ثابت ماندن شمار Restartها را بررسی کنید.

قواعد طراحی Probe¶

• Endpointی ارزان و متعلق به خود برنامه را ترجیح دهید.
• Readiness می‌تواند توانایی ضروری سرویس‌دهی را بررسی کند، اما باید پایدار باشد.
• Liveness فقط شرایطی را آزمایش کند که Restart واقعاً قادر به تعمیر آن است.
• Startup باید کندترین راه‌اندازی معتبر را پوشش دهد.
• اگر یک ثانیه کافی نیست، timeoutSeconds را صریح تنظیم کنید.
• در محیط تولید، Latency و شکست Probeها را پایش کنید.

چک‌لیست پایان¶

• هر سه Probe را بدون یکی دانستن کاربردشان توضیح می‌دهم.
• ثابت کرده‌ام Pod ناآماده در Endpointهای آمادهٔ Service حضور ندارد.
• Restart ناشی از Liveness را ایجاد و عیب‌یابی کرده‌ام.
• هر دو خرابی را تعمیر و یک Rollout پایدار را بررسی کرده‌ام.

kubectl delete namespace course-night-10