‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

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

שימוש בשערי יציאה (egress) של Cloud Service Mesh באשכולות GKE: הדרכה

במדריך הזה נסביר איך להשתמש בשערי תעבורת נתונים יוצאת (egress) של Cloud Service Mesh ובאמצעי בקרה אחרים של Google Cloud כדי לאבטח תעבורת נתונים יוצאת מעומסי עבודה שנפרסו באשכול Google Kubernetes Engine. המדריך הזה מיועד כתוספת לשיטות מומלצות לשימוש בשערי יציאה (egress) של Cloud Service Mesh באשכולות GKE.

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

מטרות

מגדירים את התשתית להרצת Cloud Service Mesh:
- רשת VPC מותאמת אישית ותת-רשת פרטית
- Cloud NAT לגישה לאינטרנט
- אשכול GKE פרטי עם מאגר צמתים נוסף ל-pods של שער יציאה
- כללי חומת אש של VPC מגבילים את התעבורה היוצאת. רק צמתי שער יכולים להגיע למארחים חיצוניים
- גישה פרטית ל-Google לחיבור אל Container Registry ואל Google APIs
מתקינים את Cloud Service Mesh.
מתקינים שרתי proxy של שערים לתעבורת נתונים יוצאת שפועלים במאגר צמתים ייעודי.
הגדרת כללי ניתוב מרובי דיירים לתעבורה חיצונית דרך שער היציאה:
- אפליקציות במרחב השמות team-x יכולות להתחבר אל example.com
- אפליקציות במרחב השמות team-y יכולות להתחבר אל httpbin.org
משתמשים במשאב Sidecar כדי להגביל את היקף ההגדרה של יציאת פרוקסי ה-sidecar לכל מרחב שמות.
הגדרת מדיניות הרשאות כדי לאכוף כללי יציאה.
מגדירים את שער היציאה כך שישדרג בקשות HTTP רגילות ל-TLS (יצירת TLS).
הגדרת שער יציאה להעברת תעבורת TLS.
הגדרת כללי מדיניות של רשת Kubernetes כאמצעי בקרה נוסף על תעבורת נתונים יוצאת (egress).
להגדיר גישה ישירה לממשקי Google API באמצעות גישה פרטית ל-Google והרשאות לניהול זהויות והרשאות גישה (IAM).

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
- יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

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

הפעלת Cloud Shell
יוצרים ספריית עבודה לשימוש במהלך ההדרכה:
```
mkdir -p ~/WORKING_DIRECTORY
cd ~/WORKING_DIRECTORY
```
יוצרים סקריפט מעטפת כדי לאתחל את הסביבה בשביל המדריך. מחליפים את המשתנים ועורכים אותם בהתאם לפרויקט ולהעדפות. אם תוקף הסשן שלכם במעטפת פג, מריצים את הסקריפט הזה עם הפקודה source כדי לאתחל מחדש את הסביבה:
```
cat << 'EOF' > ./init-egress-tutorial.sh
#! /usr/bin/env bash
PROJECT_ID=YOUR_PROJECT_ID
REGION=REGION
ZONE=ZONE

gcloud config set project ${PROJECT_ID}
gcloud config set compute/region ${REGION}
gcloud config set compute/zone ${ZONE}

EOF
```

הפעלה של compute.googleapis.com:

gcloud services enable compute.googleapis.com --project=YOUR_PROJECT_ID

הופכים את הסקריפט לניתן להרצה ומריצים אותו באמצעות הפקודה source כדי לאתחל את הסביבה. אם מוצגת בקשה להפעיל את Y, בוחרים באפשרות Y:compute.googleapis.com
```
chmod +x ./init-egress-tutorial.sh
source ./init-egress-tutorial.sh
```

הגדרת התשתית

יצירת רשת VPC ורשת משנה

יוצרים רשת VPC חדשה:

gcloud compute networks create vpc-network \
    --subnet-mode custom

יוצרים רשת משנה להרצת האשכול עם טווחים של כתובות IP משניות שהוקצו מראש לקבוצות Pod ולשירותים. הגישה הפרטית ל-Google מופעלת כדי שאפליקציות עם כתובות IP פנימיות בלבד יוכלו להגיע ל-Google APIs ולשירותים של Google:
```
gcloud compute networks subnets create subnet-gke \
    --network vpc-network \
    --range 10.0.0.0/24 \
    --secondary-range pods=10.1.0.0/16,services=10.2.0.0/20 \
    --enable-private-ip-google-access
```

הגדרת Cloud NAT

‫Cloud NAT מאפשר לעומסי עבודה ללא כתובות IP חיצוניות להתחבר ליעדים באינטרנט ולקבל תשובות נכנסות מהיעדים האלה.

יוצרים Cloud Router:

gcloud compute routers create nat-router \
    --network vpc-network

מוסיפים הגדרת NAT לנתב:

gcloud compute routers nats create nat-config \
    --router nat-router \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

יצירת חשבונות שירות לכל מאגר צמתים של GKE

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

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

gcloud iam service-accounts create sa-application-nodes \
    --description="SA for application nodes" \
    --display-name="sa-application-nodes"

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

gcloud iam service-accounts create sa-gateway-nodes \
    --description="SA for gateway nodes" \
    --display-name="sa-gateway-nodes"

מתן הרשאות לחשבונות השירות

מוסיפים קבוצה מינימלית של תפקידי IAM לחשבונות השירות של האפליקציה והשער. התפקידים האלה נדרשים לרישום ביומן, למעקב ולשליפה של תמונות קונטיינרים פרטיות מ-Container Registry.

    project_roles=(
        roles/logging.logWriter
        roles/monitoring.metricWriter
        roles/monitoring.viewer
        roles/storage.objectViewer
    )
    for role in "${project_roles[@]}"
    do
        gcloud projects add-iam-policy-binding ${PROJECT_ID} \
            --member="serviceAccount:sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
            --role="$role"
        gcloud projects add-iam-policy-binding ${PROJECT_ID} \
            --member="serviceAccount:sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
            --role="$role"
    done

יצירת הכללים של חומת האש

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

יוצרים כלל ברירת מחדל (עדיפות נמוכה) של חומת אש שחוסם את כל התעבורה היוצאת מרשת ה-VPC:

gcloud compute firewall-rules create global-deny-egress-all \
    --action DENY \
    --direction EGRESS \
    --rules all \
    --destination-ranges 0.0.0.0/0 \
    --network vpc-network \
    --priority 65535 \
    --description "Default rule to deny all egress from the network."

יוצרים כלל שמאפשר רק לצמתים עם חשבון השירות של שער להגיע לאינטרנט:

gcloud compute firewall-rules create gateway-allow-egress-web \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp:80,tcp:443 \
    --target-service-accounts sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --network vpc-network \
    --priority 1000 \
    --description "Allow the nodes running the egress gateways to connect to the web"

מאפשרים לצמתים להגיע למישור הבקרה של Kubernetes:

gcloud compute firewall-rules create allow-egress-to-api-server \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp:443,tcp:10250 \
    --target-service-accounts sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com,sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --destination-ranges 10.5.0.0/28 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow nodes to reach the Kubernetes API server."

אופציונלי: לא צריך את כלל חומת האש הזה אם משתמשים ב-Managed Cloud Service Mesh.

‫Cloud Service Mesh משתמש ב-webhooks כשהוא מוסיף שרתי proxy מסוג sidecar לעומסי עבודה. מאפשרים לשרת GKE API לקרוא ל-webhooks שנחשפים על ידי מישור הבקרה של Service mesh שפועל בצמתים:

gcloud compute firewall-rules create allow-ingress-api-server-to-webhook \
    --action ALLOW \
    --direction INGRESS \
    --rules tcp:15017 \
    --target-service-accounts sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com,sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --source-ranges 10.5.0.0/28 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow the API server to call the webhooks exposed by istiod discovery"

מאפשרים קישוריות יוצאת בין הצמתים לבין ה-Pods שפועלים באשכול. ‫GKE יוצר באופן אוטומטי כלל תואם לתעבורת נתונים נכנסת (ingress). לא נדרש כלל לקישוריות של שירותים כי שרשור הניתוב של iptables תמיד ממיר כתובות IP של שירותים לכתובות IP של Pod.

gcloud compute firewall-rules create allow-egress-nodes-and-pods \
    --action ALLOW \
    --direction EGRESS \
    --rules all \
    --target-service-accounts sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com,sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --destination-ranges 10.0.0.0/24,10.1.0.0/16 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow egress to other Nodes and Pods"

מאפשרים גישה לקבוצות השמורות של כתובות IP שמשמשות את הגישה הפרטית ל-Google להצגת ממשקי Google API,‏ Container Registry ושירותים אחרים:
```
gcloud compute firewall-rules create allow-egress-gcp-apis \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp \
    --target-service-accounts sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com,sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --destination-ranges 199.36.153.8/30 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow access to the VIPs used by Google Cloud APIs (Private Google Access)"
```
אם אתם משתמשים ב-VPC Service Controls, השתמשו בכתובת 199.36.153.8/30 במקום זאת. מידע נוסף מפורט בסעיף הבא.

במקום להשתמש בסט השמור של כתובות IP פנימיות, אפשר לחשוף נקודת קצה של Private Service Connect עם כתובת IP פנימית לפי בחירתכם.

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

gcloud compute firewall-rules create allow-ingress-gcp-health-checker \
    --action ALLOW \
    --direction INGRESS \
    --rules tcp:80,tcp:443 \
    --target-service-accounts sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com,sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --source-ranges 35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow workloads to respond to Google Cloud health checks"

הגדרת גישה פרטית ל- Google Cloud APIs

הגישה הפרטית ל-Google מאפשרת למכונות וירטואליות ול-Pods שיש להם רק כתובות IP פנימיות לגשת לשירותים ולממשקי Google API. למרות שממשקי Google API ושירותי Google מוגשים מכתובות IP חיצוניות, התעבורה מהצמתים אף פעם לא יוצאת מהרשת של Google כשמשתמשים בגישה פרטית ל-Google.

מפעילים את Cloud DNS API:

gcloud services enable dns.googleapis.com

יוצרים אזור DNS פרטי, רשומות CNAME ורשומות A כדי שהצמתים ועומסי העבודה יוכלו להתחבר לממשקי Google APIs ולשירותים של Google באמצעות גישה פרטית ל-Google ושם המארח private.googleapis.com:

gcloud dns managed-zones create private-google-apis \
    --description "Private DNS zone for Google APIs" \
    --dns-name googleapis.com \
    --visibility private \
    --networks vpc-network

gcloud dns record-sets transaction start --zone private-google-apis

gcloud dns record-sets transaction add private.googleapis.com. \
    --name "*.googleapis.com" \
    --ttl 300 \
    --type CNAME \
    --zone private-google-apis

gcloud dns record-sets transaction add "199.36.153.8" \
"199.36.153.9" "199.36.153.10" "199.36.153.11" \
    --name private.googleapis.com \
    --ttl 300 \
    --type A \
    --zone private-google-apis

gcloud dns record-sets transaction execute --zone private-google-apis

הגדרת גישה פרטית ל-Container Registry

יוצרים תחום DNS פרטי, רשומת CNAME ורשומת A כדי שהצמתים יוכלו להתחבר ל-Container Registry באמצעות Private Google Access ושם המארח gcr.io:

gcloud dns managed-zones create private-gcr-io \
    --description "private zone for Container Registry" \
    --dns-name gcr.io \
    --visibility private \
    --networks vpc-network

gcloud dns record-sets transaction start --zone private-gcr-io

gcloud dns record-sets transaction add gcr.io. \
    --name "*.gcr.io" \
    --ttl 300 \
    --type CNAME \
    --zone private-gcr-io

gcloud dns record-sets transaction add "199.36.153.8" "199.36.153.9" "199.36.153.10" "199.36.153.11" \
    --name gcr.io \
    --ttl 300 \
    --type A \
    --zone private-gcr-io

gcloud dns record-sets transaction execute --zone private-gcr-io

יצירת אשכול GKE פרטי

כדי להוסיף את כתובת ה-IP החיצונית של Cloud Shell לרשימת הרשתות שמורשות לגשת לשרת ה-API של האשכול:
```
SHELL_IP=$(dig TXT -4 +short @ns1.google.com o-o.myaddr.l.google.com)
```
אחרי תקופה של חוסר פעילות, כתובת ה-IP החיצונית של המכונה הווירטואלית של Cloud Shell יכולה להשתנות. במקרה כזה, צריך לעדכן את רשימת הרשתות המורשות של האשכול. מוסיפים את הפקודה הבאה לסקריפט האתחול:
```
cat << 'EOF' >> ./init-egress-tutorial.sh
SHELL_IP=$(dig TXT -4 +short @ns1.google.com o-o.myaddr.l.google.com)
gcloud container clusters update cluster1 \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP//\"}/32
EOF
```

מפעילים את Google Kubernetes Engine API:

gcloud services enable container.googleapis.com

יצירת אשכול GKE פרטי:
```
gcloud container clusters create cluster1 \
    --enable-ip-alias \
    --enable-private-nodes \
    --release-channel "regular" \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP//\"}/32 \
    --master-ipv4-cidr 10.5.0.0/28 \
    --enable-dataplane-v2 \
    --service-account "sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
    --machine-type "e2-standard-4" \
    --network "vpc-network" \
    --subnetwork "subnet-gke" \
    --cluster-secondary-range-name "pods" \
    --services-secondary-range-name "services" \
    --workload-pool "${PROJECT_ID}.svc.id.goog" \
    --zone ${ZONE}
```
יצירת האשכול נמשכת כמה דקות. לצומתי האשכול יש כתובות IP פנימיות. לפודים ולשירותים מוקצות כתובות IP מהטווחים המשניים שצוינו ושמוגדרים כשיוצרים את רשת המשנה של ה-VPC.

כדי להשתמש ב-Cloud Service Mesh עם מישור בקרה בתוך האשכול, צריך להשתמש בצמתי האשכול בסוג מכונה עם לפחות 4 ליבות וירטואליות (vCPU).

‫Google ממליצה להירשם לערוץ ההפצה 'רגיל' כדי לוודא שהצמתים מריצים גרסת Kubernetes שנתמכת על ידי Cloud Service Mesh.

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

מידע נוסף על הדרישות והמגבלות להפעלת Cloud Service Mesh מנוהל זמין במאמר תכונות נתמכות של Cloud Service Mesh מנוהל.

איחוד זהויות של עומסי עבודה ל-GKE מופעל באשכול. Cloud Service Mesh דורש איחוד זהויות של עומסי עבודה ל-GKE, וזו הדרך המומלצת לגשת ל-Google APIs מעומסי עבודה ב-GKE.
יוצרים מאגר צמתים בשם gateway. מאגר הצמתים הזה הוא המקום שבו שער היציאה (egress) נפרס. הdedicated=gateway:NoSchedule taint נוסף לכל צומת במאגר הצמתים של השער.
```
gcloud container node-pools create "gateway" \
    --cluster "cluster1" \
    --machine-type "e2-standard-4" \
    --node-taints dedicated=gateway:NoSchedule \
    --service-account "sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
    --num-nodes "1"
```
‫taints and tolerations ב-Kubernetes עוזרים לוודא שרק קבוצות Pod של שער יציאה פועלות בצמתים במאגר צמתי השער.
מורידים את פרטי הכניסה כדי להתחבר לאשכול באמצעות kubectl:
```
gcloud container clusters get-credentials cluster1
```

מוודאים שלצמתי השער יש את ה-taint הנכון:

kubectl get nodes -l cloud.google.com/gke-nodepool=gateway -o yaml \
-o=custom-columns='name:metadata.name,taints:spec.taints[?(@.key=="dedicated")]'

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

name                                 taints
gke-cluster1-gateway-9d65b410-cffs   map[effect:NoSchedule key:dedicated value:gateway]

התקנה והגדרה של Cloud Service Mesh

פועלים לפי אחד ממדריכי ההתקנה של Cloud Service Mesh:

אחרי שמתקינים את Cloud Service Mesh, מפסיקים וחוזרים למדריך הזה בלי להתקין שערים של תעבורת נכנסת או יוצאת.

התקנה של שער לתעבורת נתונים יוצאת

יוצרים מרחב שמות של Kubernetes לשער היציאה:
```
kubectl create namespace istio-egress
```
מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.
מנוהל (TD)
מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
kubectl label namespace istio-egress \ istio.io/rev- istio-injection=enabled --overwrite
מנוהל (Istiod)
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace istio-egress \ istio.io/rev- istio-injection=enabled --overwrite
אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:
1. מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
  
  kubectl -n istio-system get controlplanerevision
  
  הפלט אמור להיראות כך:
  
  NAME AGE asm-managed-rapid 6d7h
  הערה: אם מופיעות ברשימה שלמעלה שתי גרסאות של מישור הבקרה, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.
  
  בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.
2. החלת תווית הגרסה על מרחב השמות:
  
  kubectl label namespace istio-egress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
באשכול
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace istio-egress \ istio.io/rev- istio-injection=enabled --overwrite
מומלץ להשתמש בהחדרה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהחדרה שמבוססת על עדכון: פועלים לפי ההוראות הבאות:
1. משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod:
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. מחילים את תווית הגרסה על מרחב השמות. בפקודה הבאה, REVISION_LABEL הוא הערך של התווית istiod revision שרשמתם בשלב הקודם.
  
  kubectl label namespace istio-egress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite

יוצרים מניפסט של אופרטור לשער היציאה:

cat << EOF > egressgateway-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: egressgateway-operator
  annotations:
    config.kubernetes.io/local-config: "true"
spec:
  profile: empty
  revision: REVISION
  components:
    egressGateways:
    - name: istio-egressgateway
      namespace: istio-egress
      enabled: true
  values:
    gateways:
      istio-egressgateway:
        injectionTemplate: gateway
        tolerations:
          - key: "dedicated"
            operator: "Equal"
            value: "gateway"
        nodeSelector:
          cloud.google.com/gke-nodepool: "gateway"
EOF

מורידים את הכלי istioctl. צריך להשתמש בגרסה 1.16.2-asm.2 ואילך, גם אם אתם משתמשים ב-Cloud Service Mesh מגרסה 1.15 ומטה. הורדת הגרסה הנכונה של istioctl
אחרי שמחלצים את הארכיון שהורד, מגדירים משתנה סביבה שיכיל את הנתיב לכלי istioctl ומוסיפים אותו לסקריפט האתחול:
```
ISTIOCTL=$(find "$(pwd -P)" -name istioctl)
echo "ISTIOCTL=\"${ISTIOCTL}\"" >> ./init-egress-tutorial.sh
```
יוצרים את מניפסט ההתקנה של שער היציאה באמצעות מניפסט האופרטור ו-istioctl:
```
${ISTIOCTL} manifest generate \
    --filename egressgateway-operator.yaml \
    --output egressgateway \
    --cluster-specific
```
אפשר לראות את המניפסט שנוצר בנתיב egressgateway/Base/Pilot/EgressGateways/EgressGateways.yaml.

כשפורסים את התוסף, הוא יוצר משאבי Kubernetes רגילים כמו Deployment, ‏ Service, ‏ ServiceAccount, ‏ Role,‏ RoleBinding, ‏ HorizontalPodAutoscaler ו-PodDisruptionBudget. שימוש ב-istioctl ובמניפסט של האופרטור הוא דרך נוחה ליצור את מניפסט הפריסה. כדי ליצור ולנהל את מניפסט הפריסה של רשת הייצור שלכם, אתם יכולים להשתמש בכלים המועדפים עליכם.

מתקינים את שער היציאה:

kubectl apply --recursive --filename egressgateway/

בודקים ששער היציאה פועל בצמתים ב-node pool‏ gateway:
```
kubectl get pods -n istio-egress -o wide
```

לפודים של שער היציאה יש affinity לצמתים במאגר הצמתים gateway וסבילות שמאפשרת להם לפעול בצמתי השער המזוהמים. בודקים את הזיקה של הצומת ואת ההרשאות של ה-Pods של שער היציאה:

kubectl -n istio-egress get pod -l istio=egressgateway \
    -o=custom-columns='name:metadata.name,node-affinity:spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms,tolerations:spec.tolerations[?(@.key=="dedicated")]'

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

name                                   node-affinity                                                                                   tolerations
istio-egressgateway-754d9684d5-jjkdz   [map[matchExpressions:[map[key:cloud.google.com/gke-nodepool operator:In values:[gateway]]]]]   map[key:dedicated operator:Equal value:gateway]

זהירות

מניפסט האופרטור של שער תעבורת הנתונים היוצאת מציין טולרנטיות ו-nodeSelector, כך שהשער שנפרס יפעל רק בצמתי שער.

חשוב לוודא שרק מנהלי רשת יכולים להחיל את הטולרנטיות של השער על קבוצות Pod. שימוש לא מורשה בטולרנטיות של שער מאפשר לפודים שנפרסו להתחזות לשער ולפעול בצמתי שער. ‫Pods שפועלים בצמתי שער יכולים להתחבר ישירות למארחים חיצוניים. הגבלת השימוש ב-gateway toleration כחלק מצינורות עיבוד נתונים לפריסה או באמצעות בקרת כניסה ב-Kubernetes. בשני התרחישים האלה אפשר להשתמש באילוץ של GKE Enterprise Policy Controller.

הפעלת רישום ביומן של גישת Envoy

השלבים שנדרשים להפעלת יומני הגישה של Envoy תלויים בסוג Cloud Service Mesh, כלומר מנוהל או בתוך האשכול:

מנוהל

פועלים לפי ההוראות כדי להפעיל יומני גישה ב-Cloud Service Mesh מנוהל.

באשכול

פועלים לפי ההוראות כדי להפעיל יומני גישה ב-Cloud Service Mesh בתוך האשכול.

הכנת הרשת והאפליקציה לבדיקה

מוודאים שפרוטוקול TLS הדדי מחמיר מופעל. החלת מדיניות ברירת מחדל PeerAuthentication על הרשת במרחב השמות istio-system:
```
cat <<EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF
```
אפשר לבטל את ההגדרה הזו על ידי יצירת משאבי PeerAuthentication במרחבי שמות ספציפיים.
יוצרים מרחבי שמות לשימוש בפריסת עומסי עבודה לבדיקה. בשלבים הבאים במדריך הזה מוסבר איך להגדיר כללי ניתוב שונים של תעבורת נתונים יוצאת (egress) לכל מרחב שמות.
```
kubectl create namespace team-x
kubectl create namespace team-y
```
מתייגים את מרחבי השמות כדי שניתן יהיה לבחור אותם באמצעות כללי מדיניות של רשת Kubernetes:
```
kubectl label namespace team-x team=x
kubectl label namespace team-y team=y
```
כדי ש-Cloud Service Mesh יזריק באופן אוטומטי sidecars של proxy, צריך להגדיר את התווית של עדכון מישור הבקרה במרחבי השמות של עומס העבודה:
```
kubectl label ns team-x istio.io/rev- istio-injection=enabled --overwrite
kubectl label ns team-y istio.io/rev- istio-injection=enabled --overwrite
```

יוצרים קובץ YAML לשימוש בפריסות בדיקה:

cat << 'EOF' > ./test.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test
---
apiVersion: v1
kind: Service
metadata:
  name: test
  labels:
    app: test
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      serviceAccountName: test
      containers:
      - name: test
        image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
        command: ["/bin/sleep", "infinity"]
        imagePullPolicy: IfNotPresent
EOF

פורסים את אפליקציית הבדיקה במרחב השמות team-x:
```
kubectl -n team-x create -f ./test.yaml
```
מוודאים שאפליקציית הבדיקה נפרסה לצומת במאגר ברירת המחדל ושקונטיינר proxy sidecar מוזרק. חוזרים על הפקודה הבאה עד שהסטטוס של ה-Pod הוא Running:
```
kubectl -n team-x get po -l app=test -o wide
```
הפלט אמור להיראות כך:
```
NAME                   READY   STATUS    RESTARTS   AGE   IP          NODE                                      NOMINATED NODE   READINESS GATES
test-d5bdf6f4f-9nxfv   2/2     Running   0          19h   10.1.1.25   gke-cluster1-default-pool-f6c7a51f-wbzj
```
‫2 מתוך 2 מאגרים בסטטוס Running. מאגר תגים אחד הוא אפליקציית הבדיקה והשני הוא proxy sidecar.

ה-Pod פועל בצומת במאגר הצמתים שמוגדר כברירת מחדל.
מוודאים שאי אפשר לשלוח בקשת HTTP ממסגרת הבדיקה לאתר חיצוני:
```
kubectl -n team-x exec -it \
    $(kubectl -n team-x get pod -l app=test -o jsonpath={.items..metadata.name}) \
    -c test -- curl -v http://example.com
```
הודעת שגיאה משרת ה-Proxy מסוג קובץ עזר חיצוני נוצרת כי כלל חומת האש global-deny-egress-all דוחה את החיבור במעלה הזרם.

שימוש במשאב Sidecar כדי להגביל את ההיקף של הגדרת שרת proxy מסוג Sidecar

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

שרת ה-proxy שמופעל ב-Cloud Service Mesh ב-sidecar הוא Envoy. בטרמינולוגיה של Envoy,‏ cluster היא קבוצה דומה מבחינה לוגית של נקודות קצה במעלה הזרם שמשמשות כיעדים לאיזון עומסים.

מריצים את הפקודה istioctl proxy-config כדי לבדוק את האשכולות היוצאים שהוגדרו ב-Envoy קובץ עזר חיצוני עבור ה-Pod של הבדיקה:
```
${ISTIOCTL} pc c $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}).team-x --direction outbound
```
יש ברשימה בערך 11 אשכולות של Envoy, כולל כמה לאשכולות של שער היציאה.
הגבלת הגדרת ה-proxy ליציאות שמוגדרות באופן מפורש באמצעות service entries במרחבי השמות של היציאות team-x. החלת Sidecar משאב על מרחב השמות team-x:
```
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: team-x
spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
  egress:
  - hosts:
    - 'istio-egress/*'
    - 'team-x/*'
EOF
```
הגדרת מצב המדיניות של תעבורה יוצאת ל-REGISTRY_ONLY מגבילה את הגדרת ה-proxy כך שתכלול רק את המארחים החיצוניים שהוספו באופן מפורש למרשם השירותים של הרשת על ידי הגדרת רשומות שירות.

ההגדרה egress.hosts מציינת שקובץ העזר החיצוני בוחר רק מסלולים ממרחב השמות של תעבורת הנתונים היוצאת שזמינים באמצעות המאפיין exportTo. החלק team-x/* כולל את כל המסלולים שהוגדרו באופן מקומי במרחב השמות team-x.
אפשר לראות את האשכולות היוצאים שהוגדרו ב-Envoy קובץ עזר חיצוני ולהשוות אותם לרשימת האשכולות שהוגדרו לפני החלת המשאב Sidecar:
```
${ISTIOCTL} pc c $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}).team-x --direction outbound
```
אפשר לראות אשכולות עבור שער היציאה ואשכול אחד עבור ה-pod של הבדיקה עצמו.

הגדרת Cloud Service Mesh לניתוב תעבורה דרך שער היציאה

הגדרת Gateway לתנועת HTTP ביציאה 80. ‫Gateway בוחר את שרת ה-proxy של שער היציאה שפרסתם במרחב השמות של היציאה. ההגדרה Gateway חלה על מרחב השמות של היציאה (egress) ומטפלת בתעבורה של כל מארח.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gateway
  namespace: istio-egress
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 80
      name: https
      protocol: HTTPS
    hosts:
      - '*'
    tls:
      mode: ISTIO_MUTUAL
EOF

יוצרים DestinationRule לשער היציאה עם TLS בו-זמני (mTLS) לאימות ולהצפנה. משתמשים בכלל יעד משותף יחיד לכל המארחים החיצוניים.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: target-egress-gateway
  namespace: istio-egress
spec:
  host: istio-egressgateway.istio-egress.svc.cluster.local
  subsets:
  - name: target-egress-gateway-mTLS
    trafficPolicy:
      tls:
        mode: ISTIO_MUTUAL
EOF

יוצרים ServiceEntry במרחב השמות של תעבורת נתונים יוצאת (egress) כדי לרשום באופן מפורש את example.com במרשם השירותים של הרשת עבור מרחב השמות team-x:
```
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: example-com-ext
  namespace: istio-egress
  labels:
    # Show this service and its telemetry in the Cloud Service Mesh page of the Google Cloud console
    service.istio.io/canonical-name: example.com
spec:
  hosts:
  - example.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'team-x'
  - 'istio-egress'
EOF
```
הגדרת ניתוב שונה של תעבורת נתונים יוצאת (egress) לכל מרחב שמות
המאפיין `exportTo` קובע אילו מרחבי שמות יכולים להשתמש ברשומת השירות. אדמינים של רשתות משתמשים ברשומות שירות כדי לשלוט באופן מרכזי בקבוצת המארחים החיצוניים שזמינים לכל מרחב שמות. מגדירים הרשאות RBAC ב-Kubernetes כך שרק אדמינים של הרשת יוכלו ליצור ולשנות ישירות רשומות שירות. כדאי ליצור אוטומציה עם תהליך עבודה לאישור, כדי שמפתחי אפליקציות יוכלו לבקש גישה למארחים חיצוניים חדשים.

יוצרים VirtualService כדי להפנות תנועה אל example.com דרך שער היציאה. יש שני תנאי התאמה: התנאי הראשון מפנה את התנועה לשער היציאה, והתנאי השני מפנה את התנועה משער היציאה למארח היעד. המאפיין exportTo קובע אילו מרחבי שמות יכולים להשתמש בשירות הווירטואלי.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - example.com
  gateways:
  - istio-egress/egress-gateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: example.com
        port:
          number: 80
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

מריצים את הפקודה istioctl analyze כדי לבדוק אם יש שגיאות בהגדרות:
```
${ISTIOCTL} analyze -n istio-egress --revision REVISION
```
הפלט אמור להיראות כך:
```
✔ No validation issues found when analyzing namespace: istio-egress.
```

שולחים כמה בקשות דרך שער היציאה לאתר החיצוני:

for i in {1..4}
do
    kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
        -o jsonpath={.items..metadata.name}) -c test -- \
    curl -s -o /dev/null -w "%{http_code}\n" http://example.com
done

מוצגים קודי הסטטוס 200 לכל ארבע התגובות.

כדי לוודא שהבקשות הופנו דרך שער היציאה, בודקים את יומני הגישה של ה-proxy. קודם כל, בודקים את יומן הגישה של ה-proxy sidecar שנפרס עם אפליקציית הבדיקה:

kubectl -n team-x logs -f $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) istio-proxy

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

[2020-09-14T17:37:08.045Z] "HEAD / HTTP/1.1" 200 - "-" "-" 0 0 5 4 "-" "curl/7.67.0" "d57ea5ad-90e9-46d9-8b55-8e6e404a8f9b" "example.com" "10.1.4.12:8080" outbound|80||istio-egressgateway.istio-egress.svc.cluster.local 10.1.0.17:42140 93.184.216.34:80 10.1.0.17:60326 - -

כדאי גם לבדוק את יומן הגישה של שער היציאה:

kubectl -n istio-egress logs -f $(kubectl -n istio-egress get pod -l istio=egressgateway \
    -o jsonpath="{.items[0].metadata.name}") istio-proxy

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

[2020-09-14T17:37:08.045Z] "HEAD / HTTP/2" 200 - "-" "-" 0 0 4 3 "10.1.0.17" "curl/7.67.0" "095711e6-64ef-4de0-983e-59158e3c55e7" "example.com" "93.184.216.34:80" outbound|80||example.com 10.1.4.12:37636 10.1.4.12:8080 10.1.0.17:44404 outbound_.80_.target-egress-gateway-mTLS_.istio-egressgateway.istio-egress.svc.cluster.local -

הגדרת ניתוב שונה למרחב שמות שני

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

יוצרים משאב Sidecar למרחב השמות team-y:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: team-y
spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
  egress:
  - hosts:
    - 'istio-egress/*'
    - 'team-y/*'
EOF

פורסים את אפליקציית הבדיקה במרחב השמות team-y:
```
kubectl -n team-y create -f ./test.yaml
```

רושמים מארח חיצוני שני ומייצאים אותו למרחב השמות team-x ולמרחב השמות team-y:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: httpbin-org-ext
  namespace: istio-egress
  labels:
    # Show this service and its telemetry in the Cloud Service Mesh page of the Google Cloud console
    service.istio.io/canonical-name: httpbin.org
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'istio-egress'
  - 'team-x'
  - 'team-y'
EOF

יוצרים שירות וירטואלי לניתוב תנועה אל httpbin.org דרך שער היציאה:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-org-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  gateways:
  - istio-egress/egress-gateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: httpbin.org
        port:
          number: 80
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
  - 'team-y'
EOF

מריצים את הפקודה istioctl analyze כדי לבדוק אם יש שגיאות בהגדרות:
```
${ISTIOCTL} analyze -n istio-egress --revision REVISION
```
הפרטים שמוצגים הם:
```
✔ No validation issues found when analyzing namespace: istio-egress.
```

שליחת בקשה אל httpbin.org מאפליקציית הבדיקה team-y:

kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test -o \
    jsonpath={.items..metadata.name}) -c test -- curl -I http://httpbin.org

מוצגת 200 OK תשובה.

בנוסף, שולחים בקשה אל httpbin.org מאפליקציית הבדיקה team-x:

kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://httpbin.org

מוצגת 200 OK תשובה.

ניסיון לשלוח בקשה אל example.com ממרחב השמות team-y:
```
kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
```
הבקשה נכשלת כי לא מוגדר מסלול ליציאה עבור המארח example.com.

שימוש במדיניות הרשאות כדי לספק שליטה נוספת בתנועה

במדריך הזה, מדיניות ההרשאות לשער היציאה נוצרת במרחב השמות istio-egress. אפשר להגדיר את Kubernetes RBAC כך שרק לאדמינים של הרשת תהיה גישה למרחב השמות istio-egress.

יוצרים AuthorizationPolicy כדי שאפליקציות במרחב השמות team-x יוכלו להתחבר ל-example.com אבל לא למארחים חיצוניים אחרים כששולחים בקשות באמצעות יציאה 80. היציאה התואמת targetPort בתרמילי שער היציאה היא 8080.

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: egress-team-x-to-example-com
  namespace: istio-egress
spec:
  action: ALLOW
  rules:
    - from:
      - source:
          namespaces:
          - 'team-x'
      to:
      - operation:
          hosts:
            - 'example.com'
      when:
      - key: destination.port
        values: ["8080"]
EOF

מוודאים שאפשר לשלוח בקשה אל example.com מאפליקציית הבדיקה במרחב השמות team-x:

kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com

מוצגת 200 OK תשובה.

מנסים לשלוח בקשה אל httpbin.org מאפליקציית הבדיקה במרחב השמות team-x:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -s -w " %{http_code}\n" \
    http://httpbin.org
```
הבקשה נכשלת עם ההודעה RBAC: access denied וקוד הסטטוס 403 Forbidden. יכול להיות שתצטרכו לחכות כמה שניות כי לרוב יש עיכוב קצר לפני שמדיניות ההרשאה נכנסת לתוקף.

מדיניות ההרשאות מספקת שליטה מקיפה בתנועה שמותרת או אסורה. מחילים את מדיניות ההרשאות הבאה כדי לאפשר לאפליקציית הבדיקה במרחב השמות team-y לשלוח בקשות אל httpbin.org באמצעות נתיב כתובת ה-URL מסוים אחד כששולחים בקשות באמצעות יציאה 80. היציאה targetPort המתאימה בתרמילי שער היציאה היא 8080.

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: egress-team-y-to-httpbin-teapot
  namespace: istio-egress
spec:
  action: ALLOW
  rules:
    - from:
      - source:
          namespaces:
          - 'team-y'
      to:
      - operation:
          hosts:
          - httpbin.org
          paths: ['/status/418']
      when:
      - key: destination.port
        values: ["8080"]
EOF

מנסים להתחבר אל httpbin.org מאפליקציית הבדיקה במרחב השמות team-y:

kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -s -w " %{http_code}\n" \
    http://httpbin.org

הבקשה נכשלת עם ההודעה RBAC: access denied וקוד הסטטוס 403 Forbidden.

עכשיו שולחים בקשה אל httpbin.org/status/418 מאותה אפליקציה:

kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl http://httpbin.org/status/418

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

   -=[ teapot ]=-
      _...._
    .'  _ _ `.
   | ."` ^ `". _,
   \_;`"---"`|//
     |       ;/
     \_     _/
       `"""`

התחלת TLS בשער היציאה

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

התחלת TLS בשער יציאה

‫Create a DestinationRule. The DestinationRule מציין ששער יצור חיבור TLS אל example.com.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: example-com-originate-tls
  namespace: istio-egress
spec:
  host: example.com
  subsets:
    - name: example-com-originate-TLS
      trafficPolicy:
        portLevelSettings:
        - port:
            number: 443
          tls:
            mode: SIMPLE
            sni: example.com
EOF

מעדכנים את השירות הווירטואלי עבור example.com כך שהבקשות ליציאה 80 בשער יהיו upgraded ל-TLS ביציאה 443 כשהן נשלחות למארח היעד:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - example.com
  gateways:
  - mesh
  - istio-egress/egress-gateway
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: example.com
        port:
          number: 443
        subset: example-com-originate-TLS
      weight: 100
EOF

שליחת כמה בקשות אל example.com מאפליקציית הבדיקה במרחב השמות team-x:

for i in {1..4}
do
    kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
        -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
done

כמו קודם, הבקשות מצליחות עם תגובות 200 OK.

בודקים את היומן של שער היציאה כדי לוודא שהשער ניתב את הבקשות למארח היעד על ידי יצירת חיבורי TLS:

kubectl -n istio-egress logs -f $(kubectl -n istio-egress get pod -l istio=egressgateway \
    -o jsonpath="    {.items[0].metadata.name}") istio-proxy

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

[2020-09-24T17:58:02.548Z] "HEAD / HTTP/2" 200 - "-" "-" 0 0 6 5 "10.1.1.15" "curl/7.67.0" "83a77acb-d994-424d-83da-dd8eac902dc8" "example.com" "93.184.216.34:443" outbound|443|example-com-originate-TLS|example.com 10.1.4.31:49866 10.1.4.31:8080 10.1.1.15:37334 outbound_.80_.target-egress-gateway-mTLS_.istio-egressgateway.istio-egress.svc.cluster.local -

ה-sidecar של ה-proxy שלח את הבקשה לשער באמצעות יציאה 80, ו-TLS נוצר ביציאה 443 כדי לשלוח את הבקשה למארח היעד.

העברה של חיבורי HTTPS/TLS

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

זהירות: השער מתייחס לחיבור TLS מוצפן כחיבור TCP, ולא יכול לקרוא מאפיינים שקשורים ל-HTTP או מטא-נתונים חתומים ומהימנים. אי אפשר להשתמש במדיניות הרשאות כדי לאשר או לדחות תנועה שעוברת דרך המערכת על סמך מאפייני הבקשה. בשלבים הבאים של המדריך הזה יוצרים מדיניות הרשאה נוספת כדי לאפשר תנועה מכל סוג שנשלחת לשער היציאה ביציאה 443. התנועה הזו יכולה להיות לא מוצפנת, והמדיניות לא מגבילה חיבורים על סמך מקורות ויעדים ספציפיים בתוך הרשת או מחוצה לה. אם אתם צריכים להחיל מדיניות הרשאות, מומלץ להימנע מ-TLS pass-through.

tls pass through

משנים את ההגדרה כך ששער היציאה ישתמש ב-TLS pass-through לחיבורים ליציאה 443:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gateway
  namespace: istio-egress
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 80
      name: https
      protocol: HTTPS
    hosts:
      - '*'
    tls:
      mode: ISTIO_MUTUAL
  - port:
      number: 443
      name: tls
      protocol: TLS
    hosts:
    - '*'
    tls:
      mode: PASSTHROUGH
EOF

מעדכנים את DestinationRule שמצביע על שער היציאה כדי להוסיף קבוצת משנה שנייה ליציאה 443 בשער. קבוצת המשנה החדשה הזו לא משתמשת ב-TLS דו-כיווני. אין תמיכה ב-TLS הדדי של Istio להעברה של חיבורי TLS. החיבורים ביציאה 80 עדיין משתמשים ב-mTLS:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: target-egress-gateway
  namespace: istio-egress
spec:
  host: istio-egressgateway.istio-egress.svc.cluster.local
  subsets:
  - name: target-egress-gateway-mTLS
    trafficPolicy:
      portLevelSettings:
      - port:
          number: 80
        tls:
          mode: ISTIO_MUTUAL
  - name: target-egress-gateway-TLS-passthrough
EOF

מעדכנים את השירות הווירטואלי עבור example.com כך שתנועת TLS ביציאה 443 תעבור דרך השער:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - example.com
  gateways:
  - mesh
  - istio-egress/egress-gateway
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: example.com
        port:
          number: 443
        subset: example-com-originate-TLS
      weight: 100
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - example.com
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-TLS-passthrough
        port:
          number: 443
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 443
      sniHosts:
      - example.com
    route:
    - destination:
        host: example.com
        port:
          number: 443
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

מעדכנים את השירות הווירטואלי עבור httpbin.org כך שתנועת TLS ביציאה 443 תעבור דרך השער:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-org-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  gateways:
  - istio-egress/egress-gateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: httpbin.org
        port:
          number: 80
      weight: 100
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - httpbin.org
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-TLS-passthrough
        port:
          number: 443
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 443
      sniHosts:
      - httpbin.org
    route:
    - destination:
        host: httpbin.org
        port:
          number: 443
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
  - 'team-y'
EOF

מוסיפים מדיניות הרשאה שמקבלת כל סוג של תנועה שנשלחת ליציאה 443 של שירות שער היציאה. היציאה התואמת targetPort בתרמילי השער היא 8443.

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: egress-all-443
  namespace: istio-egress
spec:
  action: ALLOW
  rules:
    - when:
      - key: destination.port
        values: ["8443"]
EOF

מריצים את הפקודה istioctl analyze כדי לבדוק אם יש שגיאות בהגדרות:
```
${ISTIOCTL} analyze -n istio-egress --revision REVISION
```
הפרטים שמוצגים הם:
```
✔ No validation issues found when analyzing namespace: istio-egress.
```

שליחת בקשת HTTP רגילה אל example.com מאפליקציית הבדיקה במרחב השמות team-x:

kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com

הבקשה מצליחה עם תגובה 200 OK.

עכשיו שולחים כמה בקשות TLS ‏ (HTTPS) מאפליקציית הבדיקה במרחב השמות team-x:

for i in {1..4}
do
    kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
        -o jsonpath={.items..metadata.name}) -c test -- curl -s -o /dev/null \
        -w "%{http_code}\n" \
        https://example.com
done

אתם רואים 200 תשובות.

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

kubectl -n istio-egress logs -f $(kubectl -n istio-egress get pod -l istio=egressgateway \
    -o jsonpath="{.items[0].metadata.name}") istio-proxy

יופיעו רשומות ביומן שדומות לרשומות הבאות:

[2020-09-24T18:04:38.608Z] "- - -" 0 - "-" "-" 1363 5539 10 - "-" "-" "-" "-" "93.184.216.34:443" outbound|443||example.com 10.1.4.31:51098 10.1.4.31:8443 10.1.1.15:57030 example.com -

בקשת ה-HTTPS טופלה כטראפיק TCP ועברה דרך השער למארח היעד, ולכן אין מידע HTTP ביומן.

שימוש ב-Kubernetes NetworkPolicy כבקרה נוספת

יש הרבה תרחישים שבהם אפליקציה יכולה לעקוף פרוקסי מסוג sidecar. אתם יכולים להשתמש ב-Kubernetes NetworkPolicy כדי לציין בנוסף אילו חיבורים עומסי העבודה יכולים לבצע. אחרי שמחילים מדיניות רשת אחת, כל החיבורים שלא אושרו במפורש נדחים.

המדריך הזה מתייחס רק לחיבורים יוצאים ולבוררים של תעבורת נתונים יוצאת (egress) במדיניות רשת. אם אתם שולטים בתעבורת הכניסה באמצעות מדיניות רשת באשכולות שלכם, אתם צריכים ליצור מדיניות כניסה שתתאים למדיניות היציאה שלכם. לדוגמה, אם מאפשרים יציאה מעומסי עבודה במרחב השמות team-x אל מרחב השמות team-y, צריך גם לאפשר כניסה למרחב השמות team-y ממרחב השמות team-x.

לאפשר לעומסי עבודה ולשרתי proxy שנפרסו במרחב השמות team-x להתחבר אל istiod ואל שער היציאה:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-control-plane
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          "kubernetes.io/metadata.name": istio-system
      podSelector:
        matchLabels:
          istio: istiod
    - namespaceSelector:
        matchLabels:
          "kubernetes.io/metadata.name": istio-egress
      podSelector:
        matchLabels:
          istio: egressgateway
EOF

מתן הרשאה לעומסי עבודה ולשרתי proxy לשאילתות DNS:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-dns
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          "kubernetes.io/metadata.name": kube-system
    ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
EOF

מתן אפשרות לעומסי עבודה ולשרתי proxy להתחבר לכתובות ה-IP שמשרתות את ממשקי ה-API והשירותים של Google, כולל רשות האישורים של Cloud Service Mesh:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-google-apis
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 199.36.153.4/30
    - ipBlock:
        cidr: 199.36.153.8/30
EOF

מתן הרשאה לעומסי עבודה ולשרתי proxy להתחבר לשרת המטא-נתונים של GKE:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-metadata-server
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to: # For GKE data plane v2
    - ipBlock:
        cidr: 169.254.169.254/32
  - to: # For GKE data plane v1
    - ipBlock:
        cidr: 127.0.0.1/32 # Prior to 1.21.0-gke.1000
    - ipBlock:
        cidr: 169.254.169.252/32 # 1.21.0-gke.1000 and later
    ports:
    - protocol: TCP
      port: 987
    - protocol: TCP
      port: 988
EOF

אופציונלי: מאפשרים לעומסי עבודה ולשרתי proxy במרחב השמות team-x ליצור חיבורים ביניהם:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-same-namespace
  namespace: team-x
spec:
  podSelector: {}
  ingress:
    - from:
      - podSelector: {}
  egress:
    - to:
      - podSelector: {}
EOF

אופציונלי: מאפשרים לעומסי עבודה ולשרתי proxy במרחב השמות team-x ליצור חיבורים לעומסי עבודה שנפרסו על ידי צוות אחר:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-team-y
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          "kubernetes.io/metadata.name": team-y
EOF

החיבורים בין שרתי proxy מסוג sidecar נשמרים. חיבורים קיימים לא נסגרים כשמחילים מדיניות רשת חדשה. מפעילים מחדש את עומסי העבודה במרחב השמות team-x כדי לוודא שהחיבורים הקיימים נסגרו:
```
kubectl -n team-x rollout restart deployment
```
מוודאים שאפשר עדיין לשלוח בקשת HTTP אל example.com מאפליקציית הבדיקה במרחב השמות team-x:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
```
הבקשה מצליחה עם תגובה 200 OK.

גישה ישירה לממשקי Google API באמצעות גישה פרטית ל-Google והרשאות IAM

ממשקי ה-API והשירותים של Google נחשפים באמצעות כתובות IP חיצוניות. כשפודים עם כתובות IP של כינוי מקומיות ל-VPC יוצרים חיבורים לממשקי Google API באמצעות גישה פרטית ל-Google, התנועה אף פעם לא יוצאת מהרשת של Google.

כשמגדירים את התשתית במדריך הזה, מפעילים את הגישה הפרטית ל-Google עבור רשת המשנה שמשמשת את ה-Pods של GKE. כדי לאפשר גישה לכתובות ה-IP שמשמשות את Private Google Access, יצרתם נתיב, כלל של חומת אש ב-VPC ואזור DNS פרטי. ההגדרה הזו מאפשרת ל-pods להגיע ישירות לממשקי ה-API של Google בלי לשלוח תנועה דרך שער היציאה. אתם יכולים לשלוט באילו ממשקי API זמינים לחשבונות שירות ספציפיים של Kubernetes (ומכאן גם למרחבי שמות) באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE ו-IAM. הרשאות ב-Istio לא נכנסות לתוקף כי שער היציאה לא מטפל בחיבורים לממשקי ה-API של Google.

כדי ש-Pods יוכלו לקרוא לממשקי Google API, צריך להשתמש ב-IAM כדי להעניק הרשאות. האשכול שבו משתמשים במדריך הזה מוגדר לשימוש ב-איחוד זהויות של עומסי עבודה ל-GKE, שמאפשר לחשבון שירות של Kubernetes לפעול כחשבון שירות של Google.

יוצרים חשבון שירות של Google לשימוש באפליקציה:
```
gcloud iam service-accounts create sa-test-app-team-x
```

מתן אפשרות לחשבון השירות של Kubernetes להתחזות לחשבון השירות של Google:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[team-x/test]" \
  sa-test-app-team-x@${PROJECT_ID}.iam.gserviceaccount.com

מוסיפים הערה לחשבון השירות של Kubernetes עבור אפליקציית הבדיקה במרחב השמות team-x עם כתובת האימייל של חשבון השירות של Google:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: sa-test-app-team-x@${PROJECT_ID}.iam.gserviceaccount.com
  name: test
  namespace: team-x
EOF

לפוד של אפליקציית הבדיקה צריכה להיות גישה לשרת המטא-נתונים של Google (שפועל כ-DaemonSet) כדי לקבל פרטי כניסה זמניים לקריאה ל-Google APIs. יוצרים רשומת שירות לשרת המטא-נתונים של GKE:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: metadata-google-internal
  namespace: istio-egress
  labels:
    # Show this service and its telemetry in the Cloud Service Mesh page of the Google Cloud console
    service.istio.io/canonical-name: metadata.google.internal
spec:
  hosts:
  - metadata.google.internal
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

צריך גם ליצור רשומה של שירות עבור private.googleapis.com ו-storage.googleapis.com:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: private-googleapis-com
  namespace: istio-egress
  labels:
    # Show this service and its telemetry in the Cloud Service Mesh page of the Google Cloud console
    service.istio.io/canonical-name: googleapis.com
spec:
  hosts:
  - private.googleapis.com
  - storage.googleapis.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

מוודאים שחשבון השירות של Kubernetes מוגדר בצורה נכונה לפעול כחשבון השירות של Google:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- gcloud auth list
```
חשבון השירות של Google מופיע כזהות הפעילה והיחידה.

יוצרים קובץ בדיקה בקטגוריה של Cloud Storage:

echo "Hello, World!" > /tmp/hello
gcloud storage buckets create gs://${PROJECT_ID}-bucket
gcloud storage cp /tmp/hello gs://${PROJECT_ID}-bucket/

מעניקים לחשבון השירות הרשאה להציג קבצים בדלי ולראות אותם:

gcloud storage buckets add-iam-policy-binding gs://${PROJECT_ID}-bucket/ \
    --member=serviceAccount:sa-test-app-team-x@${PROJECT_ID}.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer

מוודאים שלאפליקציית הבדיקה יש גישה לקטגוריית הבדיקה:

kubectl -n team-x exec -it \
$(kubectl -n team-x get pod -l app=test -o jsonpath={.items..metadata.name}) \
-c test \
-- gcloud storage cat gs://${PROJECT_ID}-bucket/hello

הפרטים שמוצגים הם:

Hello, World!

הסרת המשאבים

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

כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, צריך לבצע את השלבים שבקטעים הבאים:

מחיקת הפרויקט

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

זהירות: כשמוחקים פרויקט:

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

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

במסוף Google Cloud , נכנסים לדף Manage resources.
כניסה לדף Manage resources
ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

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

מומלץ לקרוא את מדריך השיטות המומלצות.
מומלץ לעיין במדריך לחיזוק האבטחה של GKE.
איך משתמשים ב-CA Service כדי להגדיר אוטומציה של ניהול אישורי TLS בשער הכניסה של Cloud Service Mesh
ניהול ההגדרות והמדיניות בכל התשתית באמצעות GKE Enterprise Configuration Management
לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.

שימוש בשערי יציאה (egress) של Cloud Service Mesh באשכולות GKE: הדרכה קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מטרות

עלויות

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

הגדרת התשתית

יצירת רשת VPC ורשת משנה

הגדרת Cloud NAT

יצירת חשבונות שירות לכל מאגר צמתים של GKE

מתן הרשאות לחשבונות השירות

יצירת הכללים של חומת האש

הגדרת גישה פרטית ל- Google Cloud APIs

הגדרת גישה פרטית ל-Container Registry

יצירת אשכול GKE פרטי

התקנה והגדרה של Cloud Service Mesh

התקנה של שער לתעבורת נתונים יוצאת

מנוהל (TD)

מנוהל (Istiod)

באשכול

הפעלת רישום ביומן של גישת Envoy

מנוהל

באשכול

הכנת הרשת והאפליקציה לבדיקה

שימוש במשאב Sidecar כדי להגביל את ההיקף של הגדרת שרת proxy מסוג Sidecar

הגדרת Cloud Service Mesh לניתוב תעבורה דרך שער היציאה

הגדרת ניתוב שונה למרחב שמות שני

שימוש במדיניות הרשאות כדי לספק שליטה נוספת בתנועה

התחלת TLS בשער היציאה

העברה של חיבורי HTTPS/TLS

שימוש ב-Kubernetes NetworkPolicy כבקרה נוספת

גישה ישירה לממשקי Google API באמצעות גישה פרטית ל-Google והרשאות IAM

הסרת המשאבים

מחיקת הפרויקט

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

שימוש בשערי יציאה (egress) של Cloud Service Mesh באשכולות GKE: הדרכה