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

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

Standard

במאמר הזה מוסבר איך להטמיע זמינות גבוהה לכתובות IP קבועות ב-Google Kubernetes Engine‏ (GKE) באמצעות איזון עומסים שמבוסס על בדיקות תקינות. למרות שבמיפוי של כתובות IP קבועות רגילות ממופה כתובת IP קבועה אחת ל-Pod אחד, איזון עומסים שמבוסס על בדיקות תקינות מאפשר לכם להפיץ תנועה מכתובת IP קבועה אחת או יותר על פני מאגר של Pods תקינים.

כדי לתבוע כתובות IP קבועות ספציפיות ולזהות אילו פודים מקבלים תנועה, יוצרים משאב מותאם אישית של GKEIPRoute. כשמשלבים את המשאב GKEIPRoute עם בדיקות תקינות אזוריות, GKE עוקב אחרי עומסי העבודה בשכבת הרשת ומנתב את התנועה רק לפודים שמוכנים לקבל אותה. אפשר גם להגדיר תרמילי גיבוי אופציונליים באמצעות אובייקט GKEIPRoute. ‫GKE מנתב תנועה רק לפודים האלה במצב המתנה אם כל הפודים הפעילים הראשיים נכשלים בבדיקת התקינות שלהם.

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

כדי להשתמש באיזון עומסים שמבוסס על בדיקת תקינות, האשכול צריך להיות בגרסת GKE‏ 1.32.3-gke.1440000 ואילך. ב-GKE אפשר לבחור גיבוי של Pod רק בגרסה 1.35.0-gke.1403000 ואילך.
באשכול צריך להפעיל את GKE Dataplane V2 ואת Gateway API.
אובייקט GKEIPRoute יחיד תומך רק ב-Pod תואם אחד לכל צומת. אם כמה תרמילים (Pods) בצומת תואמים לסלקטור התרמילים של GKEIPRoute, ‏ GKE בוחר את התרמיל (Pod) שנוצר לאחרונה בצומת הזה. שדה כדי להבטיח חלוקה נכונה של תרמילים (Pods).
אי אפשר לשנות מחלקה של שער אחרי שיוצרים את אובייקט GKEIPRoute.
איזון עומסים שמבוסס על בדיקת תקינות תומך רק בתעבורה שמגיעה מחוץ לעומס העבודה. אין תמיכה בתעבורת נתונים שמתחילה מתוך עומס העבודה אל כתובת ה-IP הקבועה.

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

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

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

מידע נוסף על כתובות IP

הטמעה של איזון עומסים שמבוסס על בדיקות תקינות

בקטע הזה מוסבר בקצרה על תהליך העבודה להטמעת איזון עומסים שמבוסס על בדיקות תקינות:

יצירת בדיקת תקינות אזורית: הגדרת הפרמטרים שבהם GKE משתמש כדי לעקוב אחרי הסטטוס של ה-Pods. האובייקט הזה מציין לשכבת הרשת אילו נקודות קצה תקינות ועומדות בדרישות לקבלת תנועה מכתובת ה-IP הקבועה.
יצירת אשכול: מגדירים אשכול GKE עם GKE Dataplane V2 ו-Gateway API מופעלים. הרכיבים האלה מספקים את התשתית הבסיסית שנדרשת כדי לנהל ניתוב IP קבוע ואיזון עומסים שמבוסס על בדיקת תקינות.
שמירת כתובת IP: בוחרים ושומרים כתובת IP סטטית פנימית או חיצונית באותו אזור כמו האשכול. הכתובת הזו משמשת כנקודת כניסה קבועה ש-GKE יפיץ בין מאגר ה-Pods הפעילים או הגיבויים.
יצירת שער: מגדירים אובייקט Gateway כדי לנהל את כתובות ה-IP הקבועות ששמרתם. אובייקט GKEIPRoute תובע כתובות IP ספציפיות מהשער ומשתמש בהן עבור עומסי העבודה.
יוצרים אובייקט GKEIPRoute: מגדירים את כללי הניתוב שממפים את כתובת ה-IP הקבועה לקבוצה של Pods באמצעות בוררי תוויות. באובייקט הזה, אתם מפנים לבדיקת תקינות אזורית, ויכולים גם להגדיר פודים לגיבוי לתרחישי יתירות כשל.
הצגת נקודות קצה תואמות: בודקים את ה-EndpointSlices שנוצרו באופן אוטומטי כדי לוודא ש-GKE זיהה בצורה נכונה את ה-Pods הפעילים ואת ה-Pods לגיבוי. השלב הזה מאשר שהתוויות תואמות ל-Pods הצפויים וששכבת הרשת מוכנה לניתוב התנועה.

שלב 1: יוצרים בדיקת תקינות אזורית וכללי חומת אש

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

gcloud compute health-checks create http reg-lb-hc \
    --region=us-central1 \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2

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

שלב 2: יצירת אשכול GKE

יוצרים אשכול עם Gateway API ו-GKE Dataplane V2 מופעלים. לדוגמה:

gcloud container clusters create cluster-1 \
    --enable-dataplane-v2 \
    --gateway-api=standard \
    --region=us-central1

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

שלב 3: שומרים כתובות IP

שומרים את כתובות ה-IP שרוצים להשתמש בהן לעומסי העבודה. אתם יכולים לבחור בין שמירת כתובות IP ש-Google מספקת לבין שימוש בכתובות IP משלכם (BYOIP).

שלב 3א: שמירת כתובות IP שסופקו על ידי Google

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

gcloud compute addresses create ADDRESS_NAME \
   --region=REGION

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

‫ADDRESS_NAME: השם שרוצים לשייך לכתובת הזו.
‫REGION: האזור שבו רוצים לשמור את הכתובת. האזור הזה צריך להיות זהה לאזור של ה-Pod שאליו רוצים לצרף את כתובת ה-IP.

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

כדי לשמור כתובות IP פנימיות, מריצים את הפקודה הבאה:

gcloud compute addresses create ADDRESS_NAME \
    --region REGION
    --subnet SUBNETWORK \
    --addresses IP_ADDRESS

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

‫ADDRESS_NAME: השמות של כתובת אחת או יותר שרוצים לשריין. אם יש כמה כתובות, צריך לציין את כולן כרשימה, ולהפריד ביניהן באמצעות רווחים. לדוגמה, example-address-1 example-address-2 example-address-3.
‫REGION: האזור של הבקשה.
‫SUBNETWORK: רשת המשנה של כתובת ה-IPv4 הפנימית הזו.
‫IP_ADDRESS: כתובת IP פנימית שלא נמצאת בשימוש מטווח כתובות ה-IP הראשי של רשת המשנה שנבחרה.

כדי לוודא שהתנועה מנותבת בצורה נכונה ברשת הפרטית, כתובות ה-IP הפנימיות צריכות להיות שייכות לרשת המשנה שמוגדרת כברירת מחדל באשכול או לרשת משנה נוספת.

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

שלב 3ב: העברת כתובות IP משלכם (BYOIP)

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

שלב 4: יצירת אובייקטים של שער

יוצרים שער באמצעות אחת מהמחלקות הבאות של שערים שתומכות רק בסוג הרשת L3:

gke-passthrough-lb-external-managed או
gke-passthrough-lb-internal-managed.

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

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: lb-gateway
spec:
  gatewayClassName: gke-passthrough-lb-external-managed

  listeners:
    - name: default
      port: 443
      protocol: none
      allowedRoutes:
        namespaces:
          from: All

  addresses:
    - value: "34.123.10.1/32"
      type: "gke.networking.io/cidr"
    - value: "34.123.10.2/32"
      type: "gke.networking.io/cidr"

בדוגמה שלמעלה, שימו לב לשדות הבאים:

addresses: רשימה של כל טווחי כתובות ה-IP שהשער הספציפי מנהל את ההרשאות שלהם.
‫listeners: מזהה את מרחבי השמות שאובייקטים מסוג GKEIPRoute יכולים להפנות אל Gateway זה.

פרטים על השימוש ב-Listener זמינים במאמר יצירת אובייקטים של Gateway.

שלב 5: יוצרים אובייקט GKEIPRoute עם איזון עומסים והגדרת בדיקת תקינות

יוצרים אובייקט GKEIPRoute שבו מגדירים את בוררי ה-Pod הראשיים והגיבויים, ומשייכים את בדיקת תקינות שנוצרה בשלב 1.

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: default
  name: my-ip-route
spec:
  parentRefs:
  - name: lb-gateway
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: default
  podSelector:
    matchLabels:
      component: activePodSelector

  loadBalancing:
    healthCheckName: "reg-lb-hc"
    backupPodSelector:
      namespaceSelector:
        matchLabels:
          environment: test
          dc: us-central
      podSelector:
        matchLabels:
          component: backupPodSelector
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: proxy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: proxy
  template:
    metadata:
      # annotations:  <- Include these lines if the pods are multi-nic pods
      #   networking.gke.io/default-interface: 'eth0'
      #   networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

שימו לב לנקודות הבאות:

‫podSelector: מזהה את ה-Pods הפעילים הראשיים שמקבלים תנועה מכתובות ה-IP הקבועות שהוגדרו. השדה הזה משתמש בתוויות כדי להתאים בין Pods באותו מרחב שמות לבין משאב GKEIPRoute. ‫GKE מחלק את התנועה בין כל ה-Pods התקינים שתואמים לבורר הזה. אם כמה פודים תואמים נמצאים באותו צומת, GKE בוחר רק את הפוד שנוצר לאחרונה כדי לקבל תנועה. התוויות שמוגדרות כאן לא יכולות להיות זהות לתוויות שמוגדרות בשדה backupPodSelector. אפשר לשנות את השדה הזה.
‫backupPodSelector: מגדיר את ה-Pods במצב המתנה שמקבלים תנועה רק אם כל ה-Pods הראשיים שתואמים לאובייקט podSelector נכשלים בבדיקות התקינות שלהם. הבורר הזה כולל את האפשרויות הבאות:
- ‫namespaceSelector: קובע באילו מרחבי שמות GKE יחפש כדי למצוא את ה-Pods של הגיבוי. אפשר להגביל את החיפוש למרחבי שמות ספציפיים באמצעות בוררי תוויות. אם השדה הזה לא מצוין או שהוא ריק,‏ GKE מחפש תרמילי Pod לגיבוי בכל מרחבי השמות באשכול.
- ‫podSelector: מתאים בין Pods של גיבוי על סמך התוויות שלהם. התוויות האלה חייבות להיות שונות מהתוויות שמשמשות באובייקט podSelector הראשי.

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

שלב 6: שימוש בכתובות ה-IP שהוקצו בתוך ה-Pod

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

אפשר להגדיר את מפרט ה-Pod באמצעות אחת מהאפשרויות הבאות:

שינוי של net.ipv4.ip_nonlocal_bind sysctl

אפשר לשנות את הגדרות המערכת כדי לאפשר לאפליקציה להשתמש בכתובות IP שלא הוקצו ישירות לממשק שלה. לשם כך, צריך להגדיר את net.ipv4.ip_nonlocal_bind sysctl ב-Pod securityContext. האפשרות הזו שימושית אם האפליקציה יכולה לבצע bind לכתובת IP שלא נמצאת בממשק.

מוסיפים את הפרטים הבאים למפרט ה-YAML של Deployment או StatefulSet בקטע spec.template.spec:
```
securityContext:
  sysctls:
  - name: net.ipv4.ip_nonlocal_bind
    value: "1"
```
הוספת כתובת ה-IP שהוקצתה לממשק של ה-Pod

אתם יכולים להוסיף באופן ידני את כתובת ה-IP שמוגדרת על ידי אובייקט GKEIPRoute לאחד הממשקים של ה-Pod באמצעות קונטיינר init. כך כתובת ה-IP תהיה גלויה ל-Pod כאילו היא הוקצתה ישירות. לשם כך נדרשת היכולת NET_ADMIN.

מוסיפים את הפרטים הבאים למפרט ה-YAML של Deployment או StatefulSet בקטע spec.template.spec:
```
initContainers:
- name: configure-ips
  image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
  command: ['sh', '-c', 'ip address add ASSIGNED_IP/32 dev eth0']
  securityContext:
    capabilities:
      add:
      - NET_ADMIN
```
מחליפים את ASSIGNED_IP באחת מכתובות ה-IP שהוקצו לאובייקט GKEIPRoute.
Raw sockets: כדי לקבל שליטה רבה יותר, האפליקציה יכולה ליצור אינטראקציה ישירה עם מקבץ רשת (network stack) (מתקדם).
מערך כתובות IP במרחב המשתמש: במקרים מיוחדים, יכול להיות שתפעל ב-Pod אפליקציה נפרדת לניהול כתובת ה-IP (מתקדם מאוד).

שלב 7: מפעילים את פרוטוקול ARP לכתובות ה-IP שהוקצו (רק ברשת ברירת המחדל)

כדי ליצור בקשות ותגובות תקינות של Address Resolution Protocol‏ (ARP) וליצור חיבור חדש ל-Pod באמצעות כתובת ה-IP שהוקצתה על ידי האובייקט GKEIPRoute ברשת ברירת המחדל, צריך להגדיר את המשתנה arp_announce.

כדי להגדיר את המשתנה arp_announce, מריצים את הפקודה הבאה ב-Pod:

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

כאשר המשתנה arp_announce קובע איך המערכת מטפלת בהודעות ARP. הגדרה של הערך 2 עוזרת לוודא שהודעות ARP נשלחות לכתובת ה-IP הקבועה, וכך מכשירים אחרים ברשת יכולים ללמוד על השיוך החדש.

שלב 8: צפייה בנקודות קצה תואמות

כדי לנהל את חלוקת התנועה, מערכת GKE יוצרת EndpointSlices לכל אובייקט GKEIPRoute. הפרוסות האלה פועלות כמרשם של כל ה-Pods שמוגדרים כיעדי ניתוב של המסלול הספציפי הזה.

‫GKE יוצר EndpointSlices נפרדים לנקודות קצה פעילות ולנקודות קצה לגיבוי. המערכת משנה באופן אוטומטי את מספר ה-EndpointSlices בהתאם לעומס העבודה. למרות ש-EndpointSlice אחד תומך בעד 1,000 נקודות קצה, GKE יוצר פרוסות נוספות אם מספר ה-Pod התואם חורג מהמגבלה הזו.

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

kubectl get endpointslices --all-namespaces -l \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,\
  networking.gke.io/gkeiproute-namespace=GKEIPROUTE_NAMESPACE

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

‫GKEIPROUTE_NAME: השם של המניפסט GKEIPRoute.
‫GKEIPROUTE_NAMESPACE: מרחב השמות של המניפסט GKEIPRoute.

בדוגמה הבאה מוצג פלט של EndpointSlice:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
 name: {gkeiproute_name-truncated}-{gkeiproute_namespace-truncated}-backup-{unique_hash}
 namespace: {gkeiproute_namespace}
 labels:
  endpointslice.kubernetes.io/managed-by: gkeiproute-controller
  networking.gke.io/gkeiproute-name: {gkeiproute_name}
  networking.gke.io/gkeiproute-namespace: {gkeiproute_namespace}
  networking.gke.io/pip-es-role: backup
 ownerReferences:
  - kind: GKEIPRoute
    name: {gkeiproute_name}
    apiVersion: networking.gke.io/v1
    uid: {uid}
    controller: true
addressType: IPv4
endpoints:
 - addresses:
     - "{pod_ip_address}"
   targetRef:
     Name: {pod_name}
   nodeName: {node_name}

כדי לראות EndpointSlices ספציפיים לנקודות קצה פעילות או לנקודות קצה לגיבוי, מסננים את התוצאות באמצעות התווית pip-eps-role. לדוגמה:

kubectl get endpointslices --all-namespaces -l \
   networking.gke.io/pip-eps-role=ROLE \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,

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

‫ROLE: סוג נקודת הקצה שרוצים להציג, active או backup.
‫GKEIPROUTE_NAME: השם של אובייקט GKEIPRoute הספציפי.

פתרון בעיות באיזון עומסים שמבוסס על בדיקות תקינות

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

חלק מה-Pods הפעילים לא תקינים, אבל ה-Pods של הגיבוי לא מקבלים תנועה

תסמין

הסטטוס של GKEIPRoute הוא Ready, שמציין שההגדרה של כתובת ה-IP עבור הפודים התואמים הושלמה. בדיקות תקינות או אבחונים אחרים מראים שחלק מה-Pods הפעילים לא תקינים. עם זאת, תרמילי גיבוי לא מקבלים תנועה.

הסיבה

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

רזולוציה

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

‫GKEIPRoute מוגדר, אבל לא כל ה-Pods מקבלים תנועה

תסמין

הסטטוס של GKEIPRoute הוא Ready, שמציין שההגדרה של כתובת ה-IP עבור הפודים התואמים הושלמה, אבל חלק מהפודים התואמים לא מקבלים תנועה.

הסיבה

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

רזולוציה

מוודאים שה-Pod תקין: משתמשים ב-Google Cloud CLI או במסוףGoogle Cloud כדי לוודא שה-Pod מגיב בצורה תקינה לבדיקות תקינות.
בודקים לעומק אם צריך: אם ה-Pod לא תקין, מוודאים שהגדרתם חומות אש בצורה נכונה לבדיקות התקינות, ושה-Pod מגיב.

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

בקטע הזה מוסבר איך לפתור בעיות שקשורות לשגיאות בסטטוס של GKEIPRoute.

`Backup pod and active pod are on the same node`

תסמין

בסטטוס של GKEIPRoute מדווחת השגיאה הבאה:

invalid LB configuration: Backup pod %s and active pod %s are on the same node %s. Active and backup pods must reside on different nodes.

הסיבה

‫Pod פעיל ו-Pod גיבוי שתואמים לאותו אובייקט GKEIPRoute מתוזמנים באותו צומת. במילים אחרות, יש Pods שתואמים גם לאובייקטים הפעילים וגם לאובייקטים של podSelector לגיבוי באותו הצומת.

רזולוציה

מוודאים שתרמילי ה-Pods הפעילים והגיבוי נמצאים בצמתים שונים. מעדכנים את ההגדרה של GKEIPRoute ומשנים את התוויות podSelector או backupPodSelector כך שלא יהיו שני פודים באותו צומת שתואמים לאותו אובייקט GKEIPRoute.

`Pod cannot be selected as both an active and a backup pod`

תסמין

בסטטוס של GKEIPRoute מדווחת השגיאה הבאה:

invalid LB configuration: pod %s cannot be selected as both an active and a backup pod. Active and backup pod sets must be mutually exclusive

הסיבה

‫Pod אחד או יותר תואמים לבחירות של תוויות גם בשדה podSelector (פעיל) וגם בשדה backupPodSelector (המתנה). ב-GKE, שתי הקבוצות האלה צריכות להיות נפרדות. אי אפשר להשתמש ב-Pod יחיד כגיבוי של עצמו.

רזולוציה

חשוב לוודא שה-Pods הפעילים וה-Pods לגיבוי הם ייחודיים. משנים את השדה podSelector או את השדה backupPodSelector במניפסט של GKEIPRoute כדי להשתמש במפתחות וערכים של תוויות ספציפיות או שונות יותר.

סטטוס אחד (`NoPodsFound`)

תסמין

במניפסט GKEIPRoute מוצג סטטוס של NoPodsFound, שמציין שאין Pods במרחבי השמות עם תוויות תואמות.

סיבות אפשריות

תוויות שגויות: יכול להיות של-Pod שאיתו אתם רוצים להשתמש בכתובת ה-IP שהגדרתם יש תוויות שגויות, או שאין לו תוויות בכלל.
לא קיימים פודים: אם הפלט הוא reactionMode == Exists, בודקים אם הפוד משויך לצומת על ידי בדיקת השדה pod.Spec.nodeName. יכול להיות שאין Pods שפועלים במרחב השמות של GKEIPRoute שתואמים לבורר.
‫Pods not Ready: אם reactionMode == ReadyCondition, בודקים אם הסטטוס של ה-Pod הוא READY. אם קיים Pod תואם אבל הוא לא במצב READY, אי אפשר להשתמש ב-Pod להעברת תנועה והוא לא נבחר.

רזולוציה

בדיקת התוויות: מוודאים שהתוויות בשדה podSelector של האובייקט GKEIPRoute תואמות לתוויות שהחלתם על ה-Pod הרצוי.
אימות קיום של Pod: מוודאים ש-Pod עם התוויות הנכונות אכן קיים במרחבי השמות של אובייקט GKEIPRoute שצוינו על ידי רכיבי ה-Listener של ה-Gateway. אם ה-reactionMode == Exists, בודקים אם ה-Pod מוקצה לצומת על ידי בדיקת השדה pod.Spec.nodeName.
מאשרים שה-Pod מוכן: אם מופיע reactionMode == ReadyCondition, בודקים אם הסטטוס של ה-Pod הוא READY. מוודאים שה-Pod במצב Ready באמצעות הפקודה הבאה:
```
kubectl get pods -n NAMESPACE
```
תאי אחסון במדינות אחרות (לדוגמה, Pending, Error) לא נבחרים.

סטטוס `Mutated` כשנמצא Pod תואם ותהליך התכנות של כתובת ה-IP של GKEIPRoute נמצא בעיצומו

תסמין

הסטטוס של GKEIPRoute הוא Mutated, מה שאומר שהגדרת כתובת ה-IP של Pod תואם נמצאת בתהליך.

סיבה אפשרית

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

רזולוציה

מחכים ומנסים שוב: ברוב המקרים, תהליך ההגדרה מסתיים באופן אוטומטי תוך זמן קצר. בודקים את הסטטוס אחרי שמחכים. הוא ישתנה ל-Ready כשהפעולה תסתיים.
בדיקה נוספת (אם צריך): אם הסטטוס Mutated נמשך לאורך זמן, יכול להיות שיש שגיאת הגדרה. בודקים את תנאי הסטטוס האחרים באובייקט GKEIPRoute:
- Accepted: מציין אם הגדרת GKEIPRoute תקפה.
- ‫GCPReady: מציין אם המשאבים של Google Cloud מוגדרים כמו שצריך.

כדי לפתור את הבעיה, כדאי לחפש הודעות שגיאה בתנאים האלה.

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

מידע נוסף על כתובות IP קבועות ל-Pods של GKE

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

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

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

הטמעה של איזון עומסים שמבוסס על בדיקות תקינות

שלב 1: יוצרים בדיקת תקינות אזורית וכללי חומת אש

שלב 2: יצירת אשכול GKE

שלב 3: שומרים כתובות IP

שלב 3א: שמירת כתובות IP שסופקו על ידי Google

שלב 3ב: העברת כתובות IP משלכם (BYOIP)

שלב 4: יצירת אובייקטים של שער

שלב 5: יוצרים אובייקט GKEIPRoute עם איזון עומסים והגדרת בדיקת תקינות

שלב 6: שימוש בכתובות ה-IP שהוקצו בתוך ה-Pod

שלב 7: מפעילים את פרוטוקול ARP לכתובות ה-IP שהוקצו (רק ברשת ברירת המחדל)

שלב 8: צפייה בנקודות קצה תואמות

פתרון בעיות באיזון עומסים שמבוסס על בדיקות תקינות

חלק מה-Pods הפעילים לא תקינים, אבל ה-Pods של הגיבוי לא מקבלים תנועה

‫GKEIPRoute מוגדר, אבל לא כל ה-Pods מקבלים תנועה

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

Backup pod and active pod are on the same node

Pod cannot be selected as both an active and a backup pod

סטטוס אחד (NoPodsFound)

סטטוס Mutated כשנמצא Pod תואם ותהליך התכנות של כתובת ה-IP של GKEIPRoute נמצא בעיצומו

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

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

`Backup pod and active pod are on the same node`

`Pod cannot be selected as both an active and a backup pod`

סטטוס אחד (`NoPodsFound`)

סטטוס `Mutated` כשנמצא Pod תואם ותהליך התכנות של כתובת ה-IP של GKEIPRoute נמצא בעיצומו