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

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

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

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

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

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

הערה: משיכות תמונה עבור 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.36.100-gke.144.tar.xz אל bmpackages_1.36.100-gke.144.tar.

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

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.36.100-gke.144.tar.xz.

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

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

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

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

לדוגמה:

bmctl push images \
    --source bmpackages_1.36.100-gke.144.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.36.100-gke.144.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.36.100-gke.144.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem \
    --threads 8

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

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

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

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

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

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

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

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

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

בקובץ התצורה לדוגמה של האשכול הבא מצוין שצריך לשלוף תמונות ממראה מקומית של מאגר, שנקודת הקצה שלה היא 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
   ...
   

כדי לבצע שינויים נוספים בהגדרת ה-registry mirror עבור אשכול המשתמשים, עורכים את 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 שדה

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

pullCredentialConfigPath שדה

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

שימוש בשיקוף של מאגר רישום עם אשכולות משתמשים

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

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

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

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