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

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

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

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

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

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

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.35.300-gke.87.tar.xz.

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

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

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

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

לדוגמה:

bmctl push images \
    --source bmpackages_1.35.300-gke.87.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.35.300-gke.87.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.35.300-gke.87.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.35.300-gke.87.tar.xz.

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

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

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

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

HTTPS_PROXY=http://10.128.0.136:3128 bmctl push images \
    --source bmpackages_1.35.300-gke.87.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.35.300-gke.87.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
   ...
   

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