‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

Autopilot Standard

בדף הזה מוסבר איך להגדיר ולהשתמש ב-Ingress למאזני עומסים של אפליקציות (ALB) פנימיים ב-Google Kubernetes Engine ‏(GKE). תעבורת נתונים נכנסת (Ingress) מספקת תמיכה מובנית באיזון עומסים פנימי באמצעות בקר תעבורת הנתונים הנכנסת (Ingress) של GKE.

למידע נוסף על התכונות שנתמכות ב-Ingress למאזני עומסים פנימיים של אפליקציות (ALB), ראו תכונות של Ingress. במאמר Ingress for internal Application Load Balancers (תעבורת נתונים נכנסת למאזני עומסים פנימיים של אפליקציות) מוסבר איך פועל Ingress למאזני עומסים פנימיים של אפליקציות.

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

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

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

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

דרישות ומגבלות

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

האשכול שלכם צריך להשתמש בגרסה של GKE שחדשה יותר מ-1.16.5-gke.10.
האשכול חייב להיות VPC-native.
התוסף HttpLoadBalancing צריך להיות מופעל באשכול. התוסף הזה מופעל כברירת מחדל. אסור להשבית אותו.
צריך להשתמש בקבוצות של נקודות קצה ברשת (NEG) כ-backends לשירות.
אי אפשר להפעיל גישה גלובלית למאזן העומסים הפנימי של האפליקציות. אם אתם צריכים גישה גלובלית, מומלץ לפרוס שער פנימי.

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

בתרגילים הבאים מוסבר איך לפרוס Ingress למאזני עומסים פנימיים של אפליקציות (ALB):

הכנת הסביבה.
יוצרים אשכול.
פריסת אפליקציה.
פריסת שירות.
פריסת Ingress.
מאמתים את הפריסה.
מחיקת משאבי Ingress.

הכנת הסביבה

כדי לפרוס משאבי מאזן עומסים באמצעות Kubernetes Ingress API, צריך להכין את סביבת הרשת כך שניתן יהיה לפרוס את שרתי ה-proxy של מאזן העומסים באזור נתון.

יוצרים תת-רשת לשרת proxy בלבד:

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23

מחליפים את מה שכתוב בשדות הבאים:

‫COMPUTE_REGION: a אזור Compute Engine.
‫NETWORK_NAME: שם הרשת של רשת המשנה.

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

יצירת כלל חומת אש

בקר ה-Ingress לא יוצר כלל חומת אש כדי לאפשר חיבורים משרתי ה-proxy של מאזן העומסים בתת-הרשת של ה-proxy. צריך ליצור את כלל חומת האש הזה באופן ידני. עם זאת, בקר תעבורת הנתונים הנכנסת (ingress) יוצר כללי חומת אש כדי לאפשר תעבורת נתונים נכנסת (ingress) ל Google Cloud בדיקות תקינות.

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

gcloud compute firewall-rules create allow-proxy-connection \
    --allow=TCP:CONTAINER_PORT \
    --source-ranges=10.129.0.0/23 \
    --network=NETWORK_NAME

מחליפים את CONTAINER_PORT בערך של היציאה שה-Pod מאזין לה, למשל 9376.

יצירת אשכול

בקטע הזה, יוצרים אשכול המותאם ל-VPC שאפשר להשתמש בו עם Ingress למאזני עומסים של אפליקציות פנימיים. אפשר ליצור את האשכול הזה באמצעות Google Cloud CLI או מסוף Google Cloud .

gcloud

יוצרים אשכול באותה רשת כמו תת-הרשת של ה-proxy בלבד:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME: שם לאשכול.
‫COMPUTE_LOCATION: המיקום של Compute Engine של האשכול. צריך להשתמש באותו מיקום כמו ברשת המשנה של ה-proxy שיצרתם בקטע הקודם.

המסוף

נכנסים לדף Create an Autopilot cluster במסוף Google Cloud .
כניסה לדף Create an Autopilot cluster
בקטע Cluster basics (הגדרות בסיסיות של אשכול), מבצעים את הפעולות הבאות:
1. מזינים את השם של האשכול.
2. בקטע Location type, בוחרים Compute Engine region עבור האשכול. אתם צריכים להשתמש באותו אזור כמו רשת המשנה של ה-proxy שיצרתם בקטע הקודם.
בחלונית הניווט, לוחצים על Networking.
ברשימה Network, בוחרים את הרשת שבה רוצים ליצור את האשכול. הרשת הזו צריכה להיות באותה רשת VPC כמו תת-הרשת של ה-proxy.
ברשימה Node subnet, בוחרים את רשת המשנה של ה-proxy שיצרתם.
לוחצים על יצירה.

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

בקטע הזה אתם יוצרים פריסה.

כדי ליצור פריסה:

שומרים את קובץ המניפסט לדוגמה הבא בשם web-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hostname
  name: hostname-server
spec:
  selector:
    matchLabels:
      app: hostname
  minReadySeconds: 60
  replicas: 3
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4
        name: hostname-server
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 90

קובץ המניפסט הזה מתאר פריסה שמקשיבה בשרת HTTPS ביציאה 9376. הפריסה הזו גם מנהלת את ה-Pods של האפליקציה. כל Pod מריץ קונטיינר אחד של אפליקציה עם שרת HTTPS שמחזיר את שם המארח של שרת האפליקציה כתגובה. שם המארח שמוגדר כברירת מחדל ל-Pod הוא השם של ה-Pod. הקונטיינר מטפל גם בסיום מבוקר.

מחילים את המניפסט על האשכול:
```
kubectl apply -f web-deployment.yaml
```

פריסת שירות כקבוצה של נקודות קצה ברשת (NEG)

בקטע הזה יוצרים משאב Service. השירות בוחר את קונטיינרים של ה-backend לפי התוויות שלהם, כדי שבקר ה-Ingress יוכל לתכנת אותם כנקודות קצה של ה-backend. כדי להשתמש ב-Ingress עבור מאזני עומסים פנימיים של אפליקציות (ALB), צריך להשתמש בNEGs כבק-אנד. התכונה לא תומכת בקבוצות של מופעים כשרתי קצה עורפיים. מכיוון שנדרשים קצוות עורפיים של NEG, כשפורסים שירותים שנחשפים דרך Ingress, צריך להשתמש באנוטציית ה-NEG הבאה:

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

השירות שלכם יתויג אוטומטית ב-cloud.google.com/neg: '{"ingress": true}' אם כל התנאים הבאים יתקיימו:

אתם משתמשים באשכולות המותאמים ל-VPC.
אתם לא משתמשים ב-VPC משותף.
אתם לא משתמשים במדיניות רשת ב-Kubernetes של GKE.

ההערה מתווספת אוטומטית באמצעות MutatingWebhookConfiguration עם השם neg-annotation.config.common-webhooks.networking.gke.io. אפשר לבדוק אם MutatingWebhookConfiguration קיים באמצעות הפקודה הבאה:

kubectl get mutatingwebhookconfigurations

השימוש ב-NEGs מאפשר לבקר Ingress לבצע איזון עומסים שמקורו בקונטיינר. התנועה מאוזנת בעומס משרת ה-proxy של Ingress ישירות לכתובת ה-IP של ה-Pod, במקום לעבור דרך כתובת ה-IP של הצומת או דרך הרשת של kube-proxy. בנוסף, שערי מוכנות של Pod מוטמעים כדי לקבוע את התקינות של Pod מנקודת המבט של מאזן העומסים, ולא רק את בדיקות המוכנות והפעילות של Kubernetes. שערי מוכנות של Pod מבטיחים שלא תהיה ירידה בנפח התנועה במהלך אירועים במחזור החיים, כמו הפעלה של Pod, אובדן של Pod או אובדן של צומת.

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

Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"

קבוצת נקודות קצה של רשת (NEG) נוצרת רק כש-Ingress מפנה לשירות. ה-NEG לא יופיע ב-Compute Engine עד שגם ה-Ingress וגם השירות שאליו הוא מפנה יתקיימו. קבוצות NEGs הן משאב של תחום מוגדר, ובשביל אשכולות מרובי-תחומיים, נוצרת קבוצת NEG אחת לכל שירות בכל תחום.

כדי ליצור שירות:

שומרים את המניפסט לדוגמה הבא בתור web-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: hostname
  namespace: default
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - name: host1
    port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    app: hostname
  type: ClusterIP

החלת המניפסט על האשכול:
```
kubectl apply -f web-service.yaml
```

פריסת Ingress

בקטע הזה, יוצרים משאב Ingress שמפעיל את הפריסה של מאזן עומסים ב-Compute Engine דרך בקר Ingress. כדי להשתמש ב-Ingress למאזני עומסים פנימיים של אפליקציות (ALB), צריך להוסיף את האנוטציה הבאה:

annotations:
    kubernetes.io/ingress.class: "gce-internal"

אי אפשר להשתמש בשדה ingressClassName כדי לציין GKE Ingress. חובה להשתמש בהערה kubernetes.io/ingress.class. למידע נוסף, קראו את המאמר ההתנהגות של בקר Ingress ב-GKE.

כדי ליצור Ingress:

שומרים את קובץ המניפסט לדוגמה הבא בשם internal-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  defaultBackend:
    service:
      name: hostname
      port:
        number: 80

החלת המניפסט על האשכול:
```
kubectl apply -f internal-ingress.yaml
```

אימות של פריסת Ingress מוצלחת

בקטע הזה אפשר לוודא שהפריסה בוצעה בהצלחה.

יכול להיות שיעברו כמה דקות עד שהמשאב Ingress יוקצה באופן מלא. במהלך הזמן הזה, בקר ה-Ingress יוצר פריטים כמו כללי העברה, שירותים לקצה העורפי, מפות URL ו-NEGs.

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

kubectl get ingress ilb-demo-ingress

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

NAME               HOSTS    ADDRESS            PORTS     AGE
ilb-demo-ingress   *        10.128.0.58        80        59s

כשהשדה ADDRESS מאוכלס, ה-Ingress מוכן. שימוש בכתובת RFC 1918 בשדה הזה מציין כתובת IP פנימית ב-VPC.

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

כדי לבצע שיחה באמצעות HTTP GET, מבצעים את השלבים הבאים:

כדי להגיע לכתובת ה-VIP של Ingress מתוך ה-VPC, צריך לפרוס מכונה וירטואלית באותו אזור ובאותה רשת כמו האשכול:
```
gcloud compute instances create l7-ilb-client \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --zone=COMPUTE_ZONE \
    --tags=allow-ssh
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SUBNET_NAME: השם של רשת משנה ברשת.
- ‫COMPUTE_ZONE: a אזור Compute Engine באזור.
מידע נוסף על יצירת מכונות זמין במאמר יצירה והפעלה של מכונה וירטואלית.
כדי לגשת לכתובת ה-VIP הפנימית מתוך המכונה הווירטואלית, משתמשים בכתובת curl:
1. מתחברים למכונה הווירטואלית (VM) שיצרתם בשלב הקודם באמצעות SSH:
```
gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE
```
2. משתמשים ב-curl כדי לגשת ל-VIP של האפליקציה הפנימית:
```
curl 10.128.0.58
hostname-server-6696cf5fc8-z4788
```
  תשובת HTTP מוצלחת ושם המארח של אחד ממכלי ה-Backend מציינים שכל נתיב איזון העומסים פועל בצורה תקינה.

מחיקת משאבי Ingress

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

כדי להסיר Ingress, פועלים לפי השלבים הבאים:

מוחקים את ה-Ingress. לדוגמה, כדי למחוק את ה-Ingress שיצרתם בדף הזה, מריצים את הפקודה הבאה:
```
kubectl delete ingress ilb-demo-ingress
```
כשמוחקים את ה-Ingress, נמחקים גם כללי ההעברה, השירותים לקצה העורפי ומפות כתובות ה-URL שמשויכים למשאב ה-Ingress הזה.
מוחקים את השירות. לדוגמה, כדי למחוק את השירות שיצרתם בדף הזה, מריצים את הפקודה הבאה:
```
kubectl delete service hostname
```
מחיקת השירות מסירה את ה-NEG שמשויך לשירות.

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

הקצאת כתובות IP סטטיות

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

אם רוצים כתובת IP קבועה שלא תלויה במחזור החיים של משאב ה-Ingress הפנימי, צריך לשמור כתובת IP פנימית סטטית אזורית. אחר כך אפשר לציין כתובת IP סטטית באמצעות ההערה kubernetes.io/ingress.regional-static-ip-name במשאב Ingress.

בדוגמה הבאה אפשר לראות איך להוסיף את ההערה הזו:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"

מחליפים את STATIC_IP_NAME בשם של כתובת IP סטטית שעומד בקריטריונים הבאים:

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

‫HTTPS בין הלקוח למאזן העומסים

תעבורת נתונים נכנסת (Ingress) לאיזון עומסים פנימי תומכת בהצגת אישורי TLS ללקוחות. אפשר להציג אישורי TLS באמצעות Kubernetes Secrets או באמצעות אישורי SSL אזוריים ששותפו מראש ב- Google Cloud. אפשר גם לציין כמה אישורים לכל משאב Ingress. גרסאות GKE מ-1.25 ואילך תומכות בשימוש בו-זמני ב-HTTPS וב-HTTP. כדי להפעיל את התכונה הזו, צריך ליצור כתובת IP סטטית עם PURPOSE=SHARED_LOADBALANCER_VIP ולהגדיר אותה ב-ingress. אם לא צוינה כתובת IP סטטית, רק תנועת HTTPS מותרת, וצריך לפעול לפי ההוראות במסמך השבתת HTTP.

בשלבים הבאים מוסבר איך ליצור אישור ב- Google Cloud ואז להציג אותו באמצעות Ingress ללקוחות פנימיים, גם לתנועת HTTPS וגם לתנועת HTTP:

יוצרים את האישור האזורי:
```
gcloud compute ssl-certificates create CERT_NAME \
    --certificate CERT_FILE_PATH \
    --private-key KEY_FILE_PATH \
    --region COMPUTE_REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CERT_NAME: שם לאישור שתבחרו.
- ‫CERT_FILE_PATH: הנתיב לקובץ האישור המקומי כדי ליצור אישור בניהול עצמי. האישור צריך להיות בפורמט PEM.
- ‫KEY_FILE_PATH: הנתיב לקובץ של מפתח פרטי מקומי. המפתח הפרטי צריך להיות בפורמט PEM ולהשתמש בהצפנה מסוג RSA או ECDSA.
- COMPUTE_REGION: אזור ב-Compute Engine לאישור.
שומרים כתובת IP סטטית ומחילים אותה לפי ההוראות במאמר כתובות IP סטטיות.

שומרים את קובץ המניפסט לדוגמה הבא בשם ingress-pre-shared-cert.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ing
  namespace: default
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME"
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 80

מחליפים את מה שכתוב בשדות הבאים:

‫DOMAIN: הדומיין שלכם.
‫CERT_NAME: השם של האישור שיצרתם בקטע הקודם.
‫SERVICE_NAME: השם של השירות.

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

kubectl apply -f ingress-pre-shared-cert.yaml

‫HTTPS בין מאזן העומסים לאפליקציה

אם האפליקציה פועלת ב-Pod של GKE ויכולה לקבל בקשות HTTPS, אפשר להגדיר את מאזן העומסים כך שישתמש ב-HTTPS כשהוא מעביר בקשות לאפליקציה. למידע נוסף, קראו את המאמר HTTPS (TLS) בין מאזן העומסים לאפליקציה.

VPC משותף

הוספה ידנית של הערת ה-NEG

אם ה-GKE שבו אתם פורסים את משאבי ה-Ingress נמצא בפרויקט שירות של VPC משותף, השירותים לא מקבלים אוטומטית את ההערה cloud.google.com/neg: '{"ingress": true}' כי לא מותקן MutatingWebhookConfiguration שאחראי להוספת ההערה לשירותים.

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

כללי חומת אש ב-VPC

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

בדוגמה הבאה מוצג אירוע שעשוי להופיע ביומנים של משאב Ingress. השגיאה הזו מתרחשת אם בקר 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 ומשאבי שירות ל-Ingress בשביל מאזני עומסים פנימיים של אפליקציות.

הערות Ingress

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

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

הערה	תיאור
`cloud.google.com/backend-config`	משתמשים באנוטציה הזו כדי להגדיר את שירות לקצה העורפי שמשויך ל-servicePort. מידע נוסף זמין במאמר בנושא הגדרת Ingress.
`cloud.google.com/neg`	משתמשים בהערה הזו כדי לציין שמאזן העומסים צריך להשתמש בקבוצות של נקודות קצה ברשת. מידע נוסף זמין במאמר שימוש באיזון עומסים שמקורם בקונטיינר.

פתרון בעיות

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

הנה כמה שלבים נפוצים לפתרון בעיות:

מוודאים שתעבורת הלקוח מגיעה מאותו אזור ומאותו VPC כמו מאזן העומסים.
מוודאים שה-Pods והקצה העורפי תקינים.
אימות נתיב התנועה אל כתובת ה-VIP ואל בדיקות תקינות של Compute Engine כדי לוודא שהוא לא נחסם על ידי כללי חומת אש.
בדיקת אירועי המשאבים של Ingress לאיתור שגיאות.
תיאור משאב ה-Ingress כדי לראות את המיפוי למשאבי Compute Engine.
מוודאים שמשאבי איזון העומסים של Compute Engine קיימים, שההגדרות שלהם נכונות ושלא דווחו שגיאות.

סינון אירועים של תעבורת Ingress

השאילתה הבאה מסננת שגיאות בכל אירועי הכניסה (Ingress) באשכול:

kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress

אפשר גם לסנן לפי אובייקטים או שמות של אובייקטים:

kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress

בשגיאה הבאה אפשר לראות שהשירות שאליו מתייחס ה-Ingress לא קיים:

LAST SEEN   TYPE      REASON      OBJECT                              MESSAGE
0s          Warning   Translate   ingress/hostname-internal-ingress   error while evaluating the ingress spec: could not find service "default/hostname-invalid"

בדיקת משאבים של מאזן עומסים ב-Compute Engine

הפקודה הבאה מציגה את הפלט המלא של משאב ה-Ingress, כדי שתוכלו לראות את המיפויים למשאבי Compute Engine שנוצרו על ידי בקר ה-Ingress:

kubectl get ing INGRESS_FILENAME -o yaml

מחליפים את INGRESS_FILENAME בשם הקובץ של משאב ה-Ingress.

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

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
      ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
      kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
      kubernetes.io/ingress.class: gce-internal
    creationTimestamp: "2019-10-15T02:16:18Z"
    finalizers:
    - networking.gke.io/ingress-finalizer
    generation: 1
    name: ilb-demo-ingress
    namespace: default
    resourceVersion: "1538072"
    selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    defaultBackend:
      service:
        name: hostname
        port:
          number: 80
  status:
    loadBalancer:
      ingress:
      - ip: 10.128.0.127
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

ההערות ingress.kubernetes.io/backends מפרטות את השרתים העורפיים ואת הסטטוס שלהם. מוודאים שהקצה העורפי מופיע כ-HEALTHY.

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

כדי להציג רשימה של כל כללי ההעברה ב-Compute Engine:

gcloud compute forwarding-rules list

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

NAME                                                        REGION       IP_ADDRESS      IP_PROTOCOL  TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b  REGION_NAME  10.128.15.225   TCP          REGION_NAME/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

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

gcloud compute backend-services list

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

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   REGION_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

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

gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
    --region COMPUTE_REGION

מחליפים את COMPUTE_REGION באזור של שירות הקצה העורפי ב-Compute Engine.

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

backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/ZONE_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
  healthStatus:
  - healthState: HEALTHY

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

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

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

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

דרישות ומגבלות

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

הכנת הסביבה

יצירת כלל חומת אש

יצירת אשכול

gcloud

המסוף

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

פריסת שירות כקבוצה של נקודות קצה ברשת (NEG)

פריסת Ingress

אימות של פריסת Ingress מוצלחת

מחיקת משאבי Ingress

הקצאת כתובות IP סטטיות

‫HTTPS בין הלקוח למאזן העומסים

‫HTTPS בין מאזן העומסים לאפליקציה

VPC משותף

הוספה ידנית של הערת ה-NEG

כללי חומת אש ב-VPC

סיכום של הערות פנימיות של Ingress

הערות Ingress

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

פתרון בעיות

סינון אירועים של תעבורת Ingress

בדיקת משאבים של מאזן עומסים ב-Compute Engine

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

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