שימוש במאגר תמונות משוכפל לקובצי אימג' של קונטיינרים

בדף הזה מוסבר איך ליצור ולשדרג אשכולות באמצעות תמונות שנמשכות ממאגר תמונות משוכפל, ולא ממאגר ציבורי כמו gcr.io. אפשר להפעיל או להשבית את התכונה הזו בכל שלב במחזור החיים של האשכול.

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

שיקוף של רשם הוא עותק מקומי של רשם ציבורי שמעתיק או משקף את מבנה הקבצים של הרשם הציבורי. לדוגמה, נניח שהנתיב למאגר המקומי שלכם הוא 172.18.0.20:5000. כש-containerd מקבל בקשה לשליפת תמונה כמו gcr.io/kubernetes-e2e-test-images/nautilus:1.0, הוא מנסה לשלוף את התמונה הזו, לא מ-gcr.io, אלא מהמרשם המקומי בנתיב הבא: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0.containerd אם התמונה לא נמצאת בנתיב הזה של הרישום המקומי, היא נמשכת באופן אוטומטי מהרישום הציבורי gcr.io.

היתרונות של שימוש במאגר תמונות (mirror) של רישום:

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

הערה: משיכות תמונה עבור gcr.io/anthos-baremetal-release/kindest/node לא חוזרות ל-gcr.io. התמונות האלה נשלפות רק משיקוף המאגר. אם שיקוף הרישום לא פועל, הפעולה pull נכשלת.

לפני שמתחילים

• צריך להגדיר שרת Artifact Registry ברשת.
• אם שרת הרישום מפעיל אישור TLS פרטי, צריך שיהיה לכם קובץ של רשות האישורים (CA).
• אם שרת המרשם דורש אימות, אתם צריכים להזין את פרטי הכניסה המתאימים או להשתמש בקובץ תצורה של Docker.
• אם אתם משתמשים במאגר Red Hat Quay, יכול להיות שתצטרכו ליצור את מבנה הספריות של המאגר המקומי באופן ידני.
• כדי להשתמש ב-registry mirror, צריך להגדיר את זמן הריצה של הקונטיינר ל-containerd.

• חשוב לוודא שיש לכם מספיק מקום בדיסק בתחנת העבודה של האדמין להעלאת תמונות. הפקודה להעלאת תמונות, bmctl push images, מבצעת דחיסה חוזרת של קובץ חבילת התמונות שהורד, ואז מחלצת את כל קובצי התמונות באופן מקומי לפני ההעלאה שלהם. כדי להעלות את התמונות, צריך לפחות פי שלושה מקום בדיסק מהגודל של קובץ חבילת התמונות שהורדתם.

  לדוגמה, קובץ bmpackages_1.33.0-gke.799.tar.xz דחוס תופס נפח של כ-12 GB בדיסק, ולכן צריך שיהיה לכם נפח פנוי של 36 GB לפחות בדיסק לפני שמורידים את הקובץ.

  אם מבצעים שדרוג דילוג (שדרוג של שתי גרסאות משניות בפעולה אחת), צריך להעלות תמונות מקובצי חבילת תמונות גם לגרסת היעד (N+2) וגם לגרסת הביניים (N+1). על סמך הדוגמה הזו, נדרש שטח אחסון פנוי של כ-72 GB כדי להעלות את התמונה. מידע נוסף על גרסת הביניים זמין במאמר דרישה נוספת למאגרי תמונות של רישום.

הורדת כל התמונות הנדרשות ל-Google Distributed Cloud

מורידים את הגרסה האחרונה של כלי bmctl ואת חבילת התמונות מהדף הורדות.

הערה: לפני הגרסה המשנית 1.29, פורמט קובץ ה-tar של חבילת התמונות תואם ל-Docker. בגרסה משנית 1.29 ואילך, קובץ ה-tar של חבילת התמונות הוא בפורמט תמונה של Open Container Initiative‏ (OCI), שלא תואם ל-Docker.

העלאת תמונות של קונטיינרים לשרת הרישום

כשמשתמשים ב-bmctl push images כדי להעלות קובצי אימג' של קונטיינרים לשרת המאגר, bmctl מבצע את השלבים הבאים לפי הסדר:

1. מחלצים חבילת תמונות שהורדה מקובץ tar דחוס, כמו bmpackages_1.34.100-gke.93.tar.xz אל bmpackages_1.34.100-gke.93.tar.

2. מחלקים את כל התמונות מקובץ ה-tar שחולץ לספרייה בשם bmpackages_1.34.100-gke.93.

3. דחיפה של כל קובץ תמונה למאגר הפרטי שצוין.

   ‫bmctl משתמש בערכים --username ו---password לאימות בסיסי כדי לדחוף את התמונות למאגר הפרטי שלכם.

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

אימות מול הרשם ושיתוף אישור ה-TLS

הפקודה הבאה כוללת את הדגלים --username ו---password לאימות משתמש בשרת הרישום. הפקודה כוללת גם את הדגל --cacert להעברת אישור ה-TLS של רשות האישורים (CA), שמשמש לתקשורת מאובטחת עם שרת הרישום, כולל העלאה והורדה של תמונות. הדגלים האלה מספקים אבטחה בסיסית לשרת הרישום.

אם שרת הרישום שלכם דורש אימות ואתם לא משתמשים בדגלים --username ו---password, תתבקשו להזין פרטי כניסה כשאתם מריצים את הפקודה bmctl push images. אפשר להקליד את הסיסמה או לבחור את קובץ התצורה של Docker שמכיל את פרטי הכניסה.

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

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --username USERNAME \
    --password PASSWORD \
    --cacert CERT_PATH

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

• ‫IMAGES_TAR_FILE_PATH: הנתיב של קובץ ה-tar של חבילת התמונות שהורדתם, למשל bmpackages_1.34.100-gke.93.tar.xz.

• ‫REGISTRY_IP:PORT: כתובת ה-IP והיציאה של שרת הרישום הפרטי.

• ‫USERNAME: שם המשתמש של משתמש עם הרשאות גישה להעלאת תמונות לשרת הרישום.

• ‫PASSWORD: הסיסמה של המשתמש לאימות בשרת הרישום.

• ‫CERT_PATH: הנתיב לקובץ האישור של הרשות שמנפיקה את האישורים (CA), אם שרת המרשם משתמש באישור TLS פרטי.

לדוגמה:

bmctl push images \
    --source bmpackages_1.34.100-gke.93.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --username alex --password pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

העלאת תמונות ללא אימות משתמש או אישורים

אם שרת הרישום לא דורש פרטי כניסה, כמו שם משתמש וסיסמה, צריך לציין --need-credential=false בפקודה bmctl. אם שרת הרישום שלכם משתמש באישור TLS ציבורי, אתם לא צריכים להשתמש בדגל --cacert. סוג הפקודה הזה להעלאה מתאים במיוחד לסביבות בדיקה, שבהן האבטחה פחות חשובה מאשר בסביבת ייצור.

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

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --need-credential=false

לדוגמה:

bmctl push images \
    --source bmpackages_1.34.100-gke.93.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --need-credential=false.

שינוי מספר השרשורים

העלאת התמונות יכולה לקחת זמן רב בגלל הגודל והכמות של תמונות המאגר בקובץ ה-tar של חבילת התמונות. הגדלת מספר השרשורים המקבילים גורמת לשגרה לפעול מהר יותר. אפשר להשתמש בדגל --threads כדי לשנות את מספר השרשורים המקבילים שבהם משתמשת bmctl push images.

כברירת מחדל, תהליך העלאת התמונות משתמש ב-4 שרשורים. אם העלאת התמונות נמשכת זמן רב מדי, צריך להגדיל את הערך הזה. לשם השוואה, בסביבת בדיקה של Google, העלאת תמונות מתחנת עבודה עם 4 מעבדים אורכת כ-10 דקות עם 8 תהליכים מקבילים.

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --cacert CERT_PATH \
    --threads NUM_THREADS

מחליפים את NUM_THREADS במספר השרשורים המקבילים שמשמשים לעיבוד של העלאות התמונות. כברירת מחדל, bmctl push images משתמש בארבעה תהליכונים מקבילים.

הפקודה הבאה מגדילה את מספר השרשורים להעלאה מ-4 ל-8 כדי לקצר את זמן ההעלאה:

bmctl push images \
    --source bmpackages_1.34.100-gke.93.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem \
    --threads 8

העלאה דרך שרת proxy

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

HTTPS_PROXY=http://PROXY_IP:PORT bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT \
    --cacert=CERT_PATH

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

• ‫PROXY_IP:PORT: כתובת ה-IP והיציאה של השרת הפרוקסי.

• ‫IMAGES_TAR_FILE_PATH: הנתיב של קובץ ה-tar של חבילת התמונות שהורדתם, למשל bmpackages_1.34.100-gke.93.tar.xz.

• ‫REGISTRY_IP:PORT: כתובת ה-IP והיציאה של שרת הרישום הפרטי.

• ‫CERT_PATH: הנתיב לקובץ האישור של הרשות שמנפיקה את האישורים (CA), אם שרת המרשם משתמש באישור TLS פרטי.

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

הפקודה הבאה מעלה תמונות דרך שרת proxy:

HTTPS_PROXY=http://10.128.0.136:3128 bmctl push images \
    --source bmpackages_1.34.100-gke.93.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem

שימוש במרחב שמות משלכם עם bmctl push images

אם אתם רוצים להשתמש במרחב שמות משלכם בשרת המרשם במקום במרחב השמות הבסיסי, containerd יכול למשוך נתונים ממרחב השמות הזה אם תספקו את נקודת קצה ל-API עבור המרשם הפרטי בשדה registryMirrors.endpoint של קובץ התצורה של האשכול. נקודת הקצה בדרך כלל בפורמט <REGISTRY_IP:PORT>/v2/<NAMESPACE>. פרטים ספציפיים מופיעים במדריך למשתמש של הרישום הפרטי. מידע נוסף זמין במאמר מידע על השימוש ב-v2 בנקודת הקצה של המרשם.

bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT/NAMESPACE \
    --cacert=CERT_PATH

מחליפים את NAMESPACE בשם של מרחב השמות בשרת הרישום שאליו רוצים להעלות תמונות.

לדוגמה, אם יש לכם גישה רק אל 198.51.20.1:5000/test-namespace/, אתם יכולים להשתמש בפקודה כמו זו שבהמשך כדי להעלות את כל התמונות במרחב השמות test-namespace:

bmctl push images \
    --source=./bmpackages_1.34.100-gke.93.tar.xz \
    --private-registry=198.51.20.1:5000/test-namespace \
    --username=alex \
    --password=pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

אחר כך, בקובץ התצורה של האשכול, אפשר להוסיף את השורה הבאה כדי ש-containerd ימשוך נתונים ממרחב השמות test-namespace:

registryMirrors:
  - endpoint: https://198.51.20.1:5000/v2/test-namespace

למידע נוסף על הפקודה bmctl push images, אפשר לעיין בחומר העזר בנושא הפקודה bmctl.

הגדרת אשכולות לשימוש ברפליקציה של מאגר

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

שימוש בקטע הכותרת בקובץ התצורה של האשכול

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

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

בקובץ התצורה לדוגמה של האשכול הבא מצוין שצריך לשלוף תמונות ממראה מקומית של מאגר, שנקודת הקצה שלה היא https://198.51.20.1:5000. חלק מהשדות שמופיעים בתחילת קובץ התצורה הזה מתוארים בקטעים הבאים.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://198.51.20.1:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

שימוש בקטע nodeConfig.registryMirrors במפרט האשכול

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

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

1. מקבלים את הקטע nodeConfig.registryMirror, כולל הפניות לסודות, מ-nodeConfig.registryMirrors של משאב אשכול האדמין:

   kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE \
       --kubeconfig ADMIN_KUBECONFIG \
       -o yaml
   

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

   • ‫CLUSTER_NAME: השם של האדמין או של האשכול ההיברידי שמנהל את אשכול המשתמשים.

   • ‫CLUSTER_NAMESPACE: שם מרחב השמות של האשכול המנהל.

   • ‫ADMIN_KUBECONFIG: הנתיב של קובץ ה-kubeconfig של האשכול המנהל.

2. מוסיפים את ההגדרה nodeConfig.registryMirrors מאשכול האדמין לקובץ התצורה של אשכול המשתמשים.

   הקטע registryMirrors בקובץ התצורה של אשכול המשתמשים צריך להיראות כמו בדוגמה הבאה:

   ---
   gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
   sshPrivateKeyPath: /root/ssh-key/id_rsa
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user1
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user1
     namespace: cluster-user1
   spec:
     nodeConfig:
       containerRuntime: containerd
       registryMirrors:
       -   caCertSecretRef:
           name: the-secret-created-for-the-admin-cluster
           namespace: anthos-creds
         endpoint: https://172.18.0.20:5000
         hosts:
           -   somehost.io
           -   otherhost.io
         pullCredentialSecretRef:
           name: the-image-pull-creds-created-for-the-admin-cluster
           namespace: anthos-creds
   ...
   

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

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

hosts שדה

‫containerd בודק את הקטע hosts בקובץ התצורה של האשכול כדי לגלות אילו מארחים משוכפלים באופן מקומי. המארחים האלה ממופים לנקודת הקצה של שיקוף המאגר שצוינה בקובץ התצורה של האשכול (registryMirror.endpoint). בקובץ התצורה לדוגמה מהקטע הקודם, המאגרים הציבוריים שמופיעים בקטע hosts הם somehost.io ו-otherhost.io. מאחר שהרישומים הציבוריים האלה מופיעים בקטע hosts, ‏ containerd בודק קודם את העותק של הרישום הפרטי כשהוא נתקל בבקשות משיכה של תמונות מ-somehost.io או מ-otherhost.io.

לדוגמה, נניח ש-containerd מקבל פקודת משיכה ל-somehost.io/kubernetes-e2e-test-images/nautilus:1.0. מכיוון ש-somehost.io מופיע כאחד מהמארחים בקטע hosts של קובץ ההגדרות של האשכול, containerd מחפש את התמונה kubernetes-e2e-test-images/nautilus:1.0 במאגר המקומי. אם somehost.io לא מופיע בקטע hosts, סימן שלא ידוע ל-containerd שקיים שיקוף מקומי של somehost.io. במקרה כזה, containerd לא בודק את המראה כדי למצוא את התמונה, והוא שולף את התמונה ממאגר ציבורי של somehost.io.

שימו לב: כברירת מחדל, Google Distributed Cloud משכפל אוטומטית תמונות מ-gcr.io, כך שלא צריך לציין את gcr.io כמארח בקטע hosts.

הערכים של hosts והערך של endpoint לא יכולים להיות חופפים. לדוגמה, בדוגמה הבאה של הגדרה מוצג מארח, europe-docker.pkg.dev, שתואם לחלק הדומיין של ערך נקודת הקצה. במקרה כזה, אין צורך לציין ערך של hosts:

...
registryMirrors:
  ...
  endpoint: https://europe-docker.pkg.dev:5000/v2/cloud-data-fusion-images
  hosts:
    - europe-docker.pkg.dev
    ...

gcrKeyPath שדה

אם רוצים ש-Google Distributed Cloud ישתמש אוטומטית ב-Artifact Registry ‏(gcr.io) כדי לשלוף תמונות שלא מופיעות במאגר המקומי, צריך לציין את הנתיב למפתח של חשבון השירות של Artifact Registry. ב-Google Distributed Cloud אין מנגנון לאספקת מפתחות למאגרי מידע ציבוריים אחרים.

אם אתם לא מתכננים להשתמש בתכונה שבה התמונות נשלפות מ-gcr.io כשהן לא מופיעות במרשם המקומי, אתם לא צריכים להוסיף gcrKeyPath לקובץ התצורה של האשכול.

caCertPath שדה

אם הרישום שלכם דורש אישור TLS פרטי, בשדה הזה צריך להזין את הנתיב לקובץ אישור ה-CA של שורש השרת. קובץ האישור הזה צריך להיות בתחנת העבודה של האדמין, במחשב שבו מריצים פקודות של bmctl. אם הרישום לא דורש אישור TLS פרטי, אפשר להשאיר את השדה caCertPath ריק.

pullCredentialConfigPath שדה

אם שרת הרישום לא דורש קובץ הגדרות אימות של Docker, אפשר להשאיר את השדה pullCredentialConfigPath ריק. שימו לב שזהו הנתיב לקובץ התצורה במכונה שמריצה פקודות bmctl.

שימוש במאגר תמונות (registry) משוכפל עם אשכולות משתמשים

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

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

כדי לעדכן את נקודות הקצה של שיקוף המרשם, האישורים או פרטי הכניסה למשיכת נתונים:

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

2. מריצים את הפקודה הבאה כדי להחיל את השינויים:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

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

   • ‫CLUSTER_NAME בשם האשכול שרוצים לעדכן.

   • ADMIN_KUBECONFIG בנתיב של קובץ התצורה של אשכול האדמין.

אימות התמונות נמשכות משיקוף של מאגר

כדי לבדוק אם containerd שולף תמונות מהרישום המקומי, בודקים את התוכן של קובץ config.toml כמו שמוסבר בשלבים הבאים:

1. מתחברים לצומת ובודקים את התוכן של הקובץ הבא: /etc/containerd/config.toml

2. בודקים את הקטע plugins."io.containerd.grpc.v1.cri".registry.mirrors בקובץ config.toml כדי לראות אם שרת הרישום מופיע בשדה endpoint. קטע מתוך קובץ config.toml לדוגמה שבו השדה endpoint מופיע בהדגשה:

   version = 2
   root = "/var/lib/containerd"
   state = "/run/containerd"
   ...
   [plugins."io.containerd.grpc.v1.cri".registry]
     [plugins."io.containerd.grpc.v1.cri".registry.configs]
       [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
         [plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
           ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
     [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
       [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
         endpoint = ["http://privateregistry.io", "https://privateregistry2.io"]
   ...
   

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

פתרון בעיות בהגדרות של שיקוף מאגר

אתם יכולים להשתמש ב-crictl, כלי שורת הפקודה של ממשק זמן הריצה של הקונטיינר, כדי לבדוק את הגדרות המאגר על ידי הורדה של קובצי אימג' בודדים. כל קובץ תמונה מתויג באופן עצמאי במחרוזת גרסה משמעותית. לדוגמה, תמונת בקר ה-API של האשכול מתויגת עם גרסת ההפצה של Google Distributed Cloud, ותמונת ה-etcd מתויגת עם גרסת ה-etcd התואמת.

בגרסה 1.31.200-gke.59 של Google Distributed Cloud for bare metal, לתמונת בקר ה-API של האשכול, cluster-api-controller, ולתמונת ה-etcd,‏ etcd, יש את התגים הבאים:

• cluster-api-controller:1.31.200-gke.59
• etcd:v3.4.30-0-gke.1

שליפת תמונה משיקוף של המאגר

אם מאגר המראה שלכם לא משתמש במרחבי שמות, השתמשו בפקודה הבאה כדי למשוך תמונה:

crictl pull REGISTRY_IP:PORT/IMAGE_PATH:IMAGE_TAG

שליפת תמונה משיקוף של מאגר שמשתמש במרחבי שמות

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

crictl pull REGISTRY_IP:PORT/NAMESPACE/IMAGE_PATH:IMAGE_TAG

מידע על השימוש ב-v2 בנקודת הקצה של הרישום

כשמאגר הרישום משתמש במרחבי שמות בהתאמה אישית, צריך להוסיף את מרחב השמות לפני נקודת הקצה של מאגר הרישום (registryMirror.endpoint) בקובץ ההגדרות של האשכול עם v2/. אם אתם לא משתמשים במרחבי שמות, אל תשתמשו ב-v2. בכל מקרה, אל תשתמשו ב-v2 בערך של הדגל --private-registry או בפקודות למשיכת תמונות:

ללא מרחבי שמות

• תקין:
  • endpoint: https://172.18.0.20:5000
  • crictl pull 172.18.0.20:5000/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
• לא תקין:
  • endpoint: https://172.18.0.20:5000/v2
  • crictl pull 172.18.0.20:5000/v2/anthos-baremetal-release/etcd:v3.4.30-0-gke.1

עם מרחבי שמות

• תקין:
  • endpoint: https://172.18.0.21:5000/v2/namespace
  • crictl 172.18.0.21:5000/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
• לא תקין:
  • endpoint: https://172.18.0.21:5000/namespace
  • crictl pull 172.18.0.21:5000/v2/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1