אבטחת תעבורה ל-GKE Ingress

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

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

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

כדי לאשר בקשות HTTPS מהלקוחות, למאזן העומסים צריך להיות אישור שמוכיח את הזהות שלו ללקוחות. בנוסף, למאזן העומסים צריך להיות מפתח פרטי כדי להשלים את לחיצת היד של HTTPS. מידע נוסף על מתן אישורי SSL למאזן עומסים מסוג HTTP(S) זמין במאמר הגדרת TLS בין הלקוח למאזן העומסים.

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

כדי להגדיר אישור SSL אחד או יותר בניהול Google ולשייך אותם ל-Ingress, צריך:

  • יוצרים אובייקט ManagedCertificate אחד או יותר באותו מרחב שמות כמו Ingress. אפשר לציין עד 15 אישורים למאזן העומסים
  • משייכים את האובייקטים ManagedCertificate ל-Ingress על ידי הוספת ההערה networking.gke.io/managed-certificates ל-Ingress. ההערה הזו היא רשימה מופרדת בפסיקים של ManagedCertificate אובייקטים.

מגבלות

בקטע הזה מתוארות המגבלות של אישורים שמנוהלים על ידי Google. אם אתם צריכים אישורים בניהול עצמי או אם כבר יש לכם אישורי SSL שאתם רוצים להגדיר ב-Ingress, תוכלו לעיין במאמר הגדרת HTTPS ‏ (TLS) בין הלקוח למאזן העומסים.

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

  • מספר האישורים והסוג שלהם שנתמכים על ידי Ingress מוגדרים על ידי המגבלות של אישורי SSL בניהול Google.

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

  • אם האישור מבוטל ישירות דרך רשות האישורים, Google לא מבצעת רוטציה אוטומטית של האישור. צריך למחוק את ה-ManagedCertificate וליצור חדש.

  • ‫GKE Ingress לא תומך באישורים שמנוהלים על ידי Certificate Manager. כדי להשתמש באישורים שמנוהלים על ידי Certificate Manager, צריך להשתמש ב-Gateway API.

דרישות מוקדמות

  • אתם חייבים להיות הבעלים של שם הדומיין. שם הדומיין לא יכול להיות ארוך מ-63 תווים. אתם יכולים להשתמש בכל רשם שמות דומיין כדי לקבל שם דומיין.

  • אם אתם משתמשים באשכול GKE Standard, צריך להפעיל את התוסף HttpLoadBalancing.

  • קובץ המניפסט של Ingress חייב לכלול את ההערה kubernetes.io/ingress.class: "gce". אין תמיכה בשדה ingressClassName.

  • צריך להחיל את המשאבים של Ingress ושל ManagedCertificate באותו פרויקט ובאותו מרחב שמות.

  • יוצרים כתובת IP חיצונית שמורה (סטטית). שמירת כתובת IP סטטית מבטיחה שהיא תישאר שלכם, גם אם תמחקו את ה-Ingress. אם לא שומרים כתובת IP, היא עלולה להשתנות, ואז צריך להגדיר מחדש את רשומות ה-DNS של הדומיין. משתמשים ב-Google Cloud CLI או במסוף Google Cloud כדי ליצור כתובת IP שמורה.

    gcloud

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

    gcloud compute addresses create ADDRESS_NAME --global

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

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

    gcloud compute addresses describe ADDRESS_NAME --global

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

    address: 203.0.113.32
...

    המסוף

    כדי ליצור כתובת IP שמורה:

    1. נכנסים לדף כתובות IP חיצוניות במסוף Google Cloud .

      נכנסים אל External IP addresses

    2. מציינים שם לכתובת ה-IP (לדוגמה, example-ip-address).

    3. מציינים אם רוצים כתובת IPv4 או IPv6.

    4. בוחרים באפשרות Global (גלובלי) בשדה Type (סוג).

    5. לוחצים על Reserve. כתובת ה-IP מופיעה בעמודה External Address.

    Config Connector

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

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeAddress
metadata:
  name: example-ip-address
spec:
  location: global
    כדי לפרוס את המניפסט הזה, מורידים אותו למחשב בתור compute-address.yaml ומריצים את הפקודה:

    kubectl apply -f compute-address.yaml

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

  1. יוצרים אובייקט ManagedCertificate. במשאב הזה מצוינים הדומיינים של אישור ה-SSL. דומיינים עם תו כללי לחיפוש אינם נתמכים.

    המניפסט הבא מתאר אובייקט ManagedCertificate. שומרים את קובץ המניפסט בשם managed-cert.yaml.

    apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: FIRST_CERT_NAME
spec:
  domains:
    - FIRST_DOMAIN
---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: SECOND_CERT_NAME
spec:
  domains:
    - SECOND_DOMAIN

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

    • ‫FIRST_CERT_NAME: השם של אובייקט ManagedCertificate הראשון.
    • ‫FIRST_DOMAIN: הדומיין הראשון שבבעלותכם.
    • ‫SECOND_CERT_NAME: השם של אובייקט ManagedCertificate השני.
    • ‫SECOND_DOMAIN: הדומיין השני שבבעלותכם.

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

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

    kubectl apply -f managed-cert.yaml

  3. פועלים לפי ההוראות ליצירת פריסה ושירות כדי לחשוף את האפליקציה לאינטרנט.

  4. כדי שהאובייקט ManagedCertificate יהפוך לאובייקט Active, צריך לצרף אותו ל-Ingress באמצעות ההערה networking.gke.io/managed-certificates, כמו בדוגמה הבאה. לא צריך ש-ManagedCertificate כבר יהיה Active כדי לצרף אותו ל-Ingress.

     apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: my-gmc-ingress
   annotations:
     networking.gke.io/managed-certificates: "FIRST_CERT_NAME,SECOND_CERT_NAME"
 spec:
   rules:
   - host: FIRST_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60001
   - host: SECOND_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60002
 ```

Replace <code><var>FIRST_DOMAIN</var></code> and
<code><var>SECOND_DOMAIN</var></code> with your domain names.

This manifest describes an Ingress that lists pre-shared certificate
resources in an annotation.

Note: It might take several hours for Google Cloud to provision the load
balancer and the managed certificates, and for the load balancer to begin
using the new certificates. For more information, see
[Deploy a Google-managed certificate with load balancer authorization](/certificate-manager/docs/deploy-google-managed-lb-auth#wait_until_the_certificate_has_been_activated).

  5. ממתינים לסיום הקצאת האישורים שמנוהלים על ידי Google. התהליך עשוי להימשך עד 60 דקות. אפשר לבדוק את הסטטוס של האישורים באמצעות הפקודה הבאה:

    kubectl describe managedcertificate managed-cert

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

    Name:         managed-cert
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         ManagedCertificate
(...)
Spec:
 Domains:
   FQDN_1
   FQDN_2
Status:
 CertificateStatus: Active
(...)

    הערך בשדה Status.CertificateStatus מציין שהוקצה אישור. אם הערך של Status.CertificateStatus הוא לא Active, האישור עדיין לא הוקצה.

  6. כדי לוודא ש-SSL פועל, נכנסים לדומיינים באמצעות הקידומת https://. הדפדפן מציין שהחיבור מאובטח ואפשר לראות את פרטי האישור.

מעבר לאישורים שמנוהלים על ידי Google מאשרים שמנוהלים באופן עצמאי

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

ההוראות האלה מיועדות למעבר מאישורי SSL בניהול עצמי לאישורי SSL בניהול Google.

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

  2. ממתינים עד שהסטטוס של משאב האישור שמנוהל על ידי Google יהיה Active. בודקים את סטטוס האישור באמצעות הפקודה הבאה:

    kubectl describe managedcertificate managed-cert

  3. כשהסטטוס הוא Active, מעדכנים את Ingress כדי להסיר את ההפניות לאישור שמנוהל עצמאית.

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

כדי להסיר אישור שמנוהל על ידי Google מהאשכול, צריך למחוק את האובייקט ManagedCertificate ולהסיר את הערת ה-Ingress שמפנה אליו.

  1. מחיקת האובייקט ManagedCertificate:

    kubectl delete -f managed-cert.yaml

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

    managedcertificate.networking.gke.io "managed-cert" deleted

  2. מסירים את ההערה מ-Ingress:

    kubectl annotate ingress managed-cert-ingress networking.gke.io/managed-certificates-

    שימו לב לסימן המינוס, -, בסוף הפקודה.

  3. משחררים את כתובת ה-IP הסטטית ששמרתם למאזן העומסים.

    אפשר להשתמש ב-Google Cloud CLI, במסוף Google Cloud או ב-Config Connector כדי לבטל הקצאה של כתובת IP שמורה.

    gcloud

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

    gcloud compute addresses delete ADDRESS_NAME --global

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

    המסוף

    כדי לשחרר את כתובת ה-IP השמורה, מבצעים את השלבים הבאים:

    1. נכנסים לדף כתובות IP חיצוניות במסוף Google Cloud .

      נכנסים אל External IP addresses

    2. מסמנים את התיבה לצד כתובת ה-IP שרוצים לשחרר.

    3. לוחצים על Release IP address.

    Config Connector

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

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeAddress
metadata:
  name: example-ip-address
spec:
  location: global

    כדי לפרוס את המניפסט הזה, מורידים אותו למחשב בתור compute-address.yaml ומריצים את הפקודה:

    kubectl delete -f compute-address.yaml

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

כדי להשתמש באישור ששותף מראש או ב-Kubernetes Secrets, קודם צריך אישור אחד או יותר, עם מפתחות פרטיים תואמים. לכל אישור צריך להיות שם נפוץ (CN) ששווה לשם דומיין שבבעלותכם. אם כבר יש לכם שני קובצי אישורים עם הערכים המתאימים של השם הנפוץ, אתם יכולים לדלג אל השלב הבא.

  1. כדי ליצור את המפתח הראשון:

    openssl genrsa -out test-ingress-1.key 2048

  2. יוצרים את בקשת החתימה על האישור הראשונה:

    openssl req -new -key test-ingress-1.key -out test-ingress-1.csr \
    -subj "/CN=FIRST_DOMAIN"

    מחליפים את FIRST_DOMAIN בשם דומיין שבבעלותכם, כמו example.com.

  3. יוצרים את האישור הראשון:

    openssl x509 -req -days 365 -in test-ingress-1.csr -signkey test-ingress-1.key \
    -out test-ingress-1.crt

  4. יוצרים את המפתח השני:

    openssl genrsa -out test-ingress-2.key 2048

  5. יוצרים את בקשת החתימה השנייה על אישור:

    openssl req -new -key test-ingress-2.key -out test-ingress-2.csr \
    -subj "/CN=SECOND_DOMAIN"

    מחליפים את SECOND_DOMAIN בשם דומיין אחר שבבעלותכם, כמו examplepetstore.com.

  6. יוצרים את האישור השני:

    openssl x509 -req -days 365 -in test-ingress-2.csr -signkey test-ingress-2.key \
    -out test-ingress-2.crt

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

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

במשימות הנותרות נעשה שימוש בערכי ה-placeholder הבאים כדי להתייחס לדומיינים, לאישורים ולמפתחות שלכם:

  • ‫FIRST_CERT_FILE: הנתיב לקובץ האישור הראשון.
  • ‫FIRST_KEY_FILE: הנתיב לקובץ המפתח שמתאים לאישור הראשון.
  • ‫FIRST_DOMAIN: שם דומיין שבבעלותכם.
  • ‫FIRST_SECRET_NAME: השם של הסוד שמכיל את האישור והמפתח הראשונים.
  • ‫SECOND_CERT_FILE: הנתיב לקובץ האישור השני.
  • ‫SECOND_KEY_FILE: הנתיב לקובץ המפתח שמתאים לאישור השני.
  • ‫SECOND_DOMAIN: שם דומיין שני שבבעלותכם.
  • ‫SECOND_SECRET_NAME: השם של הסוד שמכיל את האישור והמפתח השני.

שימוש באישור ששותף מראש

אפשר להשתמש באישורי SSL בניהול עצמי שמעלים לפרויקט Google Cloud . האישורים האלה נקראים אישורים ששותפו מראש. אפשר לציין אישור אחד או יותר ששותפו מראש עבור Ingress.

כדי להשתמש בכמה אישורים ששותפו מראש, צריך לבצע את השלבים הבאים:

  1. לכל זוג של אישור ומפתח, יוצרים משאב אישור SSL שגלוי לכולם ב- Google Cloud.

     gcloud compute ssl-certificates create FIRST_CERT_NAME \
     --certificate=FIRST_CERT_FILE \
     --private-key=FIRST_KEY_FILE
 ```

```sh
 gcloud compute ssl-certificates create SECOND_CERT_NAME \
     --certificate=SECOND_CERT_FILE \
     --private-key=SECOND_KEY_FILE
 ```

Replace the following:
    • ‫FIRST_CERT_NAME, ‏SECOND_CERT_NAME: השמות של האישורים הראשון והשני.
    • ‫FIRST_CERT_FILE, SECOND_CERT_FILE: קובצי האישורים הראשונים והשניים שלכם.
    • ‫FIRST_KEY_FILE:, SECOND_KEY_FILE קובצי המפתחות הראשון והשני.

  2. במניפסט של Ingress, מוסיפים את ההערה ingress.gcp.kubernetes.io/pre-shared-cert. הערך של האנוטציה הוא רשימה של שמות האישורים שמופרדים בפסיקים. בנוסף, בקטע spec.rules, צריך לכלול את השדות host כדי לציין את הדומיינים של השירותים.

     apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: my-psc-ingress
   annotations:
     ingress.gcp.kubernetes.io/pre-shared-cert: "FIRST_CERT_NAME,SECOND_CERT_NAME"
 spec:
   rules:
   - host: FIRST_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60001
   - host: SECOND_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60002
 ```

Replace <code><var>FIRST_DOMAIN</var></code> and
<code><var>SECOND_DOMAIN</var></code> with your domain names.

This manifest describes an Ingress that lists pre-shared certificate
resources in an annotation.

שימוש בסודות של Kubernetes

כדי לספק למאזן עומסים ב-HTTP(S) אישורים ומפתחות שיצרתם בעצמכם, צריך ליצור אובייקט Secret אחד או יותר של Kubernetes. כל סוד מכיל אישור ומפתח. מוסיפים את הסודות לשדה tls במניפסט Ingress. מאזן העומסים משתמש ב-SNI (אינדיקציה של שם השרת) כדי לקבוע איזה אישור להציג ללקוח, על סמך שם הדומיין בלחיצת היד של TLS.

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

  1. יוצרים Secret לכל זוג של אישור ומפתח:

     kubectl create secret tls FIRST_SECRET_NAME \
     --cert=FIRST_CERT_FILE \
     --key=FIRST_KEY_FILE
 ```

```sh
 kubectl create secret tls SECOND_SECRET_NAME \
     --cert=SECOND_CERT_FILE \
     --key=SECOND_KEY_FILE
 ```

  2. במניפסט של Ingress, בקטע spec.tls, מפרטים את הסודות שיצרתם. בנוסף, בקטע spec.rules, צריך לכלול את השדות host כדי לציין את הדומיינים של השירותים.

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-mc-ingress
spec:
  tls:
  - secretName: FIRST_SECRET_NAME
  - secretName: SECOND_SECRET_NAME
  rules:
  - host: FIRST_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-mc-service
            port:
              number: 60001
  - host: SECOND_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-mc-service
            port:
              number: 60002

    מחליפים את FIRST_DOMAIN ואת SECOND_DOMAIN בשמות דומיין שבבעלותכם, למשל example.com ו-examplepetstore.com.

השינויים ב-Secrets מתעדכנים מעת לעת, כך שאם משנים את הנתונים בתוך ה-Secret, יידרשו עד 10 דקות עד שהשינויים יחולו על מאזן העומסים.

כדי לאבטח את ה-Ingress המוצפן ב-HTTPS עבור אשכולות GKE, אפשר לעיין בדוגמה Secure Ingress.

השבתת HTTP

אם רוצים שכל התנועה בין הלקוח לבין מאזן העומסים תשתמש ב-HTTPS, אפשר להשבית את ה-HTTP על ידי הוספת ההערה kubernetes.io/ingress.allow-http למניפסט של Ingress. מגדירים את ערך ההערה כ-"false".

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

המניפסט הזה כולל את SECRET_NAME, שהוא השם של הסוד שיצרתם.

‫HTTP/2 בין הלקוח למאזן העומסים

לקוחות יכולים להשתמש ב-HTTP/2 כדי לשלוח בקשות למאזן העומסים. לא נדרשת הגדרה.

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

אתם יכולים להגדיר את הפרוטוקול שמשמש לתקשורת בין מאזן העומסים לבין ה-Pods של האפליקציה, כדי להבטיח אבטחה מקצה לקצה או כדי לשפר את הביצועים של התנועה הפנימית. למרות שברירת המחדל של מאזן העומסים היא HTTP/1.1 לא מוצפן לחיבורי בק-אנד, אתם יכולים להפעיל HTTPS או HTTP/2 כדי לעמוד בדרישות הספציפיות של האפליקציה.

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

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

כדי להגדיר את הפרוטוקול שמשמש בין מאזן העומסים לבין האפליקציה, משתמשים בהערה cloud.google.com/app-protocols במניפסט של השירות. המניפסט של השירות הזה צריך לכלול את type: NodePort, אלא אם אתם משתמשים באיזון עומסים מובנה בקונטיינר. אם אתם משתמשים באיזון עומסים שמקורם בקונטיינר, אתם צריכים להשתמש ב-type: ClusterIP.

במניפסט השירות הבא מצוינות שתי יציאות. ההערה מציינת שכאשר מאזן עומסים מסוג HTTP(S) מכוון ליציאה 80 של השירות, הוא צריך להשתמש ב-HTTP. וכשמאזן העומסים מכוון ליציאה 443 של השירות, הוא צריך להשתמש ב-HTTPS.

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

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

שימוש ב-HTTP/2 בין מאזן העומסים לבין האפליקציה

אם האפליקציה שלכם, שפועלת ב-Pod של GKE, יכולה לקבל בקשות HTTP/2, אתם יכולים להגדיר את מאזן העומסים כך שישתמש ב-HTTP/2 כשהוא מעביר בקשות לאפליקציה.

כדי להפעיל HTTP/2, צריך להשתמש בהערת cloud.google.com/app-protocols במניפסט של שירות Kubernetes. ההערה הזו מציינת את הפרוטוקול שמאזן העומסים משתמש בו כדי לתקשר עם האפליקציה. כדי לוודא שמאזן העומסים שולח בקשת HTTP/2 נכונה לשרת העורפי, השרת העורפי צריך להיות מוגדר עם SSL.

הדוגמה הבאה היא של מניפסט שירות שהוגדר ל-HTTP/2:

apiVersion: v1
kind: Service
metadata:
  name: my-http2-service
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: my-port
    protocol: TCP
    port: 443
    targetPort: 8443

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

  • ההערה cloud.google.com/app-protocols מוגדרת לערך '{"my-port":"HTTP2"}', שמורה למאזן העומסים להשתמש ב-HTTP/2 לתעבורה שנשלחת ליציאה שנקראת my-port.
  • היציאה מוגדרת ל-443 ומפנה את התנועה אל ה-Pods ב-targetPort 8443.