דרישות רשת

כדי להתקין ולהפעיל את תוכנת Google Distributed Cloud ל-bare metal בלבד, הרשת צריכה לעמוד בדרישות שמפורטות במסמך הזה. הדרישות האלה כוללות קישוריות חיצונית ל-Google, קישוריות של שכבה 2 ושכבה 3 בין צומתי אשכולות ומאזני עומסים, טווחי כתובות IP לפודים ולשירותים, והיציאות שבהן משתמשים רכיבי האשכול. אם הצמתים מריצים את Red Hat Enterprise Linux‏ (RHEL) עם firewalld, המסמך הזה גם מראה איך לפתוח את היציאות הנדרשות.

דרישות רשת חיצוניות

כדי להפעיל את Google Distributed Cloud נדרש חיבור לאינטרנט. ‫Google Distributed Cloud מאחזר את רכיבי האשכול מ-Artifact Registry, והאשכול רשום באמצעות Connect Agent.

אתם יכולים להתחבר ל-Google באמצעות האינטרנט הציבורי דרך HTTPS, רשת וירטואלית פרטית (VPN) או חיבור Dedicated Interconnect.

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

דרישות רשת פנימיות

‫Google Distributed Cloud יכול לפעול עם קישוריות של שכבה 2 או שכבה 3 בין צומתי אשכול. הצמתים של מאזן העומסים יכולים להיות צמתים של מישור הבקרה או קבוצה ייעודית של צמתים. מידע נוסף זמין במאמר בחירה והגדרה של מאזני עומסים.

כשמשתמשים באיזון עומסים בשכבה 2 עם MetalLB (spec.loadBalancer.mode: bundled ו-spec.loadBalancer.type: layer2), צומתי מאזן העומסים צריכים להיות סמוכים לשכבה 2. הדרישה לשכנות בשכבה 2 חלה גם אם מריצים את מאזן העומסים בצומתי מישור הבקרה וגם אם מריצים אותו בקבוצה ייעודית של צומתי איזון עומסים. איזון עומסים מקובץ עם BGP תומך בפרוטוקול שכבה 3, כך שלא נדרשת סמיכות קפדנית של שכבה 2.

אלה הדרישות למכונות של מאזן העומסים:

  • באיזון עומסים של Bundled Layer 2, כל מאזני העומסים של אשכול נתון נמצאים באותו דומיין של שכבה 2. גם צומתי מישור הבקרה צריכים להיות באותו דומיין של שכבה 2.
  • באיזון עומסים מקובץ בשכבה 2, כל כתובות ה-IP הווירטואליות (VIP) צריכות להיות ברשת המשנה של מכונת איזון העומסים, וניתנות לניתוב לשער של רשת המשנה.
  • המשתמשים אחראים לאפשר תעבורת נתונים נכנסת של מאזן העומסים.

רשתות של Pods ו-Services

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

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

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

טווחי כתובות IP לפודים ולשירותים

מציינים טווח של כתובות IP כבלוק Classless Inter-Domain Routing‏ (CIDR) לשימוש של Pods, ובלוק CIDR אחר לשימוש של כתובות ClusterIP של שירותי Kubernetes. משתמשים בכתובות IP במרחב הכתובות הפרטי, כפי שמתואר ב-RFC 1918. קובץ התצורה של האשכול מכיל ערכים שממולאים מראש, שנמצאים בטווח המגבלות שמתוארות בטבלה הבאה:

הגבלה קבוצת Pod שירותים
טווח מינימלי ערך מסכה של /18 (16,384 כתובות) ערך מסכה של /24 (256 כתובות)
טווח שמולא מראש ערך מסכה של /16 (65,536 כתובות) ערך מסכה של /20 (4,096 כתובות)
טווח מקסימלי ערך מסכה של /8 (16,777,216 כתובות) ערך מסכה של /12 (1,048,576 כתובות)

כדי למנוע חפיפה עם כתובות IP שאפשר להגיע אליהן ברשת, יכול להיות שתצטרכו להשתמש בטווחי CIDR שונים מהערכים שמולאו מראש. באופן ספציפי, טווחי השירותים וה-Pods לא יכולים לחפוף לטווחים הבאים:

  • כתובות IP של צמתים בכל אשכול

  • כתובות VIP שמשמשות את הצמתים של מישור הבקרה ומאזני העומסים

  • כתובות IP של שרתי DNS או שרתי NTP

בדיקות מקדימות חוסמות את היצירה והשדרוג של אשכולות אם מזוהות כתובות IP חופפות.

אחרי שיוצרים אשכול, אפשר להגדיל את טווח הרשת של השירות (clusterNetwork.services.cidrBlocks), אבל אי אפשר להקטין את מספר כתובות ה-IP שהוקצו או לשנות אותן. אפשר לשנות רק את הסיומת של בלוק ה-CIDR, ולהקטין את ערך המסכה כדי להגדיל את מספר כתובות ה-IP.

גם clusterNetwork.pods.cidrBlocks וגם nodeConfig.podDensity.maxPodsPerNode (שמתואר בקטע הבא) הם לא ניתנים לשינוי, לכן חשוב לתכנן בקפידה את הצמיחה העתידית של האשכול כדי לא לחרוג מהקיבולת של הצמתים. במאמר מגבלות מפורטים המספרים המקסימליים המומלצים של Pods לכל אשכול, Pods לכל צומת וצמתים לכל אשכול, על סמך בדיקות.

מספר הפודים המקסימלי לכל צומת

ב-Google Distributed Cloud ב-Bare Metal, אפשר להגדיר עד 250 פודים לכל צומת. ‫Kubernetes מקצה בלוק CIDR לכל צומת, כדי שלכל pod תהיה כתובת IP ייחודית. הגודל של בלוק ה-CIDR של ה-Pod תואם למספר המקסימלי של Pods לכל צומת.

בטבלה הבאה מפורט הגודל של בלוק ה-CIDR ש-Kubernetes מקצה לכל צומת, על סמך המספר המקסימלי של Pods שהוגדר לכל צומת:

מספר הפודים המקסימלי לכל צומת בלוק CIDR לכל צומת מספר כתובות ה-IP
32 /26 64
33-64 /25 128
65-128 /24 256
129-250 /23 512

כדי להריץ 250 Pods לכל צומת, צריך להגדיר ל-Kubernetes לשמור בלוק CIDR של /23 לכל צומת. אם באשכול שלכם מוגדר ערך ברירת המחדל /16 בשדה clusterNetwork.pods.cidrBlocks, באשכול יש מגבלה של (2(23-16))=128 צמתים.

אם אתם מתכוונים להגדיל את האשכול מעבר למגבלה הזו, מומלץ מאוד להגדיר את clusterNetwork.pods.cidrBlocks לבלוק CIDR של Pod שגדול משמעותית מהערך שמולא מראש.

למידע נוסף על האופן שבו מספר הפודים והשירותים וגורמים אחרים משפיעים על יכולת ההתאמה לעומס (scaling) של האשכול, קראו את המאמר הרחבת אשכולות של Google Distributed Cloud.

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

הדיאגרמה הבאה ממחישה מספר מושגי מפתח ברשתות של Google Distributed Cloud, באחת מהגדרות הרשת האפשריות.

הגדרת רשת אופיינית ב-Google Distributed Cloud

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

  • צומתי מישור הבקרה מריצים את מאזני העומסים, ולכולם יש קישוריות לשכבה 2, בעוד שחיבורים אחרים, כולל צומתי עובד, דורשים רק קישוריות לשכבה 3.
  • קובצי התצורה מגדירים כתובות IP למאגרים של צומתי עובדים. קובצי התצורה מגדירים גם כתובות VIP למטרות הבאות:
    • שירותים
    • תעבורת נתונים נכנסת (Ingress)
    • גישה למישור הבקרה דרך Kubernetes API
  • צריך חיבור אל Google Cloud.

שימוש ביציאות

בקטע הזה מפורטות דרישות היציאות של אשכולות Google Distributed Cloud. בטבלאות הבאות מוצג איך רכיבי Kubernetes משתמשים ביציאות UDP ו-TCP בצמתים של אשכולות ומאזני עומסים.

צמתים של מישור הבקרה

גרסה 1.33 ואילך

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של אדמינים תחנת עבודה של אדמין
TCP לקבלת נתונים 2379 - 2381 ‫API, מדדים ותקינות של לקוח שרת etcd kube-apiserver וגם etcd
TCP לקבלת נתונים 2382 - 2384 ‫API, מדדים ותקינות של לקוח שרת etcd-events kube-apiserver וגם etcd-events
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 6444 שרת Kubernetes API הכול
TCP לקבלת נתונים 9100 auth-proxy node-exporter
TCP לקבלת נתונים 9101 הצגת מדדי צומת במארח מקומי בלבד

(רלוונטי לגרסה 1.28 ואילך)

node-exporter
TCP לקבלת נתונים ‫9192 (ברירת המחדל, אבל אפשר להגדיר) יציאת Node Agent (רלוונטי רק לאשכולות שמשתמשים ב-Node Agent)

(רלוונטי לגרסה 1.33 ואילך)

node-agent-port
TCP לקבלת נתונים 9977 קבלת אירוע ביקורת משרת ה-API audit-proxy
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 10257 kube-controller-manager

(שינוי מספר היציאה לגרסה 1.28 ואילך)

עצמי
TCP לקבלת נתונים 10259 kube-scheduler

(שינוי מספר היציאה לגרסה 1.28 ואילך)

עצמי
TCP לקבלת נתונים 11002 הקונטיינר הראשי של GKE Identity Service נקשר ליציאה דרך hostPort

(רלוונטי לגרסה 1.29 ואילך)

עצמי
TCP לקבלת נתונים 14443 שירות Webhook של ANG kube-apiserver וגם ang-controller-manager

גרסה 1.29-1.32

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של אדמינים תחנת עבודה של אדמין
TCP לקבלת נתונים 2379 - 2381 ‫API, מדדים ותקינות של לקוח שרת etcd kube-apiserver וגם etcd
TCP לקבלת נתונים 2382 - 2384 ‫API, מדדים ותקינות של לקוח שרת etcd-events kube-apiserver וגם etcd-events
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 6444 שרת Kubernetes API הכול
TCP לקבלת נתונים 9100 auth-proxy node-exporter
TCP לקבלת נתונים 9101 הצגת מדדי צומת במארח מקומי בלבד

(רלוונטי לגרסה 1.28 ואילך)

node-exporter
TCP לקבלת נתונים 9977 קבלת אירוע ביקורת משרת ה-API audit-proxy
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 10257 kube-controller-manager

(שינוי מספר היציאה לגרסה 1.28 ואילך)

עצמי
TCP לקבלת נתונים 10259 kube-scheduler

(שינוי מספר היציאה לגרסה 1.28 ואילך)

עצמי
TCP לקבלת נתונים 11002 הקונטיינר הראשי של GKE Identity Service נקשר ליציאה דרך hostPort

(רלוונטי לגרסה 1.29 ואילך)

עצמי
TCP לקבלת נתונים 14443 שירות Webhook של ANG kube-apiserver וגם ang-controller-manager

גרסה 1.28

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של אדמינים תחנת עבודה של אדמין
TCP לקבלת נתונים 2379 - 2381 ‫API, מדדים ותקינות של לקוח שרת etcd kube-apiserver וגם etcd
TCP לקבלת נתונים 2382 - 2384 ‫API, מדדים ותקינות של לקוח שרת etcd-events kube-apiserver וגם etcd-events
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 6444 שרת Kubernetes API הכול
TCP לקבלת נתונים 8444 הקונטיינר הראשי של GKE Identity Service נקשר ליציאה דרך hostPort

(רלוונטי רק לגרסה 1.28)

הכול
TCP לקבלת נתונים 9100 auth-proxy node-exporter
TCP לקבלת נתונים 9101 הצגת מדדי צומת במארח מקומי בלבד

(רלוונטי לגרסה 1.28 ואילך)

node-exporter
TCP לקבלת נתונים 9977 קבלת אירוע ביקורת משרת ה-API audit-proxy
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 10257 kube-controller-manager

(שינוי מספר היציאה לגרסה 1.28 ואילך)

עצמי
TCP לקבלת נתונים 10259 kube-scheduler

(שינוי מספר היציאה לגרסה 1.28 ואילך)

עצמי
TCP לקבלת נתונים 14443 שירות Webhook של ANG kube-apiserver וגם ang-controller-manager

גרסה 1.16

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של אדמינים תחנת עבודה של אדמין
TCP לקבלת נתונים 2379 - 2381 ‫API, מדדים ותקינות של לקוח שרת etcd kube-apiserver וגם etcd
TCP לקבלת נתונים 2382 - 2384 ‫API, מדדים ותקינות של לקוח שרת etcd-events

(רלוונטי לגרסה 1.16 ואילך)

kube-apiserver וגם etcd-events
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 6444 שרת Kubernetes API הכול
TCP לקבלת נתונים 9100 מדדי הצגה node-exporter
TCP לקבלת נתונים 9443 מדדי שרת/שרת proxy לרכיבים של מישור הבקרה (הדרישה הזו ליציאה היא לגרסת אשכול 1.16 ומטה). kube-control-plane-metrics-proxy
TCP לקבלת נתונים 9977 קבלת אירוע ביקורת משרת ה-API audit-proxy
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10251 kube-scheduler עצמי
TCP לקבלת נתונים 10252 kube-controller-manager עצמי
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 14443 שירות Webhook של ANG kube-apiserver וגם ang-controller-manager

גרסה 1.15 ומטה

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של אדמינים תחנת עבודה של אדמין
TCP לקבלת נתונים 2379 - 2381 ‫API, מדדים ותקינות של לקוח שרת etcd kube-apiserver וגם etcd
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 6444 שרת Kubernetes API הכול
TCP לקבלת נתונים 9100 מדדי הצגה node-exporter
TCP לקבלת נתונים 9443 מדדי שרת/שרת proxy לרכיבים של מישור הבקרה (הדרישה הזו ליציאה היא לגרסת אשכול 1.16 ומטה). kube-control-plane-metrics-proxy
TCP לקבלת נתונים 9977 קבלת אירוע ביקורת משרת ה-API audit-proxy
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10251 kube-scheduler עצמי
TCP לקבלת נתונים 10252 kube-controller-manager עצמי
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 14443 שירות Webhook של ANG kube-apiserver וגם ang-controller-manager

צומתי עובדים

גרסה 1.33 ואילך

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 9100 auth-proxy node-exporter
TCP לקבלת נתונים 9101 הצגת מדדי צומת במארח מקומי בלבד

(רלוונטי לגרסה 1.28 ואילך)

node-exporter
TCP לקבלת נתונים ‫9192 (ברירת המחדל, אבל אפשר להגדיר) יציאת Node Agent (רלוונטי רק לאשכולות שמשתמשים ב-Node Agent)

(רלוונטי לגרסה 1.33 ואילך)

node-agent-port
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 30,000-32,767 שירותי NodePort עצמי

גרסה 1.29-1.32

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 9100 auth-proxy node-exporter
TCP לקבלת נתונים 9101 הצגת מדדי צומת במארח מקומי בלבד

(רלוונטי לגרסה 1.28 ואילך)

node-exporter
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 30,000-32,767 שירותי NodePort עצמי

גרסה 1.28

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 9100 auth-proxy node-exporter
TCP לקבלת נתונים 9101 הצגת מדדי צומת במארח מקומי בלבד

(רלוונטי לגרסה 1.28 ואילך)

node-exporter
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 30,000-32,767 שירותי NodePort עצמי

גרסה 1.16

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 9100 מדדי הצגה node-exporter
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 30,000-32,767 שירותי NodePort עצמי

גרסה 1.15 ומטה

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 9100 מדדי הצגה node-exporter
TCP לקבלת נתונים 10250 kubelet API לעצמי ולמישור הבקרה
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 30,000-32,767 שירותי NodePort עצמי

צמתים של מאזן עומסים

גרסה 1.33 ואילך

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP לקבלת נתונים 443 ניהול אשכולות

אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה controlPlaneLBPort.

הכול
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
‫TCP ו-UDP לקבלת נתונים 7946 בדיקת תקינות של MetalLB צמתים של מאזן עומסים
TCP לקבלת נתונים ‫9192 (ברירת המחדל, אבל אפשר להגדיר) יציאת Node Agent (רלוונטי רק לאשכולות שמשתמשים ב-Node Agent)

(רלוונטי לגרסה 1.33 ואילך)

node-agent-port
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 11000 יציאת האזנה למדדי HAProxy (לא ניתנת לשינוי)

(רלוונטי לגרסה 1.29 ואילך)

הכול
TCP לקבלת נתונים 11001 יציאת האזנה ל-GKE Identity Service (לא ניתנת לשינוי)

(רלוונטי לגרסה 1.29 ואילך)

הכול

גרסה 1.29-1.32

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP לקבלת נתונים 443 ניהול אשכולות

אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה controlPlaneLBPort.

הכול
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
‫TCP ו-UDP לקבלת נתונים 7946 בדיקת תקינות של MetalLB צמתים של מאזן עומסים
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול
TCP לקבלת נתונים 11000 יציאת האזנה למדדי HAProxy (לא ניתנת לשינוי)

(רלוונטי לגרסה 1.29 ואילך)

הכול
TCP לקבלת נתונים 11001 יציאת האזנה ל-GKE Identity Service (לא ניתנת לשינוי)

(רלוונטי לגרסה 1.29 ואילך)

הכול

גרסה 1.28

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP לקבלת נתונים 443 ניהול אשכולות

אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה controlPlaneLBPort.

הכול
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
‫TCP ו-UDP לקבלת נתונים 7946 בדיקת תקינות של MetalLB צמתים של מאזן עומסים
TCP לקבלת נתונים 8443 יציאת האזנה ל-GKE Identity Service (לא ניתנת לשינוי)

(רלוונטי רק לגרסה 1.28)

הכול
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול

גרסה 1.16

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP לקבלת נתונים 443 ניהול אשכולות

אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה controlPlaneLBPort.

הכול
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 7946 בדיקת תקינות של MetalLB צמתים של מאזן עומסים
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול

גרסה 1.15 ומטה

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות של משתמשים צמתים של אשכול אדמין
TCP לקבלת נתונים 443 ניהול אשכולות

אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה controlPlaneLBPort.

הכול
TCP שני הסוגים 4240 בדיקת תקינות של CNI הכול
UDP לקבלת נתונים 6081 אנקפסולציה של GENEVE עצמי
TCP לקבלת נתונים 7946 בדיקת תקינות של MetalLB צמתים של מאזן עומסים
TCP לקבלת נתונים 10256 בדיקת תקינות של צומת הכול

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

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

פרוטוקול כיוון טווח יציאות מטרה בשימוש על ידי
TCP לקבלת נתונים 22 הקצאה ועדכון של צומתי אשכולות כל הצמתים
TCP לקבלת נתונים 443 שרת Kubernetes API לאשכול שנוסף

אפשר להגדיר את היציאה הזו בהגדרות האשכול, באמצעות השדה controlPlaneLBPort.

צמתים של מישור הבקרה ושל מאזן העומסים

הגדרת יציאות של firewalld

אתם לא צריכים להשבית את firewalld כדי להריץ את Google Distributed Cloud ב-Red Hat Enterprise Linux ‏(RHEL). כדי להשתמש ב-firewalld, צריך לפתוח את יציאות ה-UDP וה-TCP שמשמשות את הצמתים של מישור הבקרה, ה-worker ומאזן העומסים, כמו שמתואר בקטע שימוש ביציאות בדף הזה. בדוגמאות הבאות מוסבר איך פותחים יציאות באמצעות firewall-cmd, כלי שורת הפקודה של firewalld. צריך להריץ את הפקודות כמשתמש Root.

הגדרה לדוגמה של צומת במישור הבקרה

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

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

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

מחליפים את PODS_CIDR בבלוקי CIDR ששמורים לפודים שהוגדרו בשדה clusterNetwork.pods.cidrBlocks. בלוק ה-CIDR שמוגדר כברירת מחדל לפודים הוא 192.168.0.0/16.

הגדרה לדוגמה של צומת עובד

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

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

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

מחליפים את PODS_CIDR בבלוקי CIDR ששמורים לפודים שהוגדרו בשדה clusterNetwork.pods.cidrBlocks. בלוק ה-CIDR שמוגדר כברירת מחדל לפודים הוא 192.168.0.0/16.

הגדרה לדוגמה של צומת מאזן עומסים

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

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

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

מחליפים את PODS_CIDR בבלוקי CIDR ששמורים לפודים שהוגדרו בשדה clusterNetwork.pods.cidrBlocks. בלוק ה-CIDR שמוגדר כברירת מחדל לפודים הוא 192.168.0.0/16.

הגדרות נוספות ל-RHEL 9.2 ו-9.4

גרסאות 9.2 ו-9.4 של Red Hat Enterprise Linux ‏(RHEL) נתמכות כ-GA בגרסאות 1.29.400 ואילך. בגרסאות 9.2 ו-9.4 של RHEL, צריך לבצע הגדרה נוספת של firewalld בצמתים כדי שהשירותים וה-pods יפעלו כמו שצריך:

  1. מציגים את הממשקים הפעילים של הצומת כדי למצוא את הממשק של הצומת הראשי:

    firewall-cmd --list-interfaces
    

    בהתאם למוסכמות למתן שמות לממשקי מכונות של Linux, שם הממשק הראשי יכול להיראות כמו אחד מהשמות הבאים: eth0,‏ eno1,‏ ens1 או enp2s0.

  2. מציגים את האזורים של הצומת כדי לראות באיזה אזור הממשק הראשי משתמש:

    firewall-cmd --list-all-zones
    

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

    ...
    public (active)
      target: default
      icmp-block-inversion: no
      interfaces: eno1
      sources:
      ...
    
  3. מריצים את הפקודות הבאות של firewalld כדי להגדיר את פרטי המדיניות והאזור בהתאמה אישית ל-RHEL 9.2 או 9.4:

    firewall-cmd --permanent --new-zone=cilium
    firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
    firewall-cmd --permanent --zone=cilium --set-target ACCEPT
    firewall-cmd --permanent --zone=cilium --add-masquerade
    firewall-cmd --permanent --zone=cilium --add-forward
    firewall-cmd --permanent --new-policy cilium-host-port-forwarding
    firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
    firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
    firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
    firewall-cmd --reload
    

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

    • ‫public: אזור מוגדר מראש לשימוש באזורים ציבוריים שבהם מתקבלים רק חיבורים נכנסים נבחרים.
    • ‫trusted: אזור מוגדר מראש בסביבה מבוקרת שבה כל החיבורים לרשת מתקבלים.
    • השם של אזור מותאם אישית שהגדרתם.
  4. כדי להגדיר את פתרון האחסון, פועלים לפי ההוראות במסמכי התיעוד של הספק.

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

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

    firewall-cmd --permanent --zone=public --add-port=PORT_INFO
    

    מחליפים את PORT_INFO במספר היציאה או בטווח של מספרי יציאות, ואחריהם הפרוטוקול. לדוגמה, 10250-10252/tcp.

אישור הגדרת היציאה

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

  1. מריצים את הפקודה הבאה של Network Mapper כדי לראות אילו יציאות פתוחות:

    nmap localhost
    
  2. מריצים את הפקודות הבאות כדי לקבל את הגדרות התצורה של firewalld:

    firewall-cmd --info-zone=public
    firewall-cmd --info-zone=k8s-pods
    firewall-cmd --list-all-policies
    
  3. אם צריך, מריצים מחדש את הפקודות מהקטעים הקודמים כדי להגדיר את הצמתים כמו שצריך. יכול להיות שתצטרכו להריץ את הפקודות כמשתמש Root.

בעיה ידועה ב-firewalld

כשמפעילים את Google Distributed Cloud עם firewalld ב-Red Hat Enterprise Linux ‏(RHEL), שינויים ב-firewalld יכולים להסיר את השרשראות של Cilium iptables ברשת המארחת. השרשראות של iptables נוספות על ידי Pod של anetd כשהוא מופעל. האובדן של שרשראות iptables של Cilium גורם ל-Pod ב-Node לאבד את הקישוריות לרשת מחוץ ל-Node.

שינויים ב-firewalld שמסירים את השרשראות של iptables כוללים, בין היתר:

  • הפעלה מחדש של firewalld, באמצעות systemctl

  • טעינה מחדש של firewalld באמצעות לקוח שורת הפקודה (firewall-cmd --reload)

כדי להחיל את השינויים ב-firewalld בלי להסיר את השרשראות של iptables, צריך להפעיל מחדש את anetd בצומת:

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

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    מחליפים את ANETD_XYZ בשם של Pod של anetd.