شب ۲۵: تنظیمات پویای قابل‌انتقال¶

بخش ۲۵ از مجموعهٔ آموزش Traefik در ۳۰ شب؛ هر جلسه برای ۶۰ تا ۹۰ دقیقه مطالعه، تمرین عملی، بررسی نتیجه و تمرین رفع خرابی طراحی شده است. مثال‌ها مطابق منبع با Traefik Proxy v3.7 نوشته شده‌اند؛ برای محیط عملیاتی نسخهٔ اصلاحی آزموده‌شده یا digest مشخصی را ثابت کنید. تمرین‌ها را روی میزبان یا کلاستر آزمایشگاهی اجرا کنید.

فهرست کامل دورهٔ ترافیک در ۳۰ شب

هدف‌های یادگیری¶

• ساخت سیاست پویا برای استفادهٔ مجدد ارائه‌دهنده‌های مبتنی بر label و tag.
• استفادهٔ آگاهانه از بررسی سلامت، تلاش مجدد، مدارشکن، انتشار وزن‌دار و تنظیمات انتقال.
• پیاده‌کردن یک هدف مسیریابی در فضای نام ارائه‌دهنده‌های مختلف.

تمرین عملی: کتابخانهٔ سیاست با ارائه‌دهندهٔ فایل¶

# dynamic/platform.yml
http:
  middlewares:
    resilience:
      chain: {middlewares: [retry, breaker]}
    retry:
      retry: {attempts: 3, initialInterval: 100ms}
    breaker:
      circuitBreaker:
        expression: "NetworkErrorRatio() > 0.30"
    platform-headers:
      headers:
        contentTypeNosniff: true
        referrerPolicy: strict-origin-when-cross-origin
  services:
    app-v1:
      loadBalancer:
        healthCheck: {path: /health, interval: 10s, timeout: 2s}
        passHostHeader: true
        servers:
          - {url: "http://app-v1.internal:8080"}
    app-v2:
      loadBalancer:
        healthCheck: {path: /health, interval: 10s, timeout: 2s}
        servers:
          - {url: "http://app-v2.internal:8080"}
    app-rollout:
      weighted:
        healthCheck: {}
        services:
          - {name: app-v1, weight: 95}
          - {name: app-v2, weight: 5}
  routers:
    app:
      entryPoints: [websecure]
      rule: "Host(`app.example.test`)"
      middlewares: [resilience, platform-headers]
      service: app-rollout
      tls: {}

مسیریابی که هماهنگ‌کننده کشف کرده می‌تواند سیاست فایل را دوباره استفاده کند:

# Docker Compose label form
services:
  app:
    labels:
      traefik.http.routers.app.middlewares: resilience@file,platform-headers@file

معادل این ارجاع در CRDهای Kubernetes اغلب بهتر است به‌شکل Middleware یا زنجیرهٔ Middleware در خود Kubernetes مدل شود، چون حاکمیت namespace مهم است. اگر ارجاع میان ارائه‌دهنده‌ها مجاز است، در نسخهٔ ۳٫۷ به بعد crossProviderNamespaces را محدود کنید.

curl -fsS http://127.0.0.1:8080/api/rawdata > rawdata.json
curl -sk --resolve app.example.test:443:127.0.0.1 https://app.example.test/
for i in $(seq 1 200); do curl -sk https://app.example.test/ >/dev/null; done

در آزمون واقعی به‌جای -k از CA مورد اعتماد استفاده کنید؛ این گزینه فقط برای زمانی نشان داده شده که گواهی محلی آزمایشگاه وارد مخزن اعتماد نشده است. برای برآورد وزن، لاگ دسترسی و متریک‌ها را بررسی کنید و فقط پس از عبور از معیارهای پذیرش، وزن را به‌ترتیب از ۵ به ۲۵، ۵۰ و ۱۰۰ افزایش دهید.

فهرست طراحی¶

• نام‌ها مالک یا هدف را نشان می‌دهند و میان فایل‌ها و ارائه‌دهنده‌ها تعارض ندارند.
• ارجاع میان ارائه‌دهنده‌ها همیشه @provider دارد.
• فقط ترافیک idempotent یا قابل‌تکرار ایمن را دوباره ارسال کنید و رفتار بدنهٔ درخواست را بشناسید.
• آستانه‌های مدارشکن بر متریک تکیه دارند، نه حدس.
• مسیر سلامت آمادگی واقعی وابستگی‌ها را بدون بار اضافی زیاد بررسی می‌کند.
• تغییر وزن دارای اندازهٔ نمونه، آستانهٔ موفقیت و بازگشت فوری است.

نکته‌های عیب‌یابی¶

• بررسی سلامت همهٔ سرورها را خراب می‌داند: مسیر، scheme، نام میزبان یا وضعیت مورد انتظار اشتباه است.
• تلاش مجدد قطعی را تشدید می‌کند: تعداد تلاش زیاد است یا عملیات بالادستی idempotent نیست.
• وزن نادرست به نظر می‌رسد: نمونه کوچک است، نشست چسبنده وجود دارد یا لایهٔ توزیع بار دیگری دخیل است.
• شیء پیدا نمی‌شود: فضای نام ارائه‌دهنده یا نام متفاوت است؛ /api/rawdata را ایمن بررسی کنید.

خودآزمایی¶

1. چه چیزی اینجا قابل‌انتقال است؟ هدف و سیاست مسیریابی؛ نحوهٔ بیان و حاکمیت ویژهٔ هر ارائه‌دهنده همچنان فرق دارد.
2. چرا وزن را با متریک همراه می‌کنیم؟ تقسیم تنظیم‌شدهٔ ترافیک، مدرک سلامت canary نیست.
3. چه زمانی تلاش مجدد خطرناک است؟ درخواست غیر idempotent یا پرهزینه ممکن است تکرار یا تشدید شود.
4. اثبات کنید: وزن را تغییر دهید، توزیع را اندازه بگیرید، v2 را ناسالم کنید و ترافیک را فقط به نسخهٔ پایدار برگردانید.