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

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

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

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

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

קובץ התצורה של זמן הריצה מאפשר להגדיר רק אפשרויות ב-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). השם הזה משמש לקביעת השם של קובץ התצורה בצומת. צריך להזין כאן שם דומיין שמוגדר במלואו או כתובת IPv4.
  • ‫hosts: רשימה של הגדרות ספציפיות למארח עבור server.
  • ‫host: שם המארח של שיקוף הרישום (לדוגמה, mirror.example.com). אלה צריכים להיות שמות דומיין מלאים או כתובות IPv4.
  • ‫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 ואילך.

מידע נוסף זמין במאמר הגדרת cgroup עם הרשאות כתיבה עבור קונטיינרים.

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

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

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

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

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

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

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

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

בדיקה של הרשאת גישה רגילה

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

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

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

אם לא מוגדר ב-cluster שלכם היקף הגישה 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 על אשכולות קיימים.