פריסה ב-Google Kubernetes Engine

במדריך הזה מוסבר איך לשלוף תמונות מ-Artifact Registry כדי לפרוס אותן ב-Google Kubernetes Engine. אם רוצים לפרוס לשירותי Kubernetes של צד שלישי או לשירותים שמארחים בעצמם, צריך להגדיר אימות ל-Artifact Registry לפני שמבצעים משיכה של תמונות. Google Cloud כדי לבצע אימות ל- Google Cloud מעומסי עבודה של Kubernetes מחוץ ל- Google Cloud, אפשר לעיין במאמר הגדרת איחוד שירותי אימות הזהות של עומסי עבודה עם Kubernetes.

‫Google Kubernetes Engine יכול לשלוף תמונות ישירות ממאגרי Docker. חלק מהגרסאות כוללות תמיכה מוגדרת מראש בשליפת תמונות ממאגרי Docker ב-Artifact Registry.

דרישות

בקטע הזה מתוארות הדרישות לשילוב עם GKE.

הרשאות

כשיוצרים מאגרי צמתים או אשכולות, GKE משתמש בברירות המחדל הבאות:

• חשבון השירות של Compute Engine שמוגדר כברירת מחדל הוא הזהות של הצמתים.

• בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל אוטומטית את התפקיד 'עריכה' בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי החלת האילוץ iam.automaticIamGrantsForDefaultServiceAccounts של מדיניות הארגון. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

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

• לצמתים שיוצרים באמצעות חשבון השירות שמוגדר כברירת מחדל יש היקפי גישה שמוגדרים כברירת מחדל ב-Compute Engine, כולל גישה לקריאה בלבד לאחסון. אי אפשר לשנות את היקפי הגישה בצמתים קיימים.

אם השבתתם את ההענקה של תפקיד העריכה הבסיסי, צריך להעניק לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine את התפקיד 'קורא ב-Artifact Registry' (roles/artifactregistry.reader).

אם משתמשים בברירות המחדל האלה ומעניקים לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine את התפקיד 'קורא ב-Artifact Registry' (roles/artifactregistry.reader), ‏ GKE יכול למשוך תמונות ממאגרי Artifact Registry באותו פרויקט Google Cloud . אם אתם צריכים לשלוח תמונות מצמתים, למשוך או לשלוח תמונות בין פרויקטים, להשתמש בחשבון שירות שסופק על ידי המשתמש או שיש לכם צרכים אחרים שהגדרות ברירת המחדל לא תומכות בהם, כדאי לעיין במסמכי התיעוד בנושא בקרת גישה כדי לקבל מידע על הגדרת הגישה.

אם מופיעות שגיאות מסוג "ההרשאה נדחתה", אפשר לעיין במאמר בנושא שגיאות מסוג 4xx.

גרסת GKE

בטבלה הבאה מפורטות הגרסאות המינימליות הנדרשות של GKE כדי ליצור אשכולות עם הרשאות ברירת מחדל לשליפת קונטיינרים ממאגרי Docker באותו פרויקט.

גרסה	הטלאי המינימלי הנדרש
‫1.14	1.14.10-gke.22
1.15	1.15.9-gke.8

אם גרסת GKE שלכם מוקדמת מהגרסה המינימלית, אתם צריכים להגדיר Kubernetes imagePullSecrets כדי לאפשר ל-GKE למשוך תמונות.

אם GKE נמצא בפרויקט אחר מ-Artifact Registry, צריך להעניק הרשאות Artifact Registry לחשבון השירות שבו משתמשים בצומת GKE. כברירת מחדל, הצמתים משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

הפעלת תמונה

אפשר להריץ תמונה של Artifact Registry באשכול Google Kubernetes Engine באמצעות הפקודה הבאה:

kubectl run [NAME] --image=LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

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

where:

• ‫ LOCATION הוא המיקום האזורי או המיקום במספר אזורים של המאגר. ‫
• ‫PROJECT הוא מזהה הפרויקט במסוף. Google Cloud אם מזהה הפרויקט מכיל נקודתיים (:), אפשר לעיין במאמר בנושא פרויקטים בהיקף הדומיין.
• ‫REPOSITORY הוא שם המאגר שבו מאוחסן האימג'.
• ‫IMAGE הוא שם האימג' במאגר.
• ‫TAG הוא התג של גרסת התמונה שרוצים למשוך.

מידע נוסף על פקודות Kubernetes זמין במאמר סקירה כללית של kubectl.

פתרון בעיות בתמונות של צומתי containerd

החל מגרסת צומת 1.19 של GKE, תמונת הצומת שמוגדרת כברירת מחדל לצומתי Linux היא מערכת הפעלה שמותאמת לקונטיינרים עם containerd (cos_containerd) במקום מערכת הפעלה שמותאמת לקונטיינרים עם Docker (cos).

הקובץ הבינארי של Docker זמין בצמתי Linux שמשתמשים ב-containerd כזמן ריצה, אבל אנחנו לא ממליצים להשתמש בו. ‫Docker לא מנהל את הקונטיינרים ש-Kubernetes מריץ בצמתים של containerd, ולכן אי אפשר להשתמש בו כדי להציג קונטיינרים של Kubernetes שפועלים או כדי ליצור איתם אינטראקציה באמצעות פקודות Docker או Docker API.

כדי לבצע ניפוי באגים או לפתור בעיות בצמתי Linux, אפשר ליצור אינטראקציה עם containerd באמצעות כלי שורת הפקודה הנייד שנוצר עבור זמני ריצה של קונטיינרים ב-Kubernetes: ‏ crictl. ‫crictl תומך בפונקציות נפוצות לצפייה בקונטיינרים ובקובצי אימג', לקריאת יומנים ולהפעלת פקודות בקונטיינרים.

מידע נוסף זמין במדריך למשתמש של crictl ובמאמרי העזרה של GKE בנושא containerd.

בצמתים של Windows Server, הדמון containerd פועל כשירות Windows בשם containerd. היומנים זמינים בספריית היומנים הבאה: C:\etc\kubernetes\logs\containerd.log והם מוצגים ב-Logs Explorer בקטע LOG NAME: "container-runtime".

אזהרה: ל-Docker אין אפשרות להציג או לגשת למאגרי תגים של Linux ושל Windows node pools שמשתמשים ב-containerd כזמן ריצה.

שליפה ממאגר ציבורי של Artifact Registry

אחרי שפורסים תמונה באשכול GKE עם צמתי containerd, אפשר להתחבר למכונה וירטואלית באמצעות SSH ולהריץ פקודות crictl כדי לפתור בעיות.

מאגרי Artifact Registry ציבוריים לא דורשים אימות. crictl אפשר להשתמש בה גם כדי לשלוף תמונות ממאגרי Artifact Registry פרטיים.

המסוף

1. נכנסים לדף VM Instances במסוף Google Cloud .

   כניסה לדף VM Instances

2. ברשימת המכונות הווירטואליות, לוחצים על החץ שליד SSH בשורה של המכונה שרוצים להתחבר אליה.

   

   הערה: כשמתחברים למכונות וירטואליות באמצעות מסוף Google Cloud , מערכת Compute Engine יוצרת בשבילכם מפתח SSH זמני. מידע נוסף על מפתחות SSH זמין במאמר חיבורי SSH למכונות וירטואליות של Linux

3. בוחרים באפשרות 'פתיחה בחלון דפדפן' או בשיטת החיבור הרצויה מתוך האפשרויות בתפריט הנפתח.

4. מסוףGoogle Cloud נפתח בחלון טרמינל חדש. כדי לשלוף תמונה מ-Artifact Registry, משתמשים בפקודה crictl:

   crictl pull IMAGE_LOCATION:TAG
   

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

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

   כשמושכים תמונה ממאגר פרטי ב-Artifact Registry, צריך לאמת את המאגר. אפשר להשתמש באסימון גישה כדי לספק את פרטי הכניסה.

gcloud

1. מוודאים שמותקנת הגרסה העדכנית של Google Cloud CLI

   gcloud components update
   

2. מתחברים ל-VM:

   gcloud compute ssh --project=PROJECT_ID \
    --zone=ZONE \
    VM_NAME
   

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

   • ‫PROJECT_ID: מזהה הפרויקט שמכיל את המכונה הווירטואלית
   • ‫ZONE: השם של האזור שבו נמצאת המכונה הווירטואלית
   • ‫VM_NAME: השם של ה-VM

   אם הגדרתם מאפייני ברירת מחדל ל-Google Cloud CLI, אתם יכולים להשמיט את הדגלים --project ו---zone מהפקודה הזו. לדוגמה:

   gcloud compute ssh VM_NAME
   

3. אם עדיין לא יצרתם מפתח SSH, הכלי SSH keygen ייצור אותו בשבילכם. כשמוצגת בקשה, מזינים את סיסמת הגישה או משאירים את השדה ריק.

4. כדי לשלוף תמונה מ-Artifact Registry, משתמשים בפקודה crictl:

   crictl pull IMAGE_LOCATION:TAG
   

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

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

   כשמושכים תמונה ממאגר פרטי ב-Artifact Registry, צריך לאמת את המאגר. אפשר להשתמש באסימון גישה כדי לספק את פרטי הכניסה.

שליפה ממאגר פרטי של Artifact Registry

המסוף

1. נכנסים לדף VM Instances במסוף Google Cloud .

   כניסה לדף VM Instances

2. ברשימת המכונות הווירטואליות, לוחצים על החץ שליד SSH בשורה של המכונה שרוצים להתחבר אליה.

   

   הערה: כשמתחברים למכונות וירטואליות באמצעות מסוף Google Cloud , מערכת Compute Engine יוצרת בשבילכם מפתח SSH זמני. מידע נוסף על מפתחות SSH זמין במאמר חיבורי SSH למכונות וירטואליות של Linux

3. בוחרים באפשרות 'פתיחה בחלון דפדפן' מהתפריט הנפתח.

4. מסוףGoogle Cloud נפתח בחלון טרמינל חדש. יוצרים אסימון גישה לחשבון שירות של Compute Engine באמצעות curl.

   curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
   

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

   "access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
   HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
   sh","expires_in":3526,"token_type":"Bearer"}

5. מעתיקים את הערך של access_token מהפלט שמוחזר ללא המירכאות.

6. שולפים את התמונה באמצעות crictl pull --creds והערך access_token שהועתק בשלב הקודם.

   crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

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

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

gcloud

1. מוודאים שמותקנת הגרסה העדכנית של Google Cloud CLI

   gcloud components update
   

2. מתחברים ל-VM:

   gcloud compute ssh --project=PROJECT_ID \
    --zone=ZONE \
    VM_NAME
   

   מחליפים את המשתנים הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט שמכיל את המכונה הווירטואלית
   • ‫ZONE: השם של האזור שבו נמצאת המכונה הווירטואלית
   • ‫VM_NAME: השם של ה-VM

   אם הגדרתם מאפייני ברירת מחדל ל-Google Cloud CLI, אתם יכולים להשמיט את הדגלים --project ו---zone מהפקודה הזו. לדוגמה:

   gcloud compute ssh VM_NAME
   

3. אם עדיין לא יצרתם מפתח SSH, הכלי SSH keygen ייצור אותו בשבילכם. כשמוצגת בקשה, מזינים את סיסמת הגישה או משאירים את השדה ריק.

4. יוצרים אסימון גישה לחשבון שירות של Compute Engine באמצעות curl.

   curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
   

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

   "access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
   HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
   sh","expires_in":3526,"token_type":"Bearer"}

5. מעתיקים את הערך של access_token מהפלט שמוחזר ללא המירכאות.

6. שולפים את התמונה באמצעות crictl pull --creds והערך access_token שהועתק בשלב הקודם.

   crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

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

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

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