שירות ניהול יוצר, מעדכן ומוחק אשכולות GKE ב-AWS. במאמר הזה מוסבר איך ליצור שירות ניהול בתוך ענן וירטואלי פרטי (VPC) ייעודי של AWS. אם יש לכם VPC קיים, כדאי לעיין במאמר שילוב עם תשתית קיימת.
לפני שמתחילים
לפני שמתחילים להשתמש ב-GKE on AWS, חשוב לוודא שביצעתם את המשימות הבאות:
- ממלאים את הדרישות המוקדמות.
-
מבצעים אימות באמצעות Google Cloud CLI.
gcloud auth login && \ gcloud auth application-default login
הערכים שצריך
כדי להשלים את הנושא הזה, אתם צריכים את הדברים הבאים מהקטע בנושא דרישות מוקדמות:
- שמות משאבים (ARN) או כינויים של מפתחות KMS
- Google Cloud מפתחות של חשבונות שירות
- פרויקטGoogle Cloud
- כלי שורת הפקודה
aws,terraformו-anthos-gkeמותקנים ומוגדרים. - אזור AWS ותחומי הזמינות שבהם GKE on AWS יוצר את אשכול הניהול.
הגדרת שירות הניהול
מגדירים את שירות הניהול של GKE ב-AWS באמצעות קובץ YAML. הקובץ דומה להגדרת משאב בהתאמה אישית של Kubernetes, אבל הוא לא ייצוג של משאב.
פותחים טרמינל במחשב שבו התקנתם והגדרתם את כלי שורת הפקודה
aws,terraformו-anthos-gke.יוצרים ספרייה ריקה להגדרות של GKE ב-AWS ועוברים לספרייה הזו. במסמכי GKE on AWS, נעשה שימוש ב-
anthos-awsכספריית התצורה לדוגמה.mkdir anthos-aws cd anthos-awsיוצרים קובץ בשם
anthos-gke.yamlבכלי לעריכת טקסט. מדביקים את התוכן הבא בקובץ.apiVersion: multicloud.cluster.gke.io/v1 kind: AWSManagementService metadata: name: management spec: version: aws-1.14.1-gke.0 region: AWS_REGION authentication: awsIAM: adminIdentityARNs: - ADMIN_AWS_IAM_ARN kmsKeyARN: KMS_KEY_ARN databaseEncryption: kmsKeyARN: DATABASE_KMS_KEY_ARN googleCloud: projectID: GCP_PROJECT_ID serviceAccountKeys: managementService: MANAGEMENT_KEY_PATH connectAgent: HUB_KEY_PATH node: NODE_KEY_PATH dedicatedVPC: vpcCIDRBlock: VPC_CIDR_BLOCK availabilityZones: - ZONE_1 - ZONE_2 - ZONE_3 privateSubnetCIDRBlocks: - PRIVATE_CIDR_BLOCK_1 - PRIVATE_CIDR_BLOCK_2 - PRIVATE_CIDR_BLOCK_3 publicSubnetCIDRBlocks: - PUBLIC_CIDR_BLOCK_1 - PUBLIC_CIDR_BLOCK_2 - PUBLIC_CIDR_BLOCK_3 # Optional bastionHost: allowedSSHCIDRBlocks: - SSH_CIDR_BLOCK proxy: PROXY_JSON_FILE # optionalמחליפים את הערכים הבאים:
AWS_REGION עם האזור ב-AWS שבו רוצים להריץ את האשכול.
ADMIN_AWS_IAM_ARN עם שם המשאב של אמזון של המשתמש עם הרשאות AWS IAM ליצירת שירות ניהול. כדי לקבל את ה-ARN של המשתמש שאומת בכלי
aws, מריצים אתaws sts get-caller-identity.KMS_KEY_ARN עם שם משאב Amazon של מפתח AWS KMS או כינוי מפתח KMS שמאבטח את הנתונים של שירות הניהול במהלך היצירה. לדוגמה,
arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab. אם אין לכם את ה-ARN, מריצים את הפקודהaws kms list-keysכדי לאחזר רשימה של ARN.DATABASE_KMS_KEY_ARN עם שם משאב Amazon של מפתח AWS KMS או כינוי מפתח שמאבטח את מסדי הנתונים של שירות הניהול שלכם – לדוגמה,
arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab.etcdGCP_PROJECT_ID במזהה הפרויקט שמארח את סביבת GKE ב-AWS. Google Cloud
MANAGEMENT_KEY_PATH עם המיקום של מפתח חשבון השירות לניהולGoogle Cloud .
HUB_KEY_PATH במיקום של מפתח חשבון השירות של Google Cloud Connect.
NODE_KEY_PATH במיקום של מפתח חשבון השירות של צומת GKE ב-AWS.
VPC_CIDR_BLOCK עם טווח כתובות ה-IP הכולל של CIDR עבור AWS VPC שנוצר על ידי
anthos-gke. לדוגמה,10.0.0.0/16. מידע נוסף זמין במאמר VPC and subnet basics (הסבר על VPC ועל רשתות משנה) במסמכי התיעוד של AWS.ZONE_1, ZONE_2 ו-ZONE_3 עם אזורי הזמינות של AWS EC2 שבהם רוצים ליצור צמתים ומישורי בקרה. GKE ב-AWS יוצר רשתות משנה באזורים האלה. כשמשתמשים ב-
anthos-gkeכדי ליצור הגדרה לאשכול משתמשים, GKE ב-AWS יוצר מישורי בקרה ומאגרי צמתים באזורי הזמינות האלה – לדוגמה,us-east-1a.
אם רוצים להשתמש ב-anthos-gkeכדי ליצור אשכולות משתמשים רק באזור אחד, אפשר להסיר את ZONE_2 ואת ZONE_3.PRIVATE_CIDR_BLOCK_1, PRIVATE_CIDR_BLOCK_2 ו-PRIVATE_CIDR_BLOCK_3, עם חסימת CIDR לתת-הרשת הפרטית. רכיבים של GKE ב-AWS, כמו שירות הניהול, פועלים ברשת המשנה הפרטית. רשת המשנה הזו צריכה להיות בטווח ה-CIDR של ה-VPC שצוין ב-
vpcCIDRBlock. צריך רשת משנה אחת לכל אזור זמינות – לדוגמה,10.0.1.0/24.PUBLIC_CIDR_BLOCK_1, PUBLIC_CIDR_BLOCK_2 ו-PUBLIC_CIDR_BLOCK_3, עם בלוקי ה-CIDR של תת-הרשת הציבורית. צריך רשת משנה אחת לכל אזור זמינות. תת-הרשת הציבורית חושפת את שירותי האשכול, כמו מאזני עומסים, לקבוצות האבטחה ולטווח כתובות שצוינו ברשימות בקרת הגישה (ACL) ברשת ובקבוצות האבטחה של AWS – לדוגמה,
10.0.100.0/24.SSH_CIDR_BLOCK עם חסימת ה-CIDR שמאפשרת SSH נכנס ליעד המבוצר (bastion host) – לדוגמה,
203.0.113.0/24. אם רוצים לאפשר SSH מכל כתובת IP, משתמשים ב-0.0.0.0/0.(אופציונלי) PROXY_JSON_FILE עם הנתיב היחסי של קובץ תצורת ה-proxy. אם אתם לא משתמשים ב-Proxy, צריך למחוק את השורה הזו.
מריצים את הפקודה
anthos-gke aws management initכדי ליצור קובץanthos-gke.status.yamlעם הגדרות נוספות. הפקודהinitגם מאמתת את האובייקטAWSManagementServiceבקובץanthos-gke.yaml.anthos-gke aws management initמריצים את הפקודה
anthos-gke aws management applyכדי ליצור את שירות הניהול ב-AWS.anthos-gke aws management applyיכול להיות שיידרשו עד עשר דקות להשלמת הפקודה
anthos-gke aws management apply. אחרי שהפקודה מסתיימת, שירות הניהול פועל ב-AWS.
שדות אופציונליים
בקובץ anthos-gke.yaml שלמעלה מוצג סט אופייני של שדות שרוב הלקוחות יצטרכו. ההגדרה ב-anthos-gke.yaml תומכת גם במספר שדות אופציונליים. למשל:
- spec.bootstrapS3Bucket כדי לציין קטגוריית AWS S3 לנתוני התצורה של GKE ב-AWS
- spec.tags כדי לתייג משאבי AWS שקשורים לאשכול
- spec.securityGroupIDs כדי להקצות מזהים נוספים של קבוצות אבטחה לאשכול הניהול
- spec.*Volume ושדות המשנה שלו volumeType, iops ו-kmsKeyARN כדי לכוונן את הפרמטרים של נפח האחסון ב-EBS
- spec.terraform.stateGCSBucket כדי לציין קטגוריה של שירות Google Cloud לנתוני התצורה של Terraform
מידע נוסף על כל השדות שנתמכים ב-anthos-gke.yaml זמין במאמר בנושא AWS Management Service.
התחברות לשירות הניהול
בשלב הבא, משתמשים ב-anthos-gke כדי להתחבר לשירות הניהול של GKE ב-AWS ולאמת את החיבור.
כשיוצרים שירות ניהול באמצעות הגדרות ברירת המחדל, למישור הבקרה יש כתובת IP פרטית שלא נגישה מחוץ ל-AWS VPC. יש שלוש דרכים לגשת לשירות הניהול:
- דרך שירות AWS Direct Connect של אמזון
- דרך יעד מבוצר (bastion host) שמבצע פרוקסי לחיבורים בין האינטרנט לבין רשתות המשנה של GKE ב-AWS
- דרך VPN
כשיוצרים שירות ניהול ב-VPC ייעודי, מערכת GKE on AWS יוצרת באופן אוטומטי מארח bastion בתת-רשת ציבורית. אם אתם מתחברים לשירות הניהול שלכם דרך VPN או AWS Direct Connect, לא צריך את יעד מבוצר (bastion host) הזה. אם לא, כדי להתחבר לשירות הניהול דרך יעד מבוצר (bastion host), מבצעים את השלבים הבאים:
משתמשים בכלי
terraformכדי ליצור את הסקריפט שפותח מנהרת SSH ליעד המבוצר (bastion host). בוחרים את הגרסה של Terraform ומריצים את הפקודות הבאות:Terraform 0.12, 0.13
terraform output bastion_tunnel > bastion-tunnel.sh chmod 755 bastion-tunnel.shTerraform 0.14.3 ואילך
terraform output -raw bastion_tunnel > bastion-tunnel.sh chmod 755 bastion-tunnel.shTerraform יוצר את הסקריפט
bastion-tunnel.shשמפנה למפתח ה-SSH של מארח ה-bastion בנתיב~/.ssh/anthos-gke.כדי לפתוח את המנהרה, מריצים את הסקריפט
bastion-tunnel.sh. המנהרה מעבירה מ-localhost:8118אל יעד מבוצר (bastion host).כדי לפתוח מנהרה ליעד המבוצר (bastion host), מריצים את הפקודה הבאה:
./bastion-tunnel.sh -N -4ההודעות ממנהרת ה-SSH מופיעות בחלון הזה. כשרוצים לסגור את החיבור, מפסיקים את התהליך באמצעות Control+C או סוגרים את החלון.
פותחים טרמינל חדש ועוברים לספרייה עם ההגדרה של GKE ב-AWS.
יצירת
kubeconfigלאימות. משתמשים ב-anthos-gkeכדי לצרף פרטי כניסה להגדרה שמאוחסנת ב-~/.kube/config.anthos-gke aws management get-credentialsמוודאים שאפשר להתחבר לשירות הניהול באמצעות
kubectl.env HTTPS_PROXY=http://localhost:8118 \ kubectl cluster-infoהפלט כולל את כתובת ה-URL של שרת ה-API של שירות הניהול.
המאמרים הבאים
- יצירת אשכול משתמשים
- שימוש ב-proxy עם GKE ב-AWS.
- שינוי ההגדרה של
kubectlכדי להתחבר ל-GKE ב-AWS עם פחות אפשרויות של שורת פקודה.