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

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

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

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

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

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

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

  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. נכנסים לדף External IP addresses במסוף Google Cloud .

      נכנסים אל External IP addresses

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

    3. לוחצים על שחרור כתובת IP.

    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) שזהה לשם הדומיין שבבעלותכם. אם כבר יש לכם שני קובצי אישורים עם הערכים המתאימים ל-Common Name, אתם יכולים לדלג לקטע הבא.

  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.

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

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

  • ‫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. מאזן העומסים משתמש ב-Server Name Indication ‏ (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 בין מאזן העומסים לבין האפליקציה

אם האפליקציה שלכם, שפועלת ב-GKE Pod, יכולה לקבל בקשות 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 ומפנה את התנועה לפודים ב-targetPort 8443.