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

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

  • צמתים של מערכת הפעלה שמותאמת לקונטיינרים ו-Ubuntu‏ (Linux):
    • צמתים של Linux שמריצים GKE בגרסה 1.32 או בגרסאות קודמות, עם קובצי אימג' של צמתים של containerd, משתמשים ב-containerd בגרסה 1.7 או בגרסאות קודמות.
    • צמתים של Linux שמריצים GKE 1.33 משתמשים ב-containerd 2.0.
  • צמתים של Windows Server:
    • צמתים של שרת Windows שמריצים 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.2, עם גרסת GKE שעדיין לא הוכרזה: registry.auths, ‏ registry.configs, ‏ registry.mirrors. עם זאת, registry.configs.tls כבר הוסר ב-containerd 2.0.

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

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

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

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

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

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

‫GKE pause automatic upgrades to 1.33 for clusters with Linux nodes when it detects that the cluster uses the deprecated features. עם זאת, אם הצמתים באשכול משתמשים בתכונות האלה, מומלץ ליצור החרגה של תחזוקה כדי למנוע שדרוגים של האשכול. החרגת התחזוקה מבטיחה שהשדרוג של האשכול לא יתבצע אם 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

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

פועלים לפי ההוראות כדי לראות תובנות והמלצות. אפשר לקבל תובנות באמצעות מסוף Google Cloud . אפשר גם להשתמש ב-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 ולעדכן את האפליקציות האלה כדי להשתמש ב-v1 API.

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

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

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

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

כשצופים בתובנות במסוף Google Cloud , רואים את החלונית שבסרגל הצד העברת עומסי העבודה מ-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 בהמלצה של Google Cloud המסוף. הפונקציה מחזירה עומסי עבודה שלא מנוהלים על ידי 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 logs the last time the CRI v1alpha2 API was called.

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

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

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

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

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

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

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

כדי לעדכן את האפליקציה, צריך להסיר את המקום שבו האפליקציה מייבאת את ספריית הלקוח 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.2, עם גרסת GKE שעוד לא הוכרזה. עם זאת, registry.configs.tls כבר הוסר ב-containerd 2.0.

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

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

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

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

כשצופים בתובנות במסוף Google Cloud , רואים את החלונית בסרגל הצד 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, אתם צריכים להעביר את עומסי העבודה האלה כדי לגשת למאגרי רישום פרטיים עם אישורים של רשות אישורים פרטית.

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

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

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

פנייה לתמיכה

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