הגדרת מאזן עומסים חיצוני של אפליקציות (ALB) עם Ingress

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

הדף הזה מיועד למומחי רשתות שתפקידם לתכנן את הרשת של הארגון, להתקין ציוד רשת, להגדיר אותו ולתת לו תמיכה. כדי לקבל מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בGoogle Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

רקע

‫Google Kubernetes Engine ‏ (GKE) מציע תמיכה משולבת בשני סוגים של Cloud Load Balancing לאפליקציה שזמינה לציבור:

  1. Ingress

  2. מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי

במדריך הזה משתמשים ב-Ingresses.

תעבורת נתונים נכנסת (Ingress)

כשמציינים kind: Ingress במניפסט של משאב, נותנים ל-GKE הוראה ליצור משאב Ingress. אפשר ליצור בקר Ingress בהתאמה אישית על ידי הוספת הערות ותמיכה בעומסי עבודה ובשירותים. אחרת, GKE מבצע קריאות מתאימות ל-API של Google Cloud Google Cloud כדי ליצור מאזן עומסים חיצוני של אפליקציות. כללי המארח והתאמת הנתיבים במפת כתובות ה-URL של מאזן העומסים מפנים לשירותי קצה עורפיים אחד או יותר, כאשר כל שירות קצה עורפי תואם לשירות GKE מסוג NodePort, כפי שמצוין ב-Ingress. הבק-אנדים של כל שירות לקצה העורפי הם קבוצות של מכונות או קבוצות של נקודות קצה ברשת (NEGs). קבוצות NEG נוצרות כשמגדירים איזון עומסים ברמת הקונטיינר כחלק מההגדרה של Ingress. לכל שירות לקצה העורפי,‏ GKE יוצר בדיקת תקינות על סמך הגדרות בדיקת המוכנות של עומס העבודה שאליו מתייחס השירות המתאים של GKE. Google Cloud

אם אתם חושפים שירות HTTP(S) שמתארח ב-GKE, איזון עומסים מסוג HTTP(S) היא השיטה המומלצת לאיזון עומסים.

מטרות

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

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אפשר להשתמש במחשבון התמחור.

יכול להיות שמשתמשים חדשים ב- Google Cloud זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

כדי להפעיל את Kubernetes Engine API:
  1. נכנסים ל דף Kubernetes Engine במסוף Google Cloud .
  2. יוצרים או בוחרים פרויקט.
  3. מחכים עד שממשק ה-API והשירותים הקשורים מופעלים. הפעולה יכולה להימשך כמה דקות.

  4. Verify that billing is enabled for your Google Cloud project.

מתקינים את כלי שורת הפקודה הבאים שמשמשים במדריך הזה:

  • הדגל gcloud משמש ליצירה ולמחיקה של אשכולות Kubernetes Engine. ‫gcloud כלול ב-gcloud CLI.
  • ‫kubectl משמש לניהול Kubernetes, מערכת תזמור האשכולות שמשמשת את Kubernetes Engine. אפשר להתקין את kubectl באמצעות gcloud: 
    gcloud components install kubectl

משכפלים את הקוד לדוגמה מ-GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/networking/load-balancing

הגדרת ברירות מחדל לכלי שורת פקודה gcloud

כדי לחסוך זמן בהקלדת מזהה הפרויקט ואפשרויות אזור Compute Engine בכלי gcloud של שורת הפקודה, אפשר להגדיר את ברירות המחדל: 
gcloud config set project project-id
gcloud config set compute/zone compute-zone

יצירת אשכול GKE

יוצרים אשכול GKE Autopilot:

gcloud container clusters create-auto loadbalancedcluster

פריסת אפליקציית אינטרנט

קובץ המניפסט הבא מתאר פריסה שמריצה את קובץ האימג' של קונטיינר אפליקציית האינטרנט לדוגמה בשרת HTTP ביציאה 8080:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  selector:
    matchLabels:
      run: web
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

החלת המשאב על האשכול:

kubectl apply -f web-deployment.yaml

חשיפת הפריסה בתוך האשכול

המניפסט הבא מתאר Service שמאפשר גישה לפריסת web בתוך אשכול הקונטיינרים:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web
  type: NodePort

  1. החלת המשאב על האשכול:

    kubectl apply -f web-service.yaml

    כשיוצרים שירות מסוג NodePort באמצעות הפקודה הזו, GKE מאפשר גישה לשירות במספר יציאה גבוה שנבחר באופן אקראי (למשל, 32640) בכל הצמתים באשכול.

  2. מוודאים שהשירות נוצר ושהוקצתה יציאת צומת:

    kubectl get service web
    פלט: 
    NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
web       NodePort   10.35.245.219   <none>        8080:32640/TCP   5m

    בדוגמה של הפלט, יציאת הצומת של שירות web היא 32640. בנוסף, חשוב לזכור שלא מוקצית כתובת IP חיצונית לשירות הזה. מכיוון שצמתי GKE לא נגישים חיצונית כברירת מחדל, יצירת השירות הזה לא מאפשרת גישה לאפליקציה מהאינטרנט.

כדי להפוך את אפליקציית שרת האינטרנט HTTP(S) לזמינה לציבור, צריך ליצור משאב Ingress.

יצירת משאב Ingress

‫Ingress הוא משאב Kubernetes שמכיל אוסף של כללים והגדרות לניתוב תנועת HTTP(S) חיצונית לשירותים פנימיים.

ב-GKE, ‏ Ingress מיושם באמצעות Cloud Load Balancing. כשיוצרים Ingress באשכול, GKE יוצר מאזן עומסים ב-HTTP(S) ומגדיר אותו להפניית תנועה לאפליקציה.

קובץ המניפסט הבא מתאר משאב Ingress שמפנה תנועה לשירות web:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  defaultBackend:
    service:
      name: web
      port:
        number: 8080

החלת המשאב על האשכול:

kubectl apply -f basic-ingress.yaml

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

כניסה לאפליקציה

כדי לגלות את כתובת ה-IP החיצונית של מאזן העומסים שמשרת את האפליקציה, מריצים את הפקודה הבאה:

kubectl get ingress basic-ingress
פלט: 
NAME            HOSTS     ADDRESS         PORTS     AGE
basic-ingress   *         203.0.113.12    80        2m

פותחים את כתובת ה-IP החיצונית של האפליקציה בדפדפן ורואים תגובת HTTP בטקסט פשוט, כמו בדוגמה הבאה:

Hello, world!
Version: 1.0.0
Hostname: web-6498765b79-fq5q5

אפשר להיכנס אל Load Balancing במסוף Google Cloud ולבדוק את משאבי הרשת שנוצרו על ידי בקר GKE Ingress.

(אופציונלי) הגדרת כתובת IP קבועה

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

כברירת מחדל, ‏ GKE מקצה כתובות IP חיצוניות זמניות לאפליקציות HTTP שנחשפות דרך Ingress. כתובות זמניות עשויות להשתנות. אם אתם מתכננים להפעיל את האפליקציה שלכם למשך זמן רב, אתם צריכים להשתמש בכתובת IP חיצונית סטטית.

שימו לב: אחרי שמגדירים כתובת IP סטטית למשאב Ingress, מחיקה של ה-Ingress לא מוחקת את כתובת ה-IP הסטטית שמשויכת אליו. חשוב לנקות את כתובות ה-IP הסטטיות שהגדרתם כשאתם כבר לא מתכננים להשתמש בהן שוב.

כדי להגדיר כתובת IP קבועה, מבצעים את השלבים הבאים:

  1. שמירת כתובת IP חיצונית סטטית בשם web-static-ip:

    gcloud

    gcloud compute addresses create web-static-ip --global

    Config Connector

    הערה: כדי לבצע את השלב הזה, צריך להשתמש ב-Config Connector. פועלים לפי הוראות ההתקנה כדי להתקין את Config Connector באשכול.

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeAddress
metadata:
  name: web-static-ip
spec:
  location: global
    כדי לפרוס את קובץ המניפסט הזה, מורידים אותו למחשב בתור compute-address.yaml ומריצים את הפקודה: 
    kubectl apply -f compute-address.yaml

  2. המניפסט basic-ingress-static.yaml מוסיף הערה ל-Ingress כדי להשתמש במשאב כתובת ה-IP הסטטית שנקרא web-static-ip:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "web-static-ip"
spec:
  defaultBackend:
    service:
      name: web
      port:
        number: 8080

    צפייה במניפסט:

    cat basic-ingress-static.yaml

  3. החלת המשאב על האשכול:

    kubectl apply -f basic-ingress-static.yaml

  4. בודקים את כתובת ה-IP החיצונית:

    kubectl get ingress basic-ingress

    מחכים עד שכתובת ה-IP של האפליקציה משתנה לכתובת ה-IP השמורה של משאב web-static-ip.

    יכול להיות שיעברו כמה דקות עד שמשאב ה-Ingress הקיים יתעדכן, מאזן העומסים (LB) יוגדר מחדש וכללי איזון העומסים יופצו בכל העולם. אחרי שהפעולה הזו מסתיימת, GKE משחרר את כתובת ה-IP הזמנית שהוקצתה קודם לאפליקציה.

(אופציונלי) הצגת כמה אפליקציות במאזן עומסים

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

המניפסט הבא מתאר פריסה עם גרסה 2.0 של אותה אפליקציית אינטרנט:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web2
  namespace: default
spec:
  selector:
    matchLabels:
      run: web2
  template:
    metadata:
      labels:
        run: web2
    spec:
      containers:
      - image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
        imagePullPolicy: IfNotPresent
        name: web2
        ports:
        - containerPort: 8080
          protocol: TCP

החלת המשאב על האשכול:

kubectl apply -f web-deployment-v2.yaml

המניפסט הבא מתאר שירות שחושף את web2 באופן פנימי לאשכול בשירות NodePort שנקרא web2:

apiVersion: v1
kind: Service
metadata:
  name: web2
  namespace: default
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: web2
  type: NodePort

החלת המשאב על האשכול:

kubectl apply -f web-service-v2.yaml

המניפסט הבא מתאר משאב Ingress ש:

  • מנתב את הבקשות עם הנתיב שמתחיל ב-/v2/ לשירות web2
  • מעבירה את כל שאר הבקשות אל web השירות
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: fanout-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: web
            port:
              number: 8080
      - path: /v2/*
        pathType: ImplementationSpecific
        backend:
          service:
            name: web2
            port:
              number: 8080

החלת המשאב על האשכול:

kubectl create -f fanout-ingress.yaml

אחרי הפריסה של Ingress, מריצים את הפקודה kubectl get ingress fanout-ingress כדי לגלות את כתובת ה-IP הציבורית של האשכול.

לאחר מכן, נכנסים לכתובת ה-IP כדי לוודא שאפשר להגיע לשתי האפליקציות באותו מאזן עומסים:

  • נכנסים אל http://<IP_ADDRESS>/ ורואים שהתגובה מכילה את Version: 1.0.0 (כי הבקשה מנותבת לשירות web)
  • נכנסים אל http://<IP_ADDRESS>/v2/ ורואים שהתגובה מכילה את Version: 2.0.0 (כי הבקשה מנותבת לשירות web2)

התו הכללי היחיד שאפשר להשתמש בו בשדה path של Ingress הוא התו *. התו * חייב להופיע אחרי קו נטוי (/) ולהיות התו האחרון בתבנית. לדוגמה, /*, /foo/* ו-/foo/bar/* הן תבניות תקינות, אבל *, /foo/bar* ו-/foo/*/bar לא תקינות.

דפוס ספציפי יותר מקבל עדיפות על פני דפוס פחות ספציפי. אם יש לכם גם /foo/* וגם /foo/bar/*, המערכת תתייחס ל-/foo/bar/bat כאילו הוא תואם ל-/foo/bar/*.

מידע נוסף על מגבלות הנתיב והתאמת התבניות זמין במסמכי התיעוד בנושא מיפויי כתובות URL.

(אופציונלי) מעקב אחרי הזמינות והחביון של השירות

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

אפשר ליצור בדיקת זמינות באמצעות מסוף Google Cloud, Cloud Monitoring API או ספריות הלקוח של Cloud Monitoring. Google Cloud מידע נוסף זמין במאמר בנושא ניהול בדיקות זמינות. כדי ליצור בדיקת זמני פעילות באמצעות מסוף Google Cloud :

  1. נכנסים לדף Services & Ingress במסוף Google Cloud .

    כניסה אל Services & Ingress

  2. לוחצים על השם של השירות שעבורו רוצים ליצור בדיקת זמינות.

  3. לוחצים על יצירת בדיקת זמינות.

  4. בחלונית Create Uptime Check, מזינים שם לבדיקת זמינות ולוחצים על Next כדי לעבור להגדרות Target.

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

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

  5. לוחצים על הבא כדי לעבור להגדרות של אימות תשובות.

  6. לוחצים על הבא כדי לעבור לקטע התראות והודעות.

    כדי לעקוב אחרי בדיקת זמני פעילות, אפשר ליצור כללי מדיניות התראות או להציג את לוח הבקרה של בדיקת זמני הפעילות. מדיניות התראות יכולה לשלוח לכם התראה באימייל או בערוץ אחר אם בדיקת זמן הפעולה שלכם נכשלת. מידע כללי על מדיניות התראות זמין במאמר מבוא להתראות.

    מוסבר איך ליצור מדיניות התראות כפעולה עצמאית.

  7. לוחצים על יצירה.

הערות

כברירת מחדל, Ingress מבצע בדיקת תקינות תקופתית על ידי שליחת בקשת GET בנתיב / כדי לקבוע את תקינות האפליקציה, ומצפה לתגובה מסוג HTTP 200. אם רוצים לבדוק נתיב אחר או לצפות לקוד תגובה אחר, אפשר להשתמש בנתיב מותאם אישית לבדיקת תקינות.

‫Ingress תומך בתרחישי שימוש מתקדמים יותר, כמו:

  • אירוח וירטואלי מבוסס-שם: אפשר להשתמש ב-Ingress כדי לעשות שימוש חוזר במאזן העומסים עבור כמה שמות דומיינים ותתי-דומיינים, וכדי לחשוף כמה שירותים בכתובת IP אחת ובמאזן עומסים אחד. כדי ללמוד איך להגדיר Ingress למשימות האלה, אפשר לעיין בדוגמאות של fanout פשוט ושל אירוח וירטואלי מבוסס-שם.

  • סיום HTTPS: אפשר להגדיר את Ingress כדי לסיים את תעבורת ה-HTTPS באמצעות Cloud Load Balancer.

כשמוחקים Ingress, בקר ה-Ingress של GKE מנקה באופן אוטומטי את המשאבים המשויכים (למעט כתובות IP סטטיות שמורות).

הסרת המשאבים

כדי לא לצבור חיובים לחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

  1. מוחקים כל כללי העברה ושרתי proxy של יעד שנוצרו באופן ידני ומפנים אל Ingress:

    פרוקסי יעד תלוי באוויר שמפנה למפת URL מנוהלת של בקר GKE Ingress יגרום למחיקה של Ingress להיכשל ב-GKE בגרסאות 1.15.4-gke.22 ואילך. כדאי לבדוק את משאב ה-Ingress כדי למצוא אירוע עם הודעת שגיאה שדומה להודעה הבאה: 

     Error during GC: error running load balancer garbage collection routine: googleapi: Error 400: The url_map resource 'projects/project-id/global/urlMaps/k8s2-um-tlw9rhgp-default-my-ingress-9ifnni82' is already being used by 'projects/project-id/global/targetHttpsProxies/k8s2-um-tlw9rhgp-default-my82-target-proxy', resourceInUseByAnotherResource

    בהודעת השגיאה שלמעלה, k8s2-um-tlw9rhgp-default-my82-target-proxy הוא שרת proxy של יעד HTTPS שנוצר באופן ידני ועדיין מפנה למפת ה-URL k8s2-um-tlw9rhgp-default-my-ingress-9ifnni82 שנוצרה ונוהלה על ידי בקר Ingress.

    צריך למחוק את משאבי ה-Frontend שנוצרו באופן ידני (גם כלל ההעברה וגם שרת היעד הפרוקסי) לפני שממשיכים במחיקה של Ingress.

  2. מוחקים את ה-Ingress: בשלב הזה מתבטלת ההקצאה של כתובת ה-IP החיצונית הזמנית ושל משאבי איזון העומסים שמשויכים לאפליקציה:

    kubectl delete ingress basic-ingress

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

    kubectl delete ingress fanout-ingress

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

    • אם פעלתם לפי 'אפשרות 1' כדי להמיר כתובת IP זמנית קיימת לכתובת IP סטטית, אתם צריכים להיכנס למסוףGoogle Cloud כדי למחוק את כתובת ה-IP הסטטית.

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

      gcloud compute addresses delete web-static-ip --global

  4. מחיקת האשכול: בשלב הזה יימחקו צמתי החישוב של אשכול הקונטיינרים ומשאבים אחרים, כמו פריסות באשכול:

    gcloud container clusters delete loadbalancedcluster

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