כדי להתקין ולהפעיל את תוכנת 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.
אלה הדרישות למכונות של מאזן העומסים:
- באיזון עומסים מקובץ בשכבה 2, כל מאזני העומסים באשכול נתון נמצאים באותו דומיין של שכבה 2. צומתי מישור הבקרה חייבים להיות גם באותו דומיין של שכבה 2.
- באיזון עומסים של Bundled Layer 2, כל כתובות ה-IP הווירטואליות (VIP) צריכות להיות ברשת המשנה של מכונת איזון העומסים, וניתנות לניתוב לשער של רשת המשנה.
- המשתמשים אחראים לאפשר תעבורת נתונים נכנסת של מאזן העומסים.
רשתות של Pods ו-Services
טווחי כתובות ה-IP שזמינים לשירותים ול-Pods מצוינים בקובץ התצורה של האשכול. בקטעים הבאים נדון באילוצים המינימליים והמקסימליים של טווחי הכתובות, ובחלק מהגורמים הקשורים שצריך להביא בחשבון כשמתכננים את התקנת האשכול.
מספר ה-Pods והשירותים שיכולים להיות באשכולות נשלט על ידי ההגדרות הבאות:
clusterNetwork.pods.cidrBlocksמציין את מספר ה-Pods שמותרים באשכול.clusterNetwork.services.cidrBlocksמציין את מספר השירותים שמותרים באשכול.nodeConfig.podDensity.maxPodsPerNodeמציין את המספר המקסימלי של 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) לשימוש של פודים, ובלוק 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 (שמתוארים בקטע הבא) הם לא ניתנים לשינוי, ולכן חשוב לתכנן בקפידה את הצמיחה העתידית של האשכול כדי לא לחרוג מהקיבולת של הצומת. במאמר מגבלות מפורטים המספרים המקסימליים המומלצים לפודים בכל אשכול, לפודים בכל צומת ולצמתים בכל אשכול, על סמך בדיקות.
מספר הפודים המקסימלי לכל צומת
ב-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 פודים לכל צומת, צריך להגדיר ל-Kubernetes לשמור בלוק CIDR של /23 לכל צומת. אם באשכול שלכם מוגדר ערך ברירת המחדל /16 בשדה clusterNetwork.pods.cidrBlocks, האשכול מוגבל ל-(2(23-16))=128 צמתים.
אם אתם מתכוונים להגדיל את האשכול מעבר למגבלה הזו, מומלץ מאוד להגדיר את clusterNetwork.pods.cidrBlocks לבלוק CIDR של Pod שגדול משמעותית מהערך שמולא מראש.
למידע נוסף על האופן שבו מספר הפודים והשירותים וגורמים אחרים משפיעים על יכולת ההתאמה לעומס (scaling) של האשכול, קראו את המאמר הרחבת אשכולות של 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 | API, מדדים ותקינות של לקוח שרת etcd | kube-apiserver וגם etcd |
| TCP | לקבלת נתונים | 2382 - 2384 | API, מדדים ותקינות של לקוח שרת etcd-events | kube-apiserver וגם etcd-events |
| TCP | שני הסוגים | 4240 | בדיקת תקינות של CNI | הכול |
| UDP | לקבלת נתונים | 6081 | אנקפסולציה של GENEVE | עצמי |
| TCP | לקבלת נתונים | 6444 | שרת API של Kubernetes | הכול |
| 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 | שרת API של Kubernetes | הכול |
| 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 | שרת API של Kubernetes | הכול |
| 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 | שרת API של Kubernetes | הכול |
| 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 | שרת API של Kubernetes | הכול |
| 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 | ניהול אשכולות אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה |
הכול |
| 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 | ניהול אשכולות אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה |
הכול |
| 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 | ניהול אשכולות אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה |
הכול |
| 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 | ניהול אשכולות אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה |
הכול |
| TCP | שני הסוגים | 4240 | בדיקת תקינות של CNI | הכול |
| UDP | לקבלת נתונים | 6081 | אנקפסולציה של GENEVE | עצמי |
| TCP | לקבלת נתונים | 7946 | בדיקת תקינות של MetalLB | צומתי מאזן עומסים |
| TCP | לקבלת נתונים | 10256 | בדיקת תקינות של צומת | הכול |
גרסה 1.15 ומטה
| פרוטוקול | כיוון | טווח יציאות | מטרה | בשימוש על ידי |
|---|---|---|---|---|
| TCP | לקבלת נתונים | 22 | הקצאה ועדכון של צומתי אשכולות של משתמשים | צמתים של אשכול אדמין |
| TCP | לקבלת נתונים | 443 | ניהול אשכולות אפשר להגדיר את היציאה הזו בקובץ התצורה של האשכול באמצעות השדה |
הכול |
| TCP | שני הסוגים | 4240 | בדיקת תקינות של CNI | הכול |
| UDP | לקבלת נתונים | 6081 | אנקפסולציה של GENEVE | עצמי |
| TCP | לקבלת נתונים | 7946 | בדיקת תקינות של MetalLB | צומתי מאזן עומסים |
| TCP | לקבלת נתונים | 10256 | בדיקת תקינות של צומת | הכול |
דרישות לגבי יציאות בכמה אשכולות
בהגדרה של כמה אשכולות, האשכולות שנוספו חייבים לכלול את היציאות הבאות כדי לתקשר עם אשכול האדמין.
| פרוטוקול | כיוון | טווח יציאות | מטרה | בשימוש על ידי |
|---|---|---|---|---|
| TCP | לקבלת נתונים | 22 | הקצאה ועדכון של צומתי אשכולות | כל הצמתים |
| TCP | לקבלת נתונים | 443 | שרת Kubernetes API לאשכול שנוסף אפשר להגדיר את היציאה הזו בהגדרות של האשכול, באמצעות השדה |
צמתים של מישור הבקרה ושל מאזן העומסים |
הגדרת יציאות של 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 יפעלו כמו שצריך:
מציגים את הממשקים הפעילים של הצומת כדי למצוא את הממשק של הצומת הראשי:
firewall-cmd --list-interfacesבהתאם למוסכמות למתן שמות לממשקי מכונות של Linux, שם הממשק הראשי יכול להיראות כמו אחד מהשמות הבאים:
eth0,eno1,ens1אוenp2s0.מציגים את האזורים של הצומת כדי לראות באיזה אזור הממשק הראשי משתמש:
firewall-cmd --list-all-zonesלדוגמה, אם הממשק הראשי הוא
eno1, החלק הבא בתשובה מציין שהממשק הראשי נמצא באזורpublic:... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...מריצים את הפקודות הבאות של 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: אזור מוגדר מראש בסביבה מבוקרת שבה כל החיבורים לרשת מתקבלים. - השם של אזור מותאם אישית שהגדרתם.
-
כדי להגדיר את פתרון האחסון, פועלים לפי ההוראות במסמכי התיעוד של הספק.
לדוגמה, אם אתם משתמשים ב-Portworx כדי לנהל עומסי עבודה עם שמירת מצב, דרישות הרשת של Portworx מפרטות את היציאות שצריכות להישאר פתוחות.
לכל אחת מהיציאות שמופיעות במסמכי התיעוד של הספק, מריצים את הפקודה הבאה:
firewall-cmd --permanent --zone=public --add-port=PORT_INFOמחליפים את
PORT_INFOבמספר היציאה או בטווח של מספרי יציאות, ואחריו הפרוטוקול. לדוגמה,10250-10252/tcp.
אישור הגדרת היציאה
כדי לאמת את הגדרת היציאות, מבצעים את השלבים הבאים בצומתי מישור הבקרה, בצומתי ה-worker ובצומתי מאזן העומסים:
מריצים את הפקודה הבאה של Network Mapper כדי לראות אילו יציאות פתוחות:
nmap localhostמריצים את הפקודות הבאות כדי לקבל את הגדרות התצורה של firewalld:
firewall-cmd --info-zone=public firewall-cmd --info-zone=k8s-pods firewall-cmd --list-all-policiesאם צריך, מריצים מחדש את הפקודות מהקטעים הקודמים כדי להגדיר את הצמתים כמו שצריך. יכול להיות שתצטרכו להריץ את הפקודות כמשתמש 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 בצומת:
מאתרים ומוחקים את ה-Pod של
anetdבאמצעות הפקודות הבאות כדי להפעיל מחדש אתanetd:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZמחליפים את ANETD_XYZ בשם של ה-Pod של
anetd.