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

במדריך הזה נראה איך להפעיל אפליקציית אינטרנט מאחורי מאזן עומסים חיצוני של אפליקציות (ALB) באמצעות הגדרה של משאב 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 כדי ליצור מאזן עומסים חיצוני של אפליקציות (ALB). כללי המארח והתאמת הנתיבים במפת כתובות ה-URL של מאזן העומסים מפנים לשירות קצה עורפי אחד או יותר, כאשר כל שירות קצה עורפי תואם לשירות GKE מסוג NodePort, כפי שמצוין ב-Ingress. הבק-אנדים של כל שירות לקצה העורפי הם קבוצות של מכונות או קבוצות של נקודות קצה ברשת (NEGs). קבוצות NEG נוצרות כשמגדירים איזון עומסים ברמת הקונטיינר כחלק מההגדרה של Ingress. לכל שירות קצה עורפי, GKE יוצר Google Cloud בדיקת תקינות על סמך הגדרות בדיקת המוכנות של עומס העבודה שאליו מתייחס השירות המתאים של GKE.

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

מטרות

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

עלויות

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

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

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

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

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

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

  4. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

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

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

  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 termination: אפשר להגדיר את Ingress כדי לסיים את תעבורת ה-HTTPS באמצעות Cloud Load Balancer.

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

הסרת המשאבים

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

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

    .

    פרוקסי יעד תלוי שמתייחס ל<b>מפת URL</b> שמנוהל על ידי בקר 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

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