יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

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

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

Autopilot Standard

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

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

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

כדי לאשר בקשות 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 תווים. אתם יכולים להשתמש בכל רשם שמות דומיינים כדי לקבל שם דומיין.

הערה: שירות Google Domains כבר לא פעיל. עכשיו Squarespace מנהלת דומיינים שנרכשו בעבר מ-Google Domains. אתם יכולים לנהל את הדומיין ואת רשומות ה-DNS שלו דרך החשבון שלכם ב-Squarespace.
אם אתם משתמשים באשכול GKE Standard, צריך להפעיל את התוסף HttpLoadBalancing.
המניפסט של Ingress חייב לכלול את ההערה kubernetes.io/ingress.class: "gce". השדה ingressClassName לא נתמך.
צריך להחיל את המשאבים Ingress ו-ManagedCertificate באותו פרויקט ובאותו מרחב שמות.
יוצרים כתובת IP חיצונית שמורה (סטטית). שמירת כתובת IP סטטית מבטיחה שהיא תישאר שלכם, גם אם תמחקו את ה-Ingress. אם לא תשריינו כתובת IP, יכול להיות שהיא תשתנה ותצטרכו להגדיר מחדש את רשומות ה-DNS של הדומיין. כדי ליצור כתובת IP שמורה, משתמשים ב-Google Cloud CLI או במסוף Cloud de Confiance .
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 במסוף Cloud de Confiance .
  
  נכנסים אל 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

יוצרים אובייקט 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, אתם צריכים לדעת רק את השמות שלהם.
מחילים את המניפסט על האשכול:
```
kubectl apply -f managed-cert.yaml
```
פועלים לפי ההוראות ליצירת פריסה ושירות כדי לחשוף את האפליקציה לאינטרנט.

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

 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 Cloud de Confiance 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).

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

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

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

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

יוצרים משאב ManagedCertificate ומחילים אותו על האשכול, כמו שמתואר במאמר הגדרת אישור בניהול Google.
מעדכנים את המניפסט של Ingress כדי להוסיף את ההערה networking.gke.io/managed-certificates שמפנה למשאב ManagedCertificate החדש. משאירים את האישור הקיים בניהול עצמי בהערה ingress.gcp.kubernetes.io/pre-shared-cert, כמו בדוגמה הבאה:
```
metadata:
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "EXISTING_SELF_MANAGED_CERT_NAME"
    networking.gke.io/managed-certificates: "NEW_MANAGED_CERT_NAME"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫EXISTING_SELF_MANAGED_CERT_NAME: השם של משאב אישור ה-SSL הקיים בניהול עצמי.
- ‫NEW_MANAGED_CERT_NAME: השם של אובייקט ManagedCertificate החדש.
אזהרה: אל תמחקו את ההערה ingress.gcp.kubernetes.io/pre-shared-cert מהמניפסט של Ingress. הבקר GKE ManagedCertificate משתמש בהערה הזו במשאב Ingress כדי לצרף אישורים בניהול Google למאזן העומסים. מחיקת ההערה תסיר את כל האישורים ממאזן העומסים, ועלולה לגרום לשיבוש בשירות בזמן שהבקר מתאים את המצב.
מחילים את המניפסט המעודכן של Ingress:
```
kubectl apply -f INGRESS_MANIFEST.yaml
```
מחליפים את INGRESS_MANIFEST בשם של קובץ המניפסט של Ingress.

אחרי שיוצרים את המשאב ManagedCertificate, הבקר של ManagedCertificate יוצר את משאב אישור ה-SSL של Compute Engine (עם שם שנוצר ומתחיל ב-mcrt-). החלת המניפסט של Ingress מפעילה סנכרון, שמוסיף את שם האישור mcrt- שנוצר להערה ingress.gcp.kubernetes.io/pre-shared-cert ב-Ingress הפעיל, כדי שבקר ה-Ingress יצרף אותו לשרת ה-proxy לחלוקת העומס של מאזן העומסים. בזמן ש- Cloud de Confiance מקצה את האישור החדש, מאזן העומסים ממשיך להעביר תנועה באמצעות האישור הקיים בניהול עצמי שהגדרתם בהערה ingress.gcp.kubernetes.io/pre-shared-cert.
ממתינים עד שהסטטוס של המשאב ManagedCertificate יהיה Active. זה יכול להימשך עד 60 דקות. בסיום ההקצאה, גם האישור בניהול עצמי וגם האישור בניהול Google יהיו פעילים במאזן העומסים. כדי לבדוק את הסטטוס ולאחזר את מזהה האישור שנוצר ל-mcrt-, מתארים את המשאב ManagedCertificate:
```
kubectl describe managedcertificate NEW_MANAGED_CERT_NAME
```
הפלט אמור להיראות כך:
```
Name:         NEW_MANAGED_CERT_NAME
Namespace:    default
(...)
Spec:
  Domains:
    DOMAIN
Status:
  Certificate Name:    MCRT_CERT_ID
  Certificate Status:  Active
  Domain Status:
    Domain:  DOMAIN
    Status:  Active
```
שימו לב לערך של השדה Certificate Name בקטע Status (לדוגמה, mcrt-a1b2c3d4-e5f6-7890-abcd-ef1234567890).
במניפסט של Ingress, מחליפים את מזהה האישור בניהול עצמי שמופיע בהערה ingress.gcp.kubernetes.io/pre-shared-cert במזהה של האישור בניהול Google:
```
metadata:
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "MCRT_CERT_ID"
    networking.gke.io/managed-certificates: "NEW_MANAGED_CERT_NAME"
```
מחליפים את MCRT_CERT_ID בערך Certificate Name (שמתחיל ב-mcrt-) מהשלב הקודם.
מחילים את המניפסט המעודכן של Ingress:
```
kubectl apply -f INGRESS_MANIFEST.yaml
```
השינוי הזה מנתק את האישור הישן בניהול עצמי ממאזן העומסים, ומשאיר את האישור הפעיל בניהול Google (MCRT_CERT_ID) מחובר להערה ingress.gcp.kubernetes.io/pre-shared-cert. השינוי הזה מעביר את כל התנועה לאישור שמנוהל על ידי Google בלי הפרעה.
אחרי שמנתקים את האישור הישן בניהול עצמי ממאזן העומסים, אפשר למחוק אותו בבטחה אם לא צריך אותו יותר, כי בקר ה-Ingress לא מנהל את משאבי אישורי ה-SSL של Compute Engine ששותפו מראש ולא אוסף את הזבל שלהם:
```
gcloud compute ssl-certificates delete EXISTING_SELF_MANAGED_CERT_NAME
```

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

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

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

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

kubectl delete -f managed-cert.yaml

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

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

מסירים את ההערה מה-Ingress:
```
kubectl annotate ingress managed-cert-ingress networking.gke.io/managed-certificates-
```
שימו לב לסימן המינוס, -, בסוף הפקודה.
משחררים את כתובת ה-IP הסטטית ששמרתם למאזן העומסים.

כדי לשחרר כתובת IP שמורה, אתם יכולים להשתמש ב-Google Cloud CLI, במסוף Cloud de Confiance או ב-Config Connector.
gcloud
כדי לשחרר את כתובת ה-IP השמורה, משתמשים בפקודה הבאה:
gcloud compute addresses delete ADDRESS_NAME --global
מחליפים את ADDRESS_NAME בשם של כתובת ה-IP.
המסוף
כדי לשחרר את כתובת ה-IP השמורה, מבצעים את השלבים הבאים:
1. נכנסים לדף External IP addresses במסוף Cloud de Confiance .
  
  נכנסים אל 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, קודם צריך אישור אחד או יותר, עם מפתחות פרטיים תואמים. לכל אישור צריך להיות שם נפוץ (CN) שזהה לשם הדומיין שבבעלותכם. אם כבר יש לכם שני קובצי אישורים עם הערכים המתאימים ל-Common Name, אתם יכולים לדלג לקטע הבא.

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

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

יוצרים את הבקשה הראשונה לחתימה על אישור:
```
openssl req -new -key test-ingress-1.key -out test-ingress-1.csr \
    -subj "/CN=FIRST_DOMAIN"
```
מחליפים את FIRST_DOMAIN בשם דומיין שבבעלותכם, כמו example.com.

כדי ליצור את האישור הראשון:

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

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

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

יוצרים את הבקשה השנייה לחתימה על אישור:
```
openssl req -new -key test-ingress-2.key -out test-ingress-2.csr \
    -subj "/CN=SECOND_DOMAIN"
```
מחליפים את SECOND_DOMAIN בשם דומיין אחר שבבעלותכם, כמו examplepetstore.com.

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

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

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

לכל אחד מזוגות המפתחות והאישורים, יוצרים משאב של אישור SSL שגלוי לכולם ב- Cloud de Confiance.
```
 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 קובץ המפתח הראשון והשני.

במניפסט של 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) אישורים ומפתחות שיצרתם בעצמכם, צריך ליצור אובייקט אחד או יותר של Kubernetes Secret. כל Secret מכיל אישור ומפתח. מוסיפים את הסודות לשדה tls במניפסט של Ingress. מאזן העומסים משתמש ב-Server Name Indication ‏ (SNI) כדי לקבוע איזה אישור להציג ללקוח, על סמך שם הדומיין בלחיצת היד בפרוטוקול TLS.

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

יוצרים 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
 ```

במניפסט של 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.

השינויים בסודות נאספים מדי פעם, כך שאם משנים את הנתונים בתוך הסוד, השינויים האלה יחולו על מאזן העומסים תוך 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.

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