‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

העברת Ingress ל-Gateway API

טייס אוטומטי רגילה

בדף הזה מוסבר איך להעביר את ניהול התעבורה ב-Google Kubernetes Engine‏ (GKE) מ-Ingress API ל-Gateway API. ‫Gateway API מספק פתרון מנוהל מלא לטיפול בתנועת הנתונים של האפליקציה. Google Cloud

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

באופן כללי, אסטרטגיית המעבר כוללת את השלבים הבאים:

מגדירים את מאזן העומסים החדש.
הגדרת כללים לטיפול בתנועה נכנסת.
פורסים את ההגדרה החדשה ובודקים את זרימת התנועה לכתובת ה-IP החדשה של השער.
מעבירים את תנועת הנתונים בסביבת הייצור אל Gateway API.
מחיקת משאבי Ingress שנותרו.

הגדרת מאזן העומסים החדש

בשלב הזה פורסים משאב Kubernetes Gateway כדי לאזן את עומס התנועה באשכול GKE. כשפורסים משאב Gateway,‏ GKE מגדיר מאזן עומסים של אפליקציות בשכבה 7 כדי לחשוף טראפיק HTTP(S) לאפליקציות שפועלות באשכול. פורסים משאב Gateway אחד לכל אשכול או לכל מאזן עומסים שנדרש.

בדוגמה הבאה מוגדר מאזן עומסים גלובלי חיצוני של אפליקציות (ALB). כדי ליצור שער, שומרים את קובץ המניפסט הבא בשם gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

המניפסט שלמעלה מתאר שער שכולל את השדות הבאים:

‫gatewayClassName: gke-l7-global-external-managed: מציין את GatewayClass עבור שער זה. השער הזה משתמש במאזן עומסים גלובלי חיצוני של אפליקציות (ALB).
‫protocol: HTTP ו-port: 80: מציינים ששער חושף יציאה 80 לתנועת HTTP.

הגדרת כללי תנועה לתנועה נכנסת

משאבי ניתוב מגדירים כללים ספציפיים לפרוטוקול למיפוי תעבורה משער לשירותי קצה עורפי.

בשלב הזה, מתרגמים את מניפסט ה-Ingress למשאב HTTPRoute. כדי להמיר את מניפסט ה-Ingress, פועלים לפי השלבים בכלי ingress2gateway.

בדוגמה הזו אנחנו מניחים שיש לכם את משאב ה-Ingress הבא:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

אחרי שממירים את המניפסט באמצעות הכלי ingress2gateway, הפלט הוא מניפסט מתורגם של HTTPRoute.

שומרים את קובץ המניפסט לדוגמה הבא בשם httproute.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

שימו לב: השדה rules במניפסט של HTTPRoute תואם ישירות לכללי הניתוב שהוגדרו במניפסט המקורי של Ingress.

פריסה ובדיקה של ההגדרה החדשה

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

החלת המניפסטים של Gateway ו-HTTPRoute:

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

משיגים את כתובת ה-IP של השער. יכול להיות שיחלפו כמה דקות עד שהקצאת כתובת ה-IP תסתיים:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
הפלט הוא כתובת ה-IP החיצונית של השער, לדוגמה, 203.0.113.90.
בודקים את כתובת ה-IP החדשה של השער. משתמשים בפקודה curl הבאה כדי לשלוח בקשה לכתובת ה-IP ולציין את שם המארח cafe.example.com. לדוגמה:
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
מחליפים את 203.0.113.90 בכתובת ה-IP החיצונית שקיבלתם בשלב הקודם. הפלט מאשר שכתובת ה-IP החדשה של השער מעבירה את התנועה של cafe.example.com בצורה נכונה בלי לבצע חיפוש DNS.

הפניית התנועה לכתובת ה-IP החדשה של השער

בשלב הזה, מעבירים את תעבורת הנתונים הפעילה מה-Ingress הקודם אל ה-Gateway החדש על ידי עדכון רשומות ה-DNS כך שיפנו לכתובת ה-IP החדשה של ה-Gateway. השלבים המדויקים לעדכון רשומות DNS משתנים בהתאם לספק ה-DNS.

לדוגמה, אם הגדרתם cafe.example.com ב-Ingress, תצטרכו לאתר את רשומת A של cafe.example.com אצל ספק ה-DNS ולשנות את הערך של כתובת ה-IP הישנה של Ingress ל-203.0.113.90, שהיא כתובת ה-IP החדשה של Gateway.

אחרי שמעדכנים את רשומת ה-DNS, התנועה מתחילה לעבור מ-Ingress ל-Gateway, אבל המעבר לא מתרחש באופן מיידי אצל כל הלקוחות. שרתי DNS לפתרון שמות ששמרו במטמון את הרשומה הקודמת ימתינו עד שתוקף הערך של זמן החיים (TTL) של הרשומה יפוג, לפני שהם יבצעו שאילתה לגבי הרשומה שוב ויקבלו את כתובת ה-IP המעודכנת. לכן, כדאי להמשיך להפעיל את ה-Ingress הקיים ואת ה-Gateway החדש במקביל עד שתוודאו שהתנועה אל ה-Ingress פסקה. זה מצביע על כך שהפצת ה-DNS הושלמה והלקוחות כבר לא מופנים לכתובת ה-IP הישנה. כדי לוודא זאת, אפשר לעקוב אחרי התנועה במאזן העומסים או בבקר Ingress. מידע נוסף מופיע במאמר בנושא בדיקת ההפצה של DNS.

אם אתם משתמשים ב-Cloud DNS, אתם יכולים להשתמש במשקלים של יעדים כדי להעביר את תעבורת הנתונים בהדרגה מכתובת ה-IP הישנה לכתובת ה-IP החדשה. מידע נוסף זמין במאמר בנושא הגדרה של מדיניות ניתוב DNS ובדיקות תקינות.

מחיקת משאבי Ingress שנותרו

אחרי שמוודאים שהשער החדש פועל בצורה תקינה, מנקים את משאבי ה-Ingress הישנים.

מחיקת משאב Ingress:
```
kubectl delete ingress cafe-ingress
```
מסירים את הבקר ingress-nginx. לדוגמה, אם השתמשתם ב-Helm כדי להתקין את בקר, מריצים את הפקודה הבאה:
```
helm uninstall ingress-nginx -n ingress-nginx
```

השוואה בין התכונות של Ingress NGINX לבין התכונות של GKE Gateway

‫Gateway API מספק דרך סטנדרטית יותר להגדרת תעבורת נכנסת, ויש לו תכונות מקבילות לרוב התכונות הנפוצות כמו ניתוב, כותרות ופיצול תעבורה.

בטבלה הבאה מוצגת השוואה בין ההערות שמשמשות לתכונות נפוצות ב-Ingress Controller וב-Gateway API.

תכונה	הערה ב-Ingress	הערה ב-GKE Gateway	שוויון
ניתוב מבוסס-מארח	‫`spec.rules.host` באובייקט Ingress.	‫`hostnames` באובייקט HTTPRoute.	שוויון מלא.
ניתוב מבוסס-נתיב	‫`spec.rules.http.paths` באובייקט Ingress.	‫`rules.matches.path` באובייקט HTTPRoute.	שוויון מלא.
חלוקת התנועה	`nginx.ingress.kubernetes.io/canary` הערות.	‫`HTTPRoute` עם משוקלל `backendRefs`.	שוויון מלא. בנוסף, אתם יכולים לפצל את התנועה עם שליטה מדויקת.
CORS (שיתוף משאבים בין מקורות)	`nginx.ingress.kubernetes.io/enable-cors`	`HTTPRoute` עם מסנן `CORS`.	שוויון מלא. הערה: GKE Gateway מטיל מגבלות על מספר תבניות התווים הכלליים שאפשר להגדיר לכל מאזין או שם מארח
שכתוב של כתובות URL	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` עם מסנן `urlRewrite`.	שוויון חלקי. GKE Gateway תומך רק בהחלפות של קידומות.
מניפולציה של כותרות	`nginx.ingress.kubernetes.io/proxy-set-headers` או `add-headers`	‫`HTTPRoute` עם משנה `requestHeaderModifier` או מסנן `responseHeaderModifier`.	שוויון מלא.
אימות	`nginx.ingress.kubernetes.io/auth-url` לאימות חיצוני.	שרת proxy לאימות זהויות (IAP): `BackendPolicy` CRD. אחר: נדרש פה פתרון מותאם אישית יותר, אולי עם Service mesh או מסננים בהתאמה אישית.	שוויון חלקי. שרת proxy לאימות זהויות (IAP) הוא הדרך המומלצת לאבטח את שער הגישה, והוא מוגדר בקצה העורפי.