آموزش Kubernetes - قسمت سیزدهم (Backup-Gateway API)

1.Backup

فرض کنید ما دو تا دیتاسنتر با نام های DC-1 و DC-2 داشته باشیم و بخواهیم یک نسخه کامل از همه اپلیکیشن ها و دیتاهای دیتاسنتر1 را به عنوان Disaster روی دیتاسنتر2 هم داشته باشیم.

راه اول این است که ما یک کلاستر کوبر توزیع شده بین این دو دیتاسنتر داشته باشیم. یعنی یکی از نودهای مستر کلاستر در دیتاسنتر1 و نود مستر دیگر، در دیتاسنتر2 قرار بگیرند. و هر پاد را هم در نودهای worker دیتاسنتر1 و هم در نودهای worker دیتاسنتر2 اجرا کنیم.

برای انجام این کار می توان از مفهوم Affinity و Anti Affinity کمک گرفت.

راه دوم این است که ما با ابزاری مانند Velero در بازه های زمانی مختلف یک بکاپ از دیتاسنتر1 را در دیتاسنتر2 قرار دهیم.

برای انجام این کار باید ابزار Velero را روی کلاستر1 بالا بیاوریم (Velero بصورت پاد در کلاستر اجرا می شود) این Velero در بازه های زمانی مشخص شده، یک نسخه از همه پادها و اطلاعات موجود در کلاستر1 را ذخیره می کند.

برای ذخیره سازی این اطلاعات نیاز به یک storage داریم که S3 را پشتیبانی کند. توجه داشته باشید که این storage نباید داخل کلاستر1 یا 2 باشد زیرا در مواقعی که برای این کلاسترها مشکلی پیش بیاید و در دسترس نباشند، امکان دسترسی به storage باید وجود داشته باشد.

یک نسخه دیگر از Velero را هم در کلاستر2 بالا می آوریم. این نسخه بر خلاف نسخه اول، اطلاعات را در بازه های زمانی مشخص شده از storage خوانده و به کلاستر2 منتقل می کند.

راهنمای نصب Velero:

https://velero.io/docs/v1.6/basic-install

بعد از اینکه خود Velero را نصب کردیم، باید آن را کانفیگ و محل ذخیره سازی را برای آن تنظیم کنیم. این کار با دستور velero install انجام می شود.

velero install --provider velero.io/aws --bucket mybucket --backup-location-config region=ir-thr-at1,s3ForcePathStyle="true",s3Url=https://s3.ir-thr-at1.arvanstorage.ir --plugins velero/velero-plugin-for-aws:v1.0.0,digitalocean/velero-plugin:v1.0.0  --secret-file ./credentials

قبل از کانفیگ Velero ما باید محل ذخیره سازی بکاپ ها را مشخص کنیم. محل ذخیره سازی در پارامتر backup-location-config وارد می شود. به عنوان مثال فرض کنید ما یک باکت در آروان کلاد ایجاد کرده ایم و از آن به عنوان محل ذخیره سازی استفاده خواهیم کرد.

https://mybucket.s3.ir-thr-at1.arvanstorage.ir

توجه: قسمت اول آدرس در باکت آروان کلاد، نام bucket و قسمت میانی نام region می باشد.

برای اتصال به باکت همچنین نیاز است که access_key و secret_key داشته باشیم. این کلیدها به فرمت زیر و داخل فایل credentials تعریف می شوند.

credentials

[default]
aws_access_key_id=ee00744a-8d81-4989-8804-8868e3c51ff7
aws_secret_access_key=3e366632a7bda34cee72d3efa192c0c250fcb7b8

ایجاد بکاپ:

velero backup create nginx-backup --selector app=v1

شرح بکاپ:

velero backup describe nginx-backup

مشاهده لاگ:

velero backup logs nginx-backup

2.Gateway API

Gateway API نسل جدید مدیریت ترافیک در Kubernetes است که توسط جامعه Kubernetes توسعه داده شده تا محدودیت‌های Ingress را برطرف کند.

اگر بخواهم خیلی ساده بگویم:

• Ingress = راه‌حل قدیمی و ساده برای ورود ترافیک HTTP/HTTPS

• Gateway API = راه‌حل جدید، انعطاف‌پذیر و استاندارد برای مدیریت انواع ترافیک (HTTP، HTTPS، TCP، UDP، TLS و ...)

مشکل Ingress چه بود؟

فرض کنید یک برنامه دارید.

Internet
     │
     ▼
Ingress
     │
     ▼
Service
     │
     ▼
Pods

یک Ingress معمولی:

apiVersion: networking.k8s.io/v1
kind: Ingress

spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: api-service
            port:
              number: 80

برای کاربردهای ساده مناسب است.

اما مشکلاتی داشت:

• فقط HTTP/HTTPS را به خوبی پشتیبانی می‌کرد.

• هر Ingress Controller قابلیت‌های اختصاصی خودش را داشت.

• برای ویژگی‌هایی مانند Rate Limiting، Canary، Header Rewrite یا JWT باید از Annotationهای مخصوص هر کنترلر استفاده می‌کردید.

• اگر از کنترلری مانند NGINX به HAProxy مهاجرت می‌کردید، احتمالاً باید Annotationها را بازنویسی می‌کردید.
  

مثلاً:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /

اگر از کنترلر دیگری استفاده کنید، این Annotation دیگر کار نمی‌کند.

Gateway API چه چیزی اضافه می‌کند؟

Gateway API منابع Kubernetes را به چند بخش تقسیم کرده است تا هر بخش مسئولیت مشخصی داشته باشد.

مهم‌ترین منابع عبارت‌اند از:

• GatewayClass

• Gateway

• HTTPRoute

• TCPRoute

• TLSRoute

• UDPRoute

• GRPCRoute

در نتیجه، پیکربندی ساده‌تر و قابل توسعه‌تر می‌شود.

معماری Gateway API

               GatewayClass
                     │
                     ▼
                 Gateway
                     │
        ┌────────────┴────────────┐
        ▼                         ▼
   HTTPRoute                 TCPRoute
        │                         │
        ▼                         ▼
    Service A                 Service B
        │                         │
      Pods                      Pods

GatewayClass:

مشخص می‌کند از چه پیاده‌سازی استفاده می‌کنید.

مثلاً:

• NGINX Gateway

• Envoy Gateway

• Kong Gateway

• Istio

• Cilium

نمونه:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass

metadata:
  name: envoy

spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

این شبیه StorageClass در Storage یا IngressClass برای Ingress است.

Gateway:

Gateway همان Load Balancer یا Entry Point است.

مثلاً:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway

metadata:
  name: web-gateway

spec:
  gatewayClassName: envoy
  listeners:
  - protocol: HTTP
    port: 80
    name: http

در اینجا فقط تعریف می‌کنید که Gateway روی پورت ۸۰ به درخواست‌ها گوش دهد.

HTTPRoute:

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

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute

metadata:
  name: api-route

spec:
  parentRefs:
  - name: web-gateway

  hostnames:
   - example.com

  rules:
    - matches:
      - path:
          type: PathPrefix
          value: /api
    backendRefs:
      - name: api-service
        port: 80
        weight: 90

در این مثال:

/api
    │
    ▼
api-service

مثال کامل

فرض کنید دو سرویس دارید:

frontend-service
backend-service

می‌خواهید:

/
↓
frontend

/api
↓
backend

Gateway:

Internet
↓
Gateway

HTTPRoute:

/
↓
frontend-service

/api
↓
backend-service

به این ترتیب، مسئولیت Listener و مسئولیت Route از هم جدا شده‌اند.

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

در Ingress معمولاً یک فایل همه چیز را مشخص می‌کرد:

• پورت

• دامنه

• مسیرها

• TLS
  

در Gateway API این مسئولیت‌ها جدا شده‌اند.

مثلاً:

تیم زیرساخت:

Gateway

را مدیریت می‌کند.

اما تیم توسعه فقط:

HTTPRoute

خودش را ایجاد می‌کند.

بدون اینکه به تنظیمات Load Balancer دست بزند.

این موضوع برای سازمان‌های بزرگ بسیار مهم است.

قابلیت‌های پیشرفته

Gateway API به صورت استاندارد از قابلیت‌هایی مانند:

• Header Matching

• Header Rewrite

• URL Rewrite

• Traffic Splitting

• Canary Deployment

• Weight-based Routing

• gRPC

• TCP

• UDP

• TLS Passthrough

پشتیبانی می‌کند.

بدون اینکه وابسته به Annotationهای مخصوص یک Vendor باشید.

آیا Gateway API جایگزین Ingress شده است؟

در عمل، بله، اما به تدریج.

Ingress هنوز به‌طور گسترده استفاده می‌شود و توسط Kubernetes حذف نشده است، اما Gateway API مسیر آینده اکوسیستم Kubernetes محسوب می‌شود و بسیاری از پروژه‌ها و کنترلرها (مانند Envoy Gateway، Istio، Kong، Cilium و نسخه‌های جدید NGINX Gateway Fabric) روی آن سرمایه‌گذاری کرده‌اند.

آیا برای Gateway API باز هم به یک Controller نیاز داریم؟

بله. این نکته یکی از رایج‌ترین ابهام‌هاست.

Gateway API فقط تعریف استاندارد Resourceها (CRDها) را ارائه می‌دهد. برای اینکه این Resourceها واقعاً ترافیک را مدیریت کنند، باید یک Gateway Controller آن‌ها را پیاده‌سازی کند.

نمونه‌هایی از Gateway Controllerها عبارت‌اند از:

• NGINX Gateway Fabric

• Envoy Gateway

• Kong Gateway Operator

• Istio (با پشتیبانی از Gateway API)

• Cilium Gateway API

به عبارت دیگر:

• Ingress + Ingress Controller → مدیریت ترافیک

• Gateway API + Gateway Controller → مدیریت ترافیک با قابلیت‌های بیشتر
  

بنابراین Gateway API جایگزین Ingress Resource است، نه جایگزین خود Controller. همچنان برای اعمال تنظیمات و هدایت ترافیک به یک پیاده‌سازی (Controller) نیاز دارید.

How to install envoy gateway:

https://gateway.envoyproxy.io/v1.5/install/install-helm/