דרישות רשת

במאמר הזה מפורטים דרישות הרשת להתקנה ולהפעלה של תוכנת Distributed Cloud רק לשרת פיזי.

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

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

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

הערה: למרות ש-Container Registry נסגר, Artifact Registry עדיין משתמש באותן כתובות URL‏ gcr.io ששימשו את Container Registry. מידע נוסף זמין במאמר בנושא מאגרי gcr.io.

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

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

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

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

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

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

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

רשתות של Pods ושירותים

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

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

• ‫clusterNetwork.pods.cidrBlocks מציין את מספר ה-Pods שמותרים באשכול.

• ‫clusterNetwork.services.cidrBlocks מציין את מספר השירותים שמותרים באשכול.

• ‫nodeConfig.podDensity.maxPodsPerNode מציין את המספר המקסימלי של פודים שיכולים לפעול בצומת יחיד.

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 עבור Pods ושירותים

מציינים בלוק Classless Inter-Domain Routing‏ (CIDR) של כתובות IP לשימוש ב-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 ששונים מהערכים שמולאו מראש. בפרט, טווחי ה-Service וה-Pod לא יכולים לחפוף לטווחי ה-Service וה-Pod הבאים:

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

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

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

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

הערה: בלוקי ה-CIDR של הפוד והשירות עבור האשכול מחולקים לטווחים קטנים יותר של כתובות IP לכל צומת באשכול. ב-Google Distributed Cloud, המערכת משתמשת בתרגום כתובות רשת (NAT) כדי למפות את טווחי כתובות ה-IP של ה-Pod לכתובת ה-IP של הצומת. אם אחת מכתובות ה-IP של ה-Pod תואמת לכתובת IP חיצונית, הכתובת החיצונית הזו נחשבת ככתובת שלא ניתן להגיע אליה מתוך האשכול.

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

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

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

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

הערה: ההגדרה maxPodsPerNode מתייחסת רק לפודים פעילים, כלומר לפודים שמשתמשים במשאבים. לדוגמה, Job ב-Kubernetes יוצר פוד אחד או יותר כדי לבצע משימה ספציפית. הפודים בדרך כלל פועלים עד שהם משלימים את המשימה (או נכשלים) ומפסיקים. בדרך כלל, הפודים שהופסקו לא מנוקים אוטומטית, ולכן הם מופיעים בצומת כשמריצים את הפקודה kubectl get pods. עם זאת, מכיוון שפודים שהופסקו לא צורכים משאבים, כולל כתובות IP, הם לא נכללים במגבלה הכוללת של פודים לכל צומת.

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

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

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

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

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

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

בתרשים הבא מוצגים כמה מושגים חשובים בנושא רישות ב-Google Distributed Cloud, בתצורת רשת אפשרית אחת.

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

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

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

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

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

גרסה 1.33 ומעלה

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתים באשכול אדמין	תחנת עבודה לאדמין
TCP	לקבלת נתונים	2379 - 2381	etcd server client API, metrics and health	kube-apiserver וגם etcd
TCP	לקבלת נתונים	2382 - 2384	‫etcd-events server client API, מדדים ומצב	kube-apiserver וגם etcd-events
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
TCP	לקבלת נתונים	6444	שרת Kubernetes API	הכול
TCP	לקבלת נתונים	9100	auth-proxy	node-exporter
TCP	לקבלת נתונים	9101	הצגת מדדי צמתים רק ב-localhost (רלוונטי לגרסה 1.28 ואילך)	node-exporter
TCP	לקבלת נתונים	‫9192 (ברירת מחדל, אבל אפשר להגדיר)	היציאה של סוכן הצומת (רלוונטי רק לאשכולות שמשתמשים בסוכן הצומת) (רלוונטי לגרסה 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	ANG Webhook Service	kube-apiserver וגם ang-controller-manager

גרסה 1.29-1.32

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתים באשכול אדמין	תחנת עבודה לאדמין
TCP	לקבלת נתונים	2379 - 2381	etcd server client API, metrics and health	kube-apiserver וגם etcd
TCP	לקבלת נתונים	2382 - 2384	‫etcd-events server client API, מדדים ומצב	kube-apiserver וגם etcd-events
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
TCP	לקבלת נתונים	6444	שרת Kubernetes API	הכול
TCP	לקבלת נתונים	9100	auth-proxy	node-exporter
TCP	לקבלת נתונים	9101	הצגת מדדי צמתים רק ב-localhost (רלוונטי לגרסה 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	ANG Webhook Service	kube-apiserver וגם ang-controller-manager

גרסה 1.28

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתים באשכול אדמין	תחנת עבודה לאדמין
TCP	לקבלת נתונים	2379 - 2381	etcd server client API, metrics and health	kube-apiserver וגם etcd
TCP	לקבלת נתונים	2382 - 2384	‫etcd-events server client API, מדדים ומצב	kube-apiserver וגם etcd-events
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
TCP	לקבלת נתונים	6444	שרת Kubernetes API	הכול
TCP	לקבלת נתונים	8444	הקונטיינר הראשי של GKE Identity Service נקשר ליציאה דרך hostPort (רלוונטי לגרסה 1.28 בלבד)	הכול
TCP	לקבלת נתונים	9100	auth-proxy	node-exporter
TCP	לקבלת נתונים	9101	הצגת מדדי צמתים רק ב-localhost (רלוונטי לגרסה 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	ANG Webhook Service	kube-apiserver וגם ang-controller-manager

גרסה 1.16

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתים באשכול אדמין	תחנת עבודה לאדמין
TCP	לקבלת נתונים	2379 - 2381	etcd server client API, metrics and health	kube-apiserver וגם etcd
TCP	לקבלת נתונים	2382 - 2384	‫etcd-events server client API, מדדים ומצב (רלוונטי לגרסה 1.16 ואילך)	kube-apiserver וגם etcd-events
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
TCP	לקבלת נתונים	6444	שרת Kubernetes API	הכול
TCP	לקבלת נתונים	9100	מדדים של הצגת מודעות	node-exporter
TCP	לקבלת נתונים	9443	הצגה/העברה של מדדים לרכיבי מישור הבקרה (הדרישה לגבי היציאה הזו היא לגרסה 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	ANG Webhook Service	kube-apiserver וגם ang-controller-manager

גרסה 1.15 ומטה

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתים באשכול אדמין	תחנת עבודה לאדמין
TCP	לקבלת נתונים	2379 - 2381	etcd server client API, metrics and health	kube-apiserver וגם etcd
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
TCP	לקבלת נתונים	6444	שרת Kubernetes API	הכול
TCP	לקבלת נתונים	9100	מדדים של הצגת מודעות	node-exporter
TCP	לקבלת נתונים	9443	הצגה/העברה של מדדים לרכיבי מישור הבקרה (הדרישה לגבי היציאה הזו היא לגרסה 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	ANG Webhook Service	kube-apiserver וגם ang-controller-manager

צומתי עובד

גרסה 1.33 ומעלה

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתי אשכולות משתמשים	צמתים של אשכול אדמין
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
TCP	לקבלת נתונים	9100	auth-proxy	node-exporter
TCP	לקבלת נתונים	9101	הצגת מדדי צמתים רק ב-localhost (רלוונטי לגרסה 1.28 ואילך)	node-exporter
TCP	לקבלת נתונים	‫9192 (ברירת מחדל, אבל אפשר להגדיר)	היציאה של סוכן הצומת (רלוונטי רק לאשכולות שמשתמשים בסוכן הצומת) (רלוונטי לגרסה 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 Encapsulation	עצמי
TCP	לקבלת נתונים	9100	auth-proxy	node-exporter
TCP	לקבלת נתונים	9101	הצגת מדדי צמתים רק ב-localhost (רלוונטי לגרסה 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 Encapsulation	עצמי
TCP	לקבלת נתונים	9100	auth-proxy	node-exporter
TCP	לקבלת נתונים	9101	הצגת מדדי צמתים רק ב-localhost (רלוונטי לגרסה 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 Encapsulation	עצמי
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 Encapsulation	עצמי
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 Encapsulation	עצמי
‫TCP ו-UDP	לקבלת נתונים	7946	בדיקת תקינות של MetalLB	צמתים של מאזן עומסים
TCP	לקבלת נתונים	‫9192 (ברירת מחדל, אבל אפשר להגדיר)	היציאה של סוכן הצומת (רלוונטי רק לאשכולות שמשתמשים בסוכן הצומת) (רלוונטי לגרסה 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 Encapsulation	עצמי
‫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 Encapsulation	עצמי
‫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 Encapsulation	עצמי
TCP	לקבלת נתונים	7946	בדיקת תקינות של MetalLB	צמתים של מאזן עומסים
TCP	לקבלת נתונים	10256	בדיקת תקינות של צומת	הכול

גרסה 1.15 ומטה

פרוטוקול	כיוון	טווח יציאות	מטרה	בשימוש על ידי
TCP	לקבלת נתונים	22	הקצאה ועדכון של צמתי אשכולות משתמשים	צמתים של אשכול אדמין
TCP	לקבלת נתונים	443	ניהול אשכולות אפשר להגדיר את הפורט הזה בקובץ התצורה של האשכול באמצעות השדה controlPlaneLBPort.	הכול
TCP	שני הסוגים	4240	בדיקת תקינות של CNI	הכול
UDP	לקבלת נתונים	6081	GENEVE Encapsulation	עצמי
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 שמשמשות את הצמתים של מישור הבקרה, העובד ומאזן העומסים, כמו שמתואר בקטע שימוש ביציאות בדף הזה. ההגדרות לדוגמה שמופיעות בהמשך מראות איך אפשר לפתוח יציאות באמצעות 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.

דוגמה להגדרה של צומת Worker

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

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) נתמכות כזמינות כללית בגרסאות 1.29.400 ואילך. בגרסאות RHEL 9.2 ו-9.4, צריך לבצע הגדרה נוספת של firewalld בצמתים כדי שהשירותים והפודים יפעלו בצורה תקינה:

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.

הערה: באג בחלק מליבות לינוקס ב-Red Hat Enterprise Linux‏ (RHEL) 9.2 עלול לגרום להורדות איטיות מאוד של תמונות. מידע נוסף, כולל הוראות לפתרון הבעיה, זמין במאמר הורדות איטיות בקונטיינרים ב-RHEL 9.2.

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

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

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 יכולים להסיר את שרשראות iptables של Cilium ברשת המארחת. שרשראות iptables מתווספות על ידי anetd Pod כשהוא מופעל. הניתוק של שרשראות Cilium iptables גורם לכך שאין ל-Pod בצומת קישוריות לרשת מחוץ לצומת.

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

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

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

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

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

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

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