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

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

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

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

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

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

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

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

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

1. הכנת הסביבה
2. יצירת אשכול
3. פריסת אפליקציה.
4. פריסת שירות.
5. פריסת Ingress.
6. מאמתים את הפריסה.
7. מחיקת משאבי 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 יוצר כללי חומת אש כדי לאפשר תעבורת נתונים נכנסת לבדיקות תקינות. Cloud de Confiance

יוצרים כלל של חומת אש שמאפשר חיבורים משרתי ה-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 או מסוף Cloud de Confiance .

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

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

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

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

1. שומרים את קובץ המניפסט לדוגמה הבא בשם 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. הקונטיינר מטפל גם בסיום מבוקר.

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

   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 משותף.
• אתם לא משתמשים ב-GKE Network Policy.

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

kubectl get mutatingwebhookconfigurations

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

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

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

1. שומרים את קובץ המניפסט לדוגמה הבא בשם 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
   

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

   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. מידע נוסף זמין במאמר בנושא התנהגות של בקר GKE Ingress.

כדי ליצור Ingress:

1. שומרים את קובץ המניפסט לדוגמה הבא בשם 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
   

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

   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.

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

כדי לבצע קריאה ל-HTTP GET, מבצעים את השלבים הבאים:

1. כדי להגיע לכתובת ה-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 zone in the region.

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

2. כדי לגשת לכתובת ה-VIP הפנימית מתוך המכונה הווירטואלית, משתמשים ב-curl:

   1. מתחברים באמצעות SSH למכונה הווירטואלית שיצרתם בשלב הקודם:

      gcloud compute ssh l7-ilb-client \
          --zone=COMPUTE_ZONE
      

   2. משתמשים ב-curl כדי לגשת ל-VIP של האפליקציה הפנימית:

      curl 10.128.0.58
      hostname-server-6696cf5fc8-z4788
      

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

מחיקת משאבי Ingress

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

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

1. מוחקים את ה-Ingress. לדוגמה, כדי למחוק את ה-Ingress שיצרתם בדף הזה, מריצים את הפקודה הבאה:

   kubectl delete ingress ilb-demo-ingress
   

   מחיקת ה-Ingress מסירה את כללי ההעברה, את שירותי ה-Backend ואת מיפויי כתובות ה-URL שמשויכים למשאב ה-Ingress הזה.

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

   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 משותף.
• מפנים למשאב של כתובת ה-IP לפי השם שלו ולא לפי כתובת ה-IP. Cloud de Confiance by S3NS
• כתובת ה-IP צריכה להיות מתת-רשת באותו אזור כמו אשכול GKE. אפשר להשתמש בכל תת-רשת פרטית שזמינה באזור (חוץ מתת-הרשת של ה-proxy בלבד). למשאבי Ingress שונים יכולות להיות כתובות מתת-רשתות שונות.

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

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

בשלבים הבאים מוסבר איך ליצור אישור ב- Cloud de Confiance by S3NS ואז להציג אותו דרך Ingress ללקוחות פנימיים לתנועת HTTPS ו-HTTP:

1. יוצרים את האישור האזורי:

   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 של האישור.

2. שומרים ומקצים כתובת IP סטטית לפי ההוראות במאמר הקצאת כתובות IP סטטיות.

3. שומרים את קובץ המניפסט לדוגמה הבא בשם 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: השם של השירות.

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

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

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

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

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

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

פתרון בעיות

כדי להבין את מצב ה-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 מציגות את רשימת ה-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

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

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 למאזני עומסים חיצוניים של אפליקציות

• במאמר בנושא שירותים ב-GKE תוכלו לקרוא סקירה כללית על המושג.

• איך יוצרים מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ב-GKE

• להטמיע תעבורת נתונים נכנסת (ingress) פנימית בסיסית.