העברת צמתים ל-containerd 2

אשכולות Google Kubernetes Engine‏ (GKE) משתמשים בקובצי אימג' של צמתים עם כל צמתי העובדים שמריצים גרסה 1.24 ואילך. צמתי העובדים משתמשים בגרסה ספציפית של containerd, בהתאם למערכת ההפעלה ולגרסה המשנית של GKE:

  • צמתים של מערכת הפעלה שמותאמת לקונטיינרים ושל Ubuntu‏ (Linux):
    • צמתים של Linux שמריצים GKE בגרסה 1.32 או בגרסאות קודמות, עם קובצי אימג' של צמתים של containerd, משתמשים ב-containerd בגרסה 1.7 או בגרסאות קודמות.
    • צמתים של Linux שמריצים GKE 1.33 משתמשים ב-containerd 2.0.
  • צמתים של Windows Server:
    • צמתים של Windows Server שמריצים GKE בגרסה 1.34 או בגרסה מוקדמת יותר, עם תמונות צמתים של containerd, משתמשים ב-containerd בגרסה 1.7 או בגרסאות מוקדמות יותר.
    • צמתים של Windows Server שמריצים GKE 1.35 משתמשים ב-containerd 2.0.

כשמשדרגים צמתים של GKE לגרסת המשנה המתאימה של GKE, הצמתים עוברים משימוש ב-containerd 1.7 לגרסה הראשית החדשה, containerd 2.0. אי אפשר לשנות את גרסת containerd שבה נעשה שימוש בגרסת GKE.

אם אתם יודעים שעומסי העבודה שלכם פועלים כצפוי ב-containerd 2, אתם יכולים לדלג על קריאת הדף הזה.

איך GKE עובר ל-containerd 2

הציר הזמן הבא מציג את המעבר של אשכולות קיימים ב-GKE לשימוש ב-containerd 2:

  • בצמתים של Linux עם גרסה 1.32 ובצמתים של Windows Server עם גרסה 1.34,‏ GKE משתמש ב-containerd 1.7. ב-containerd 1.7 הוצאו משימוש גם קובצי אימג' של Docker Schema 1 וגם Container Runtime Interface ‏ (CRI) API v1alpha2. מידע על תכונות נוספות שהוצאו משימוש בגרסאות קודמות זמין במאמר בנושא מאפייני הגדרה שהוצאו משימוש.
  • בצמתים של Linux עם גרסה 1.33 ובצמתים של Windows Server עם גרסה 1.35,‏ GKE משתמש ב-containerd 2.0, שבו הוסר התמיכה בקובצי אימג' של Docker Schema 1 וב-CRI v1alpha2 API.
  • המאפיינים הבאים של containerd config בתוסף CRI הוצאו משימוש ויוסרו ב-containerd 2.4 ואילך, בגרסת GKE שעדיין לא הוכרזה: registry.auths, ‏ registry.configs, ‏ registry.mirrors. עם זאת, registry.configs.tls כבר הוסר ב-containerd 2.0.

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

ההשפעה של המעבר ל-containerd 2

בקטע הבא מוסבר איך המעבר ל-containerd 2 ישפיע על השימוש שלכם.

השהיית השדרוגים האוטומטיים

מערכת GKE משהה את השדרוגים האוטומטיים באופנים הבאים, בהתאם לגרסה המשנית הנוכחית של האשכול ולסוג הצמתים באשכול (צמתים של Linux או צמתים של Windows Server).

השהיית השדרוגים האוטומטיים של צמתי Linux

‫GKE משהה שדרוגים אוטומטיים לגרסה 1.33 באשכולות עם צמתי Linux, כשהמערכת מזהה שהאשכול משתמש בתכונות שהוצאו משימוש. עם זאת, אם הצמתים באשכול משתמשים בתכונות האלה, מומלץ ליצור החרגה של תחזוקה כדי למנוע שדרוגים של האשכול. החרגת התחזוקה מבטיחה שהשדרוג של האשכול לא יתבצע אם GKE לא יזהה שימוש.

אחרי שתעברו לשימוש בתכונות האלה, GKE ימשיך לבצע שדרוגים משניים אוטומטיים לגרסה 1.33 אם התנאים הבאים מתקיימים:

  • ‫GKE לא זיהה שימוש בתכונות שהוצאו משימוש במשך 14 ימים, או 3 ימים במקרה של מאפייני CRI registry.configs שהוצאו משימוש.
  • ‫1.33 הוא יעד שדרוג אוטומטי לאשכול.
  • אין גורמים אחרים שמונעים את ההצגה. מידע נוסף זמין במאמר התזמון של שדרוגים אוטומטיים.

אפשר גם לשדרג את האשכול באופן ידני.

השהיית שדרוגים אוטומטיים של צמתי Windows Server

‫GKE מפסיק את השדרוגים האוטומטיים לגרסה 1.35 לכל האשכולות עם צמתים של Windows Server, בלי קשר לשאלה אם האשכול משתמש בתכונות שהוצאו משימוש. מערכת GKE לא יכולה לזהות אם צמתי Windows Server משתמשים בתכונות שהוצאו משימוש.

כדי לשדרג את האשכול עם צמתי Windows Server לגרסה 1.35, קודם צריך לפעול לפי ההוראות למעבר מתכונות שהוצאו משימוש. אחרי שמבצעים את ההוראות האלה, אפשר לשדרג את האשכול באופן ידני לגרסה 1.35.

סוף התמיכה וההשפעה של אי-הכנה להעברה

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

אם לא תבצעו מיגרציה מהתכונות האלה, כשהגרסה 1.32 (לצמתים של Linux) או 1.34 (לצמתים של Windows Server) תגיע לסוף תקופת התמיכה, והצמתים של האשכול ישודרגו אוטומטית לגרסה 1.33 או 1.35, יכול להיות שתיתקלו בבעיות הבאות באשכולות:

  • עומסי עבודה שמשתמשים בקובצי אימג' של Docker Schema 1 נכשלים.
  • אפליקציות ששולחות קריאה ל-API של CRI v1alpha2 נכשלות בשליחת קריאה ל-API.

זיהוי אשכולות מושפעים

‫GKE מנטר את האשכולות שלכם ומשתמש בשירות ההמלצות כדי לספק הדרכה באמצעות תובנות והמלצות לזיהוי צמתים של Linux באשכול שמשתמשים בתכונות האלה שהוצאו משימוש. מערכת GKE לא מזהה שימוש בצמתים של Windows Server.

דרישות לגבי גרסה

קלאסטרים מקבלים את התובנות וההמלצות האלה אם פועלות בהם הגרסאות הבאות או גרסאות מאוחרות יותר:

  • 1.28.15-gke.1159000
  • 1.29.9-gke.1541000
  • 1.30.5-gke.1355000
  • 1.31.1-gke.1621000

קבלת תובנות והמלצות

פועלים לפי ההוראות כדי לראות תובנות והמלצות. אפשר לקבל תובנות באמצעות מסוף Cloud de Confiance . אפשר גם להשתמש ב-Google Cloud CLI או ב-Recommender API, ולסנן לפי סוגי המשנה הבאים:

  • DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: קובצי אימג' של Docker Schema 1
  • ‫DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: CRI v1alpha2 API
  • ‫DEPRECATION_CONTAINERD_V2_CONFIG_REGISTRY_CONFIGS: מאפייני CRI שהוצאו משימוש, כולל registry.configs.auth ו-registry.configs.tlsregistry.configs

מעבר מתכונות שהוצאו משימוש

כדאי לעיין בתוכן הבא כדי להבין איך לבצע מיגרציה מתכונות שהוצאו משימוש ב-containerd 2.

העברה מקובצי אימג' של Docker Schema 1

מזהים עומסי עבודה (workload) באמצעות תמונות שצריך להעביר, ואז מעבירים את עומסי העבודה האלה.

תמונה שסופקה על ידי Google שהושפעה מהבעיה הזו היא gcr.io/google-containers/startup-script.

  • ‫gcr.io/google-containers/startup-script:v1: משתמש בפורמט Schema 1 שיצא משימוש, ולא ניתן לשלוף אותו ב-GKE 1.33 ואילך עבור צמתי Linux.
  • ‫gcr.io/google-containers/startup-script:v2: משתמש בפורמט Schema 2 הנתמך ואפשר לשלוף אותו בהצלחה.

אם אתם משתמשים ב-gcr.io/google-containers/startup-script:v1 באחת מעומסי העבודה שלכם (כמו DaemonSets או Deployments), אתם צריכים לעדכן את ההפניה לתמונה ל-gcr.io/google-containers/startup-script:v2.

חיפוש תמונות להעברה

אתם יכולים להשתמש בכלים שונים כדי למצוא תמונות שצריך להעביר.

שימוש בתובנות ובהמלצות או ב-Cloud Logging

כפי שמוסבר בקטע זיהוי אשכולות מושפעים, אם האשכול שלכם מריץ גרסה מינימלית או גרסה מאוחרת יותר, תוכלו להשתמש בתובנות ובהמלצות כדי למצוא אשכולות עם צמתי Linux שמשתמשים בתמונות של Docker Schema 1. בנוסף, אפשר להשתמש בשאילתה הבאה ב-Cloud Logging כדי לבדוק את היומנים של containerd ולמצוא תמונות Docker Schema 1 באשכול:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

אם חלפו יותר מ-30 ימים מאז שהתמונה נמשכה, יכול להיות שלא תראו יומנים של התמונה.

שימוש בפקודה ctr ישירות בצומת

כדי לשלוח שאילתה לצומת ספציפי כדי להחזיר את כל התמונות שלא נמחקו ונמשכו כסכימה 1, מריצים את הפקודה הבאה בצומת:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

הפקודה הזו יכולה להיות שימושית אם, לדוגמה, אתם פותרים בעיות בצומת ספציפי ולא רואים רשומות ביומן ב-Cloud Logging כי עברו יותר מ-30 יום מאז שהתמונה נמשכה.

שימוש בכלי הקוד הפתוח crane

אפשר גם להשתמש בכלים בקוד פתוח כמו crane כדי לבדוק תמונות.

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

crane manifest $tagged_image | jq .schemaVersion

הכנת עומסי עבודה

כדי להכין עומסי עבודה שמריצים תמונות של Docker Schema 1, צריך להעביר את עומסי העבודה האלה לתמונות של Docker Schema 2 או לתמונות של Open Container Initiative‏ (OCI). אפשר לשקול את האפשרויות הבאות להעברה:

  • חיפוש תמונה חלופית: יכול להיות שאפשר למצוא תמונה שזמינה לציבור, שסופקה על ידי ספק או שהיא בקוד פתוח.
  • המרת התמונה הקיימת: אם לא מוצאים תמונה חלופית, אפשר להמיר תמונות קיימות של Docker Schema 1 לתמונות OCI באמצעות השלבים הבאים:
    1. מושכים את קובץ האימג' של Docker אל containerd, שממיר אותו באופן אוטומטי לקובץ אימג' של OCI.
    2. שולחים את תמונת ה-OCI החדשה למאגר.

מעבר מ-CRI v1alpha2 API

ממשק CRI v1alpha2 API הוסר ב-Kubernetes 1.26. צריך לזהות עומסי עבודה שיש להם גישה לשקע containerd ולעדכן את האפליקציות האלה כדי להשתמש ב-API בגרסה 1.

זיהוי עומסי עבודה שעשויים להיות מושפעים

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

שימוש בתובנות ובהמלצות

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

כשצופים בתובנות במסוף Cloud de Confiance , רואים את החלונית שבסרגל הצד Migrate your workloads off deprecated CRI v1alpha2 API. בטבלה Workloads to Verify שבחלונית הזו מפורטים עומסי עבודה שעשויים להיות מושפעים. הרשימה הזו כוללת עומסי עבודה שלא מנוהלים על ידי GKE, שיש להם נפחי hostPath שמכילים את נתיב שקע containerd (לדוגמה, /var/run/containerd/containerd.sock או /run/containerd/containerd.sock).

חשוב להבין את הנקודות הבאות:

  • רשימת עומסי העבודה לאימות עשויה להכיל תוצאות חיוביות כוזבות. השתמשו בו רק לצורך חקירה. אם עומס עבודה מופיע ברשימה הזו, זה לא אומר בהכרח שהוא משתמש ב-API שהוצא משימוש. אם יש תוצאה חיובית שגויה, השדרוגים האוטומטיים לא יושהו. ההשהיה מבוססת רק על השימוש שנצפה בפועל ב-API שהוצא משימוש.
  • יכול להיות שהרשימה הזו ריקה או חלקית. רשימה ריקה או לא מלאה יכולה להופיע אם עומסי העבודה שמשתמשים ב-API שהוצא משימוש היו לטווח קצר ולא פעלו כש-GKE ביצע את הבדיקה התקופתית שלו. ההמלצה עצמה מצביעה על כך שזוהה שימוש ב-API‏ CRI v1alpha2 לפחות בצומת אחד באשכול. השדרוגים האוטומטיים יחזרו לפעול אחרי 14 ימים, אם לא יזוהה שימוש ב-API שהוצא משימוש.

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

בדיקה של עומסי עבודה של צד שלישי שהושפעו

אם פרסתם תוכנה של צד שלישי באשכולות, צריך לוודא שעומסי העבודה האלה לא משתמשים ב-API של CRI v1alpha2. יכול להיות שתצטרכו לפנות לספקים המתאימים כדי לוודא אילו גרסאות של התוכנה שלהם תואמות.

שימוש ב-kubectl

הפקודה הבאה עוזרת לכם למצוא עומסי עבודה שאולי הושפעו מהתקלה. הפקודה מחפשת עומסי עבודה שיש להם גישה לשקע של containerd. ההמלצה מבוססת על אותה לוגיקה שמשמשת ליצירת הטבלה Workloads to Verify במסוף Cloud de Confiance . הפונקציה מחזירה עומסי עבודה שלא מנוהלים על ידי GKE שיש להם נפחי אחסון של hostPath, כולל הנתיב של השקע. בדומה להמלצה, יכול להיות שהשאילתה הזו תחזיר תוצאות חיוביות כוזבות או שלא תזהה עומסי עבודה לזמן קצר.

מריצים את הפקודה הבאה:

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/var", "/var/","/var/run", "/var/run/",
    "/var/run/containerd", "/var/run/containerd/", "/var/run/containerd/containerd.sock",
    "/run", "/run/", "/run/containerd", "/run/containerd/",
    "/run/containerd/containerd.sock"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'
שימוש במעקב eBPF כדי לזהות את המתקשרים ל-API

כדי לזהות בצורה מדויקת יותר אילו עומסי עבודה שפועלים בצמתי Linux מבצעים קריאה ל-CRI v1alpha2 API, אפשר לפרוס שני DaemonSets ייעודיים:

  • בקטעי היומן containerd-socket-tracer מתועד כל תהליך שפותח חיבור לשקע containerd, יחד עם הפרטים של ה-Pod והמאגר.
  • ‫cri-v1alpha2-api-deprecation-reporter מתעד את הפעם האחרונה שבוצעה קריאה ל-CRI v1alpha2 API.

הכלים האלה משתמשים ב-Extended Berkeley Packet Filter‏ (eBPF) כדי לעקוב אחרי חיבורים לשקע containerd ולבצע קורלציה בין החיבורים לבין קריאות בפועל ל-API שהוצא משימוש.

אי אפשר לפרוס את ה-DaemonSets האלה בצמתי Windows Server.

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

הוראות מפורטות על פריסה ושימוש בכלים האלה, ועל פירוש היומנים שלהם, מופיעות במאמר בנושא מעקב אחר חיבורי Socket של containerd.

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

אחרי שמזהים עומס עבודה שמשתמש ב-CRI API v1alpha2, באמצעות השיטות שלמעלה או על ידי בדיקת בסיס הקוד, צריך לעדכן את הקוד שלו כדי להשתמש ב-API v1.

עדכון קוד האפליקציה

כדי לעדכן את האפליקציה, צריך להסיר את המקום שבו האפליקציה מייבאת את ספריית הלקוח k8s.io/cri-api/pkg/apis/runtime/v1alpha2 ולשנות את הקוד כך שישתמש בגרסה v1 של ה-API. בשלב הזה צריך לשנות את נתיב הייבוא ולעדכן את האופן שבו הקוד קורא ל-API.

לדוגמה, אפשר לראות את קוד ה-golang הבא, שמשתמש בספרייה שהוצאה משימוש:

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

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

כדי לחפש ולעדכן את קוד האפליקציה:

  1. כדי לזהות אפליקציות בעייתיות של golang, מריצים את הפקודה הבאה כדי לחפש את נתיב הייבוא v1alpha2:

      grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

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

    לדוגמה, מחליפים את קוד האפליקציה הבא:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

  2. מעדכנים את הקוד לשימוש בגרסה v1:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"

העברה ממאפייני הגדרה שהוצאו משימוש ב-containerd

המאפיינים registry.auths,‏ registry.configs ו-registry.mirrors containerd config בתוסף CRI הוצאו משימוש ויוסרו ב-containerd 2.4 ואילך, עם גרסת GKE שעדיין לא הוכרזה. עם זאת, registry.configs.tls כבר הוסר ב-containerd 2.0.

זיהוי עומסי עבודה

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

שימוש בתובנות ובהמלצות

כגישה ראשונית, אפשר להשתמש בתובנות ובהמלצות כדי למצוא אשכולות עם צמתי Linux שמשתמשים במאפייני ההגדרה של containerd שהוצאו משימוש. לשם כך נדרשת גרסת GKE מינימלית. מידע נוסף על הגישה הזו זמין במאמר זיהוי אשכולות מושפעים.

כשצופים בתובנות במסוף Cloud de Confiance , אפשר לראות את החלונית בסרגל הצד Migrate your containerd configuration off deprecated CRI registry auths או Migrate your containerd configuration off deprecated CRI registry mirrors. כדי למצוא עומסי עבודה שאולי יש להם גישה להגדרות של containerd, צריך לבדוק את הקטע Workloads to Verify (עומסי עבודה לאימות).

שימוש ב-kubectl

לחלופין, אפשר להשתמש ב-kubectl כדי לזהות עומסי עבודה.

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

  • עומסי עבודה שמכילים נפח hostPath שכולל את ההגדרה של containerd
  • עומסי עבודה שיש להם מאגר עם גישת הרשאה (spec.containers.securityContext.privileged: true) ומשתמשים במרחב השמות של מזהה התהליך (PID) של המארח (spec.hostPID: true)

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

מריצים את הפקודה הבאה כדי לבדוק את DaemonSets:

kubectl get daemonsets --all-namespaces -o json | \
jq -r '
  [
    "/", "/etc", "/etc/",
    "/etc/containerd", "/etc/containerd/",
    "/etc/containerd/config.toml"
  ] as $host_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
    and
    (
      (any(.spec.template.spec.volumes[]?.hostPath.path; IN($host_paths[])))
      or
      (
        .spec.template.spec.hostPID == true and
        any(.spec.template.spec.containers[]; .securityContext?.privileged == true)
      )
    )
  ) |
  .metadata.namespace + "/" + .metadata.name
'

מעבר מנכסי auths או configs.auth של CRI

אם עומסי העבודה משתמשים במאפיינים auths או configs.auth בקובץ ההגדרות של containerd כדי לבצע אימות לרישום פרטי לצורך משיכת תמונות של קונטיינרים, צריך להעביר את עומסי העבודה שמשתמשים בתמונות האלה לשדה imagePullSecrets. מידע נוסף זמין במאמר שליפת תמונה ממאגר פרטי.

כדי לזהות ולהעביר עומסי עבודה שמשתמשים במאפיינים auths או configs.auth שהוצאו משימוש, כדאי לעיין בהוראות הבאות.

איתור פרטי האימות של המרשם

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

  • מתחברים לצומת GKE ובודקים את הקטעים auths ו-configs.auth בקובץ /etc/containerd/config.toml.
  • כדי לגלות איזה פרטי אימות נכללים, מאתרים את עומס העבודה שמשנה את קובץ התצורה של containerd באמצעות השיטות שמתוארות למעלה לזיהוי עומסי עבודה. מערכת GKE לא משתמשת בהגדרות האלה לעומסי העבודה שלה.

אם משתמשים במאפיין registry.configs.auth, פרטי האימות יכולים להיראות כך:

  [plugins."io.containerd.grpc.v1.cri".registry.configs."$REGISTRY_DOMAIN".auth]
    username = "example-user"
    password = "example-password"

צריך לאסוף את פרטי האימות האלה לכל דומיין רישום שצוין בהגדרה.

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

  2. כדי לזהות אילו עומסי עבודה צריך להעביר לשדה imagePullSecrets, מריצים את הפקודה הבאה:

    kubectl get pods -A -o json |
jq -r ".items[] |
  select(.spec.containers[] |
        .image | startswith(\"$REGISTRY_DOMAIN\")) |
  .metadata.namespace + \"/\" + .metadata.name"

    צריך ליצור Secret לכל מרחב שמות שבו נעשה שימוש בעומסי עבודה עם תמונות מדומיין הרישום הזה.

  3. מעדכנים את עומסי העבודה כך שישתמשו בשדה imagePullSecrets עם הסודות שיצרתם בשלב הקודם.

    לחלופין, אם אתם צריכים להעביר מספר גדול של עומסי עבודה, אתם יכולים להטמיע MutatingAdmissionWebhook כדי להוסיף את השדה imagePullSecrets.

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

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

בדיקה באמצעות מאגר צמתים חדש והעברת עומסי עבודה למאגר הצמתים החדש

כדי לצמצם את הסיכון לגרימת בעיות בעומסי העבודה, צריך לבצע את הפעולות הבאות:

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

העברה ממאפיין configs.tls של רישום CRI

אם עומסי העבודה שלכם משתמשים במאפיין registry.configs.tls, אתם צריכים להעביר את עומסי העבודה האלה כדי לגשת למאגרי רישום פרטיים עם אישורי CA פרטיים.

פועלים לפי ההוראות למעבר מ-DaemonSets של הגדרות. התהליך הזה מתבצע באמצעות השלבים הבאים:

  1. צריך לעדכן את עומסי העבודה שמשנים את ההגדרה של containerd כדי להפסיק להגדיר את פרטי ה-TLS.
  2. מאחסנים את האישורים ב-Secret Manager.
  3. יוצרים קובץ תצורת זמן ריצה שמפנה אל האישורים.
  4. יוצרים מאגר צמתים חדש ובודקים שעומסי העבודה שמשתמשים בתמונות שמארח רשם פרטי פועלים כמצופה.
  5. אפשר להחיל את התצורה על אשכול חדש ולהתחיל להריץ את עומסי העבודה באשכול הזה, או להחיל את התצורה על האשכול הקיים. החלת ההגדרה על האשכול הקיים עלולה לשבש עומסי עבודה קיימים אחרים. מידע נוסף על שתי הגישות האלה זמין במאמר בנושא יצירת קובץ הגדרות של זמן ריצה.

אחרי ההעברה, חשוב להפסיק להחיל שינויים בשדה registry.configs, אחרת עלולות להיות בעיות ב-containerd.

פנייה לתמיכה

אם עדיין לא הצלחתם לזהות את המקור של הקריאות ל-API שיצא משימוש, וההמלצות עדיין פעילות, כדאי לנסות את השלב הבא: