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

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

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

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

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

קובץ התצורה של זמן הריצה מאפשר להגדיר רק אפשרויות ב-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. אפשר להשתמש בסכימה, ביציאה ובנתיב במדיניות הזו. הערך של scheme יכול להיות רק 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) של מארח הרישום. כדי ליצור סוד לאישורים ולהגדיר את ההרשאות הנדרשות, אפשר לעיין בהוראות שבמאמר איך מאחסנים את המפתחות הציבוריים של רשות ה-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: רשימה של אישורי לקוח וזוגות מפתחות לאימות למארח של המרשם. כדי ליצור סוד לאישורים ולהגדיר את ההרשאות הנדרשות, אפשר לעיין בהוראות שבמאמר איך מאחסנים את המפתחות הציבוריים של רשות ה-CA ב-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 על מאגר צמתים חדש של 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 על אשכולות וצמתים קיימים.

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

אם קובץ התצורה שלכם משתמש בסודות מ-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"

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

אם באשכול 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 על אשכולות קיימים.