התאמה אישית של הגדרות containerd בצמתי GKE

בדף הזה מוסבר איך להתאים אישית את ההגדרה של זמן הריצה של קונטיינר containerd בצמתים של Google Kubernetes Engine‏ (GKE). לפני שתקראו את המסמך הזה, חשוב שתבינו מה זה סביבת זמן ריצה של קונטיינר ולמה כדאי להתאים אותה אישית.

מידע על ההגדרה של containerd ב-GKE

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

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

אפשר להגדיר את ההגדרות של containerd ברמת האשכול או ברמת מאגר הצמתים. הגדרה ברמת מאגר הצמתים מבטלת הגדרה ברמת האשכול לאפשרויות האלה. כשמעדכנים אפשרות הגדרה של containerd ברמת האשכול (כמו registryHosts או writableCgroups), ‏ GKE מעדכן ויוצר מחדש את הצמתים רק במאגרי צמתים שאין להם הגדרות משלהם ברמת מאגר הצמתים לאפשרויות האלה. מאגרי צמתים עם הגדרות משלהם ברמת מאגר הצמתים לא יעודכנו או ייצרו מחדש, וימשיכו להשתמש בהגדרות שלהם.

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

מגבלות

אי אפשר להשתמש בקובץ תצורה של זמן ריצה כדי לשנות את ההגדרות של containerd בקובצי אימג' של צמתים ב-Windows.

אפשרויות ההגדרה הזמינות של containerd

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

privateRegistryAccessConfig

גישה למאגרי תמונות פרטיים באמצעות פרטי כניסה פרטיים שמאוחסנים ב-Secret Manager.

האפשרות הזו זמינה בגרסאות GKE‏ 1.27.3-gke.1700 ואילך לתמונות צמתים של מערכת הפעלה שמותאמת לקונטיינרים, ובגרסה 1.33 ואילך לתמונות צמתים של Ubuntu.

הוראות מפורטות זמינות במאמר בנושא גישה למאגרי רישום פרטיים באמצעות אישורי CA פרטיים.

privateRegistryAccessConfig:
  enabled: true
  certificateAuthorityDomainConfig:
  - gcpSecretManagerCertificateConfig:
    secretURI: "SECRET_LOCATION"
  fqdns:
  - "FQDN1"
  - "FQDN2"

ההגדרה הזו כוללת את השדות הבאים:

• ‫enabled: ערך בוליאני להפעלת ההגדרה של רישום פרטי. אם מגדירים את enabled: false, צריך למחוק את כל השדות האחרים בפריט privateRegistryAccessConfig.
• ‫certificateAuthorityDomainConfig: מכיל עד חמש הגדרות של אישורים ו-FQDN.
• ‫gcpSecretManagerCertificateConfig: מכיל אישור שמאוחסן ב-Secret Manager ומערך של שמות דומיין מלאים (FQDN).
• ‫secretURI: המיקום של האישור ב-Secret Manager. ב-privateRegistryAccessConfig יש תמיכה בסודות גלובליים רק ב-secretURI.
• ‫fqdns: רשימה של שמות דומיין מלאים של רשומות פרטיות. אפשר גם להשתמש בכתובות IPv4, אבל מומלץ להשתמש ב-FQDN.

registryHosts

הגדרת הגדרות מתקדמות למאגרי containerd, כמו יכולות, כותרות בהתאמה אישית ואישורים. הקובץ הזה מקביל ל-hosts.toml של containerd.

האפשרות הזו זמינה בגרסאות GKE‏ ‎1.34.1-gke.2980000 ואילך.

registryHosts:
- server: "REGISTRY_SERVER_FQDN"
  hosts:
  - host: "MIRROR_FQDN"
    capabilities:
    - "HOST_CAPABILITY_PULL"
    - "HOST_CAPABILITY_RESOLVE"
    - "HOST_CAPABILITY_PUSH"
    overridePath: false
    dialTimeout: "30s"
    header:
    - key: "HEADER_KEY"
      value:
      - "HEADER_VALUE_1"
      - "HEADER_VALUE_2"
    ca:
    - gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/CA_SECRET/versions/VERSION"
    client:
    - cert:
        gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/CLIENT_CERT_SECRET/versions/VERSION"
      key:
        gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/CLIENT_KEY_SECRET/versions/VERSION"

ההגדרה הזו כוללת את השדות הבאים:

• ‫server: שם המארח של שרת המרשם (לדוגמה, example.com). השם הזה משמש לקביעת השם של קובץ התצורה בצומת. זה צריך להיות שם דומיין שמוגדר במלואו או כתובת IP ללא סכימה, יציאה או נתיב.
• ‫hosts: רשימה של הגדרות ספציפיות למארח עבור server.
• ‫host: שם המארח של שיקוף של מאגר (לדוגמה, https://mirror.example.com:8000/1234, ‏ 1.2.3.4:80). אלה צריכים להיות שמות דומיין מלאים או כתובות IP. אפשר להשתמש בסכימה, ביציאה ובנתיב במדיניות הזו. הסכימה יכולה להיות רק http או https.
• ‫capabilities: רשימה של יכולות שמציינת אילו פעולות מארח יכול לבצע. הערכים הנתמכים הם:
  • ‫HOST_CAPABILITY_PULL: מייצגת את היכולת לאחזר מניפסטים ו-blobs לפי תקציר.
  • HOST_CAPABILITY_RESOLVE: מייצג את היכולת לאחזר מניפסטים לפי שם.
  • ‫HOST_CAPABILITY_PUSH: מייצג את היכולת לדחוף blobs ומניפסטים.
  אם לא מציינים יכולות, כל היכולות מופעלות.
• ‫overridePath: ערך בוליאני. אם true, המשמעות היא שנקודת הקצה הבסיסית של ה-API של המארח מוגדרת בנתיב כתובת ה-URL ולא במפרט ה-API. אפשר להשתמש בזה עם מאגרי OCI שלא תואמים וחסרה להם הקידומת /v2. ברירת המחדל היא false.
• ‫dialTimeout: מחרוזת משך זמן (לדוגמה, "30s") שמציינת את משך הזמן המקסימלי המותר להשלמת ניסיון התחברות. הערך המקסימלי המותר הוא "180s". אם לא מגדירים את המדיניות, containerd מגדיר את ברירת המחדל "30s". הערך צריך להיות מספר עשרוני של שניות עם הסיומת s.
• ‫header: רשימה של כותרות HTTP מותאמות אישית שצריך לשלוח למארח של המרשם.
  • ‫key: מפתח הכותרת.
  • ‫value: רשימה של ערכי כותרות.
• ‫ca: רשימה של הגדרות אישורים עבור רשות האישורים (CA) של מארח הרישום. כדי ליצור סוד לאישורים ולהגדיר את ההרשאות הנדרשות, אפשר לעיין בהוראות שבמאמר אחסון המפתחות הציבוריים של רשות האישורים ב-Secret Manager.
  • ‫gcpSecretManagerSecretUri: ה-URI של סוד ב-Secret Manager שמכיל את אישור ה-CA. הוא תומך גם בסודות גלובליים וגם בסודות אזוריים. אלה הפורמטים של סוגי הסודות השונים:
    • פורמט הסוד הגלובלי: projects/PROJECT_ID_OR_NUMBER/secrets/SECRET_NAME/versions/VERSION.
    • פורמט סודי אזורי: projects/PROJECT_ID_OR_NUMBER/locations/REGION/secrets/SECRET_NAME/versions/VERSION.
• ‫client: רשימה של אישורי לקוח וזוגות מפתחות לאימות מול מארח המרשם. כדי ליצור סוד לאישורים ולהגדיר את ההרשאות הנדרשות, אפשר לעיין בהוראות שבמאמר איך מאחסנים את המפתחות הציבוריים של רשות האישורים ב-Secret Manager.
  • ‫cert: הגדרות אישור הלקוח.
  • ‫gcpSecretManagerSecretUri: ה-URI של סוד ב-Secret Manager שמכיל את אישור הלקוח. הוא תומך גם בסודות גלובליים וגם בסודות אזוריים.
  • ‫key: ההגדרה של המפתח הפרטי של הלקוח.
  • ‫gcpSecretManagerSecretUri: ה-URI של סוד ב-Secret Manager שמכיל את מפתח הלקוח. הוא תומך גם בסודות גלובליים וגם בסודות אזוריים.

writableCgroups

מפעילים את מערכת הקבצים /sys/fs/cgroup במצב קריאה-כתיבה כדי שעומסי העבודה יוכלו לנהל את המשאבים של תהליכי הצאצא שלהם.

האפשרות הזו זמינה בגרסאות GKE‏ 1.34.1-gke.2541000 ואילך.

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

writableCgroups:
  enabled: true

החלת ההגדרות האישיות של containerd על אשכולות חדשים

בקטע הזה מוסבר איך להחיל קובץ הגדרה של containerd כשיוצרים אשכול GKE חדש.

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

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

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

• ‫CLUSTER_NAME: השם של האשכול החדש.
• ‫LOCATION: המיקום של Compute Engine באשכול החדש.
• ‫PATH_TO_CONFIG_FILE: הנתיב לקובץ התצורה שיצרתם, למשל ~/containerd-configuration.yaml.

כדי להפעיל את ההגדרה של containerd באשכולות רגילים חדשים, מריצים את הפקודה gcloud container clusters create עם אותן אפשרויות. אלא אם מציינים הגדרה אחרת של containerd, מאגרי צמתים חדשים שנוצרים באשכול מקבלים בירושה את הגדרת ברירת המחדל של containerd ברמת האשכול.

החלת הגדרות containerd על מאגרי צמתים חדשים

כדי להחיל את ההגדרות האישיות של containerd על מאגר צמתים חדש ב-GKE, אפשר להשתמש בפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

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

• ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
• ‫CLUSTER_NAME: השם של האשכול הקיים.
• ‫LOCATION: המיקום ב-Compute Engine של מאגר הצמתים החדש.
• ‫PATH_TO_CONFIG_FILE: הנתיב לקובץ התצורה שיצרתם, כמו ~/containerd-configuration.yaml.

החלת ההגדרה של containerd על אשכולות קיימים

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

עדכון ההגדרה של containerd ברמת האשכול חל רק על מאגרי צמתים שלא מוגדרות להם הגדרות משלהם ברמת מאגר הצמתים (כמו registryHosts או writableCgroups). מערכת GKE יוצרת מחדש את הצמתים במאגרי הצמתים האלה כדי להחיל את ההגדרה החדשה. מאגרי צמתים עם הגדרות ברמת מאגר הצמתים ממשיכים להשתמש בהגדרות שלהם, והצמתים שלהם לא נוצרים מחדש. כשמעדכנים אשכול או מאגר צמתים עם הגדרת containerd, הצמתים נוצרים מחדש כדי להחיל את ההגדרה. יכול להיות שיהיו שיבושים זמניים בהרצת עומסי העבודה. ‫GKE יוצר מחדש צמתים רק אם מופעלים שדרוגים אוטומטיים. היצירה מחדש הזו מתבצעת בהתאם לחלונות הזמן לתחזוקה שהגדרתם. באשכולות רגילים שבהם לא מופעלים שדרוגים אוטומטיים, צריך ליצור מחדש את הצמתים באופן ידני כדי להחיל את ההגדרה.

בדיקת היקפי הגישה

אם קובץ התצורה משתמש בסודות מ-Secret Manager, לאשכול או למאגר הצמתים צריך להיות היקף הגישה cloud-platform. בקטע הזה מוסבר איך לבדוק את היקפי הגישה ואיך לעדכן קלאסטר קיים באמצעות קובץ חדש או מעודכן של הגדרות זמן ריצה.

לפרטים על היקפי הגישה שמוגדרים כברירת מחדל באשכולות חדשים, קראו את המאמר היקפי גישה ב-GKE.

בדיקת היקפי ההרשאות של Autopilot

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

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodeConfig \
    --format='csv[delimiter="\\n",no-heading](oauthScopes)'

אם אתם משתמשים בסודות מ-Secret Manager ולצבירת המחשבים שלכם אין את היקף הגישה https://www.googleapis.com/auth/cloud-platform, אתם צריכים ליצור צבירת מחשבים חדשה עם היקף הגישה הזה.

בדיקה של היקפי גישה רגילים

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

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value[delimiter="\\n"](config.oauthScopes)'

מחליפים את NODE_POOL_NAME בשם של מאגר הצמתים.

אם אתם משתמשים בסודות מ-Secret Manager ולצביר שלכם אין את היקף הגישה https://www.googleapis.com/auth/cloud-platform, אתם צריכים ליצור מאגר צמתים חדש עם היקף הגישה cloud-platform ולמחוק את מאגר הצמתים הקיים.

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

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

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

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

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

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

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

• ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים לעדכן.
• ‫CLUSTER_NAME: השם של האשכול הקיים.
• ‫LOCATION: המיקום של האשכול ב-Compute Engine.
• ‫PATH_TO_CONFIG_FILE: הנתיב לקובץ התצורה שיצרתם, כמו ~/containerd-configuration.yaml.

יצירה מחדש של צמתים באשכולות Standard

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

gcloud container clusters upgrade CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION

מחליפים את VERSION באותה גרסת תיקון של GKE שכבר נמצאת בשימוש באשכול.

השבתת אפשרויות ההגדרה של containerd

השבת את privateRegistryAccessConfig

1. מעדכנים את קובץ ההגדרות כדי לציין enabled: false ב-privateRegistryAccessConfig ומסירים את כל השדות האחרים בפריט, כמו בדוגמה הבאה:

   privateRegistryAccessConfig:
     enabled: false

2. מחילים את קובץ התצורה המעודכן על האשכול. להוראות, ראו החלת הגדרות של containerd על אשכולות קיימים.

השבת את registryHosts

1. מעדכנים את קובץ התצורה כדי לציין מערך ריק בפריט registryHosts, כמו בדוגמה הבאה:

   registryHosts: []

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