יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פריסה ב-Google Kubernetes Engine

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

כדי לפרוס בשירותי Kubernetes באירוח עצמי או של צד שלישי, צריך להגדיר אימות ל- Cloud de Confiance by S3NS לפני ששולפים קובצי אימג' מ-Artifact Registry. כדי לבצע אימות ב- Cloud de Confiance by S3NS מעומסי עבודה של Kubernetes מחוץ ל- Cloud de Confiance by S3NS, קראו את המאמר הגדרת איחוד שירותי אימות הזהות של עומסי עבודה באמצעות Kubernetes.

דרישות

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

הרשאות

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

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

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

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

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

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

אם נתקלתם בשגיאות מסוג "ההרשאה נדחתה", עיינו בקטע שגיאות 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.s3nsregistry.fr/PROJECT-ID/REPOSITORY/IMAGE:TAG

כאשר:

‫ LOCATION הוא המיקום האזורי של המאגר.
‫PROJECT הוא מזהה הפרויקט במסוף Cloud de Confiance .
‫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".

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

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

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

המסוף

נכנסים לדף VM instances במסוף Cloud de Confiance .

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

הערה: כשמתחברים למכונות וירטואליות באמצעות מסוף Cloud de Confiance , מערכת Compute Engine יוצרת מפתח SSH זמני. מידע נוסף על מפתחות SSH זמין במאמר חיבורי SSH למכונות וירטואליות של Linux.
בוחרים באפשרות "פתיחה בחלון דפדפן" או בשיטת החיבור הרצויה מהאפשרויות בתפריט הנפתח.
Cloud de Confiance פותח חלון טרמינל חדש. משתמשים ב-crictl כדי לשלוף קובץ אימג' מ-Artifact Registry:
```
crictl pull IMAGE_LOCATION:TAG
```
הפלט אמור להיראות כך:
```
Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5
```
כשמושכים קובץ אימג' ממאגר פרטי ב-Artifact Registry, צריך לבצע אימות מול המאגר. אתם יכולים להשתמש באסימון גישה כדי לספק את פרטי הכניסה שלכם.

gcloud

מוודאים שמותקנת הגרסה העדכנית של Google Cloud CLI.
```
gcloud components update
```
מתחברים למכונה הווירטואלית:
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט שמכיל את המכונה הווירטואלית
- ‫ZONE: שם האזור שבו נמצא ה-VM
- ‫VM_NAME: השם של ה-VM
אם הגדרתם מאפייני ברירת מחדל ל-Google Cloud CLI, אתם יכולים להשמיט מהפקודה הזו את הדגלים --project ו---zone. לדוגמה:
```
gcloud compute ssh VM_NAME
```
אם עדיין לא יצרתם מפתח SSH, הכלי SSH keygen ייצור אחד בשבילכם. מזינים ביטוי סיסמה או משאירים את השדה ריק כשמוצגת בקשה לעשות זאת.
משתמשים ב-crictl כדי לשלוף קובץ אימג' מ-Artifact Registry:
```
crictl pull IMAGE_LOCATION:TAG
```
הפלט אמור להיראות כך:
```
Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5
```
כשמושכים קובץ אימג' ממאגר פרטי ב-Artifact Registry, צריך לבצע אימות מול המאגר. אתם יכולים להשתמש באסימון גישה כדי לספק את פרטי הכניסה שלכם.

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

המסוף

נכנסים לדף VM instances במסוף Cloud de Confiance .

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

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

Cloud de Confiance פותח חלון טרמינל חדש. יוצרים אסימון גישה לחשבון שירות של 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"}

מעתיקים את הערך של access_token מהפלט שהתקבל, בלי המירכאות.
מורידים את קובץ האימג' באמצעות crictl pull --creds והערך של access_token שהועתק בשלב הקודם.
```
crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG
```
הפלט אמור להיראות כך:
```
Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5
```

gcloud

מוודאים שמותקנת הגרסה העדכנית של Google Cloud CLI.
```
gcloud components update
```
מתחברים למכונה הווירטואלית:
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
מחליפים את המשתנים הבאים:
- ‫PROJECT_ID: מזהה הפרויקט שמכיל את המכונה הווירטואלית
- ‫ZONE: שם האזור שבו נמצא ה-VM
- ‫VM_NAME: השם של ה-VM
אם הגדרתם מאפייני ברירת מחדל ל-Google Cloud CLI, אתם יכולים להשמיט מהפקודה הזו את הדגלים --project ו---zone. לדוגמה:
```
gcloud compute ssh VM_NAME
```
אם עדיין לא יצרתם מפתח SSH, הכלי SSH keygen ייצור אחד בשבילכם. מזינים ביטוי סיסמה או משאירים את השדה ריק כשמוצגת בקשה לעשות זאת.

יוצרים אסימון גישה לחשבון שירות של 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"}

מעתיקים את הערך של access_token מהפלט שהתקבל, בלי המירכאות.
מורידים את קובץ האימג' באמצעות 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.