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

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

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

כברירת מחדל, הרשאות הגישה בתוך הצומת מושבתות באשכולות רגילים ומופעלות באשכולות 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.
  • באשכולות שמוגדרים עם רשתות מרובות, החשיפה בתוך הצומת חלה רק על תנועה ברשת שמוגדרת כברירת מחדל.
  • באשכולות רגילים, מנות בין Pods באותו צומת יוצאות וחוזרות לאותו צומת. אם הסתרת ה-IP משכתבת את כתובת ה-IP של המקור לכתובת ה-IP של הצומת, סינון נתיב הפוך (RPF) בצומת GKE יכול להשמיט את החבילה שחוזרת. כדי למנוע את הירידות האלה, הוסיפו את טווחי כתובות ה-IP של ה-Pod והצומת של האשכול לרשימה nonMasqueradeCIDRs ב-ConfigMap של ip-masq-agent.

כללי חומת אש

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

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

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

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

  • מפעילים את Google Kubernetes Engine API.
  • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי להוריד את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא תומכות בהרצת הפקודות שבמסמך הזה.

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

אפשר ליצור אשכול עם הרשאות גישה בתוך הצומת באמצעות ה-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. מזינים את השם (Name) של האשכול.

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

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

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

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

  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. לוחצים על שמירת השינויים.

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

השבתת החשיפה בתוך הצומת

אפשר להשבית את החשיפה בתוך הצומת באשכול באמצעות ה-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. לוחצים על שמירת השינויים.

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

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

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

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

  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
    

יצירת שני Pods

  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. הצגת ה-Pods:

    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
    

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