הגדרת Kubernetes Gateway API: תחליף ל-Ingress

בעת מעבר מ-Ingress ל-Gateway API, לקוחות נתקלים לעיתים קרובות בנעילת ספק: כל בקר Ingress משתמש ב-annotations משלו, ומעבר בין מימושים שונים דורש שכתוב מלא של המניפסטים. לדוגמה, 70% מהצוותים מבלים עד 3 שבועות בשכתוב כללים בעת החלפת בקרים. אנו מגדירים את Gateway API כתחליף תקני הפותר זאת באמצעות מודל מבוסס-תפקידים ו-CRDs אחידים. Gateway API v1.2 (יציב) מכסה ניתוב HTTP, gRPC ו-TCP—ועובד באופן זהה על Cilium, Envoy, Istio ו-Traefik. לפי התיעוד הרשמי של Gateway API, האימוץ גדל ב-30% משנה לשנה—זהו תקן הניתוב החדש ב-Kubernetes.

למה Gateway API במקום Ingress

Ingress קיים מאז Kubernetes 1.1 וצבר annotations ספציפיות לספקים, מה שהופך אותו ל-API שונה עבור כל בקר. Gateway API מחלק את האחריות לשלוש שכבות:

• GatewayClass—מגדיר את המימוש (הבקר). נוצר על ידי מנהלי האשכול.
• Gateway—נקודת כניסת התעבורה (פורטים, פרוטוקולים, TLS). נוצר על ידי צוות SRE.
• HTTPRoute / TCPRoute / GRPCRoute—כללי ניתוב. נוצרים על ידי מפתחים ב-namespaces שלהם.

היררכיה זו מבטלת את נקודת הכאב המרכזית: מפתחים כבר לא צריכים גישה ל-annotations הגלובליות של הבקר. הם מנהלים את ה-HTTPRoute שלהם, בעוד שצוות הפלטפורמה מנהל את ה-Gateway. הם לא חופפים.

Gateway API מהיר פי 2 להקמה עבור פריסות canary בהשוואה ל-Ingress עם annotations. אין צורך בכלים נוספים כמו Flagger או Argo Rollouts.

כיצד Gateway API פותר את נעילת הספק

ה-API האחיד מפשט את המימוש. בעת החלפת בקרים (לדוגמה, מ-Nginx Ingress ל-Envoy Gateway), יש צורך רק לשנות את ה-GatewayClass—כל ה-HTTPRoutes נשארים ללא שינוי. זה מקצר את זמן ההגירה פי 3 בהשוואה לשכתוב annotations. החיסכון הכולל בעלויות תחזוקה מגיע ל-40%.

אתגרים אמיתיים במהלך הפריסה הראשונה

Gateway API מתייצב החל מ-Kubernetes 1.28+, אך יש להתקין את ה-CRDs ידנית—הם לא מגיעים מובנים כברירת מחדל:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml 

לאחר מכן, יש צורך במימוש—הבקר. Gateway API עצמו הוא רק ה-API, לא מימוש. אפשרויות פופולריות: Cilium Gateway API, Envoy Gateway, Istio, Traefik (v3+), Kong Gateway Operator. השוואת מימושים:

הטעות הנפוצה ביותר: יצירת HTTPRoute שתלוי ללא ADDRESS. הסיבה היא שה-Gateway עדיין לא מוכן או שה-GatewayClass לא מזוהה על ידי הבקר. kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml יציג את התנאי: kubectl describe gateway my-gateway עם סיבה. בדרך כלל, או שהבקר לא מותקן או ששם ה-GatewayClass לא תואם למה שהבקר מצפה לו.

תרחיש שני: ניתוב בין-namespaces. HTTPRoute ב-namespace Programmed: False מנסה להתחבר ל-Gateway ב-namespace app. כברירת מחדל, זה אסור. יש לאפשר זאת במפורש דרך infra:

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
      tls:
        certificateRefs:
          - name: wildcard-tls
---

דוגמה ל-HTTPRoute עם פיצול תעבורה

Gateway API תומך בניתוב משוקלל באופן מובנה—משהו ש-Ingress הסטנדרטי חסר:

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: production
spec:
  parentRefs:
    - name: main-gateway
      namespace: infra
  hostnames:
    - "app.example.com"
  rules:
    - backendRefs:
        - name: app-v2
          port: 8080
          weight: 20
        - name: app-v1
          port: 8080
          weight: 80

20% תעבורה ל-v2, 80% ל-v1. Canary ללא ArgoCD, ללא Flagger—רק allowedRoutes. התאם בהדרגה את המשקלים ככל שהביטחון בגרסה החדשה גדל.

מה כוללת העבודה שלנו

• ביקורת של כללי Ingress קיימים ותצורת TLS
• התקנת CRDs של Gateway API ובחירת מימוש (Envoy Gateway / Cilium / Istio)
• הגדרת GatewayClass ו-Gateway עם TLS ותמיכה בין-namespaces
• המרת כללים מ-Ingress ל-HTTPRoute/GRPCRoute
• הגדרת פיצול תעבורה (canary, blue-green)
• תיעוד הארכיטקטורה החדשה
• הדרכת צוות על Gateway API
• אחריות לתפעול ותמיכה לאחר ההגירה

תהליך העבודה שלנו

1. ניתוח—ביקורת של Ingress קיים, זיהוי תלויות ובעיות פוטנציאליות. אנו בדרך כלל חושפים עד 15 תלויות annotations לא ברורות.
2. עיצוב—סכמה עבור GatewayClass, Gateway ו-Route; בחירת בקר. אנו מציעים 3 אפשרויות עם הערכות מורכבות.
3. יישום—התקנת CRDs, הגדרת Gateway, המרת כללים. יצירת סקריפטים להמרה המונית מ-Ingress ל-HTTPRoute.
4. בדיקות—אימות ניתוב, TLS, תמיכה בין-namespaces בסביבת staging. כיסוי של 100% מהמקרים.
5. פריסה—שלב אחר שלב לייצור עם גישת canary. אחריות לחזרה לאחור תוך 5 דקות.

לוחות זמנים ועלות

הקמת Gateway API בסיסית עם HTTPRoute ראשון—החל מיום אחד. הגירה מלאה מ-Ingress (עד 50 כללים) עם TLS ופיצול תעבורה—2–3 ימים. העלות מחושבת באופן אישי לאחר ביקורת. צור קשר להערכת פרויקט.

למהנדסים שלנו יש ניסיון של 5+ שנים ב-Kubernetes ו-50+ פרויקטי הגירה מוצלחים מ-Ingress ל-Gateway API. הזמן הגירה—קבל ייעוץ, ואנו נבחר את הפתרון הטוב ביותר עבור האשכול שלך.

הערה: למידע מפורט על פרוטוקולים ו-CRDs, עיין במאגר הרשמי של Gateway API.