המוצר שמתואר במסמכים האלה, GKE ב-AWS, נמצא עכשיו במצב תחזוקה והוא ייסגר ב-17 במרץ 2027.

פתרון בעיות ביצירה או בעדכון של אשכול

בדף הזה מוסבר איך לפתור בעיות שקשורות להתקנה או לשדרוג של GKE ב-AWS.

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

כשלים ביצירת אשכולות

כששולחים בקשה ליצירת אשכול, GKE on AWS מפעיל קודם סדרה של בדיקות לפני ההפעלה כדי לאמת את הבקשה. אם יצירת האשכול נכשלת, יכול להיות שאחת מהבדיקות המקדימות נכשלה או ששלב בתהליך יצירת האשכול עצמו לא הושלם.

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

ERROR: (gcloud.container.aws.clusters.create) INVALID_ARGUMENT: must be
between 1-63 characters, valid characters are /[a-z][0-9]-/, should start with a
letter, and end with a letter or a number: "invalid%%%name",
field: aws_cluster_id

יכול להיות שיצירת האשכול תיכשל גם אחרי שהבדיקות המקדימות יעברו בהצלחה. יכול להיות שהשגיאה תופיע כמה דקות אחרי שהתחילה יצירת האשכול, אחרי ש-GKE on AWS יצר משאבים ב- Google Cloud וב-AWS. במקרה כזה, משאב AWS יהיה קיים בפרויקט Google Cloud עם הסטטוס ERROR.

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

gcloud container aws clusters describe CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --format "value(state, errors)"

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME בשם האשכול שאת המצב שלו רוצים לבדוק
‫GOOGLE_CLOUD_LOCATION עם שם Google Cloud האזור שמנהל את אשכול ה-AWS הזה

לחלופין, אפשר לקבל פרטים על הכשל ביצירה על ידי תיאור המשאב Operation שמשויך לקריאה ל-API של יצירת אשכול.

gcloud container aws operations describe OPERATION_ID

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

gcloud container aws operations list \
    --location GOOGLE_CLOUD_LOCATION

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

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

gcloud container aws operations describe b6a3d042-8c30-4524-9a99-6ffcdc24b370 \
  --location GOOGLE_CLOUD_LOCATION

הפלט אמור להיראות כך:

done: true
error:
  code: 9
  message: 'could not set deregistration_delay timeout for the target group: AccessDenied
    User: arn:aws:sts::0123456789:assumed-role/foo-1p-dev-oneplatform/multicloud-service-agent
    is not authorized to perform: elasticloadbalancing:ModifyTargetGroupAttributes
    on resource: arn:aws:elasticloadbalancing:us-west-2:0123456789:targetgroup/gke-4nrk57tlyjva-cp-tcp443/74b57728e7a3d5b9
    because no identity-based policy allows the elasticloadbalancing:ModifyTargetGroupAttributes
    action'
metadata:
  '@type': type.googleapis.com/google.cloud.gkemulticloud.v1.OperationMetadata
  createTime: '2021-12-02T17:47:31.516995Z'
  endTime: '2021-12-02T18:03:12.590148Z'
  statusDetail: Cluster is being deployed
  target: projects/123456789/locations/us-west1/awsClusters/aws-prod1
name: projects/123456789/locations/us-west1/operations/b6a3d042-8c30-4524-9a99-6ffcdc24b370

יצירה או פעולה של אשכול נכשלות עם שגיאת הרשאה

שגיאה שמציינת כשל בהרשאה בדרך כלל מעידה על כך שאחד משני תפקידי AWS IAM שציינתם במהלך הפקודה ליצירת האשכול נוצר בצורה שגויה. לדוגמה, אם תפקיד ה-API לא כולל את ההרשאה elasticloadbalancing:ModifyTargetGroupAttributes, יצירת האשכול תיכשל ותוצג הודעת שגיאה שדומה להודעה הבאה:

ERROR: (gcloud.container.aws.clusters.create) could not set
deregistration_delay timeout for the target group: AccessDenied User:
arn:aws:sts::0123456789:assumed-role/cloudshell-user-dev-api-role/multicloud-
service-agent is not authorized to perform:
elasticloadbalancing:ModifyTargetGroupAttributes on resource:
arn:aws:elasticloadbalancing:us-east-1:0123456789:targetgroup/gke-u6au6c65e4iq-
cp-tcp443/be4c0f8d872bb60e because no identity-based policy allows the
elasticloadbalancing:ModifyTargetGroupAttributes action

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

כדי לפתור שגיאות הרשאה כאלה, צריך לוודא שהמדיניות שמשויכת לשני תפקידי ה-IAM שציינתם במהלך יצירת האשכול נכונה. חשוב לוודא שהם תואמים לתיאורים שבמאמר יצירת תפקידי AWS IAM, ואז למחוק את האשכול וליצור אותו מחדש. תיאורים של כל תפקיד זמינים במאמרים תפקיד API ותפקיד במישור הבקרה.

יצירה או הפעלה של אשכול נכשלות בשלב של בדיקת תקינות

לפעמים יצירת האשכול נכשלת במהלך בדיקת התקינות עם סטטוס פעולה שדומה לזה:

done: true
error:
  code: 4
  message: Operation failed
metadata:
  '@type': type.googleapis.com/google.cloud.gkemulticloud.v1.OperationMetadata
  createTime: '2022-06-29T18:26:39.739574Z'
  endTime: '2022-06-29T18:54:45.632136Z'
  errorDetail: Operation failed
  statusDetail: Health-checking cluster
  target: projects/123456789/locations/us-west1/awsClusters/aws-prod1
name: projects/123456789/locations/us-west1/operations/8a7a3b7f-242d-4fff-b518-f361d41c6597

יכול להיות שהסיבה לכשל היא שתפקידי ה-IAM חסרים או שצוינו בצורה שגויה. אפשר להשתמש ב-AWS CloudTrail כדי לחשוף בעיות ב-IAM.

לדוגמה:

אם תפקיד ה-API לא כלל את ההרשאה kms:GenerateDataKeyWithoutPlaintext למפתח KMS של עוצמת הקול הראשית של מישור הבקרה, יוצגו האירועים הבאים:

"eventName": "AttachVolume",
"errorCode": "Client.InvalidVolume.NotFound",
"errorMessage": "The volume 'vol-0ff75940ce333aebb' does not exist.",

וגם

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/foo-1p-dev-oneplatform/multicloud-service-agent is not authorized to perform: kms:GenerateDataKeyWithoutPlaintext on resource: arn:aws:kms:us-west1:0123456789:key/57a61a45-d9c1-4038-9021-8eb08ba339ba because no identity-based policy allows the kms:GenerateDataKeyWithoutPlaintext action",

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

"eventName": "AttachVolume",
"errorCode": "Client.CustomerKeyHasBeenRevoked",
"errorMessage": "Volume vol-0d022beb769c8e33b cannot be attached. The encrypted volume was unable to access the KMS key.",

וגם

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/foo-controlplane/i-0a11fae03eb0b08c1 is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:us-west1:0123456789:key/57a61a45-d9c1-4038-9021-8eb08ba339ba because no identity-based policy allows the kms:CreateGrant action",

אם לא הענקתם לתפקיד המקושר לשירות שנקרא AWSServiceRoleForAutoScalingkms:CreateGrant הרשאות להשתמש במפתח KMS של נפח הבסיס של מישור הבקרה, תראו את האירועים הבאים:

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/AWSServiceRoleForAutoScaling/AutoScaling is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:us-west1:0123456789:key/c77a3a26-bc91-4434-bac0-0aa963cb0c31 because no identity-based policy allows the kms:CreateGrant action",

אם לא נתתם לתפקיד המקושר לשירות שנקרא AWSServiceRoleForAutoScaling עם ההרשאות kms:GenerateDataKeyWithoutPlaintext להשתמש במפתח ה-KMS של נפח הבסיס של מישור הבקרה, יוצגו האירועים הבאים:

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/AWSServiceRoleForAutoScaling/AutoScaling is not authorized to perform: kms:GenerateDataKeyWithoutPlaintext on resource: arn:aws:kms:us-west1:0123456789:key/c77a3a26-bc91-4434-bac0-0aa963cb0c31 because no identity-based policy allows the kms:CreateGrant action",

בהמתנה להצטרפות הצמתים לאשכול

אם אתם מקבלים את השגיאה הבאה כשאתם יוצרים מאגר צמתים, בדקו ש-VPC לא כולל בלוק CIDR משני משויך של IPv4.

errorDetail: Operation failed
statusDetail: Waiting for nodes to join the cluster (0 out of 1 are ready)

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

אחזור יומן מערכת של מופע

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

פותחים את מסוף המופעים של AWS EC2.
לוחצים על Instances (מופעים).
מחפשים את המכונה לפי השם שלה. בדרך כלל, ב-GKE on AWS נוצרים מופעים בשם CLUSTER_NAME-cp לצמתים של מישור הבקרה או בשם CLUSTER_NAME-np לצמתים של מאגר הצמתים.
בוחרים באפשרות פעולות -> מעקב ופתרון בעיות -> קבלת יומן המערכת. יומן המערכת של המופע מופיע.

עדכוני אשכולות שנכשלו

כשמעדכנים אשכול, בדיוק כמו כשיוצרים אשכול חדש,‏ GKE on AWS מריץ קודם סדרה של בדיקות לפני ההפעלה כדי לאמת את הבקשה. אם עדכון האשכול נכשל, יכול להיות שאחד מהבדיקות המקדימות נכשל או ששלב בתהליך עדכון האשכול לא הושלם.

אם בדיקה לפני הפעלה נכשלת, אף משאב באשכול לא מתעדכן, ופרטי השגיאה מוחזרים ישירות אליכם. לדוגמה, אם מנסים לעדכן אשכול כדי להשתמש בזוג מפתחות SSH עם השם test_ec2_keypair, הבדיקה המקדימה מנסה לאחזר את זוג המפתחות של EC2 ונכשלת, והבקשה מחזירה את השגיאה הבאה:

ERROR: (gcloud.container.aws.clusters.update) INVALID_ARGUMENT: key pair
"test_ec2_keypair" not found,
field: aws_cluster.control_plane.ssh_config.ec2_key_pair

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

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

עדכון האשכול נכשל כשמעדכנים תגים של מישור הבקרה

‫AWS update API תומך בעדכון תגים של מישור הבקרה. כדי לעדכן תגים, צריך אשכול עם Kubernetes מגרסה 1.24 ואילך. צריך גם לוודא שלתפקיד AWS IAM יש את ההרשאות המתאימות שמופיעות בדף עדכון אשכול לעדכון תגים של מישור הבקרה.

שגיאה שמציינת כשל באימות בדרך כלל מעידה על כך ששכחתם להוסיף הרשאת IAM כלשהי. לדוגמה, אם תפקיד ה-API לא כולל את ההרשאה ec2:DeleteTags, יכול להיות שעדכון האשכול לתגים ייכשל ותוצג הודעת שגיאה שדומה להודעה הבאה (הטקסט <encoded_auth_failure_message> הושמט לצורך קיצור):

ERROR: (gcloud.container.aws.clusters.update) could not delete tags:
UnauthorizedOperation You are not authorized to perform this operation.
Encoded authorization failure message: <encoded_auth_failure_message>

כדי לנפות באגים בהודעת השגיאה המקודדת שלמעלה, אפשר לשלוח בקשה ל-AWS STS decode-authorization-message API כמו שמוצג בפקודה הבאה:

aws sts decode-authorization-message --encoded-message
<encoded_auth_failure_message> --query DecodedMessage --output
text | jq '.' | less