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

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

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

לפני שקוראים את הדף הזה, חשוב להכיר את המושגים של רשתות GKE.

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

מפעילים את ממשק Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מוודאים שיש לכם אשכול קיים של Autopilot או Standard. כדי ליצור אשכול חדש, אפשר לעיין במאמר בנושא יצירת אשכול Autopilot.

הפעלת התוסף `HttpLoadBalancing`

צריך להפעיל את התוסף HttpLoadBalancing באשכול. התוסף הזה מופעל כברירת מחדל. ב-Autopilot clusters, אי אפשר להשבית את התוסף הזה.

אפשר להפעיל את התוסף HttpLoadBalancing באמצעות מסוף Google Cloud או Google Cloud CLI.

המסוף

נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

מעבר אל Google Kubernetes Engine
לוחצים על השם של האשכול שרוצים לשנות.
בקטע Networking, בשדה HTTP Load Balancing, לוחצים על Edit HTTP Load Balancing.
מסמנים את תיבת הסימון הפעלת איזון עומסים של HTTP.
לוחצים על שמירת השינויים.

gcloud

gcloud container clusters update CLUSTER_NAME --update-addons=HttpLoadBalancing=ENABLED

מחליפים את CLUSTER_NAME בשם האשכול.

יצירת כתובת IP סטטית

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

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

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

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

לחצו על תראו לי איך כדי לקרוא הסבר מפורט על המשימה ישירות במסוף Google Cloud :

תראו לי איך

יצירת פריסות ושירותים

יוצרים שתי פריסות עם שירותים בשמות hello-world-1 ו-hello-world-2:

שומרים את קובץ המניפסט הבא בשם hello-world-deployment-1.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment-1
spec:
  selector:
    matchLabels:
      greeting: hello
      version: one
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        version: one
    spec:
      containers:
      - name: hello-app-1
        image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
        env:
        - name: "PORT"
          value: "50000"

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

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

kubectl apply -f hello-world-deployment-1.yaml

שומרים את קובץ המניפסט הבא בשם hello-world-service-1.yaml:
```
apiVersion: v1
kind: Service
metadata:
  name: hello-world-1
spec:
  type: NodePort
  selector:
    greeting: hello
    version: one
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000
```
קובץ המניפסט הזה מתאר שירות עם המאפיינים הבאים:
- כל פוד שיש לו את התווית greeting: hello ואת התווית version: one הוא חלק מהשירות.
- ‫GKE מעביר בקשות שנשלחות לשירות ביציאת TCP‏ 60000 לאחד מ-Pods החברים ביציאת TCP‏ 50000.
- סוג השירות הוא NodePort, שנדרש אלא אם משתמשים באיזון עומסים מובנה בקונטיינר. אם משתמשים באיזון עומסים מקורי של קונטיינרים, אין הגבלה על סוג השירות, אבל מומלץ להשתמש בשירות מסוג type ClusterIP, אלא אם אתם צריכים במפורש את NodePort שסופק על ידי שירות NodePort. אין תמיכה בשירותי LoadBalancer כקצה עורפי של Ingress.
מחילים את המניפסט על האשכול:
```
kubectl apply -f hello-world-service-1.yaml
```

שומרים את קובץ המניפסט הבא בשם hello-world-deployment-2.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment-2
spec:
  selector:
    matchLabels:
      greeting: hello
      version: two
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        version: two
    spec:
      containers:
      - name: hello-app-2
        image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"
        env:
        - name: "PORT"
          value: "8080"

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

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

kubectl apply -f hello-world-deployment-2.yaml

שומרים את קובץ המניפסט הבא בשם hello-world-service-2.yaml:
```
apiVersion: v1
kind: Service
metadata:
  name: hello-world-2
spec:
  type: NodePort
  selector:
    greeting: hello
    version: two
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
```
קובץ המניפסט הזה מתאר שירות עם המאפיינים הבאים:
- כל פוד שיש לו את התווית greeting: hello ואת התווית version: two הוא חלק מהשירות.
- ‫GKE מעביר בקשות שנשלחות לשירות ביציאת TCP‏ 80 לאחד מה-Pods החברים ביציאת TCP‏ 8080.
מחילים את המניפסט על האשכול:
```
kubectl apply -f hello-world-service-2.yaml
```

יצירת Ingress

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

שומרים את קובץ המניפסט הבא בשם my-ingress.yaml:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    # If the class annotation is not specified it defaults to "gce".
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-world-1
            port:
              number: 60000
      - path: /v2
        pathType: ImplementationSpecific
        backend:
          service:
            name: hello-world-2
            port:
              number: 80
```
קובץ המניפסט הזה מתאר Ingress עם המאפיינים הבאים:
- יש שני סוגים של GKE Ingress. כדי לציין מחלקת Ingress, צריך להשתמש בהערה kubernetes.io/ingress.class. אי אפשר לציין GKE Ingress באמצעות spec.ingressClassName.
- ב-gce class מפעילים מאזן עומסים חיצוני של אפליקציות (ALB).
- הסיווג gce-internal פורס מאזן עומסים פנימי של אפליקציות.
- כשפורסים משאב Ingress בלי ההערות spec.ingressClassName ו-kubernetes.io/ingress.class, ‏ GKE יוצר מאזן עומסים של אפליקציות. זו אותה התנהגות שמתרחשת אם מציינים את ההערה kubernetes.io/ingress.class: gce. מידע נוסף זמין במאמר התנהגות של בקר GKE Ingress.
- ‫GKE יוצר Google Cloud backend Service לכל backend.service. כל אחד מהשירותים לקצה העורפי תואם לשירות Kubernetes, וכל שירות לקצה העורפי חייב להפנות אל Google Cloud בדיקת תקינות. הבדיקה הזו שונה מבדיקת פעילות או מוכנות של Kubernetes, כי היא מיושמת מחוץ לאשכול. מידע נוסף זמין במאמר בנושא בדיקות תקינות
- כשלקוח שולח בקשה למאזן העומסים עם נתיב כתובת ה-URL‏ /,‏ GKE מעביר את הבקשה לשירות hello-world-1 ביציאה 60000. כשלקוח שולח בקשה למאזן העומסים באמצעות נתיב ה-URL‏ /v2, ‏ GKE מעביר את הבקשה לשירות hello-world-2 ביציאה 80. מידע נוסף על המאפיינים path ו-pathType זמין במאמר נתיבי URL.
- אם רוצים לשמור כתובת IP חיצונית סטטית גלובלית, צריך לכלול הערה kubernetes.io/ingress.global-static-ip-name באובייקט Ingress כמו שמוצג כאן:
```
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: my-ingress
   annotations:
     kubernetes.io/ingress.global-static-ip-name: my-static-address
 ```
```
מחילים את המניפסט על האשכול:
```
kubectl apply -f my-ingress.yaml
```

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

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

צפייה ב-Ingress:
```
kubectl get ingress my-ingress --output yaml
```
בפלט מוצגת כתובת ה-IP של מאזן העומסים החיצוני של האפליקציות:
```
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.1
```
בודקים את הנתיב /:
```
curl LOAD_BALANCER_IP_ADDRESS/
```
מחליפים את LOAD_BALANCER_IP_ADDRESS בכתובת ה-IP החיצונית של מאזן העומסים.

הפלט אמור להיראות כך:
```
Hello, world!
Version: 1.0.0
Hostname: ...
```
אם הפלט כולל שגיאת 404, צריך להמתין כמה דקות.

בודקים את הנתיב /v2:

curl load-balancer-ip/v2

הפלט אמור להיראות כך:

Hello, world!
Version: 2.0.0
Hostname: ...

איך פועל Ingress לאיזון עומסים חיצוני

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

נתיבים של כתובות URL

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

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

באשכולות GKE שמריצים גרסאות מוקדמות מ-1.21.3-gke.1600, הערך הנתמך היחיד בשדה pathType הוא ImplementationSpecific. בקטעי קוד שמופעלים בגרסה 1.21.3-gke.1600 ואילך, גם הערכים Prefix ו-Exact נתמכים ב-pathType.

קבוצות של נקודות קצה ברשת

אם האשכול שלכם תומך באיזון עומסים מובנה בקונטיינרים, מומלץ להשתמש בקבוצות של נקודות קצה ברשת (NEGs). כשיוצרים Ingress, ‏ GKE יוצר מאזן עומסים של אפליקציות בפרויקט, וקבוצות NEG נוצרות בכל אזור שבו האשכול פועל. נקודות הקצה ב-NEG ונקודות הקצה של השירות נשמרות בסנכרון. ב-GKE מגרסה 1.17 ואילך, איזון עומסים שמקורם בקונטיינר מוגדר כברירת מחדל ולא דורש הערה מפורשת של cloud.google.com/neg: '{"ingress": true}' Service, בתנאים מסוימים. במקרים שבהם NEGs לא מוגדרים כברירת מחדל, אנחנו עדיין ממליצים מאוד להשתמש באיזון עומסים מובנה ב-Containers, אבל צריך להפעיל אותו באופן מפורש לכל שירות בנפרד. ההערה צריכה להיות מיושמת על השירותים באופן הבא:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

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

VPC משותף

אם אשכול GKE שבו אתם פורסים את משאבי ה-Ingress נמצא בפרויקט שירות, ואתם רוצים שמישור הבקרה של GKE ינהל את משאבי חומת האש בפרויקט המארח, צריך להעניק לחשבון השירות של GKE בפרויקט השירות את הרשאות ה-IAM המתאימות בפרויקט המארח, בהתאם להוראות שבמאמר ניהול משאבי חומת אש באשכולות עם VPC משותף. כך בקר התעבורה הנכנסת יכול ליצור כללי חומת אש כדי לאפשר תעבורת נתונים נכנסת ותעבורת נתונים של Google Cloud בדיקות תקינות.

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

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

אם אתם מעדיפים להקצות כללי חומת אש באופן ידני מפרויקט המארח, אתם יכולים להשתיק את האירועים firewallXPNError על ידי הוספת ההערה networking.gke.io/suppress-firewall-xpn-error: "true" למשאב Ingress.

סיכום של הערות על תעבורת נתונים נכנסת (ingress) חיצונית

אתם יכולים להשתמש בהערות הבאות כדי להגדיר את ההתנהגות של משאבי ה-Ingress החיצוניים ואובייקטי השירות המשויכים של Kubernetes.

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

הערה	תיאור
kubernetes.io/ingress.allow-http	המדיניות מציינת אם לאפשר תעבורת HTTP בין הלקוח לבין מאזן העומסים מסוג HTTP(S). הערכים האפשריים הם true ו-false. ברירת המחדל היא true. איך משביתים את HTTP
ingress.gcp.kubernetes.io/pre-shared-cert	אפשר להשתמש בהערה הזו כדי לצרף משאבי אישורים למשאבי GKE Ingress. מידע נוסף זמין במאמר בנושא שימוש בכמה אישורי SSL עם מאזני עומסים חיצוניים של אפליקציות.
kubernetes.io/ingress.global-static-ip-name	משתמשים בהערה הזו כדי לציין שמאזן העומסים צריך להשתמש בכתובת IP חיצונית סטטית שיצרתם קודם. כתובות IP סטטיות למאזני עומסים מסוג HTTP(S)
networking.gke.io/v1beta1.FrontendConfig	אפשר להשתמש בהערה הזו כדי להתאים אישית את ההגדרה שמוצגת ללקוח של מאזן העומסים. מידע נוסף זמין במאמר בנושא הגדרת Ingress.
networking.gke.io/suppress-firewall-xpn-error	במאזני עומסים של Ingress, אם ל-Kubernetes אין הרשאה מספקת לשנות את כללי חומת האש, נוצר אירוע `firewallXPNError` כל כמה דקות. ב-GLBC 1.4 ואילך, אפשר להשתיק את אירוע `firewallXPNError` על ידי הוספת הערה `networking.gke.io/suppress-firewall-xpn-error: "true"` למשאב ה-Ingress. כדי לבטל את ההשתקה, אפשר להסיר את ההערה הזו. הערכים האפשריים הם `true` ו-`false`. ערך ברירת המחדל הוא `false`.

הערות שירות שקשורות ל-Ingress

הערה	תיאור
cloud.google.com/app-protocols	משתמשים בהערה הזו כדי להגדיר את הפרוטוקול לתקשורת בין מאזן העומסים לבין האפליקציה. הפרוטוקולים האפשריים הם HTTP,‏ HTTPS ו-HTTP2.
cloud.google.com/backend-config	משתמשים בהערה הזו כדי להגדיר את שירות הקצה העורפי שמשויך ל-Service. מידע נוסף זמין במאמר בנושא הגדרת Ingress.
cloud.google.com/neg	אפשר להשתמש בהערה הזו כדי לציין שמאזן העומסים צריך להשתמש בקבוצות של נקודות קצה ברשת. אפשר לקרוא מידע נוסף במאמר בנושא שימוש באיזון עומסים שמקורם בקונטיינר.

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

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

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