פריסת Ingress באשכולות

בדף הזה מוסבר איך לפרוס Ingress שמשרת אפליקציה בכמה אשכולות GKE. מידע נוסף על Multi Cluster Ingress זמין במאמר בנושא Multi Cluster Ingress.

השוואה מפורטת בין Multi Cluster Ingress ‏ (MCI),‏ Multi-cluster Gateway ‏(MCG) ומאזן עומסים עם Standalone Network Endpoint Groups ‏ (LB ו-Standalone NEGs) זמינה במאמר בחירת API לאיזון עומסים בין כמה אשכולות ב-GKE.

מדריך לפריסה

במשימות הבאות תפרסו אפליקציה פיקטיבית בשם whereami ו-MultiClusterIngress בשני אשכולות. ה-Ingress מספק כתובת IP וירטואלית (VIP) משותפת לפריסות האפליקציות.

הדף הזה מבוסס על העבודה שבוצעה במאמר בנושא הגדרת Multi Cluster Ingress, שבו יצרתם ורשמתם שני אשכולות. מוודאים שיש לכם שני אשכולות שרשומים גם לצי:

gcloud container clusters list

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

NAME    LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
gke-eu  europe-west1-b  1.16.8-gke.9    ***             e2-medium      1.16.8-gke.9     2          RUNNING
gke-us  us-central1-b   1.16.8-gke.9    ***             e2-medium      1.16.6-gke.13 *  2          RUNNING

יצירת מרחב השמות

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

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

  1. יוצרים קובץ בשם namespace.yaml עם התוכן הבא:

    apiVersion: v1
kind: Namespace
metadata:
  name: whereami

  2. עוברים להקשר gke-us:

    kubectl config use-context gke-us

  3. יוצרים את מרחב השמות:

    kubectl apply -f namespace.yaml

  4. עוברים להקשר gke-eu:

    kubectl config use-context gke-eu

  5. יוצרים את מרחב השמות:

    kubectl apply -f namespace.yaml

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

    namespace/whereami created

פריסת האפליקציה

  1. יוצרים קובץ בשם deploy.yaml עם התוכן הבא:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-deployment
  namespace: whereami
  labels:
    app: whereami
spec:
  selector:
    matchLabels:
      app: whereami
  template:
    metadata:
      labels:
        app: whereami
    spec:
      containers:
      - name: frontend
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080

  2. עוברים להקשר gke-us:

    kubectl config use-context gke-us

  3. פריסת האפליקציה whereami:

    kubectl apply -f deploy.yaml

  4. עוברים להקשר gke-eu:

    kubectl config use-context gke-eu

  5. פריסת האפליקציה whereami:

    kubectl apply -f deploy.yaml

  6. מוודאים שאפליקציית whereami נפרסה בהצלחה בכל אשכול:

    kubectl get deployment --namespace whereami

    הפלט בשני האשכולות צריך להיות דומה לזה:

    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
whereami-deployment   1/1     1            1           12m

פריסה דרך אשכול ההגדרות

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

במדריך ההגדרה, הגדרתם את אשכול gke-us כאשכול ההגדרות. אשכול ההגדרות משמש לפריסה ולהגדרה של Ingress בכל האשכולות.

  1. מגדירים את ההקשר לאשכול ההגדרות.

    kubectl config use-context gke-us

MultiClusterService

  1. יוצרים קובץ בשם mcs.yaml עם התוכן הבא:

    apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080

  2. פורסים את המשאב MultiClusterService שתואם לאפליקציית whereami:

    kubectl apply -f mcs.yaml

  3. מוודאים שהמשאב whereami-mcs נפרס בהצלחה באשכול ההגדרות:

    kubectl get mcs -n whereami

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

    NAME       AGE
whereami-mcs   9m26s

    הפקודה MultiClusterService יוצרת שירות נגזר ללא ראש בכל אשכול שתואם ל-Pods עם app: whereami. אפשר לראות שיש כזה באוסף gke-us kubectl get service -n whereami.

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

    NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
mci-whereami-mcs-svc-lgq966x5mxwwvvum   ClusterIP   None          <none>        8080/TCP         4m59s

שירות דומה בלי GUI יופיע גם ב-gke-eu. השירותים המקומיים האלה משמשים לבחירה דינמית של נקודות קצה (endpoints) של Pod כדי לתכנת את איזון העומסים הגלובלי של Ingress עם שרתי קצה עורפיים (backends).

MultiClusterIngress

  1. יוצרים קובץ בשם mci.yaml עם התוכן הבא:

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080

    שימו לב שההגדרה הזו מעבירה את כל התנועה אל MultiClusterService השם whereami-mcs שקיים במרחב השמות whereami.

  2. פורסים את משאב MultiClusterIngress שמפנה אל whereami-mcs כאל קצה עורפי:

    kubectl apply -f mci.yaml

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

    multiclusteringress.networking.gke.io/whereami-ingress created

    שימו לב: הסכימה של MultiClusterIngress זהה לסכימת ה-Ingress של Kubernetes. גם הסמנטיקה של משאב ה-Ingress זהה, למעט השדה backend.serviceName.

השדה backend.serviceName ב-MultiClusterIngress מפנה אל MultiClusterService ב-Fleet API ולא אל Service באשכול Kubernetes. כלומר, אפשר להגדיר את כל ההגדרות של תעבורת נתונים נכנסת (ingress), כמו סיום TLS, באותו אופן.

אימות סטטוס פריסה מוצלחת

Google Cloud יכול להיות שיחלפו כמה דקות עד שמאזני עומסים חדשים יופעלו. עדכון של מאזני עומסים קיימים מתבצע מהר יותר כי לא צריך לפרוס משאבים חדשים. במשאב MultiClusterIngress מפורטים משאבי Compute Engine הבסיסיים שנוצרו בשם MultiClusterIngress.

  1. מוודאים שהפריסה הצליחה:

    kubectl describe mci whereami-ingress -n whereami

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

    Name:         whereami-ingress
Namespace:    whereami
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"whereami-ingress","namespace":"whe...
API Version:  networking.gke.io/v1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2020-04-10T23:35:10Z
  Finalizers:
    mci.finalizer.networking.gke.io
  Generation:        2
  Resource Version:  26458887
  Self Link:         /apis/networking.gke.io/v1/namespaces/whereami/multiclusteringresses/whereami-ingress
  UID:               62bec0a4-8a08-4cd8-86b2-d60bc2bda63d
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  whereami-mcs
        Service Port:  8080
Status:
  Cloud Resources:
    Backend Services:
      mci-8se3df-8080-whereami-whereami-mcs
    Firewalls:
      mci-8se3df-default-l7
    Forwarding Rules:
      mci-8se3df-fw-whereami-whereami-ingress
    Health Checks:
      mci-8se3df-8080-whereami-whereami-mcs
    Network Endpoint Groups:
      zones/europe-west1-b/networkEndpointGroups/k8s1-e4adffe6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-88670678
      zones/us-central1-b/networkEndpointGroups/k8s1-a6b112b6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-609ab6c6
    Target Proxies:
      mci-8se3df-whereami-whereami-ingress
    URL Map:  mci-8se3df-whereami-whereami-ingress
  VIP:        34.98.102.37
Events:
  Type    Reason  Age                    From                              Message
  ----    ------  ----                   ----                              -------
  Normal  ADD     3m35s                  multi-cluster-ingress-controller  whereami/whereami-ingress
  Normal  UPDATE  3m10s (x2 over 3m34s)  multi-cluster-ingress-controller  whereami/whereami-ingress

    יש כמה שדות שמציינים את הסטטוס של פריסת ה-Ingress הזו:

    • Events הוא המקום הראשון שצריך לבדוק. אם קרתה שגיאה, היא תופיע כאן.

    • Cloud Resourceמציג את רשימת המשאבים של Compute Engine, כמו כללי העברה, שירותים לקצה העורפי וכללי חומת אש, שנוצרו על ידי בקר Multi Cluster Ingress. אם הם לא מופיעים ברשימה, סימן שהם עדיין לא נוצרו. אפשר לבדוק משאבים ספציפיים של Compute Engine באמצעות המסוף או הפקודה gcloud כדי לראות את הסטטוס שלהם.

    • ‫VIP מציג כתובת IP אם הוקצתה כזו. שימו לב: יכול להיות שמאזן העומסים עדיין לא מעבד תנועה, גם אם כתובת ה-VIP קיימת. אם לא רואים כתובת VIP אחרי כמה דקות, או אם מאזן העומסים לא מציג תגובה מסוג 200 תוך 10 דקות, אפשר לעיין במאמר פתרון בעיות ותפעול.

    אם אירועי הפלט הם Normal, סביר שהפריסה של MultiClusterIngress הצליחה, אבל הדרך היחידה לוודא שכל נתיב התנועה פועל היא לבדוק אותו.

  2. מוודאים שהאפליקציה פועלת ב-VIP עם נקודת הקצה /ping:

    curl INGRESS_VIP/ping

    מחליפים את INGRESS_VIP בכתובת ה-IP הווירטואלית (VIP).

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

    {
"cluster_name": "gke-us",
"host_header": "34.120.175.141",
"pod_name": "whereami-deployment-954cbf78-mtlpf",
"pod_name_emoji": "😎",
"project_id": "my-project",
"timestamp": "2021-11-29T17:01:59",
"zone": "us-central1-b"
}

    הפלט צריך לציין את האזור ואת הקצה העורפי של האפליקציה.

  3. אפשר גם לעבור לכתובת ה-URL בדפדפן כדי לראות גרסה גרפית של האפליקציה שבה מוצג האזור שממנו היא מוגשת.http://INGRESS_VIP

    האשכול שאליו מועברת התנועה תלוי במיקום שלכם. ה-GCLB נועד להעביר תנועת לקוחות אל העורף הזמין הקרוב ביותר עם קיבולת.

מפרט המשאבים

מפרט MultiClusterService

ההגדרה MultiClusterService מורכבת משני חלקים:

  1. קטע template שמגדיר את השירות שייווצר באשכולות Kubernetes. שימו לב: בקטע template יש שדות שנתמכים בשירות רגיל, אבל יש רק שני שדות שנתמכים ב-MultiClusterService: selector ו-ports. המערכת מתעלמת משאר השדות.

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

המניפסט הבא מתאר MultiClusterService רגיל:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      selector:
        app: POD_LABEL
      ports:
      - name: web
        protocol: TCP
        port: PORT
        targetPort: TARGET_PORT

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

  • ‫NAME: השם של MultiClusterService. השם הזה מופיע בשדה serviceName במשאבי MultiClusterIngress.
  • ‫NAMESPACE: מרחב השמות של Kubernetes שבו נפרס MultiClusterService. הוא חייב להיות באותו מרחב שמות כמו MultiClusterIngress וה-Pods בכל האשכולות בצי.
  • ‫POD_LABEL: התווית שקובעת אילו פודים נבחרים כשרתי קצה עורפיים עבור MultiClusterService בכל האשכולות ב-Fleet.
  • ‫PORT: צריך להיות זהה ליציאה שאליה מתייחס MultiClusterIngress שמתייחס ל-MultiClusterService הזה.
  • ‫TARGET_PORT: היציאה שמשמשת לשליחת תנועה אל ה-Pod מ-GCLB. בכל אשכול נוצר NEG עם היציאה הזו כיציאת השירות שלו.

מפרט MultiClusterIngress

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

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      backend:
       serviceName: DEFAULT_SERVICE
       servicePort: PORT
      rules:
        - host: HOST_HEADER
          http:
            paths:
            - path: PATH
              backend:
                serviceName: SERVICE
                servicePort: PORT

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

  • ‫NAME: השם של משאב MultiClusterIngress.
  • ‫NAMESPACE: מרחב השמות של Kubernetes שבו נפרס MultiClusterIngress. היא צריכה להיות באותו מרחב שמות כמו MultiClusterService וה-Pods בכל האשכולות בצי.
  • ‫DEFAULT_SERVICE: משמש כקצה העורפי שמוגדר כברירת מחדל לכל התנועה שלא תואמת לכללים של מארח או נתיב. זהו שדה חובה, וצריך לציין קצה עורפי (backend) שמוגדר כברירת מחדל ב-MultiClusterIngress, גם אם מוגדרים התאמות אחרות של מארחים או נתיבים.
  • ‫PORT: כל מספר יציאה תקין. הערך הזה צריך להיות זהה לערך בשדה port של משאבי MultiClusterService.
  • ‫HOST_HEADER: התאמה של תנועה לפי שדה הכותרת של מארח ה-HTTP. השדה host הוא אופציונלי.
  • ‫PATH: התאמה של תנועה לפי הנתיב של כתובת URL מסוג HTTP. השדה path הוא אופציונלי.
  • ‫SERVICE: השם של MultiClusterService שנפרס באותו מרחב שמות ובאותו אשכול הגדרות כמו MultiClusterIngress.

תכונות של Multi Cluster Ingress

בקטע הזה מוסבר איך להגדיר תכונות נוספות של Multi Cluster Ingress.

בחירת אשכול

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

  • החלת Multi Cluster Ingress על כל האשכולות, למעט אשכול ההגדרות, כדי לבודד את אשכול ההגדרות.
  • העברת עומסי עבודה בין אשכולות בשיטת blue-green.
  • ניתוב לשרתי בק-אנד של אפליקציות שקיימים רק בקבוצת משנה של אשכולות.
  • שימוש ב-VIP יחיד ברמה 7 לניתוב מארחים או נתיבים לקצוות עורפיים שנמצאים באשכולות שונים.

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

  1. פתיחת mcs.yaml

    apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080

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

  2. מוסיפים את השורות הבאות לקטע clusters:

    apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080
  clusters:
  - link: "us-central1-b/gke-us"
  - link: "europe-west1-b/gke-eu"

    בדוגמה הזו, משאבי Derived Service נוצרים רק באשכולות gke-us ו-gke-eu. צריך לבחור אשכולות כדי להחיל כללי Ingress באופן סלקטיבי. אם הקטע [clusters] של MultiClusterService לא מצוין או אם לא מופיעים אשכולות, המערכת מפרשת את זה כאשכולות ברירת המחדל [all].

תמיכה ב-HTTPS

‫Kubernetes Secret תומך ב-HTTPS. לפני שמפעילים תמיכה ב-HTTPS, צריך ליצור כתובת IP סטטית. כתובת ה-IP הסטטית הזו מאפשרת ל-HTTP ול-HTTPS לשתף את אותה כתובת IP. מידע נוסף זמין במאמר בנושא יצירת כתובת IP סטטית.

אחרי שיוצרים כתובת IP סטטית, אפשר ליצור סוד.

  1. יצירת סוד:

    kubectl -n whereami create secret tls SECRET_NAME --key PATH_TO_KEYFILE --cert PATH_TO_CERTFILE

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

    • SECRET_NAME בשם הסוד.
    • ‫PATH_TO_KEYFILE מחליפים בנתיב לקובץ מפתח ה-TLS.
    • ‫PATH_TO_CERTFILE עם הנתיב לקובץ אישור ה-TLS.

  2. מעדכנים את הקובץ mci.yaml עם שם הסוד:

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
  annotations:
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080
      tls:
      - secretName: SECRET_NAME

    מחליפים את SECRET_NAME בשם הסוד. ‫STATIC_IP_ADDRESS היא כתובת ה-IP או כתובת ה-URL המלאה שהקציתם בקטע יצירת כתובת IP סטטית.

  3. פורסים מחדש את המשאב MultiClusterIngress:

    kubectl apply -f mci.yaml

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

    multiclusteringress.networking.gke.io/whereami-ingress configured

תמיכה ב-BackendConfig

ה-CRD הבא של BackendConfig מאפשר להתאים אישית את ההגדרות במשאב BackendService של Compute Engine:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: whereami-health-check-cfg
  namespace: whereami
spec:
  healthCheck:
    checkIntervalSec: [int]
    timeoutSec: [int]
    healthyThreshold: [int]
    unhealthyThreshold: [int]
    type: [HTTP | HTTPS | HTTP2 | TCP]
    port: [int]
    requestPath: [string]
  timeoutSec: [int]
  connectionDraining:
    drainingTimeoutSec: [int]
  sessionAffinity:
    affinityType: [CLIENT_IP | CLIENT_IP_PORT_PROTO | CLIENT_IP_PROTO | GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | NONE]
    affinityCookieTtlSec: [int]
  cdn:
    enabled: [bool]
    cachePolicy:
      includeHost: [bool]
      includeQueryString: [bool]
      includeProtocol: [bool]
      queryStringBlacklist: [string list]
      queryStringWhitelist: [string list]
  securityPolicy:
    name: ca-how-to-security-policy
  logging:
    enable: [bool]
    sampleRate: [float]
  iap:
    enabled: [bool]
    oauthclientCredentials:
      secretName: [string]

כדי להשתמש ב-BackendConfig, צריך לצרף אותו למשאב MultiClusterService באמצעות הערה:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
  annotations:
    cloud.google.com/backend-config: '{"ports": {"8080":"whereami-health-check-cfg"}}'
spec:
 template:
   spec:
     selector:
       app: whereami
     ports:
     - name: web
       protocol: TCP
       port: 8080
       targetPort: 8080

מידע נוסף על הסמנטיקה של BackendConfig זמין במאמר שיוך של יציאת שירות ל-BackendConfig.

תמיכה ב-gRPC

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

  1. מוודאים שהתעבורה ממאזן העומסים לאפליקציה היא HTTP/2. כדי להגדיר את זה, משתמשים בפרוטוקולי אפליקציה.
  2. צריך לוודא שהאפליקציה מוגדרת כראוי ל-SSL, כי זו דרישה של HTTP/2. שימו לב: מותר להשתמש באישורים בחתימה עצמית.
  3. צריך להשבית את mTLS באפליקציה כי mTLS לא נתמך במאזני עומסים חיצוניים ברמה 7.

מחזור החיים של משאב

שינויים בהגדרות

המשאבים MultiClusterIngress ו-MultiClusterService מתנהגים כאובייקטים רגילים של Kubernetes, ולכן שינויים באובייקטים משתקפים במערכת באופן אסינכרוני. שינויים שמובילים להגדרה לא תקינה גורמים לכך שאובייקטים משויכיםGoogle Cloud לא משתנים ומוצגת שגיאה בזרם האירועים של האובייקט. שגיאות שקשורות להגדרה ידווחו כאירועים.

ניהול משאבי Kubernetes

מחיקת אובייקט ה-Ingress מוחקת את מאזן העומסים מסוג HTTP(S), כך שהתנועה לא מועברת יותר לאף MultiClusterService שהוגדר.

מחיקה של MultiClusterService מסירה את השירותים הנגזרים המשויכים בכל אחד מהאשכולות.

ניהול אשכולות

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

לדוגמה, כדי להסיר את אשכול gke-eu כקצה עורפי של Ingress, מריצים את הפקודה:

gcloud container fleet memberships unregister CLUSTER_NAME \
  --gke-uri=URI

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

  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫URI: מזהה ה-URI של אשכול GKE.

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

gcloud container fleet memberships register europe-cluster \
  --context=europe-cluster --enable-workload-identity

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

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

השבתת Multi Cluster Ingress

לפני שמשביתים את Multi Cluster Ingress, צריך לוודא שקודם מוחקים את משאבי MultiClusterIngress ו-MultiClusterService ומוודאים שכל משאבי הרשת המשויכים נמחקו.

כדי להשבית את Multi Cluster Ingress, משתמשים בפקודה הבאה:

gcloud container fleet ingress disable

אם לא תמחקו את משאבי MultiClusterIngress ו-MultiClusterService לפני השבתת Multi Cluster Ingress, יכול להיות שתיתקלו בשגיאה דומה לזו שמופיעה בהמשך:

Feature has associated resources that should be cleaned up before deletion.

כדי להשבית את Multi Cluster Ingress באופן מאולץ, משתמשים בפקודה הבאה:

gcloud container fleet ingress disable --force

הערות

ההערות הבאות נתמכות במשאבי MultiClusterIngress ו-MultiClusterService.

הערות MultiClusterIngress

הערה תיאור
networking.gke.io/frontend-config מפנה אל משאב FrontendConfig באותו מרחב שמות כמו משאב MultiClusterIngress.
networking.gke.io/static-ip מתייחס לכתובת ה-IP המילולית של כתובת IP סטטית גלובלית.
networking.gke.io/pre-shared-certs הפניה למשאב SSLCertificate גלובלי.

הערות MultiClusterService

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

מדיניות SSL והפניות אוטומטיות ל-HTTPS

אפשר להשתמש במשאב FrontendConfig כדי להגדיר מדיניות SSL והפניות אוטומטיות של HTTPS. כללי מדיניות SSL מאפשרים לציין אילו סטים של אלגוריתמים להצפנה וגרסאות TLS מתקבלים על ידי מאזן העומסים. הפניות אוטומטיות של HTTPS מאפשרות לכם לאכוף את ההפניה מ-HTTP או מיציאה 80 אל HTTPS או מיציאה 443. בשלבים הבאים מוסבר איך להגדיר מדיניות SSL והפניה אוטומטית ל-HTTPS ביחד. חשוב לציין שאפשר גם להגדיר אותם בנפרד.

  1. יוצרים מדיניות SSL שתדחה בקשות שמשתמשות בגרסה נמוכה מ-TLS v1.2.

    gcloud compute ssl-policies create tls-12-policy \
 --profile MODERN \
 --min-tls-version 1.2 \
 --project=PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שבו פועלים אשכולות GKE.

  2. בודקים את המדיניות כדי לוודא שהיא נוצרה.

    gcloud compute ssl-policies list --project=PROJECT_ID

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

    NAME           PROFILE  MIN_TLS_VERSION
tls-12-policy  MODERN   TLS_1_2

  3. יוצרים אישור עבור foo.example.com כמו בדוגמה. אחרי שמקבלים את key.pem ואת cert.pem, מאחסנים את פרטי הכניסה האלה כסוד שמשמש כהפניה למשאב MultiClusterIngress.

    kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem

  4. שומרים את משאב FrontendConfig הבא בשם frontendconfig.yaml. מידע נוסף על השדות הנתמכים ב-FrontendConfig זמין במאמר הגדרת משאבי FrontendConfig.

    apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: frontend-redirect-tls-policy
  namespace: whereami
spec:
  sslPolicy: tls-12-policy
  redirectToHttps:
    enabled: true

    ההגדרה הזו של FrontendConfig תפעיל הפניות אוטומטיות של HTTPS ומדיניות SSL שתאכוף גרסת TLS מינימלית של 1.2.

  5. פורסים את frontendconfig.yaml באשכול ההגדרות.

    kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER

    מחליפים את MCI_CONFIG_CLUSTER בשם של אשכול התצורה.

  6. שומרים את MultiClusterIngress הבא בתור mci-frontendconfig.yaml.

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
  namespace: whereami
  annotations:
    networking.gke.io/frontend-config: frontend-redirect-tls-policy
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 8080
      rules:
      - host: foo.example.com
        http:
          paths:
            - backend:
                serviceName: whereami-mcs
                servicePort: 8080
      tls:
      - secretName: SECRET_NAME
    • מחליפים את STATIC_IP_ADDRESS בכתובת IP גלובלית סטטית שכבר הקציתם.
    • מחליפים את SECRET_NAME ב-Secret שבו מאוחסן האישור foo.example.com.

    יש שני תנאים להפעלת הפניות אוטומטיות ל-HTTPS:

    • צריך להפעיל TLS, דרך השדה spec.tls או דרך הערת האישור שמשותף מראש networking.gke.io/pre-shared-certs. הפריסה של MultiClusterIngress לא תתבצע אם הפניות אוטומטיות ל-HTTPS מופעלות אבל HTTPS לא מופעל.
    • צריך להפנות לכתובת IP סטטית באמצעות ההערה networking.gke.io/static-ip. נדרשות כתובות IP סטטיות כשמפעילים HTTPS ב-MultiClusterIngress.

  7. פורסים את MultiClusterIngress באשכול התצורה.

    kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER

  8. ממתינים דקה או שתיים ובודקים את foo-ingress.

    kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER

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

    • הסטטוס Cloud Resources מאוכלס בשמות משאבים
    • השדה VIP מאוכלס בכתובת ה-IP של מאזן העומסים
    Name:         foobar-ingress
Namespace:    whereami

...

Status:
  Cloud Resources:
    Backend Services:
      mci-otn9zt-8080-whereami-bar
      mci-otn9zt-8080-whereami-default-backend
      mci-otn9zt-8080-whereami-foo
    Firewalls:
      mci-otn9zt-default-l7
    Forwarding Rules:
      mci-otn9zt-fw-whereami-foobar-ingress
      mci-otn9zt-fws-whereami-foobar-ingress
    Health Checks:
      mci-otn9zt-8080-whereami-bar
      mci-otn9zt-8080-whereami-default-backend
      mci-otn9zt-8080-whereami-foo
    Network Endpoint Groups:
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluste-mci-default-backend-svc--80-9e362e3d
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-bar-svc-067a3lzs8-808-89846515
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-foo-svc-820zw3izx-808-8bbcb1de
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluste-mci-default-backend-svc--80-a528cc75
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-bar-svc-067a3lzs8-808-36281739
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-foo-svc-820zw3izx-808-ac733579
    Target Proxies:
      mci-otn9zt-whereami-foobar-ingress
      mci-otn9zt-whereami-foobar-ingress
    URL Map:  mci-otn9zt-rm-whereami-foobar-ingress
  VIP:        34.149.29.76
Events:
  Type     Reason  Age                From                              Message
  ----     ------  ----               ----                              -------
  Normal   UPDATE  38m (x5 over 62m)  multi-cluster-ingress-controller  whereami/foobar-ingress

  9. כדי לוודא שההפניות האוטומטיות ל-HTTPS פועלות בצורה תקינה, שולחים בקשת HTTP דרך curl.

    curl VIP

    מחליפים את VIP בכתובת ה-IP של MultiClusterIngress.

    הפלט צריך להראות שהבקשה הופנתה מחדש ליציאת HTTPS, מה שמצביע על כך שההפניות פועלות בצורה תקינה.

  10. כדי לוודא שמדיניות ה-TLS פועלת בצורה תקינה, שולחים בקשת HTTPS באמצעות גרסה 1.1 של TLS. מכיוון ש-DNS לא מוגדר לדומיין הזה, צריך להשתמש באפשרות --resolve כדי להנחות את curl לפתור את כתובת ה-IP ישירות.

    curl https://foo.example.com --resolve foo.example.com:443:VIP --cacert CERT_FILE -v

    בשלב הזה נדרש קובץ ה-PEM של האישור שמשמש לאבטחת MultiClusterIngress. פלט מוצלח ייראה כך:

    ...
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=foo.example.com
*  start date: Sep  1 10:32:03 2021 GMT
*  expire date: Aug 27 10:32:03 2022 GMT
*  common name: foo.example.com (matched)
*  issuer: O=example; CN=foo.example.com
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fa10f00e400)
> GET / HTTP/2
> Host: foo.example.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< content-type: application/json
< content-length: 308
< access-control-allow-origin: *
< server: Werkzeug/1.0.1 Python/3.8.6
< date: Wed, 01 Sep 2021 11:39:06 GMT
< via: 1.1 google
< alt-svc: clear
<
{"cluster_name":"gke-us","host_header":"foo.example.com","metadata":"foo","node_name":"gke-gke-us-default-pool-22cb07b1-r5r0.c.mark-church-project.internal","pod_name":"foo-75ccd9c96d-dkg8t","pod_name_emoji":"👞","project_id":"mark-church-project","timestamp":"2021-09-01T11:39:06","zone":"us-central1-b"}
* Connection #0 to host foo.example.com left intact
* Closing connection 0

    קוד התגובה הוא 200 ונעשה שימוש ב-TLSv1.2, מה שמצביע על כך שהכול פועל בצורה תקינה.

    אחר כך אפשר לוודא שמדיניות ה-SSL אוכפת את גרסת ה-TLS הנכונה על ידי ניסיון להתחבר באמצעות TLS 1.1. כדי שהשלב הזה יפעל, צריך להגדיר את מדיניות ה-SSL לגרסה מינימלית של 1.2.

  11. שולחים את אותה בקשה מהשלב הקודם, אבל אוכפים גרסת TLS של 1.1.

    curl https://foo.example.com --resolve foo.example.com:443:VIP -v \
  --cacert CERT_FILE \
  --tls-max 1.1

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

    * Added foo.example.com:443:34.149.29.76 to DNS cache
* Hostname foo.example.com was found in DNS cache
*   Trying 34.149.29.76...
* TCP_NODELAY set
* Connected to foo.example.com (34.149.29.76) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: cert.pem
  CApath: none
* TLSv1.1 (OUT), TLS handshake, Client hello (1):
* TLSv1.1 (IN), TLS alert, protocol version (582):
* error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version

    הכישלון בהשלמת לחיצת היד של TLS מצביע על כך שמדיניות ה-SSL חסמה את TLS 1.1 בהצלחה.

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

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

    gcloud compute addresses create ADDRESS_NAME --global

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

    הפלט מכיל את כתובת ה-URL המלאה של הכתובת שיצרתם, בדומה לכתובת הבאה:

    Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME].

  2. כדי לראות את כתובת ה-IP שיצרתם:

    gcloud compute addresses list

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

    NAME          ADDRESS/RANGE  TYPE      STATUS
ADDRESS_NAME  STATIC_IP_ADDRESS  EXTERNAL  RESERVED

    הפלט הזה כולל:

    • ה-ADDRESS_NAME שהגדרתם.
    • הסכום STATIC_IP_ADDRESS שהוקצה.

  3. מעדכנים את הקובץ mci.yaml עם כתובת ה-IP הסטטית:

    apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
  annotations:
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080

    מחליפים את STATIC_IP_ADDRESS באחד מהערכים הבאים:

    • כתובת ה-IP שהוקצתה, בפורמט הבא: 34.102.201.47
    • כתובת ה-URL המלאה של הכתובת שיצרתם, בדומה לכתובת הבאה: "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME"

    הערך STATIC_IP_ADDRESS הוא לא שם המשאב (ADDRESS_NAME).

  4. פורסים מחדש את המשאב MultiClusterIngress:

    kubectl apply -f mci.yaml

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

    multiclusteringress.networking.gke.io/whereami-ingress configured

  5. פועלים לפי השלבים במאמר אימות סטטוס פריסה מוצלחת כדי לוודא שהפריסה משרתת ב-STATIC_IP_ADDRESS.

אישורים ששותפו מראש

אישורים ששותפו מראש הם אישורים שהועלו אל Google Cloud ואפשר להשתמש בהם במאזן העומסים לסיום TLS במקום באישורים שמאוחסנים ב-Kubernetes Secrets. האישורים האלה מועלים מחוץ לפס מ-GKE אל Google Cloud ומקושרים למשאב MultiClusterIngress. יש גם תמיכה בכמה אישורים, באמצעות אישורים ששותפו מראש או סודות של Kubernetes.

כדי להשתמש באישורים ב-Multi Cluster Ingress, צריך להשתמש בהערה networking.gke.io/pre-shared-certs ובשמות האישורים. כשמציינים כמה אישורים עבור MultiClusterIngress מסוים, סדר קבוע מראש קובע איזה אישור יוצג ללקוח.

כדי לראות את רשימת אישורי ה-SSL הזמינים, מריצים את הפקודה:

gcloud compute ssl-certificates list

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

kind: MultiClusterIngress
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/pre-shared-certs: "domain1-cert, domain2-cert"
spec:
  template:
    spec:
      rules:
      - host: my-domain1.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain1-svc
              servicePort: 443
      - host: my-domain2.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain2-svc
              servicePort: 443

אישורים שמנוהלים על ידי Google

אישורים שמנוהלים על ידי Google נתמכים במשאבי MultiClusterIngress באמצעות ההערה networking.gke.io/pre-shared-certs. ‫Multi Cluster Ingress תומך בצירוף אישורים שמנוהלים על ידי Google למשאב MultiClusterIngress, אבל בניגוד ל-Single Cluster Ingress, לא ניתן לבצע יצירה הצהרתית של משאב Kubernetes‏ ManagedCertificate במשאבי MultiClusterIngress. צריך ליצור את האישור המנוהל על ידי Google ישירות דרך compute ssl-certificates create API לפני שאפשר לצרף אותו ל-MultiClusterIngress. כדי לעשות את זה:

  1. יוצרים אישור שמנוהל על ידי Google כמו שמתואר בשלב 1 כאן. אל תעברו לשלב 2 כי Multi Cluster Ingress יצרף את האישור הזה בשבילכם.

    gcloud compute ssl-certificates create my-google-managed-cert \
    --domains=my-domain.gcp.com \
    --global

  2. מפנים לשם האישור ב-MultiClusterIngress באמצעות ההערה networking.gke.io/pre-shared-certs.

    kind: MultiClusterIngress
metadata:
name: shopping-service
namespace: whereami
annotations:
  networking.gke.io/pre-shared-certs: "my-google-managed-cert"
spec:
template:
  spec:
    rules:
    - host: my-domain.gcp.com
      http:
        paths:
        - backend:
            serviceName: my-domain-svc
            servicePort: 8080

קובץ המניפסט שלמעלה מצרף את האישור ל-MultiClusterIngress כדי שיוכל להפסיק את התנועה עבור אשכולות ה-GKE של ה-Backend. ‏Google Cloud יחדש את האישור באופן אוטומטי לפני שתוקף האישור יפוג. החידושים מתבצעים באופן שקוף ולא נדרשים עדכונים ל-Multi Cluster Ingress.

פרוטוקולים של אפליקציות

החיבור משרת ה-proxy של מאזן העומסים לאפליקציה משתמש ב-HTTP כברירת מחדל. באמצעות ההערה networking.gke.io/app-protocols, אפשר להגדיר את מאזן העומסים כך שישתמש ב-HTTPS או ב-HTTP/2 כשהוא מעביר בקשות לאפליקציה. בשדה annotation בדוגמה הבאה, http2 מתייחס לשם היציאה MultiClusterService ו-HTTP2 מתייחס לפרוטוקול שבו משתמש מאזן העומסים.

kind: MultiClusterService
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/app-protocols: '{"http2":"HTTP2"}'
spec:
  template:
    spec:
      ports:
      - port: 443
        name: http2

BackendConfig

בקטע למעלה מוסבר איך להגדיר את ההערה.

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