בדף הזה מוסבר איך ליצור אשכול GKE ב-AWS. אפשר גם ליצור VPC ואשכול באמצעות Terraform.
הדף הזה מיועד לאדמינים, לארכיטקטים ולמפעילים שרוצים להגדיר תשתית ענן, לעקוב אחריה ולנהל אותה. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בתוכן זמין במאמר תפקידים נפוצים של משתמשי GKE ומשימות. Google Cloud
לפני שמתחילים
לפני שיוצרים אשכול, צריך להשלים את הדרישות המוקדמות. בפרט, אתם צריכים לספק את המשאבים הבאים:
- AWS VPC שבו האשכול יפעל.
- עד שלושה תתי-רשתות של AWS לשלושת העותקים של רמת הבקרה. כל אחד מהם צריך להיות באזור זמינות שונה ב-AWS.
- תפקיד ה-IAM ב-AWS ש-GKE ב-AWS מקבל כשמנהלים את האשכול. לשם כך נדרש סט ספציפי של הרשאות IAM.
- מפתחות סימטריים של CMK ב-KMS להצפנת נתונים (etcd) והגדרות של אשכול במצב מנוחה.
- פרופיל המכונה של AWS IAM לכל עותק משוכפל של מישור הבקרה. לשם כך נדרש סט ספציפי של הרשאות IAM.
- זוג מפתחות SSH של EC2 (אופציונלי) אם אתם צריכים גישת SSH למופעי EC2 שמריצים כל רפליקה של מישור הבקרה.
באחריותכם ליצור ולנהל את המשאבים האלה, שאפשר לשתף בין כל אשכולות GKE. כל שאר משאבי ה-AWS הבסיסיים בהיקף האשכול מנוהלים על ידי GKE ב-AWS.
בחירת טווחי CIDR לאשכול
כשיוצרים אשכול ב-GKE ב-AWS, צריך לספק טווחי כתובות IPv4 לשימוש ב-Pods וב-Services.
טווח כתובות ה-IP האלה מצוין באמצעות סימון Classless Inter-Domain Routing (CIDR) – לדוגמה, 100.64.0.0/16.
טווחים מומלצים
אנחנו ממליצים על טווחי ה-CIDR הבאים לשירותים ול-Pods:
- שירותים: 100.64.0.0/16
- Pods: 100.96.0.0/11
הטווחים האלה גדולים מספיק כדי שתוכלו להגדיל את האשכול בלי בעיות.
בקטעים הבאים מפורטים פרטים נוספים.
פרטים על בחירת טווחים
ב-GKE on AWS נעשה שימוש ברשת שכבת-על בשביל Pods ושירותים, כך שאין צורך שטווח כתובות ה-IP של הרשתות האלה יהיה ניתן לניתוב ב-VPC. צריך לוודא שכל טווחי כתובות ה-IP שבהם אתם משתמשים זמינים. מידע נוסף זמין במאמר בנושא Dataplane V2.
טווח כתובות ה-IP של ה-Pod והשירות יכול לחפוף לטווח כתובות ה-IP של רשת ה-VPC, בתנאי שאף אחד מהם לא כולל את טווח כתובות ה-IP של מישור הבקרה או של תת-הרשת של מאגר הצמתים.
טווח כתובות ה-IP של ה-Pod והשירות חייב להיות אחד מטווח כתובות ה-IP הפרטיות הבאים:
-
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16– כתובות IP פרטיות (RFC 1918) -
100.64.0.0/10— מרחב כתובות משותף (RFC 6598) -
192.0.0.0/24— הקצאות פרוטוקול של IETF (RFC 6890) -
192.0.2.0/24,198.51.100.0/24,203.0.113.0/24— מסמכי תיעוד (RFC 5737) -
192.88.99.0/24— IPv6 to IPv4 relay (הוצא משימוש) (RFC 7526) -
198.18.0.0/15– בדיקת השוואה לשוק (RFC 2544)
-
מומלץ להשתמש בטווחים של כתובות IP בתוך 100.64.0.0/10 (RFC 6598). הטווח הזה שמור ל-NAT ברמת ספק, שסביר להניח שלא נעשה בו שימוש ב-VPC שלכם.
לדוגמה, ההגדרה הבאה היא הגדרה תקינה שבה אין חפיפה בין רשתות ה-Pod, ה-Service וה-Node (רשת ה-VPC משתמשת בכתובות IP פרטיות מסוג RFC 1918, ואילו רשתות ה-Pod וה-Service מוצבות על כתובות IP פרטיות מסוג RFC 6598).
- רשת VPC:
10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24 - רשת Pod:
100.65.0.0/16 - רשת שירות:
100.66.0.0/16
ההגדרה הבאה היא גם הגדרה תקינה, למרות שיש חפיפה בין רשתות ה-Pod והשירות לבין רשת ה-VPC, כי אין חפיפה עם העותקים המשוכפלים של מישור הבקרה.
- רשת VPC:
10.0.0.0/16 - רשת Pod:
10.0.1.0/24 - רשת שירות:
10.0.2.0/24 - תת-רשתות של העתק של מישור הבקרה:
10.0.3.0/24,10.0.4.0/24,10.0.5.0/24
ההגדרה הבאה לא תקפה, כי טווח כתובות ה-IP של ה-Pod חופף לרשת של מישור הבקרה. יכול להיות שהחפיפה הזו תמנע מעומסי עבודה לתקשר עם העותק המשוכפל של מישור הבקרה ברשת ה-VPC:
- רשת VPC:
10.0.0.0/16 - רשת Pod:
10.0.1.0/24 - רשת שירות:
10.1.0.0/24 - תת-רשתות של העתק של מישור הבקרה:
10.0.1.0/24,10.0.2.0/24,10.0.3.0/24
פרטים על טווח הכתובות של ה-Pod
Kubernetes מקצה כתובות לאובייקטים מסוג Pod מתוך טווח הכתובות של ה-Pod. טווח ה-Pod של אשכול מחולק לטווחים קטנים יותר לכל צומת. כשמגדירים תזמון של Pod בצומת מסוים, מערכת Kubernetes מקצה כתובת IP של Pod מתוך הטווח של הצומת.
כדי לחשב את הגודל של טווח כתובות ה-Pod, צריך להעריך את מספר הצמתים שרוצים באשכול ואת מספר ה-Pods שרוצים להפעיל בכל צומת.
בטבלה הבאה מפורטות המלצות לגבי גודל טווחי ה-CIDR של ה-Pod, על סמך מספר הצמתים וה-Pods שאתם מתכוונים להפעיל.
טבלה של טווחי כתובות של Pod
| טווח כתובות של Pod | כתובות IP מקסימליות של Pod | מספר הצמתים המקסימלי | מספר המכשירים המקסימלי |
|---|---|---|---|
| /24 טווח הכתובות הקטן ביותר האפשרי של Pod |
256 כתובות | צומת אחד | 110 טבליות |
| /23 | 512 כתובות | 2 צמתים | 220 טבליות |
| /22 | 1,024 כתובות | 4 צמתים | 440 טבליות |
| /21 | 2,048 כתובות | 8 צמתים | 880 קבוצות Pod |
| /20 | 4,096 כתובות | 16 צמתים | 1,760 טבליות |
| /19 | 8,192 כתובות | 32 צמתים | 3,520 טבליות |
| /18 | 16,384 כתובות | 64 צמתים | 7,040 טבליות |
| /17 | 32,768 כתובות | 128 צמתים | 14,080 טבליות |
| /16 | 65,536 כתובות | 256 צמתים | 28,160 טבליות |
| /15 | 131,072 כתובות | 512 צמתים | 56,320 טבליות |
| /14 | 262,144 כתובות | 1,024 צמתים | 112,640 טבליות |
פרטים על טווח הכתובות למקרי חירום
Kubernetes מקצה כתובות IP וירטואליות לאובייקטים של Service – לדוגמה, מאזני עומסים מתוך טווח הכתובות הזה.
כדי לחשב את הגודל של טווח כתובות השירות, צריך להעריך את מספר השירותים שרוצים באשכול.
בטבלה הבאה מפורטות המלצות לגבי גודל טווחי ה-CIDR של השירותים, על סמך מספר השירותים שאתם מתכוונים להפעיל.
טבלה של טווחי כתובות למקרי חירום
| טווח כתובות למקרי חירום | מספר השירותים המקסימלי |
|---|---|
| /27 טווח כתובות השירות הקטן ביותר האפשרי |
32 Services |
| /26 | 64 שירותים |
| /25 | 128 Services |
| /24 | 256 שירותים |
| /23 | 512 שירותים |
| /22 | 1,024 שירותים |
| /21 | 2,048 שירותים |
| /20 | 4,096 שירותים |
| /19 | 8,192 שירותים |
| /18 | 16,384 שירותים |
| /17 | 32,768 שירותים |
| /16 טווח כתובות השירות הגדול ביותר האפשרי |
65,536 שירותים |
בחירת פרויקט לאירוח צי הרכבים
Fleets הםGoogle Cloud קונספט לארגון אשכולות לקבוצות גדולות יותר. באמצעות צי של אשכולות, אפשר לנהל כמה אשכולות בכמה עננים ולהחיל עליהם מדיניות עקבית. ממשק ה-API של GKE Multi-Cloud רושם אוטומטית את האשכולות שלכם ב-Fleet כשהאשכול נוצר.
כשיוצרים אשכול, מציינים פרויקט מארח של Fleet שממנו יתבצע ניהול האשכול. מכיוון ש-GKE ב-AWS משתמש בשם האשכול כשם החברות ב-Fleet, צריך לוודא ששמות האשכולות ייחודיים ב-Fleet.
רישום חוצה-פרויקטים
אם רוצים להשתמש בפרויקט מארח של Fleet שאינו הפרויקט שבו נמצא האשכול, צריך להחיל עוד קשירת מדיניות IAM על חשבון השירות של סוכן השירות מרובה-העננים. Google Cloud כך חשבון השירות יכול לנהל את צי הרכבים באמצעות פרויקט המארח של צי הרכבים.
כדי להוסיף את סוכן השירות לפרויקט, מריצים את הפקודה הבאה:
gcloud beta services identity create --service=gkemulticloud.googleapis.com \ --project=CLUSTER_PROJECT_NUMBERמחליפים את
CLUSTER_PROJECT_NUMBERבמספר הפרויקט ב- Google Cloud .מקצים את הקישור הזה באמצעות הפקודה הבאה:
gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \ --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \ --role="roles/gkemulticloud.serviceAgent"מחליפים את מה שכתוב בשדות הבאים:
-
FLEET_PROJECT_ID: הפרויקט המארח של ה-Fleet, כלומרGoogle Cloud project -
CLUSTER_PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud
-
השם של חשבון סוכן השירות לריבוי עננים הוא בפורמט הבא: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.
אפשר למצוא את חשבונות השירות בדף Service account במסוף Google Cloud . מידע נוסף על איתור מספר הפרויקט זמין במאמר זיהוי פרויקטים.
יצירת האשכול
כדי ליצור את האשכול ב-GKE ב-AWS, משתמשים בפקודה הבאה. למידע נוסף על הפקודה הזו, כולל הפרמטרים האופציונליים שלה, תוכלו לעיין בדף העזר בנושא gcloud container aws.
gcloud container aws clusters create CLUSTER_NAME \
--aws-region AWS_REGION \
--location GOOGLE_CLOUD_LOCATION \
--cluster-version CLUSTER_VERSION \
--fleet-project FLEET_PROJECT \
--vpc-id VPC_ID \
--subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
--pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
--service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
--role-arn API_ROLE_ARN \
--database-encryption-kms-key-arn DB_KMS_KEY_ARN \
--admin-users ADMIN_USERS_LIST \
--config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
--iam-instance-profile CONTROL_PLANE_PROFILE \
--tags "Name=CLUSTER_NAME-cp"
מחליפים את מה שכתוב בשדות הבאים:
-
CLUSTER_NAME: שם האשכול שבחרתם -
AWS_REGION: האזור ב-AWS שבו רוצים ליצור את האשכול -
GOOGLE_CLOUD_LOCATION: השם של המיקום שממנו ינוהל האשכול הזה, כפי שמוגדר בGoogle Cloud אזורי הניהול. Google Cloud -
CLUSTER_VERSION: גרסת Kubernetes להתקנה באשכול -
FLEET_PROJECT: פרויקט המארח של ה-Fleet שבו האשכול יירשם. אם רוצים לנהל את האשכול הזה מפרויקט אחר, אפשר לעיין במאמר בנושא רישום בין פרויקטים.Google Cloud -
VPC_ID: המזהה של ה-VPC ב-AWS עבור האשכול הזה -
CONTROL_PLANE_SUBNET_1, CONTROL_PLANE_SUBNET_2ו-CONTROL_PLANE_SUBNET_3: מזהי רשתות המשנה של שלושת המופעים של מישור הבקרה של האשכול -
POD_ADDRESS_CIDR_BLOCKS: טווח כתובות CIDR של הפודים באשכול -
SERVICE_ADDRESS_CIDR_BLOCKS: טווח כתובות CIDR של השירותים באשכול -
API_ROLE_ARN: ה-ARN של תפקיד GKE Multi-Cloud API -
CONTROL_PLANE_PROFILE: הפרופיל של מופע IAM שמשויך לאשכול. פרטים על עדכון פרופיל של מופע IAM זמינים במאמר עדכון פרופיל של מופע AWS IAM. -
DB_KMS_KEY_ARN: שם משאב Amazon (ARN) של מפתח AWS KMS להצפנת הסודות של האשכול -
CONFIG_KMS_KEY_ARN: שם משאב Amazon (ARN) של מפתח AWS KMS להצפנת נתוני משתמשים -
ADMIN_USERS_LIST(אופציונלי): רשימה מופרדת בפסיקים של כתובות אימייל של המשתמשים שרוצים להעניק להם הרשאות אדמין – לדוגמה, "kai@example.com,hao@example.com,kalani@example.com". ברירת המחדל היא המשתמש שיוצר את האשכול
אם הפרמטר --tags קיים, הוא מחיל את תג ה-AWS שצוין על כל משאבי ה-AWS הבסיסיים שמנוהלים על ידי GKE ב-AWS. בדוגמה הזו, הצמתים של מישור הבקרה מתויגים בשם האשכול שאליו הם שייכים.
לא תוכלו להשתמש ב-SSH כדי להיכנס לצמתי מישור הבקרה האלה, אלא אם תציינו זוג מפתחות SSH עם הדגל --ssh-ec2-key-pair.
כדי לראות את כל הגרסאות הנתמכות של Kubernetes ב Google Cloud מיקום מסוים, מריצים את הפקודה הבאה.
gcloud container aws get-server-config --location GCP_LOCATION
אישור של Cloud Logging / Cloud Monitoring
כדי ש-GKE ב-AWS יוכל ליצור ולהעלות יומנים ומדדים של המערכת אלGoogle Cloud, צריך לאשר את הפעולה.
כדי לתת לזהות של עומס העבודה ב-Kubernetes gke-system/gke-telemetry-agentהרשאה לכתוב יומנים ב- Google Cloud Logging ומדדים ב- Google Cloud Monitoring, מריצים את הפקודה הבאה:
gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
--member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
--role=roles/gkemulticloud.telemetryWriter
מחליפים את GOOGLE_PROJECT_ID במזהה הפרויקט של האשכול. Google Cloud
הקישור הזה ב-IAM מעניק גישה לכל האשכולות בפרויקט Google Cloud project project להעלאת יומנים ומדדים. צריך להריץ אותה רק אחרי שיוצרים את האשכול הראשון בפרויקט.
הוספת הקישור הזה של IAM תיכשל אלא אם נוצר לפחות אשכול אחד בפרויקט Google Cloud . הסיבה לכך היא שמאגר הזהויות של עומסי העבודה שאליו הוא מתייחס (GOOGLE_PROJECT_ID.svc.id.goog) לא מוקצה עד ליצירת האשכול.
המאמרים הבאים
- יצירת מאגר צמתים
- הגדרת גישה לאשכול עבור kubectl.
- כדאי לנסות את המדריך למתחילים כדי להפעיל את עומס העבודה הראשון.
- אפשר לקרוא את מאמרי העזרה של
gcloud container clusters create. - נתקלתם בבעיה ביצירת אשכול? מידע נוסף זמין במאמר בנושא פתרון בעיות.