הגדרת הרשאות גישה בתוך הצומת

טייס אוטומטי רגילה

במדריך הזה נסביר איך להגדיר הרשאות גישה בתוך הצומת באשכול של Google Kubernetes Engine ‏ (GKE).

התכונה "הרשאות גישה בתוך הצומת" מגדירה את הרשת בכל צומת באשכול, כך שתעבורת הנתונים שנשלחת מפוד אחד לפוד אחר מעובדת על ידי רשת הענן הווירטואלי הפרטי (VPC) של האשכול, גם אם הפודים נמצאים באותו צומת.

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

ארכיטקטורה

האפשרות 'חשיפה בתוך הצומת' עוזרת לוודא שמנות שנשלחות בין Pods מעובדות על ידי רשת ה-VPC. לאחר מכן, רשת ה-VPC מחילה על החבילות האלה כללי חומת אש, נתיבים, יומני תנועה והגדרות של רפליקציה של חבילות נתונים.

כש-Pod שולח מנה ל-Pod אחר באותו צומת, המנה יוצאת מהצומת ומעובדת על ידי רשת Google Cloud . לאחר מכן, החבילה נשלחת מיד בחזרה לאותו צומת ומועברת ל-Pod היעד.

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

• ב-GKE Dataplane V2 (גרסה 1.36.0-gke.3302000 או גרסה חדשה יותר של GKE): הניראות בתוך הצומת היא נייטיב של eBPF. הניתוב מחדש של תעבורת הנתונים מתבצע ב-eBPF, תוך עקיפת מקבץ הרשת (network stack) של המארח.
• בגרסאות קודמות של GKE או באשכולות שאינם GKE Dataplane V2: ה-DaemonSet של netd מנהל את ההפניה האוטומטית של החבילות בצומת.

יתרונות

היתרונות של חשיפה בתוך הצומת:

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

דרישות ומגבלות

הדרישות והמגבלות הבאות חלות על חשיפה בתוך הצומת:

• האשכול צריך להיות בגרסה 1.15 ומעלה של GKE.
• אין תמיכה בנראות בתוך הצומת במאגרי צמתים של Windows Server.
• באשכולות שמוגדרים עם מספר רשתות, החשיפה בתוך הצומת חלה רק על תעבורת הנתונים ברשת שמוגדרת כברירת מחדל.
• כדי למנוע בעיות קישוריות, כשמשתמשים ב-ip-masq-agent עם הגדרת visibility של intranode, רשימת nonMasqueradeCIDRs המותאמת אישית צריכה לכלול את טווחי כתובות ה-IP של הצומת וה-Pod של האשכול.

כללי חומת אש

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

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

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

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

• מפעילים את ממשק ה-API של Google Kubernetes Engine.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

הפעלת הרשאות גישה בתוך הצומת באשכול חדש

אפשר ליצור אשכול עם הפעלת ההגדרה 'חשיפה בתוך הצומת' באמצעות ה-CLI של gcloud או מסוף Google Cloud .

gcloud

כדי ליצור אשכול עם צומת יחיד שבו מופעלת חשיפה בתוך הצומת, משתמשים בדגל --enable-intra-node-visibility:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-intra-node-visibility

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

• ‫CLUSTER_NAME: השם של האשכול החדש.
• ‫CONTROL_PLANE_LOCATION: המיקום ב-Compute Engine של מישור הבקרה של האשכול. באשכולות אזוריים צריך לציין אזור, ובאשכולות של תחומים צריך לציין תחום.

המסוף

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

1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

   כניסה ל-Google Kubernetes Engine

2. לוחצים על Create.

3. מזינים את השם של האשכול.

4. בתיבת הדו-שיח Configure cluster, לוחצים על Configure ליד GKE Standard.

5. מגדירים את האשכול לפי הצורך.

6. בחלונית הניווט, בקטע Cluster, לוחצים על Networking.

7. מסמנים את תיבת הסימון הפעלת חשיפה בתוך הצומת.

8. לוחצים על יצירה.

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

אפשר להפעיל את ההגדרה 'חשיפה בתוך הצומת' באשכול קיים באמצעות ה-CLI של gcloud או מסוף Google Cloud .

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

gcloud

כדי להפעיל את ההגדרה 'חשיפה בתוך הצומת' באשכול קיים, משתמשים בדגל --enable-intra-node-visibility:

gcloud container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

מחליפים את CLUSTER_NAME בשם האשכול.

המסוף

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

1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

   מעבר אל Google Kubernetes Engine

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

3. בקטע Networking, לוחצים על Edit intranode visibility (עריכת רמת החשיפה של צמתים פנימיים).

4. מסמנים את התיבה Enable intranode visibility.

5. לוחצים על שמירת השינויים.

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

חשוב: מערכת GKE פועלת בהתאם למדיניות התחזוקה כשיוצרת מחדש את הצמתים לשינוי הזה באמצעות אסטרטגיית שדרוג הצמתים, והיא תלויה בזמינות המשאבים. השבתת השדרוגים האוטומטיים של הצמתים לא מונעת את השינוי הזה. כדי להחיל את השינויים בצמתים באופן ידני, משתמשים ב-CLI של gcloud כדי לקרוא לפקודה gcloud container clusters upgrade, ומעבירים את הדגל --cluster-version עם אותה גרסת GKE שמאגר הצמתים כבר מריץ.

השבתת הניראות בתוך הצומת

אפשר להשבית את ההגדרה 'חשיפה בתוך הצומת' באשכול באמצעות ה-CLI של gcloud או מסוף Google Cloud .

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

gcloud

כדי להשבית את החשיפה בתוך הצומת, משתמשים בדגל --no-enable-intra-node-visibility:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

מחליפים את CLUSTER_NAME בשם של האשכול.

המסוף

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

1. נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

   מעבר אל Google Kubernetes Engine

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

3. בקטע Networking, לוחצים על Edit intranode visibility.

4. מבטלים את הסימון בתיבה Enable intranode visibility (הפעלת חשיפה בתוך הצומת).

5. לוחצים על שמירת השינויים.

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

חשוב: כשיוצרים מחדש את הצמתים לשינוי הזה באמצעות אסטרטגיית שדרוג הצמתים, GKE פועל בהתאם למדיניות התחזוקה, וזה תלוי בזמינות המשאבים. השבתה של שדרוגים אוטומטיים של צמתים לא מונעת את השינוי הזה. כדי להחיל את השינויים בצמתים באופן ידני, משתמשים ב-CLI של gcloud כדי לקרוא לפקודה gcloud container clusters upgrade, ומעבירים את הדגל --cluster-version עם אותה גרסת GKE שמאגר הצמתים כבר מריץ.

תרגול: אימות החשיפה בתוך הצומת

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

בשיעור הזה תבצעו את השלבים הבאים:

1. הפעלת יומני תנועה ברשת המשנה שמוגדרת כברירת מחדל באזור us-central1.
2. יוצרים אשכול עם צומת יחיד שבו מופעלת הרשאות הגישה בתוך הצומת באזור us-central1-a.
3. יוצרים שני Pods באשכול.
4. שליחת בקשת HTTP מ-Pod אחד ל-Pod אחר.
5. צפייה ברשומה ביומן תנועת הנתונים של הבקשה בין Pod ל-Pod.

הפעלת יומני זרימה

1. הפעלת יומני זרימה עבור רשת המשנה שמוגדרת כברירת מחדל:

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. מוודאים שיומני תנועה מופעלים ברשת המשנה שמוגדרת כברירת מחדל:

   gcloud compute networks subnets describe default \
       --region=us-central1
   

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

   ...
   enableFlowLogs: true
   ...
   

יצירת אשכול

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

   gcloud container clusters create flow-log-test \
       --location=us-central1-a \
       --num-nodes=1 \
       --enable-intra-node-visibility
   

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

   gcloud container clusters get-credentials flow-log-test \
       --location=us-central1-a
   

ליצור שני Pod

1. יוצרים פוד.

   שומרים את קובץ המניפסט הבא בשם pod-1.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: google/cloud-sdk:slim
       command:
       - sh
       - -c
       - while true; do sleep 30; done
   

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

   kubectl apply -f pod-1.yaml
   

3. יוצרים Pod שני.

   שומרים את קובץ המניפסט הבא בשם pod-2.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

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

   kubectl apply -f pod-2.yaml
   

5. מציגים את הפודים:

   kubectl get pod pod-1 pod-2 --output wide
   

   הפלט יציג את כתובות ה-IP של ה-Pods, כמו בדוגמה הבאה:

   NAME      READY     STATUS    RESTARTS   AGE       IP           ...
   pod-1     1/1       Running   0          1d        10.52.0.13   ...
   pod-2     1/1       Running   0          1d        10.52.0.14   ...
   

   שימו לב לכתובות ה-IP של pod-1 ו-pod-2.

שליחת בקשה

1. פותחים מעטפת לקונטיינר ב-pod-1:

   kubectl exec -it pod-1 -- sh
   

2. במעטפת, שולחים בקשה אל pod-2:

   curl -s POD_2_IP_ADDRESS:8080
   

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

   הפלט מציג את התשובה מהקונטיינר שפועל ב-pod-2.

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. מקלידים exit כדי לצאת מהמעטפת ולחזור לסביבת שורת הפקודה הראשית.

צפייה ברשומות ביומן של זרימת נתונים

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

gcloud logging read \
    'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'

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

• PROJECT_ID: מזהה הפרויקט.
• ‫POD_1_IP_ADDRESS: כתובת ה-IP של pod-1.
• ‫POD_2_IP_ADDRESS: כתובת ה-IP של pod-2.

הפלט מציג רשומה ביומן של תעבורת נתונים לבקשה מ-pod-1 אל pod-2. בדוגמה הזו, ל-pod-1 יש כתובת IP‏ 10.56.0.13, ול-pod-2 יש כתובת IP‏ 10.56.0.14.

...
jsonPayload:
  bytes_sent: '0'
  connection:
    dest_ip: 10.56.0.14
    dest_port: 8080
    protocol: 6
    src_ip: 10.56.0.13
    src_port: 35414
...

הסרת המשאבים

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

1. מחיקת האשכול:

   gcloud container clusters delete -q flow-log-test
   

2. משביתים את יומני התנועה ברשת של רשת המשנה שמוגדרת כברירת מחדל:

   gcloud compute networks subnets update default --no-enable-flow-logs
   

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

• כך יוצרים מדיניות רשת באשכול כדי לשלוט בתקשורת בין ה-Pods והשירותים באשכול.
• מידע נוסף על היתרונות של אשכולות מקוריים של VPC