העברת Ingress ל-Gateway API

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

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

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

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

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

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

בדוגמה הבאה מוגדר מאזן עומסים גלובלי חיצוני של אפליקציות. כדי ליצור שער, שומרים את המניפסט הבא בשם 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 עבור השער הזה. הסוג Gateway הזה משתמש במאזן עומסים חיצוני גלובלי של אפליקציות.
• ‫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.

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

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

2. מקבלים את כתובת ה-IP של השער. יכול להיות שיחלפו כמה דקות עד שהקצאת כתובת ה-IP תסתיים:

   kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
   

   הפלט הוא כתובת ה-IP החיצונית של השער, לדוגמה, 203.0.113.90.

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

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

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

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

1. מחיקת משאב ה-Ingress:

   kubectl delete ingress cafe-ingress
   

2. מסירים את הבקר ingress-nginx. לדוגמה, אם השתמשתם ב-Helm כדי להתקין את בקר, מריצים את הפקודה הבאה:

   helm uninstall ingress-nginx -n ingress-nginx
   

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

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

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

המאמרים הבאים

• איך מאבטחים את שער התשלומים
• קרא כיצד פועל ניהול התנועה בשער Gateway.