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

אפשר להיכנס אל איזון עומסים במסוף 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. לוחצים על Create Uptime Check (יצירת בדיקת זמני פעילות).

  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:

    שרת proxy לחלוקת העומס לא מקושר שמפנה למפת 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 ל-HTTP של יעד שנוצר באופן ידני ועדיין מפנה למפת URL k8s2-um-tlw9rhgp-default-my-ingress-9ifnni82 שנוצרה ונוהלה על ידי בקר Ingress.

    צריך למחוק את משאבי החזית שנוצרו באופן ידני (גם כלל העברה וגם שרת proxy לחלוקת העומס) לפני שמוחקים את ה-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

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