‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

התאמה אישית של הגדרות המערכת של הצומת

Standard

במאמר הזה מוסבר איך להתאים אישית את הגדרות הצומת ב-Google Kubernetes Engine ‏ (GKE) באמצעות קובץ תצורה שנקרא הגדרת מערכת הצומת.

קובץ תצורה של מערכת צמתים הוא קובץ תצורה שמאפשר לשנות קבוצה מוגבלת של הגדרות מערכת. במאגר הצמתים, אתם יכולים להשתמש בהגדרת המערכת של הצומת כדי לציין הגדרות בהתאמה אישית לסוכן הצומת kubelet של Kubernetes ולהגדרות sysctl ברמה נמוכה של ליבת Linux.

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

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

היתרונות של הגדרות המערכת של הצומת:

כוונון ביצועים: אופטימיזציה של ביצועי מקבץ הרשת (network stack), ניהול הזיכרון, תזמון המעבד (CPU) או התנהגות הקלט/פלט (I/O) לאפליקציות תובעניות כמו אימון או הצגה של AI, מסדי נתונים, שרתי אינטרנט עם תנועה גבוהה או שירותים שרגישים לזמן אחזור.
הקשחת אבטחה: החלת הגדרות אבטחה ספציפיות ברמת הליבה או הגבלת התנהגויות מסוימות של המערכת כדי לצמצם את שטח המתקפה.
ניהול משאבים: התאמה אישית של האופן שבו kubelet מנהל את מזהי התהליכים (PID), המקום בכונן, איסוף הזבל של קובצי האימג' או משאבי המעבד (CPU) והזיכרון.
תאימות לעומסי עבודה: לוודא שסביבת הצומת עומדת בדרישות מוקדמות ספציפיות לתוכנות מיוחדות או לאפליקציות ישנות שדורשות הגדרות ליבה מסוימות.

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

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

קובץ תצורה של סביבת זמן ריצה: כדי להתאים אישית סביבת זמן ריצה של קונטיינר containerd בצמתים של GKE, אתם יכולים להשתמש בקובץ אחר שנקרא קובץ תצורה של סביבת זמן ריצה. מידע נוסף זמין במאמר התאמה אישית של הגדרות containerd בצומתי GKE.
‫ComputeClass: אתם יכולים לציין מאפייני צמתים במפרט של ComputeClass ב-GKE. אפשר להשתמש ב-ComputeClasses גם במצב אוטומטי וגם במצב רגיל של GKE, בגרסה 1.32.1-gke.1729000 ואילך של GKE. מידע נוסף זמין במאמר התאמה אישית של הגדרת המערכת של הצומת.
‫DaemonSets: אפשר גם להשתמש ב-DaemonSets כדי להתאים אישית צמתים. מידע נוסף זמין במאמר אתחול אוטומטי של צומתי GKE באמצעות DaemonSets.

בצמתים של Windows Server אין תמיכה בהגדרות של מערכת הצמתים.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שהתנאים הבאים מתקיימים:

התקנת כלים של שורת הפקודה:
- אם אתם משתמשים בדוגמאות של ה-CLI של gcloud במסמך הזה, ודאו שהתקנתם והגדרתם את Google Cloud CLI.
- אם אתם משתמשים בדוגמאות של Terraform, ודאו שהתקנתם והגדרתם את Terraform.
לתת הרשאות: כדי ליצור ולעדכן אשכולות GKE ומאגרי צמתים, צריך הרשאות IAM מתאימות, כמו container.clusterAdmin או תפקיד אחר עם הרשאות דומות.
תכנון לשיבושים פוטנציאליים בעומסי העבודה: הגדרות מותאמות אישית של צמתים מוחלות ברמת מאגר הצמתים. בדרך כלל, שינויים מפעילים עדכון בהדרגה (rolling) של הצמתים במאגר, שכולל יצירה מחדש של הצמתים. תכננו מראש שיבושים פוטנציאליים בעומסי העבודה והשתמשו בתקציבים לשיבוש Pod‏ (PDB) במקרים המתאימים.
לגבות ולבדוק את כל השינויים: תמיד צריך לבדוק את השינויים בהגדרות בסביבת בדיקה או פיתוח לפני שמיישמים אותם בסביבת הייצור. הגדרות שגויות עלולות לגרום לחוסר יציבות של הצומת או לכשלים בעומסי העבודה.
בדיקת הגדרות ברירת המחדל של GKE: קובצי האימג' של צומתי GKE מגיעים עם הגדרות ברירת מחדל שעברו אופטימיזציה. מומלץ להתאים אישית פרמטרים רק אם יש לכם צורך ספציפי ואתם מבינים את ההשפעה של השינויים.

הוספת הגדרת מערכת של צומת

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

שימוש ב-ComputeClass להגדרת מערכת הצמתים

אתם יכולים להשתמש ב-ComputeClass בהתאמה אישית כדי להתאים אישית פרמטרים מסוימים ב-kubelet ובליבה של Linux. השיטה הזו זמינה ב-GKE בגרסה 1.32.1-gke.1729000 ואילך.

כדי להשתמש ב-ComputeClass להתאמה אישית של הגדרת המערכת של הצומת:

יוצרים ComputeClass שכולל את צמד הערכים בשדה spec.nodePoolAutoCreation.enabled: true ומציינים את הגדרות המערכת בשדה priorityDefaults.
פורסים עומס עבודה שבוחר את ComputeClass.

יצירת ComputeClass

כותבים את ההגדרות של ComputeClass ב-YAML. כדי להגדיר את המערכת בכל רמות העדיפות, משתמשים בשדה nodeSystemConfig במפרט priorityDefaults.

בדוגמה הבאה, ComputeClass מגדיר את המדיניות הסטטית של מנהל המעבד (CPU) ואת הפרמטרים המותאמים אישית של הליבה:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-sysconfig
spec:
  nodePoolAutoCreation:
    enabled: true
  priorityDefaults:
    nodeSystemConfig:
      kubeletConfig:
        cpuManagerPolicy: static
      linuxNodeConfig:
        sysctls:
          net.core.somaxconn: 2048
  priorities:
  - machineFamily: n4

מחילים את ה-ComputeClass:

kubectl apply -f custom-sysconfig.yaml

פריסת עומס עבודה שבוחר את ComputeClass

במפרט של ה-Pod, מוסיפים בורר צמתים לשם של ComputeClass:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        cloud.google.com/compute-class: custom-sysconfig
      containers:
      - name: app-container
        image: nginx

מפעילים את עומס העבודה:

kubectl apply -f my-app.yaml

מידע נוסף זמין במאמר התאמה אישית של הגדרות המערכת של הצומת.

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

כשמשתמשים בקובץ תצורה של מערכת הצמתים, משתמשים בקובץ YAML שמכיל את הפרמטרים של התצורה של kubelet ושל ליבת Linux. אפשר להגדיר את מערכת הצמתים גם במצב אוטומטי של GKE, אבל השלבים במסמך הזה מראים איך ליצור קובץ תצורה ולהשתמש בו במצב רגיל של GKE.

כדי להשתמש בקובץ תצורה של מערכת צמתים במצב GKE Standard:

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

יצירת קובץ תצורה

כותבים את הגדרת המערכת של הצומת ב-YAML. בדוגמה הבאה מוסיפים הגדרות לאפשרויות kubelet ו-sysctl:

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue.*'
    - 'net.*'
linuxConfig:
  sysctl:
    net.core.somaxconn: '2048'
    net.ipv4.tcp_rmem: '4096 87380 6291456'
  kernelOverrides:
    kernelCommandlineOverrides:
      specRstackOverflow: 'SPEC_RSTACK_OVERFLOW_OFF'
      initOnAlloc: 'INIT_ON_ALLOC_OFF'

בדוגמה הזו, התנאים הבאים חלים:

השדה cpuManagerPolicy: static מגדיר את kubelet כך שישתמש במדיניות הסטטית לניהול המעבד (CPU).
השדה net.core.somaxconn: '2048' מגביל את ה-backlog של socket listen() ל-2,048 בייטים.
השדה net.ipv4.tcp_rmem: '4096 87380 6291456' מגדיר את הערך המינימלי, ערך ברירת המחדל והערך המקסימלי של מאגר הנתונים הזמני לקבלת שקע TCP ל-4,096 בייטים, 87,380 בייטים ו-6,291,456 בייטים, בהתאמה.
הבלוק kernelCommandlineOverrides משבית את ההשבתה הזמנית של אותות האכיפה של גלישת מחסנית החזרה הספקולטיבית (SRSO) ואת הפרמטר init_on_alloc של הליבה.

אם רוצים להוסיף הגדרות רק ל-kubelet או ל-sysctl, צריך לכלול רק את הקטע הזה בהגדרת המערכת של הצומת. לדוגמה, כדי להוסיף הגדרת kubelet, יוצרים את הקובץ הבא:

kubeletConfig:
  cpuManagerPolicy: static

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

הוספת ההגדרה למאגר צמתים רגיל

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

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

אפשר להוסיף הגדרות מערכת לצומת במהלך יצירת האשכול באמצעות ה-CLI של gcloud או Terraform. ההוראות הבאות מחילות את הגדרת המערכת של הצומת על מאגר ברירת המחדל של הצמתים:

‫CLI של gcloud

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

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

‫CLUSTER_NAME: השם של האשכול
‫LOCATION: אזור המחשוב או האזור של האשכול
‫SYSTEM_CONFIG_PATH: הנתיב לקובץ שמכיל את ההגדרות של kubelet ו-sysctl

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

Terraform

כדי ליצור אשכול אזורי עם הגדרת מערכת מותאמת אישית של צמתים באמצעות Terraform, אפשר להיעזר בדוגמה הבאה:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

מידע נוסף על השימוש ב-Terraform זמין במאמר תמיכה של Terraform ב-GKE.

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

אתם יכולים להוסיף הגדרת מערכת של צומת כשאתם משתמשים ב-CLI של gcloud או ב-Terraform כדי ליצור מאגר צמתים חדש.

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

‫CLI של gcloud

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

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

‫POOL_NAME: שם מאגר הצמתים
‫CLUSTER_NAME: שם האשכול שרוצים להוסיף לו מאגר צמתים
‫LOCATION: אזור המחשוב או האזור של האשכול
‫SYSTEM_CONFIG_PATH: הנתיב לקובץ שמכיל את ההגדרות של kubelet ו-sysctl

Terraform

כדי ליצור מאגר צמתים עם הגדרת מערכת מותאמת אישית באמצעות Terraform, אפשר להיעזר בדוגמה הבאה:

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

מידע נוסף על השימוש ב-Terraform זמין במאמר תמיכה של Terraform ב-GKE.

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

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

עדכון בזמן אמת ללא הפרעה: החלת הגדרות מעודכנות של sysctl ו-kubelet ישירות על צמתים פועלים, בלי ליצור מחדש את המכונות הווירטואליות או להסיר Pods. השיטה הזו מתאימה כשמשנים רק את ההגדרות של sysctl או kubelet ורוצים לצמצם את ההפרעה.
שיטת שדרוג רגילה: יוצרת מחדש את הצמתים עם ההגדרות החדשות. השתמשו בשיטה הזו כשאתם משנים הגדרות שלא תומכות בעדכונים בזמן אמת, כשהאשכול או מאגר הצמתים מריצים גרסת GKE שקודמת ל-1.37.1-gke.1954000, או כשאתם רוצים ש-GKE ירוקן את ה-Pods ויתזמן אותם מחדש לצמתים חדשים.

כדי לשנות את ההגדרות של צמתים שמשתמשים ב-ComputeClass, עיינו במאמר עריכת הגדרות המערכת של צומת ל-ComputeClasses.

עדכון באמצעות עדכון בזמן אמת שלא משבש את הפעילות

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

מצב cgroup ב-Linux
דפים גדולים ב-Linux
סנכרון זמן מדויק ב-Linux
Linux VFIO
מתזמן הקלט/פלט של הדיסק ב-Linux

איך פועלים העדכונים בזמן אמת

העדכונים בזמן אמת פועלים באופן הבא בכל אחת מההגדרות הנתמכות:

הגדרות של sysctl: ‏GKE מפעיל מחדש את שירות systemd של sysctl בכל צומת כדי להחיל את הפרמטרים של הליבה בשדה linuxConfig.sysctl. אם מעדכנים פרמטר sysctl של מרחב שמות, GKE מפעיל מחדש גם את השירות kubelet כדי לעדכן את ההגדרה sysctl ברמת ה-Pod. במאמר אפשרויות הגדרה של Sysctl מפורטים הפרמטרים הנתמכים.
הגדרות של kubelet: ‏GKE מפעיל מחדש את השירות kubelet בכל צומת כדי להחיל את הפרמטרים בשדה kubeletConfig. רוב אפשרויות ההגדרה של kubelet תומכות בעדכונים בזמן אמת. עם זאת, האפשרויות cpuManagerPolicy,‏ shutdownGracePeriodSeconds ו-shutdownGracePeriodCriticalPodsSeconds דורשות את אסטרטגיית השדרוג הרגילה.

בשני המקרים, GKE מחיל את השינוי במקום בצמתים הפועלים בלי ליצור מחדש את המכונות הווירטואליות, לפנות את ה-Pods או ליצור מכונות וירטואליות זמניות. ב-GKE, סכום ההגדרות של --max-surge-upgrade ו---max-unavailable-upgrade במאגר הצמתים משמש כמגבלת בו-זמניות, כדי לקבוע כמה צמתים קיימים מתעדכנים במקביל.

דרישות מוקדמות לעדכונים בזמן אמת

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

להפעיל את GKE בגרסה 1.37.1-gke.1954000 ואילך.
מפעילים את התוסף NodeReadinessController באשכול. במהלך עדכון בזמן אמת, הבקר הזה מחיל באופן זמני את ה-taint‏ readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule על כל צומת שמתעדכן, כדי ש-GKE לא יתזמן Pods חדשים לצומת עד שהעדכון יושלם:
- באשכולות חדשים, צריך לכלול את התוסף NodeReadinessController בדגל --addons כשיוצרים את האשכול. הדגל הזה מפעיל רק את התוספים שציינתם ומשבית את כל השאר, לכן צריך לכלול גם את כל תוספי ברירת המחדל שאתם רוצים לשמור.
- באשכולות קיימים, מעבירים את הדגל --update-addons=NodeReadinessController=ENABLED במהלך עדכון האשכול.

החלת עדכון בזמן אמת

כדי להחיל עדכון בזמן אמת:

יוצרים או משנים את קובץ ה-YAML של הגדרת המערכת של הצומת כך שיכיל את ההגדרה המלאה של מאגר הצמתים, כולל ההגדרות של kubelet או sysctl שרוצים לשנות. כדי לא לאפס הגדרות שאתם לא רוצים לשנות, התחילו מההגדרות הקיימות של מאגר הצמתים.
מעדכנים את מאגר הצמתים באמצעות קובץ התצורה ומגדירים את הערך של הדגל --node-config-update-mode ל-LIVE_UPDATE_WITHOUT_DRAIN:
```
gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH \
    --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POOL_NAME: שם מאגר הצמתים שרוצים לעדכן
- ‫CLUSTER_NAME: שם האשכול שמכיל את מאגר הצמתים
- ‫LOCATION: אזור המחשוב או האזור של האשכול
- ‫SYSTEM_CONFIG_PATH: הנתיב לקובץ ה-YAML שמכיל את הגדרות המערכת של הצומת
מוודאים ש-GKE החיל את ההגדרות המעודכנות על מאגר הצמתים:
```
gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig, config.linuxNodeConfig)"
```
פלט הפקודה מציג את ההגדרות הפעילות במאגר הצמתים בשדות config.kubeletConfig ו-config.linuxNodeConfig.
אופציונלי: מפעילים מחדש את ה-Pods הקיימים. העדכון בזמן אמת לא מפריע לפודים שפועלים, ולכן GKE מחיל את ההגדרות המעודכנות רק על פודים שמתחילים אחרי שהעדכון מסתיים. כדי להחיל את ההגדרות על עומס עבודה שכבר פועל, מפעילים מחדש את ה-Pods שלו, למשל על ידי הפעלת kubectl rollout restart ב-Deployment.

אם עדכון בזמן אמת לא מתבצע כמצופה, נתיב השחזור תלוי בשאלה אם פעולת העדכון הסתיימה:

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

איך לשחזר אחרי עדכון בזמן אמת שנכשל

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

מריצים את הפקודה gcloud container operations describe. בפלט, השדה statusMessage מזהה את הצומת שבו העדכון בזמן אמת נכשל ואת השגיאה שדווחה על ידי הצומת, לדוגמה:
```
statusMessage: 'Failed precondition: live update failed on node gke-my-cluster-default-pool-ae3770ee-2kk0:
  Live update fails with error: failed to write new kubelet config: ...'
```
ב-Logs Explorer, בודקים אם יש שגיאות מהרכיב gke-node-live-update-reconciler בצמתים המושפעים.

עדכון בזמן אמת שנכשל לא משנה את ההגדרות ששמורות במאגר הצמתים, ולכן הפעלה מחדש של ההגדרות הקודמות באמצעות הפקודה gcloud container node-pools update לא מפעילה עדכון. אחרי שבודקים את הכשל, בוחרים באחת מאפשרויות השחזור הבאות:

תיקון הבעיה והשלמת העדכון בזמן אמת (מומלץ): פותרים את הבעיה שגרמה לכשל, ואז מריצים מחדש את הפקודה gcloud container node-pools update מהתהליך הקודם עם הגדרת היעד.
חזרה להגדרות הקודמות: אם אתם לא מצליחים לפתור את הבעיה, הריצו את הפקודה gcloud container node-pools rollback כדי להחזיר את מאגר הצמתים להגדרות הקודמות שלו. בניגוד לעדכון בזמן אמת, הפקודה הזו יוצרת מחדש את כל הצמתים במאגר, מה שמשבש את עומסי העבודה שפועלים בהם.

ביטול עדכון בזמן אמת שהושלם

אם פעולת העדכון בזמן אמת מצליחה, אבל הגדרה חדשה שחלה גורמת להתנהגות לא מכוונת של עומס העבודה, צריך לבטל את השינוי במקום על ידי החלת עדכון נוסף בזמן אמת עם ההגדרה הקודמת. העדכון הזה בזמן אמת משחזר את ההגדרה הקודמת בלי להוציא Pods או להפעיל מחדש צמתים. הפקודה gcloud container node-pools rollback לא זמינה אחרי שהפעולה בוצעה בהצלחה, אלא רק כשהפעולה נכשלת.

כדי לבטל עדכון בזמן אמת שהסתיים:

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

מחילים את ההגדרות הקודמות על מאגר הצמתים:

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH \
    --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN

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

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

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

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

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

‫POOL_NAME: שם מאגר הצמתים שרוצים לעדכן
‫CLUSTER_NAME: שם האשכול שמכיל את מאגר הצמתים
‫LOCATION: אזור המחשוב או האזור של האשכול
‫SYSTEM_CONFIG_PATH: הנתיב לקובץ ה-YAML שמכיל את הגדרות המערכת של הצומת

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

מידע נוסף על עדכוני צמתים זמין במאמר תכנון לשיבושים בעדכוני צמתים.

עריכת הגדרות המערכת של הצומת

אתם יכולים לערוך את הגדרות המערכת של הצומת בהתאם לשימוש שלכם ב-ComputeClasses או בקובץ תצורה.

ב-ComputeClasses

כדי לערוך את הגדרת המערכת של הצומת כשמשתמשים ב-ComputeClasses, בוחרים באחת מהשיטות הבאות:

שיטה 1: עדכון ה-ComputeClass הקיים

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

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

מגדירים העברה פעילה ב-ComputeClass.
כדי להפעיל הרחבה של צמתים חדשים, צריך להפעיל מחדש או ליצור מחדש את עומסי העבודה באופן ידני.

כדי לעדכן את ComputeClass, עורכים את קובץ ה-YAML ומחילים אותו:

kubectl apply -f custom-sysconfig.yaml

שיטה 2: יצירת ComputeClass חדש

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

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

לקובצי תצורה

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

עריכה באמצעות יצירת מאגר צמתים

כדי לערוך הגדרות מערכת של צומת באמצעות יצירת מאגר צמתים:

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

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

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

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

כדי לאחזר את הגדרת המערכת הקיימת של הצומת במאגר הצמתים – לדוגמה, אם כבר התאמתם אישית את ההגדרה ואתם רוצים להוסיף לה – השתמשו בפקודה gcloud container node-pools describe. בפלט של הפקודה מופיעה רשימה של כל ההגדרות הקיימות ב-kubeletConfig וב-linuxNodeConfig.

לדוגמה, בקטע הקוד הבא מוצג פורמט הפלט של הפקודה describe:

  kubeletConfig:
    allowedUnsafeSysctls:
    - kernel.shm*
    - kernel.msg*
    - kernel.sem
    - fs.mqueue.*
    - net.*
    cpuManagerPolicy: static
    insecureKubeletReadonlyPortEnabled: false
    maxParallelImagePulls: 2
  linuxNodeConfig: # IMPORTANT: Use linuxConfig when updating these settings
    sysctl:
      net.core.somaxconn: '2048'
      net.ipv4.tcp_rmem: 4096 87380 6291456

אם עדיין לא הגדרתם את המערכת של הצומת, הפלט לא יכלול את kubeletConfig או את linuxNodeConfig.

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

אם רוצים לאפס את הגדרות המערכת של הצומת לברירות המחדל, מעדכנים את קובץ התצורה עם ערכים ריקים בשדות kubelet ו-sysctl, לדוגמה:

```yaml
kubeletConfig: {}
linuxConfig:
  sysctl: {}
```

מחיקת הגדרות המערכת של צומת

כדי להסיר הגדרת מערכת של צומת, פועלים לפי השלבים בהתאם לשימוש ב-ComputeClasses או בקובץ תצורה.

ב-ComputeClasses

כדי להסיר את הגדרת המערכת של הצומת בהתאמה אישית:

מסירים את בורר הצמתים cloud.google.com/compute-class מהמפרט של עומס העבודה.
מחילים את המפרטים המעודכנים של עומס העבודה. ‫GKE יוצר מחדש את עומסי העבודה בצומתי ברירת המחדל. בסופו של דבר, המידרוג האוטומטי של האשכול יצמצם אנכית בהתאם לעומס (scale down) וימחק את הצמתים שהוקצו ל-ComputeClass.
מוחקים את האובייקט ComputeClass מהאשכול:
```
kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
```

לקובצי תצורה

כדי להסיר הגדרת מערכת של צומת שהוחלה באמצעות קובץ תצורה:

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

אפשרויות הגדרה של `kubelet`

בטבלאות שבקטע הזה מתוארות האפשרויות של kubelet שאפשר לשנות.

ניהול המעבד (CPU)

בטבלה הבאה מתוארות האפשרויות לניהול המעבד (CPU) ב-kubelet.

הגדרות אישיות של kubelet הגבלות הגדרת ברירת המחדל תיאור

cpuCFSQuota הערך חייב להיות true או false. true ההגדרה הזו אוכפת את מגבלת המעבד (CPU) של ה-Pod. אם הערך הזה מוגדר כ-false, המערכת מתעלמת ממגבלות המעבד (CPU) של Pods.

התעלמות ממגבלות המעבד (CPU) יכולה להועיל בתרחישים מסוימים שבהם Pods רגישים למגבלות המעבד (CPU). הסיכון בהשבתת cpuCFSQuota הוא ש-Pod זדוני יכול לצרוך יותר משאבי מעבד (CPU) מהמתוכנן.

cpuCFSQuotaPeriod צריך להזין משך זמן. "100ms" ההגדרה הזו קובעת את הערך של תקופת המכסה של CPU CFS,‏ cpu.cfs_period_us, שמציין את התדירות שבה צריך להקצות מחדש את הגישה של cgroup למשאבי המעבד (CPU). האפשרות הזו מאפשרת לכם לשנות את ההתנהגות של ויסות המעבד (CPU).

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`cpuCFSQuota`	הערך חייב להיות `true` או `false`.	`true`	ההגדרה הזו אוכפת את מגבלת המעבד (CPU) של ה-Pod. אם הערך הזה מוגדר כ-`false`, המערכת מתעלמת ממגבלות המעבד (CPU) של Pods. התעלמות ממגבלות המעבד (CPU) יכולה להועיל בתרחישים מסוימים שבהם Pods רגישים למגבלות המעבד (CPU). הסיכון בהשבתת `cpuCFSQuota` הוא ש-Pod זדוני יכול לצרוך יותר משאבי מעבד (CPU) מהמתוכנן.
`cpuCFSQuotaPeriod`	צריך להזין משך זמן.	`"100ms"`	ההגדרה הזו קובעת את הערך של תקופת המכסה של CPU CFS,‏ `cpu.cfs_period_us`, שמציין את התדירות שבה צריך להקצות מחדש את הגישה של cgroup למשאבי המעבד (CPU). האפשרות הזו מאפשרת לכם לשנות את ההתנהגות של ויסות המעבד (CPU).
`reservedSystemCPUs` (גרסת טרום-השקה (Preview))	צריך להיות רשימה של ליבות מעבד ספציפיות לשמירה (לדוגמה, `0-1` או `0,1` כדי לשמור את הליבות 0 ו-1). מכיוון שהאינדקס של הליבות מתחיל באפס, הערכים חייבים להיות קטנים ממספר ה-vCPU בסוג המכונה.	`none`	שומרת במפורש ליבות מעבד ספציפיות לשירותי המערכת המארחת, כמו דימונים של מערכת ההפעלה ושירות `kubelet`. כברירת מחדל, השירותים האלה יכולים לפעול בכל ליבת מעבד (CPU), מה שעלול לגרום לבעיות בביצועים של עומסי עבודה שרגישים למעבד. ההגדרה `cpuManagerPolicy: static` מקצה ליבות ייעודיות לפודים של `Guaranteed` עם בקשות למספר שלם של מעבדי CPU, אבל היא לא מונעת משירותי המערכת המארחת להשתמש בליבות האלה. הוספת ההגדרה `reservedSystemCPUs` מגבילה את שירותי המערכת המארחת לליבות השמורות שלהם, ומונעת מהם להפריע לליבות הבלעדיות של עומסי העבודה. כדי לבצע את המשימה הזו, GKE מצמיד באופן אוטומטי את ה-cgroup‏ `system.slice` לליבות השמורות בזמן הפעלת הצומת. הקצאת מעבדי CPU של המערכת מקטינה את הקיבולת הכוללת שניתן להקצות לצמתים. למרות ש-Pods של `Burstable` ו-`BestEffort` עדיין יכולים לפעול בליבות השמורות האלה, בקשות ה-CPU שלהם, כולל בקשות חלקיות מ-DaemonSets של GKE, עדיין נספרות כחלק מהקיבולת שניתנת להקצאה של הצומת. בגלל שעומסי עבודה בלעדיים של `Guaranteed` דורשים ליבות שלמות, אפילו בקשות קטנות של חלקי ליבות מפחיתות את מספר הליבות הבלעדיות הזמינות. חשוב לוודא ששמרתם מספיק ליבות מעבד (CPU) ב-`reservedSystemCPUs`. אם מקצים מעט מדי ליבות, יכול להיות שהתהליכים של מערכת ההפעלה וה-daemons של המערכת המארחת יוגבלו על ידי המעבד (CPU) בעומס גבוה, מה שעלול לגרום לחוסר יציבות או לאובדן של חבילות נתונים ברשת.

reservedSystemCPUs (גרסת טרום-השקה (Preview))

צריך להיות רשימה של ליבות מעבד ספציפיות לשמירה (לדוגמה, 0-1 או 0,1 כדי לשמור את הליבות 0 ו-1). מכיוון שהאינדקס של הליבות מתחיל באפס, הערכים חייבים להיות קטנים ממספר ה-vCPU בסוג המכונה.

none

שומרת במפורש ליבות מעבד ספציפיות לשירותי המערכת המארחת, כמו דימונים של מערכת ההפעלה ושירות kubelet. כברירת מחדל, השירותים האלה יכולים לפעול בכל ליבת מעבד (CPU), מה שעלול לגרום לבעיות בביצועים של עומסי עבודה שרגישים למעבד. ההגדרה cpuManagerPolicy: static מקצה ליבות ייעודיות לפודים של Guaranteed עם בקשות למספר שלם של מעבדי CPU, אבל היא לא מונעת משירותי המערכת המארחת להשתמש בליבות האלה. הוספת ההגדרה reservedSystemCPUs מגבילה את שירותי המערכת המארחת לליבות השמורות שלהם, ומונעת מהם להפריע לליבות הבלעדיות של עומסי העבודה. כדי לבצע את המשימה הזו, GKE מצמיד באופן אוטומטי את ה-cgroup‏ system.slice לליבות השמורות בזמן הפעלת הצומת.

הקצאת מעבדי CPU של המערכת מקטינה את הקיבולת הכוללת שניתן להקצות לצמתים. למרות ש-Pods של Burstable ו-BestEffort עדיין יכולים לפעול בליבות השמורות האלה, בקשות ה-CPU שלהם, כולל בקשות חלקיות מ-DaemonSets של GKE, עדיין נספרות כחלק מהקיבולת שניתנת להקצאה של הצומת. בגלל שעומסי עבודה בלעדיים של Guaranteed דורשים ליבות שלמות, אפילו בקשות קטנות של חלקי ליבות מפחיתות את מספר הליבות הבלעדיות הזמינות.

חשוב לוודא ששמרתם מספיק ליבות מעבד (CPU) ב-reservedSystemCPUs. אם מקצים מעט מדי ליבות, יכול להיות שהתהליכים של מערכת ההפעלה וה-daemons של המערכת המארחת יוגבלו על ידי המעבד (CPU) בעומס גבוה, מה שעלול לגרום לחוסר יציבות או לאובדן של חבילות נתונים ברשת.

ניהול זיכרון ופינוי מקום

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

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`evictionSoft`	מפה של שמות האותות. בטבלה הבאה מפורטות ההגבלות על הערכים.	`none`	ההגדרה הזו ממפה שמות של אותות לכמות או לאחוז שמגדירים סף פינוי גמיש. לסף פינוי גמיש חייבת להיות תקופת חסד. ה-`kubelet` לא מפנה Pods עד שתקופת החסד מסתיימת.
`evictionSoftGracePeriod`	מפה של שמות האותות. לכל שם של אות, הערך חייב להיות משך זמן חיובי שקטן מ-`5m`. יחידות הזמן התקינות הן `ns`,‏ `us` (או `µs`),‏ `ms`,‏ `s` או `m`.	`none`	ההגדרה הזו ממפה שמות של אותות למשכי זמן שמגדירים תקופות חסד לספי פינוי גמישים. לכל סף פינוי לא קשיח חייבת להיות תקופת חסד תואמת.
`evictionMinimumReclaim`	מפה של שמות האותות. לכל שם של אות, הערך חייב להיות אחוז חיובי שקטן מ-`10%`.	`none`	ההגדרה הזו ממפה שמות של אותות לאחוזים שמגדירים את הכמות המינימלית של משאב נתון ש-`kubelet` מחזיר כשהוא מבצע פינוי של Pod.
`evictionMaxPodGracePeriodSeconds`	הערך חייב להיות מספר שלם בין `0` ל-`300`.	`0`	ההגדרה הזו קובעת, בשניות, את תקופת החסד המקסימלית לסיום Pod במהלך פינוי.
`singleProcessOOMKill`	הערך חייב להיות `true` או `false`.	‫`true` לצומתי cgroupv1,‏ `false` לצומתי cgroupv2.	ההגדרה הזו קובעת אם התהליכים בקונטיינר יופסקו בגלל מחסור בזיכרון (OOMkilled) בנפרד או כקבוצה. זמין בגרסאות GKE‏ 1.32.4-gke.1132000, ‏ 1.33.0-gke.1748000 ואילך.

בטבלה הבאה מוצגות האפשרויות שאפשר לשנות בדגל evictionSoft. אותן אפשרויות חלות גם על הדגלים evictionSoftGracePeriod ו-evictionMinimumReclaim, עם הגבלות שונות.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`memoryAvailable`	הערך חייב להיות כמות גדולה מ-`100Mi` וקטנה מ-`50%` של זיכרון הצומת.	`none`	ההגדרה הזו מייצגת את כמות הזיכרון הזמינה לפני פינוי קל. מגדיר את כמות האותות של `memory.available` ב-`kubelet` .
`nodefsAvailable`	הערך צריך להיות בין `10%` ל-`50%`.	`none`	ההגדרה הזו מייצגת את ה-nodefs שזמינים לפני פינוי זמני. מגדיר את כמות האותות של `nodefs.available` ב-`kubelet` .
`nodefsInodesFree`	הערך צריך להיות בין `5%` ל-`50%`.	`none`	ההגדרה הזו מייצגת את צומתי ה-inode של nodefs שפנויים לפני פינוי קל. מגדיר את כמות האותות של `nodefs.inodesFree` ב-`kubelet` .
`imagefsAvailable`	הערך צריך להיות בין `15%` ל-`50%`.	`none`	ההגדרה הזו מייצגת את ה-imagefs שזמין לפני פינוי רך. מגדיר את כמות האותות של `imagefs.available` ב-`kubelet` .
`imagefsInodesFree`	הערך צריך להיות בין `5%` ל-`50%`.	`none`	ההגדרה הזו מייצגת את צומתי ה-inode של imagefs שפנויים לפני פינוי רך. מגדיר את כמות האותות של `imagefs.inodesFree` ב-`kubelet`.
`pidAvailable`	הערך צריך להיות בין `10%` ל-`50%`.	`none`	ההגדרה הזו מייצגת את מזהי התהליכים שזמינים לפני פינוי קל. מגדיר את כמות האותות של `pid.available` ב-`kubelet`.

ניהול PID

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות בניהול PID.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`podPidsLimit`	הערך צריך להיות בין `1024` ל-`4194304`.	`none`	ההגדרה הזו קובעת את המספר המקסימלי של מזהי תהליכים (PID) שכל Pod יכול להשתמש בהם.

רישום ביומן

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות ביומן.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`containerLogMaxSize`	הערך חייב להיות מספר חיובי וסיומת יחידה בין `10Mi` ל-`500Mi`, כולל.	`10Mi`	ההגדרה הזו קובעת את ההגדרה containerLogMaxSize של מדיניות החלפת היומנים של מאגר התגים, שמאפשרת להגדיר את הגודל המקסימלי של כל קובץ יומן. ערך ברירת המחדל הוא `10Mi`. היחידות התקינות הן `Ki`,‏ `Mi` ו-`Gi`.
`containerLogMaxFiles`	הערך חייב להיות מספר שלם בין `2` ל-`10` (כולל).	`5`	ההגדרה הזו קובעת את ההגדרה containerLogMaxFiles של מדיניות הרוטציה של קובצי היומן של מאגר התגים, שמאפשרת להגדיר את המספר המקסימלי של קבצים שמותרים לכל מאגר תגים בהתאמה. ערך ברירת המחדל הוא `5`. הגודל הכולל של היומן `(container_log_max_size*container_log_max_files)` לכל קונטיינר לא יכול לחרוג מ-1% מסך האחסון של הצומת.

איסוף אשפה של תמונות

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות לאיסוף של תמונות.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`imageGcHighThresholdPercent`	הערך חייב להיות מספר שלם בין 10 ל-85 (כולל), וגבוה מ-`imageGcLowThresholdPercent`.	`85`	ההגדרה הזו קובעת את אחוז השימוש בדיסק שמעליו מופעל איסוף אשפה של תמונות. הוא מייצג את השימוש המקסימלי בדיסק לאיסוף. כדי לחשב את האחוז, המערכת מחלקת את הערך של השדה הזה ב-100.
`imageGcLowThresholdPercent`	הערך חייב להיות מספר שלם בין 10 ל-85 (כולל), ונמוך מ-`imageGcHighThresholdPercent`.	`80`	ההגדרה הזו קובעת את אחוז השימוש בדיסק שמתחתיו לא יתבצע אף פעם איסוף אשפה של תמונות. הוא מייצג את השימוש הנמוך ביותר בדיסק לאיסוף. כדי לחשב את האחוז, המערכת מחלקת את הערך של השדה הזה ב-100.
`imageMinimumGcAge`	הערך חייב להיות משך זמן שלא עולה על `2m`. יחידות הזמן התקינות הן `ns`,‏ `us` (או `µs`),‏ `ms`,‏ `s`,‏ `m` או `h`.	`2m`	ההגדרה הזו קובעת את הגיל המינימלי של תמונה שלא בשימוש לפני שהיא נאספת כזבל.
`imageMaximumGcAge`	הערך חייב להיות משך זמן.	`0s`	ההגדרה הזו קובעת את משך הזמן המקסימלי שבו תמונה יכולה להיות לא בשימוש לפני שהיא נאספת כזבל. ערך ברירת המחדל של השדה הזה הוא `0s`, והוא משבית את השדה. לכן, תמונות לא ייאספו כזבל אם לא נעשה בהן שימוש. כשמציינים את הערך הזה, הוא חייב להיות גדול מהערך של השדה `imageMinimumGcAge`. זמין בגרסאות GKE‏ 1.30.7-gke.1076000, ‏ 1.31.3-gke.1023000 ואילך.

שליפת תמונה

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות בשליפת תמונות.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`maxParallelImagePulls`	הערך חייב להיות מספר שלם בין 2 ל-5, כולל.	‫`2` או `3`, בהתאם לסוג הדיסק.	ההגדרה הזו קובעת את המספר המקסימלי של שליפות תמונות במקביל. ערך ברירת המחדל נקבע לפי סוג דיסק האתחול.

אבטחה ופעולות לא בטוחות

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות כדי להגדיר את האבטחה ולטפל בפעולות לא בטוחות.

הגדרות אישיות של kubelet הגבלות הגדרת ברירת המחדל תיאור

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`allowedUnsafeSysctls`	רשימה של `sysctl` שמות או קבוצות. אלה `sysctl` הקבוצות המורשות: `kernel.shm` `kernel.msg` `kernel.sem` `fs.mqueue.` `net.`.	`none`	ההגדרה הזו מגדירה רשימת היתרים מופרדת בפסיקים של שמות `sysctl` לא בטוחים או קבוצות `sysctl` שאפשר להגדיר ב-Pods.
`insecureKubeletReadonlyPortEnabled`	הערך חייב להיות ערך בוליאני, `true` או `false`.	`false`	ההגדרה הזו משביתה את היציאה הלא מאובטחת `kubelet` לקריאה בלבד `10255` בכל מאגר צמתים חדש באשכול. אם קובעים את ההגדרה הזו בקובץ, אי אפשר להשתמש בלקוח API של GKE כדי לשנות את ההגדרה ברמת האשכול.

allowedUnsafeSysctls

רשימה של sysctl שמות או קבוצות. אלה sysctl הקבוצות המורשות:

kernel.shm*
kernel.msg*
kernel.sem
fs.mqueue.*
net.*.

none

ההגדרה הזו מגדירה רשימת היתרים מופרדת בפסיקים של שמות sysctl לא בטוחים או קבוצות sysctl שאפשר להגדיר ב-Pods.

insecureKubeletReadonlyPortEnabled הערך חייב להיות ערך בוליאני, true או false. false ההגדרה הזו משביתה את היציאה הלא מאובטחת kubelet לקריאה בלבד 10255 בכל מאגר צמתים חדש באשכול. אם קובעים את ההגדרה הזו בקובץ, אי אפשר להשתמש בלקוח API של GKE כדי לשנות את ההגדרה ברמת האשכול.

מנהלי משאבים

ב-Kubernetes יש חבילה של מנהלי משאבים. אתם יכולים להגדיר את מנהלי המשאבים האלה כדי לתאם ולייעל את ההתאמה של משאבי הצומת לפודים שמוגדרים עם דרישות ספציפיות למשאבי מעבדים, מכשירים וזיכרון (hugepages).

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות במנהלי המשאבים.

הגדרות אישיות של kubelet הגבלות הגדרת ברירת המחדל תיאור

cpuManagerPolicy הערך חייב להיות none או static. none ההגדרה הזו קובעת את מדיניות מנהל המעבד (CPU) של kubelet. ערך ברירת המחדל הוא none, שהוא סכימת ברירת המחדל של שיוך ה-CPU, ולא מספק שיוך מעבר למה שמתזמן מערכת ההפעלה עושה באופן אוטומטי.

הגדרת הערך הזה ל-static מאפשרת להקצות מעבדי CPU בלעדיים לפודים שנמצאים במחלקת ה-QoS של Guaranteed ויש להם בקשות CPU של מספרים שלמים.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`cpuManagerPolicy`	הערך חייב להיות `none` או `static`.	`none`	ההגדרה הזו קובעת את מדיניות מנהל המעבד (CPU) של `kubelet`. ערך ברירת המחדל הוא `none`, שהוא סכימת ברירת המחדל של שיוך ה-CPU, ולא מספק שיוך מעבר למה שמתזמן מערכת ההפעלה עושה באופן אוטומטי. הגדרת הערך הזה ל-`static` מאפשרת להקצות מעבדי CPU בלעדיים לפודים שנמצאים במחלקת ה-QoS של `Guaranteed` ויש להם בקשות CPU של מספרים שלמים.
`memoryManager.policy`	הערך חייב להיות `None` או `Static`.	`None`	ההגדרה הזו קובעת את המדיניות של מנהל הזיכרון ב-`kubelet`. עם ערך ברירת המחדל `None`, ‏Kubernetes פועל כאילו מנהל הזיכרון לא קיים. אם מגדירים את הערך הזה ל-`Static`, המדיניות של מנהל הזיכרון שולחת רמזים לטופולוגיה שתלויים בסוג ה-Pod. פרטים נוספים זמינים במאמר מדיניות סטטית. ההגדרה הזו נתמכת באשכולות שבהם מישור הבקרה פועל ב-GKE מגרסה 1.32.3-gke.1785000 ואילך.
`topologyManager`	הערך חייב להיות אחת מההגדרות הנתמכות בכל אחד מהשדות הרלוונטיים. אי אפשר להגדיר את השדה `topologyManager` כשמשתמשים בהוראות של Terraform כדי להוסיף את ההגדרה למאגר צמתים רגיל.	`policy`: `none` `scope`: `container`	ההגדרות האלה קובעות את ההגדרה של Topology Manager ב-`kubelet` באמצעות שדות המשנה `policy` ו-`scope`. מנהל הטופולוגיה מתאם את קבוצת הרכיבים שאחראים לאופטימיזציות של ביצועים שקשורות לבידוד של המעבד (CPU), לזיכרון ולמיקום המכשיר. אפשר להגדיר את המדיניות ואת היקף ההרשאות בנפרד. מידע נוסף על ההגדרות האלה זמין במאמר היקפים וכללי מדיניות של מנהל הטופולוגיה. משאבי GKE הבאים תומכים בהגדרה הזו: אשכולות שבהם מישור הבקרה מריץ את GKE בגרסה 1.32.3-gke.1785000 ואילך. באשכולות שבהם מישור הבקרה והצמתים מריצים את גרסה ‎1.33.0-gke.1712000 ואילך, מנהל הטופולוגיה מקבל גם מידע על טופולוגיית ה-GPU. צמתים עם סוגי המכונות הבאים: A2, ‏ A3, ‏ A4, ‏ C3, ‏ C4, ‏ C4A, ‏ C4N, ‏ G2, ‏ G4, ‏ M3, ‏ N4

memoryManager.policy

הערך חייב להיות None או Static.

None

ההגדרה הזו קובעת את המדיניות של מנהל הזיכרון ב-kubelet. עם ערך ברירת המחדל None, ‏Kubernetes פועל כאילו מנהל הזיכרון לא קיים.

אם מגדירים את הערך הזה ל-Static, המדיניות של מנהל הזיכרון שולחת רמזים לטופולוגיה שתלויים בסוג ה-Pod. פרטים נוספים זמינים במאמר מדיניות סטטית.

ההגדרה הזו נתמכת באשכולות שבהם מישור הבקרה פועל ב-GKE מגרסה 1.32.3-gke.1785000 ואילך.

topologyManager

הערך חייב להיות אחת מההגדרות הנתמכות בכל אחד מהשדות הרלוונטיים.

אי אפשר להגדיר את השדה topologyManager כשמשתמשים בהוראות של Terraform כדי להוסיף את ההגדרה למאגר צמתים רגיל.

policy: none
scope: container

ההגדרות האלה קובעות את ההגדרה של Topology Manager ב-kubelet באמצעות שדות המשנה policy ו-scope. מנהל הטופולוגיה מתאם את קבוצת הרכיבים שאחראים לאופטימיזציות של ביצועים שקשורות לבידוד של המעבד (CPU), לזיכרון ולמיקום המכשיר.

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

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

אשכולות שבהם מישור הבקרה מריץ את GKE בגרסה 1.32.3-gke.1785000 ואילך. באשכולות שבהם מישור הבקרה והצמתים מריצים את גרסה ‎1.33.0-gke.1712000 ואילך, מנהל הטופולוגיה מקבל גם מידע על טופולוגיית ה-GPU.
צמתים עם סוגי המכונות הבאים: A2, ‏ A3, ‏ A4, ‏ C3, ‏ C4, ‏ C4A, ‏ C4N, ‏ G2, ‏ G4, ‏ M3, ‏ N4

השהיה בהפעלה מחדש של קונטיינר

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

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות ב-crashLoopBackOff.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`crashLoopBackOff.maxContainerRestartPeriod`	הערך חייב להיות משך זמן חיובי של עד 5 דקות (`5m`). יחידות הזמן החוקיות הן `ns`,‏ `us` (או `µs`),‏ `ms`,‏ `s` או `m`.	`none`	משך הזמן המקסימלי שההשהיה של ההמתנה יכולה לצבור להפעלות מחדש של קונטיינרים. ההשהיה בין ההפעלות מחדש גדלה באופן אקספוננציאלי מערך התחלתי ועד למגבלה המקסימלית הזו. כברירת מחדל, המגבלה המקסימלית לאשכול Kubernetes היא 5 דקות. מידע נוסף זמין במאמר השהיה ניתנת להגדרה של הפעלה מחדש של קונטיינר.

סגירה מבוקרת של מכונות וירטואליות במודל Spot ב-GKE

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות לתקופת הסיום והכיבוי המבוקר של מכונות וירטואליות במודל Spot ב-GKE. כדי להשתמש באפשרויות האלה, מישור הבקרה של האשכול צריך להריץ את GKE בגרסה ‎1.35.0-gke.1171000‎ ואילך. מידע נוסף מופיע במאמר איך פועלות מכונות וירטואליות במחיר Spot ב-GKE.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`shutdownGracePeriodSeconds`	הערך חייב להיות מספר שלם שמייצג את משך הזמן בשניות. הערכים המותרים הם `0`,‏ `30` או `120`.	`30`	מציינת את משך הזמן הכולל בשניות שבו הצומת מעכב את הכיבוי כדי לסיים את הפעילות של Pods בצורה תקינה.
`shutdownGracePeriodCriticalPodsSeconds`	הערך חייב להיות מספר שלם בין `0` ל-`120` (כולל), וקטן מ-`shutdownGracePeriodSeconds`. תקף רק אם גם `shutdownGracePeriodSeconds` מוגדר.	`15`	מציינת את משך הזמן בשניות שמשמש לסגירת Pods קריטיים במהלך כיבוי של צומת.

הזמנת משאבי מערכת

במאגרי צמתים רגילים שפועלים ב-Linux וב-GKE בגרסה 1.37 ואילך, אפשר להתאים אישית את כמות הזיכרון והמעבד (CPU) ששמורים לרכיבי המערכת. כך אפשר לכוונן את הקיבולת שניתנת להקצאה בתרחישים ספציפיים, כמו טיפול בשליפת תמונות בנפח גבוה או הפעלת DaemonSets בהתאמה אישית בצומת. מידע נוסף על הקצאות ברירת המחדל זמין במאמר מידע על גודל הצומת ב-GKE.

בטבלה הבאה מתוארות האפשרויות שאפשר לשנות בהקצאות של משאבי המערכת.

הגדרות אישיות של `kubelet`	הגבלות	הגדרת ברירת המחדל	תיאור
`reservedResourcesConfig.memoryReservedMib`	הערך חייב להיות מספר שלם. הערך חייב להיות גדול או שווה להקצאת הזיכרון שמוגדרת כברירת מחדל למאגרי צמתים שנוצרו בגרסה 1.37 ואילך, וקטן מ-50% מקיבולת הזיכרון הכוללת של הצומת.	הקצאות זיכרון	נפח הזיכרון שצריך להקצות לרכיבי המערכת, במגה-בייטים (MiB).
`reservedResourcesConfig.cpuReservedMillicore`	הערך חייב להיות מספר שלם. הערך חייב להיות גדול או שווה להקצאת ברירת המחדל של המעבד (CPU) למאגרי צמתים שנוצרו בגרסה 1.37 ואילך, וקטן מ-50% מקיבולת המעבד הכוללת של הצומת.	הזמנות של מעבדים (CPU)	כמות המעבד (CPU) שצריך להקצות לרכיבי המערכת, באלפיות ליבה.

אימות הזמנות בפועל

כדי לבדוק את ההזמנות הפעילות שחלות על מאגר הצמתים, בודקים את שדות הפלט effectiveMemoryReservedMib ו-effectiveCpuReservedMillicore:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig.reservedResourcesConfig)"

אפשרויות הגדרה של Sysctl

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

פרמטרים של מערכת הקבצים (`fs.*`)

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

פרמטר `Sysctl`	הגבלות	תיאור
`fs.aio-max-nr`	הערך חייב להיות בין [65536, 4194304].	ההגדרה הזו קובעת את המספר המקסימלי של בקשות קלט/פלט (I/O) אסינכרוניות בכל המערכת.
`fs.file-max`	הערך חייב להיות בין [104857, 67108864].	ההגדרה הזו קובעת את המספר המקסימלי של נקודות אחיזה בקבצים שליבת Linux יכולה להקצות.
`fs.inotify.max_user_instances`	הערך חייב להיות בין [8192, 1048576].	ההגדרה הזו קובעת את המספר המקסימלי של מכונות inotify שמשתמש יכול ליצור.
`fs.inotify.max_user_watches`	הערך חייב להיות בין [8192, 1048576].	ההגדרה הזו קובעת את המספר המקסימלי של מעקבי inotify שמשתמש יכול ליצור.
`fs.nr_open`	הערך חייב להיות בין [1048576, 2147483584].	ההגדרה הזו קובעת את המספר המקסימלי של תיאורי קבצים שתהליך יכול לפתוח.

פרמטרים של ליבה (`kernel.*`)

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

פרמטר Sysctl	הגבלות	תיאור
`kernel.shmmni`	הערך חייב להיות בין 4,096 ל-32,768.	ההגדרה הזו קובעת את המספר המקסימלי של מקטעי זיכרון משותפים בכל המערכת. אם הערך הזה לא מוגדר, ברירת המחדל היא `4096`.
`kernel.shmmax`	הערך צריך להיות בין [0, 18446744073692774399].	ההגדרה הזו קובעת את הגודל המקסימלי, בבייטים, של מקטע זיכרון משותף אחד שמותר לליבה. המערכת מתעלמת מהערך הזה אם הוא גדול מהכמות בפועל של זיכרון ה-RAM, כלומר אפשר לשתף את כל זיכרון ה-RAM הזמין.
`kernel.shmall`	הערך צריך להיות בין [0, 18446744073692774399].	ההגדרה הזו קובעת את הכמות הכוללת של דפי זיכרון משותפים שאפשר להשתמש בהם במערכת בו-זמנית. דף הוא בגודל 4,096 בייטים בארכיטקטורת AMD64 ו-Intel 64.
`kernel.perf_event_paranoid`	הערך חייב להיות בין ‎[-1, 3]‎.	ההגדרה הזו קובעת את השימוש במערכת אירועי הביצועים על ידי משתמשים ללא הרשאות וללא CAP_PERFMON. ערך ברירת המחדל הוא `2` בקרנל.
`kernel.sched_rt_runtime_us`	הערך חייב להיות בין ‎-1 ל-1,000,000.	ההגדרה הזו קובעת מגבלה גלובלית על משך הזמן שבו אפשר להשתמש בתזמון בזמן אמת.
`kernel.softlockup_panic`	אופציונלי (בוליאני).	ההגדרה הזו קובעת אם הליבה תגיב לשגיאת ליבה קריטית כשמזוהה נעילה זמנית.
`kernel.yama.ptrace_scope`	הערך צריך להיות בין [0, 3].	ההגדרה הזו קובעת את ההיקף וההגבלות של קריאת המערכת `ptrace()`, ומשפיעה על ניפוי הבאגים ועל המעקב אחר תהליכים. הערכים הנתמכים כוללים: ‫`0`: הרשאות ptrace קלאסיות. ‫`1`: ptrace מוגבל, שהוא ברירת המחדל בהרבה הפצות. רק תהליכים משניים או CAP_SYS_PTRACE. ‫`2`: ptrace לאדמינים בלבד. רק תהליכים עם CAP_SYS_PTRACE. ‫`3`: אין ptrace. אסור להשתמש בקריאות ptrace.
`kernel.kptr_restrict`	הערך צריך להיות בין [0, 2].	ההגדרה הזו מציינת אם יש הגבלות על חשיפת כתובות ליבה דרך `/proc` וממשקים אחרים.
`kernel.dmesg_restrict`	אופציונלי (בוליאני).	ההגדרה הזו קובעת אם למשתמשים ללא הרשאות מיוחדות אין אפשרות להשתמש ב-`dmesg(8)` כדי להציג הודעות ממאגר הנתונים הזמני של יומן הליבה.
`kernel.sysrq`	הערך צריך להיות בין 0 ל-511.	ההגדרה הזו קובעת אילו פונקציות אפשר להפעיל באמצעות המקש SysRq. הערכים האפשריים כוללים: ‫`0`: משבית את sysrq לגמרי. ‫`1`: הפעלת כל הפונקציות של sysrq. ‫`>1`: מסכת סיביות של פונקציות sysrq מותרות. מידע נוסף זמין במאמר Linux Magic System Request Key Hacks.
`kernel.keys.maxbytes`	הערך צריך להיות בין [20000, 2097152].	ההגדרה הזו קובעת את המספר המקסימלי של בייטים שמשתמש שאינו משתמש בסיסי יכול להחזיק בקטע המטען הייעודי (payload) של כל המפתחות שלו.
`kernel.keys.maxkeys`	הערך חייב להיות בין [200, 1048576].	ההגדרה הזו קובעת את המספר המקסימלי של מפתחות שיכולים להיות בבעלות של משתמש שאינו משתמש בסיסי.

פרמטרים של רשת (`net.*`)

בטבלה הבאה מתוארים הפרמטרים שאפשר לשנות ברשת. ההגדרות האלה מכווננות את הביצועים וההתנהגות של מקבץ הרשת (network stack), ממאגרי נתונים זמניים של שקעים ועד למעקב אחרי חיבורים.

פרמטר Sysctl	הגבלות	תיאור
`net.core.busy_poll`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את הזמן הקצוב לתפוסה של דגימה עם זמן אחזור קצר, לדגימה ולבחירה. הוא מייצג את הזמן המשוער במיקרו-שניות של לולאת המתנה פעילה לאירועים.
`net.core.busy_read`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את הזמן הקצוב לתפוגה של סקרים פעילים עם זמן אחזור קצר לקריאות של שקעים. הוא מייצג את הזמן המשוער במיקרו-שניות של לולאת המתנה פעילה למנות בתור של המכשיר.
`net.core.netdev_max_backlog`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את המספר המקסימלי של חבילות נתונים בתור בצד הקלט, כשהממשק מקבל חבילות נתונים מהר יותר מהקצב שבו הליבה יכולה לעבד אותן.
`net.core.rmem_default`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את גודל ברירת המחדל של שטח האחסון הזמני של שקע הקבלה, בבייטים.
`net.core.rmem_max`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את הגודל המקסימלי של שטח האחסון הזמני של שקע הקבלה, בבייטים.
`net.core.wmem_default`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את הגדרת ברירת המחדל, בבייטים, של מאגר הנתונים הזמני לשליחה של השקע.
`net.core.wmem_max`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את הגודל המקסימלי של מאגר הנתונים הזמני לשליחת שקעים, בבייטים.
`net.core.optmem_max`	מספר שלם חיובי, קטן מ-2147483647.	ההגדרה הזו קובעת את הגודל המקסימלי של שטח אחסון זמני משני שמותר לכל שקע.
`net.core.somaxconn`	הערך צריך להיות בין 128 ל-2,147,483,647.	ההגדרה הזו קובעת את המגבלה של צבר המשימות של `socket listen()`, שנקרא SOMAXCONN במרחב המשתמש. ברירת המחדל של ההגדרה הזו היא `128`.
`net.ipv4.tcp_rmem`	‫{min, default, max} (כל אחד > 0, זיכרון בבייטים).	ההגדרה הזו קובעת את הגודל המינימלי, בבייטים, של מאגר הנתונים הזמני לקבלה שמשמש את שקעי ה-UDP בניהול התוכן. הגדרת ברירת המחדל היא דף אחד.
`net.ipv4.tcp_wmem`	‫{min, default, max} (כל אחד > 0, זיכרון בבייטים).	ההגדרה הזו קובעת את הגודל המינימלי, בבייטים, של מאגר הנתונים הזמני לשליחה שמשמש את שקעי ה-UDP במצב ניהול תוכן. הגדרת ברירת המחדל היא דף אחד.
`net.ipv4.tcp_tw_reuse`	הערך צריך להיות בין {0, 1}.	ההגדרה הזו קובעת אם לאפשר שימוש חוזר בשקעים במצב `TIME_WAIT` לחיבורים חדשים, כשהדבר בטוח מבחינת הפרוטוקול. ערך ברירת המחדל הוא `0`.
`net.ipv4.tcp_max_orphans`	הערך צריך להיות בין [16384, 262144].	ההגדרה הזו קובעת את המספר המקסימלי של שקעי TCP שלא מחוברים לאף נקודת אחיזה בקובץ של המשתמש.
`net.ipv4.tcp_max_tw_buckets`	הערך צריך להיות בין 4096 ל-2147483647.	ההגדרה הזו קובעת את המספר המקסימלי של שקעי timewait שהמערכת יכולה להחזיק בו-זמנית. אם חורגים מהמספר הזה, השקע של זמן ההמתנה נהרס באופן מיידי ומודפסת אזהרה.
`net.ipv4.tcp_syn_retries`	הערך חייב להיות בין 1 ל-127.	ההגדרה הזו קובעת את מספר הפעמים שבהן נשלחות מחדש בקשות SYN ראשוניות לניסיון חיבור TCP פעיל.
`net.ipv4.tcp_ecn`	הערך צריך להיות בין [0, 2].	ההגדרה הזו קובעת את השימוש ב-Explicit Congestion Notification‏ (ECN) על ידי TCP. המערכת משתמשת ב-ECN רק כששני הקצוות של חיבור ה-TCP מציינים שהם תומכים בו.
`net.ipv4.tcp_mtu_probing`	הערך צריך להיות בין [0, 2].	ההגדרה הזו קובעת את גילוי ה-MTU של נתיב שכבת החבילות של TCP. אלה הערכים הנתמכים: ‫`0`: מושבת. ‫`1`: מושבת כברירת מחדל, מופעל כשמזוהה חור שחור של ICMP. ‫`2`: תמיד מופעל. משתמשים ב-MSS הראשוני של `tcp_base_mss`.
`net.ipv4.tcp_congestion_control`	צריך להיות אחד מהערכים הנתמכים מהעמודה תיאור.	ההגדרה הזו לא נתמכת כש-GKE Dataplane V2 מופעל באשכול. הערכים הנתמכים הבאים תלויים בסוג התמונה: ‫`Container-Optimized OS`: `reno`, `cubic`, `bbr`, `lp`, `htcp` (זמין בגרסאות GKE 1.34.1-gke.3355001 ואילך) `Ubuntu`: `reno`, `cubic`, `bbr`, `lp`, `htcp`, `vegas`, `dctcp`, `bic`, `cdg`, `highspeed`, `hybla`, `illinois`, `nv`, `scalable`, `veno`, `westwood`, `yeah`
`net.ipv6.conf.all.disable_ipv6`	בוליאני.	שינוי הערך הזה זהה לשינוי ההגדרה `conf/default/disable_ipv6` וגם כל ההגדרות של `disable_ipv6` לכל ממשק לאותו ערך.
`net.ipv6.conf.default.disable_ipv6`	בוליאני.	ההגדרה הזו משביתה את הפעולה של IPv6.
`net.netfilter.nf_conntrack_acct`	הערך צריך להיות בין {0, 1}.	ההגדרה הזו מפעילה את החשבונאות של תהליך מעקב החיבורים. ערך ברירת המחדל הוא `0`, כלומר ההגדרה מושבתת. זמין בגרסאות GKE‏ 1.32.0-gke.1448000 ואילך.
`net.netfilter.nf_conntrack_max`	הערך חייב להיות בין [65536, 4194304].	ההגדרה הזו קובעת את הגודל של טבלת מעקב החיבורים. אם מגיעים למכסה המקסימלית, הקישור החדש נכשל. זמין בגרסאות GKE‏ 1.32.0-gke.1448000 ואילך.
`net.netfilter.nf_conntrack_buckets`	הערך צריך להיות בין [65536, 524288].	ההגדרה הזו קובעת את הגודל של טבלת הגיבוב. ההגדרה המומלצת היא התוצאה של: `nf_conntrack_max = nf_conntrack_buckets * 4`. זמין בגרסאות GKE‏ 1.32.0-gke.1448000 ואילך.
`net.netfilter.nf_conntrack_tcp_timeout_close_wait`	הערך צריך להיות בין 60 ל-3, 600.	ההגדרה הזו קובעת את משך הזמן, בשניות, שבו חיבורי ה-TCP יכולים להישאר במצב `CLOSE_WAIT`. ערך ברירת המחדל הוא `3600`. זמין בגרסאות GKE‏ 1.32.0-gke.1448000 ואילך.
`net.netfilter.nf_conntrack_tcp_timeout_established`	הערך חייב להיות בין [600, 86400].	ההגדרה הזו קובעת את משך הזמן, בשניות, של חיבורים לא פעילים לפני שהם נמחקים באופן אוטומטי מטבלת מעקב החיבורים. זמין בגרסאות GKE‏ 1.32.0-gke.1448000 ואילך.
`net.netfilter.nf_conntrack_tcp_timeout_time_wait`	הערך חייב להיות בין 1 ל-600.	ההגדרה הזו קובעת את משך הזמן, בשניות, שבו חיבורי ה-TCP יכולים להישאר במצב `TIME_WAIT`. ערך ברירת המחדל הוא `120`. זמין בגרסאות GKE‏ 1.32.0-gke.1448000 ואילך.
`net.ipv4.neigh.default.gc_thresh1`	הערך חייב להיות בין [0, 262144].	ההגדרה הזו קובעת את מספר הרשומות המינימלי שיישמרו במטמון של ה-ARP. מנגנון איסוף האשפה לא פועל אם מספר הרשומות נמוך מההגדרה הזו. הגדרת הערך הזה ל-`0` עלולה לגרום ל-cache thrashing ולפגוע בביצועים.
`net.ipv4.neigh.default.gc_thresh2`	הערך חייב להיות בין [512, 524288].	ההגדרה הזו קובעת את המספר המקסימלי של רשומות שאפשר לשמור במטמון של פרוטוקול ARP. אוסף האשפה מאפשר למספר הערכים לחרוג מערך זה למשך 5 שניות לפני שהוא מתחיל איסוף אשפה רך.
`net.ipv4.neigh.default.gc_thresh3`	הערך חייב להיות בין [1024, 1048576].	ההגדרה הזו קובעת את המספר המקסימלי של רשומות שיישמרו במטמון ה-ARP. מנגנון איסוף האשפה מתוכנן לפעול תמיד אם מספר הרשומות חורג מההגדרה הזו.

פרמטרים של זיכרון וירטואלי (`vm.*`)

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

פרמטר `sysctl`	הגבלות	תיאור
`vm.max_map_count`	הערך חייב להיות בין [65536, 2147483647].	הקובץ הזה מגדיר את המספר המקסימלי של אזורים במפת הזיכרון שיכולים להיות לתהליך.
`vm.dirty_background_ratio`	הערך חייב להיות בין 1 ל-100.	ההגדרה הזו קובעת את אחוז הזיכרון של המערכת שאפשר למלא בדפים מלוכלכים לפני ששרשורי ה-flusher של הליבה ברקע מתחילים את פעולת ה-writeback. הערך צריך להיות קטן מהערך של השדה `vm.dirty_ratio`.
`vm.dirty_background_bytes`	הערך חייב להיות בין [0, 68719476736].	ההגדרה הזו קובעת את כמות הזיכרון המלוכלך שבה השרשורים של מנקה הליבה ברקע מתחילים את פעולת הכתיבה לאחור. חשוב לזכור ש-`vm.dirty_background_bytes` הוא המקביל של `vm.dirty_background_ratio`. אפשר לציין רק אחת מההגדרות האלה.
`vm.dirty_expire_centisecs`	הערך צריך להיות בין 0 ל-6, 000.	ההגדרה הזו קובעת את הגיל המקסימלי, במאיות השנייה, שבו נתונים מלוכלכים יכולים להישאר בזיכרון לפני ששרשורי ה-flusher של הליבה כותבים אותם בדיסק.
`vm.dirty_ratio`	הערך חייב להיות בין 1 ל-100.	ההגדרה הזו קובעת את אחוז הזיכרון של המערכת שאפשר למלא בדפים מלוכלכים לפני שתהליכים שמבצעים כתיבה נאלצים לחסום ולכתוב נתונים מלוכלכים באופן סינכרוני.
`vm.dirty_bytes`	הערך חייב להיות בין [0, 68719476736].	ההגדרה הזו קובעת את כמות הזיכרון המלוכלך שבה תהליך שיוצר כתיבות בדיסק מתחיל כתיבה לאחור בעצמו. הערך המינימלי המותר ל-`vm.dirty_bytes` הוא שני דפים בבייטים. המערכת תתעלם מכל ערך שנמוך מהמגבלה הזו, וההגדרה הישנה תישמר. חשוב לזכור ש-`vm.dirty_bytes` הוא המקביל של `vm.dirty_ratio`. אפשר לציין רק אחת מההגדרות האלה.
`vm.dirty_writeback_centisecs`	הערך חייב להיות בין 0 ל-1, 000.	ההגדרה הזו קובעת את המרווח, במאיות השנייה, שבו שרשורי ה-flusher של הליבה מתעוררים כדי לכתוב נתונים מלוכלכים ישנים לדיסק.
`vm.overcommit_memory`	הערך צריך להיות {0, 1, 2}.	ההגדרה הזו קובעת את האסטרטגיה של הליבה לטיפול בהקצאת יתר של זיכרון. אלה הערכים: ‫`0`: דחיית הקצאות גדולות ‫`1`: בלי הגבלת שימוש (ערך ברירת המחדל) ‫`2`: מניעת הקצאה מעבר לזיכרון הווירטואלי + יחס של זיכרון RAM ההגדרה הזו לא נתמכת במחשבים עם זיכרון של פחות מ-15GB.
`vm.overcommit_ratio`	הערך צריך להיות בין 0 ל-100.	ההגדרה הזו קובעת את אחוז ה-RAM הפיזי שמותר להקצות יתר על המידה כשהערך של השדה `vm.overcommit_memory` מוגדר כ-`2`.
`vm.vfs_cache_pressure`	הערך צריך להיות בין 0 ל-100.	ההגדרה הזו משנה את העדפת הליבה (kernel) לגבי החזרת הזיכרון שמשמש למטמונים של dentry (ספרייה) ו-inode.
`vm.swappiness`	הערך חייב להיות בין 0 ל-200.	ההגדרה הזו קובעת את הנטייה של הליבה להעביר תהליכים מהזיכרון הפיזי לדיסק ההחלפה. ערך ברירת המחדל הוא `60`.
`vm.watermark_scale_factor`	הערך צריך להיות בין 10 ל-3, 000.	ההגדרה הזו קובעת את מידת האגרסיביות של kswapd. הוא מגדיר את הזיכרון שנותר לפני ש-kswapd מתעורר ואת הזיכרון שצריך לפנות לפני שהוא נכנס למצב שינה. ערך ברירת המחדל הוא `10`.
`vm.min_free_kbytes`	הערך חייב להיות בין [67584, 1048576].	ההגדרה הזו קובעת את הזיכרון הפנוי המינימלי לפני OOM. ערך ברירת המחדל הוא `67584`.

מידע נוסף על הערכים הנתמכים לכל דגל sysctl זמין במסמכי התיעוד של ה-CLI של gcloud בנושא ‎--system-config-from-file.

למרחבי שמות שונים של Linux יכולים להיות ערכים ייחודיים לדגל sysctl נתון, אבל אחרים יכולים להיות גלובליים לכל הצומת. עדכון האפשרויות של sysctl באמצעות הגדרת מערכת של צומת עוזר לוודא שה-sysctl מוחל באופן גלובלי על הצומת ובכל מרחב שמות, כך שלכל Pod יש ערכי sysctl זהים בכל מרחב שמות של Linux.

אפשרויות הגדרה של מצב cgroup ב-Linux

סביבת זמן הריצה של הקונטיינר ו-kubelet משתמשים ב-cgroups של ליבת Linux לניהול משאבים, כמו הגבלת כמות ה-CPU או הזיכרון שכל קונטיינר ב-Pod יכול לגשת אליהם. יש שתי גרסאות של תת-המערכת cgroup בליבה: cgroupv1 ו-cgroupv2. התמיכה של Kubernetes ב-cgroupv2 הושקה כגרסת אלפא ב-Kubernetes בגרסה 1.18, כגרסת בטא בגרסה 1.22 וכגרסת GA בגרסה 1.25. למידע נוסף, קראו את המסמכים של Kubernetes בנושא cgroups v2.

הגדרת המערכת של הצומת מאפשרת להתאים אישית את הגדרת ה-cgroup של מאגרי הצמתים. אפשר להשתמש ב-cgroupv1 או ב-cgroupv2. ב-GKE, במאגרי צמתים חדשים מסוג Standard שפועלים בגרסה 1.26 ואילך נעשה שימוש ב-cgroupv2, ובמאגרי צמתים שפועלים בגרסאות קודמות ל-1.26 נעשה שימוש ב-cgroupv1. במאגרי צמתים שנוצרו באמצעות הקצאת צמתים אוטומטית, הגדרת ה-cgroup תלויה בגרסת האשכול הראשונית, ולא בגרסת מאגר הצמתים. אי אפשר להשתמש ב-cgroupv1 במכונות Arm.

אתם יכולים להשתמש בהגדרות המערכת של הצומת כדי לשנות את ההגדרה של מאגר צמתים, כך שישתמש ב-cgroupv1 או ב-cgroupv2 באופן מפורש. אם משדרגים לגרסה 1.26 מאגר צמתים קיים שמשתמש ב-cgroupv1, ההגדרה לא משתנה ל-cgroupv2. מאגרי צמתים קיימים שמריצים גרסה שקודמת ל-1.26, ולא כוללים הגדרת cgroup בהתאמה אישית, ימשיכו להשתמש ב-cgroupv1. כדי לשנות את ההגדרה, צריך לציין במפורש את הערך cgroupv2 למאגר הצמתים הקיים.

לדוגמה, כדי להגדיר את מאגר הצמתים לשימוש ב-cgroupv2, משתמשים בקובץ תצורה של מערכת הצמתים, כמו הקובץ הבא:

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

אלה האפשרויות הנתמכות של cgroupMode:

‫CGROUP_MODE_V1: שימוש ב-cgroupv1 במאגר הצמתים.
‫CGROUP_MODE_V2: שימוש ב-cgroupv2 במאגר הצמתים.
‫CGROUP_MODE_UNSPECIFIED: שימוש בהגדרת ברירת המחדל של cgroup ב-GKE.

כדי להשתמש ב-cgroupv2, צריך לעמוד בדרישות ובמגבלות הבאות:

במאגר צמתים שפועל בגרסה שקודמת ל-1.26, צריך להשתמש ב-CLI של gcloud בגרסה 408.0.0 ואילך. לחלופין, אפשר להשתמש ב-gcloud beta בגרסה 395.0.0 ואילך.
באשכול ובמאגרי הצמתים צריכה לפעול גרסת GKE‏ 1.24.2-gke.300 ואילך.
צריך להשתמש בתמונת צומת של מערכת הפעלה שמותאמת לקונטיינרים עם containerd או של Ubuntu עם containerd.
אם אחד מעומסי העבודה שלכם תלוי בקריאה של מערכת הקבצים cgroup (/sys/fs/cgroup/...), ודאו שהם תואמים ל-API של cgroupv2.
אם אתם משתמשים בכלים של צד שלישי או בכלים למעקב, ודאו שהם תואמים ל-cgroupv2.
אם אתם משתמשים בעומסי עבודה של Java‏ (JDK), מומלץ להשתמש בגרסאות שתומכות באופן מלא ב-cgroupv2, כולל JDK 8u372, ‏JDK 11.0.16 ואילך או JDK 15 ואילך.

אימות ההגדרות של cgroup

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

כדי לבדוק את הגדרת ה-cgroup של צמתים במאגר צמתים, אתם יכולים להשתמש ב-CLI של gcloud או בכלי שורת הפקודה kubectl:

‫CLI של gcloud

בודקים את ההגדרה של cgroup למאגר צמתים:

gcloud container node-pools describe POOL_NAME \
  --format='value(Config.effectiveCgroupMode)'

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

הפלט האפשרי הוא אחד מהבאים:

EFFECTIVE_CGROUP_MODE_V1: הצמתים משתמשים ב-cgroupv1
EFFECTIVE_CGROUP_MODE_V2: הצמתים משתמשים ב-cgroupv2

הפלט מציג רק את הגדרת ה-cgroup החדשה אחרי שהצמתים במאגר הצמתים נוצרים מחדש. הפלט ריק למאגרי צמתים של שרת Windows, שלא תומכים ב-cgroup.

kubectl

כדי להשתמש ב-kubectl לאימות ההגדרה של cgroup לצמתים במאגר הצמתים הזה, בוחרים צומת ומתחברים אליו לפי ההוראות הבאות:

ליצור מעטפת אינטראקטיבית עם כל צומת במאגר הצמתים. בפקודה, מחליפים את mynode בשם של אחד מהצמתים במאגר צמתים.
זיהוי גרסת ה-cgroup בצומתי Linux

אפשרויות הגדרה של דפים גדולים ב-Linux

אתם יכולים להשתמש ב-hugepages שהוקצו מראש באופן ידני או ב-transparent hugepages שהוקצו באופן אוטומטי.

דפים ענקיים שהוקצו מראש

אתם יכולים להשתמש בקובץ תצורה של מערכת הצמתים כדי להקצות מראש hugepages. ב-Kubernetes אפשר להקצות מראש דפי ענק כסוג משאב, בדומה למעבד (CPU) או לזיכרון.

כדי להשתמש ב-hugepages, צריך לעמוד במגבלות ובדרישות הבאות:

כדי לוודא שהצומת לא תפוס כולו על ידי hugepages, הגודל הכולל של ה-hugepages שהוקצו לא יכול לחרוג מהערכים הבאים:
- במכונות עם פחות מ-30GB זיכרון: 60% מסך הזיכרון. לדוגמה, במכונה מסוג e2-standard-2 עם זיכרון של 8GB, אי אפשר להקצות יותר מ-4.8GB ל-hugepages.
- במכונות עם זיכרון של יותר מ-30GB: ‏80% מנפח הזיכרון הכולל. לדוגמה, במכונות c4a-standard-8 עם זיכרון בנפח 32GB, דפי hugepages לא יכולים לחרוג מ-25.6GB.
דפי hugepage בנפח 1GB זמינים רק בסוגי המכונות A3,‏ C2D,‏ C3,‏ C3D,‏ C4,‏ C4A,‏ C4D,‏ C4N,‏ CT5E,‏ CT5LP,‏ CT6E,‏ H3,‏ M2,‏ M3,‏ M4,‏ Z3 או Z4D.

בטבלה הבאה מתוארות ההגדרות שאפשר לשנות ב-hugepages ב-Linux.

פרמטר ההגדרה	הגבלות	ערך ברירת המחדל	תיאור
`hugepage_size2m`	מספר שלם. בכפוף למגבלות הקצאת הזיכרון שמתוארות למעלה.	`0`	ההגדרה הזו מקצה מראש מספר ספציפי של דפים ענקיים בגודל 2MB.
`hugepage_size1g`	מספר שלם. בכפוף למגבלות הזיכרון וסוג המכונה שתוארו למעלה.	`0`	ההגדרה הזו מקצה מראש מספר ספציפי של דפים ענקיים בנפח 1GB.

דפים ענקיים שקופים (THP)

אתם יכולים להשתמש בקובץ תצורה של מערכת הצמתים כדי להפעיל את Transparent HugePage Support של ליבת Linux. עם THP, הליבה מקצה באופן אוטומטי דפי ענק לתהליכים בלי הקצאה מראש באופן ידני.

בטבלה הבאה מתוארים הפרמטרים שאפשר לשנות ב-THP.

פרמטר ההגדרה	ערכים נתמכים	ערך ברירת המחדל	תיאור
`transparentHugepageEnabled`	‫`TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS`: דף ענק שקוף מופעל בכל המערכת. ‫`TRANSPARENT_HUGEPAGE_ENABLED_MADVISE`: דף ענק שקוף מופעל בתוך אזורי MADV_HUGEPAGE. ההגדרה הזו היא הגדרת ברירת המחדל של הליבה. ‫`TRANSPARENT_HUGEPAGE_ENABLED_NEVER`: דף ענק שקוף מושבת. ‫`TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED`: ערך ברירת המחדל. ‫GKE לא משנה את הגדרת הליבה.	`UNSPECIFIED`	ההגדרה הזו קובעת אם THP מופעל לזיכרון אנונימי.
`transparentHugepageDefrag`	‫`TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS`: אפליקציה שמבקשת THP נתקעת אם ההקצאה נכשלת, ומחזירה ישירות דפים וזיכרון קומפקטי כדי להקצות THP באופן מיידי. ‫`TRANSPARENT_HUGEPAGE_DEFRAG_DEFER`: אפליקציה מעירה את kswapd ברקע כדי להחזיר דפים, ומעירה את kcompactd כדי לדחוס את הזיכרון כך ש-THP יהיה זמין בעתיד הקרוב. לאחר מכן, באחריות khugepaged להתקין את דפי ה-THP. ‫`TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE`: האפליקציה נכנסת להחזרה ישירה ולדחיסה כרגיל, אבל רק לאזורים שהשתמשו ב-`madvise(MADV_HUGEPAGE)`. בכל שאר האזורים, המערכת מפעילה את kswapd ברקע כדי להחזיר דפים, ומפעילה את kcompactd כדי לדחוס את הזיכרון, כך ש-THP יהיה זמין בעתיד הקרוב. ‫`TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE`: האפליקציה נכנסת להחזרה ישירה ולדחיסה כרגיל, אבל רק לאזורים שהשתמשו ב-`madvise(MADV_HUGEPAGE)`. בכל שאר האזורים, המערכת מפעילה את kswapd ברקע כדי להחזיר דפים, ומפעילה את kcompactd כדי לדחוס את הזיכרון, כך ש-THP יהיה זמין בעתיד הקרוב. ‫`TRANSPARENT_HUGEPAGE_DEFRAG_NEVER`: אפליקציה אף פעם לא נכנסת להחזרה ישירה או לדחיסה. ‫`TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED`: ערך ברירת המחדל. ‫GKE לא משנה את הגדרת הליבה.	`UNSPECIFIED`	ההגדרה הזו קובעת את הגדרת הדפרגמנטציה של THP.

אפשר להשתמש ב-THP ב-GKE מגרסה 1.33.2-gke.4655000 ואילך. הוא גם מופעל כברירת מחדל במאגרים חדשים של צומתי TPU בגרסה 1.33.2-gke.4655000 ואילך של GKE. ‫THP לא מופעל כשמשדרגים מאגרי צמתים קיימים לגרסה נתמכת או לגרסה מאוחרת יותר.

אפשרות לסנכרון זמן מדויק ב-Linux

אם סנכרון זמן מדויק ומעקב אחרי הדיוק של סנכרון הזמן חשובים לעומסי העבודה שלכם, אתם יכולים להגדיר זמן מדויק כדי לסנכרן את השעון של ה-VM עם השעון של המארח באמצעות chrony ו-ptp_kvm. סנכרון זמן מדויק זמין ב-GKE מגרסה 1.36.0-gke.3241000 ואילך. ההגדרה הזו נועדה להשיג דיוק של עד אלפית השנייה בהגדרות נתמכות. למידע נוסף על סוגי המכונות, מערכות ההפעלה והאזורים הנתמכים, קראו את המאמר הגדרת זמן מדויק למכונות וירטואליות של Compute Engine.

בטבלה הבאה מתואר הפרמטר להגדרת סנכרון זמן מדויק עם GKE:

פרמטר ההגדרה	ערכים נתמכים	ערך ברירת המחדל	תיאור
קובץ תצורה: `accurateTimeConfig.enablePtpKvmTimeSync` ‫Terraform: `accurate_time_config.enable_ptp_kvm_time_sync`	`true` או `false`	`false`	ההגדרה הזו מאפשרת סנכרון זמן מדויק. התכונה הזו נתמכת רק בסוגי מכונות, במערכות הפעלה ובאזורים ספציפיים.

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

המדד compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy, שמציין את הדיוק של שעון המארח של ה-VM ביחס ל-UTC.
היומן projects/PROJECT_ID/logs/chrony.tracking, שמכיל את יומני המעקב מ-chrony. היומנים האלה מספקים מידע כמו שיעור הרווח או ההפסד של שעון המערכת.

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

לדוגמה, ההגדרה הבאה של gke-clock-metric.json מגדירה מדד מבוסס-יומנים של שגיאת השעון המקסימלית במארח:

{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "resource.type=\"k8s_node\" AND log_id(\"chrony.tracking\")",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": []
  },
  "valueExtractor": "REGEXP_EXTRACT(textPayload, \"^.*PHC0.* ([-\\\\d\\\\.eE]+)$\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 5.0E-7, 1.0E-6, 2.0E-6, 4.0E-6, 5.0E-6, 8.0E-6, 1.0E-5, 2.0E-5,
        1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  }
}

ההגדרה הבאה ב-gke-metrics-dashboard.json מגדירה לוח בקרה ב-Monitoring, שצובר את נתוני השגיאות מהמדד שמבוסס-יומנים וממדד הדיוק של UTC:

{
  "displayName": "Overall Clock Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "width": 28,
        "height": 28,
        "widget": {
          "xyChart": {
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n  histogram_quantile(1, sum by (le, node_name) (\n    increase(logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"k8s_node\"}[1m])\n  )) * 1000000000\n)\n+ on(node_name) group_left()\nlabel_replace(\n  compute_googleapis_com:instance_clock_accuracy_ptp_kvm_nanosecond_accuracy{monitored_resource=\"gce_instance\"},\n  \"node_name\", \"$1\", \"instance_name\", \"(.*)\"\n)\n",
                  "unitOverride": "ns"
                }
              }
            ],
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}

אפשרויות הגדרה של Linux VFIO

בטבלה הבאה מתואר הפרמטר להגדרת VFIO (קלט/פלט של פונקציה וירטואלית) בצומת. ‫VFIO מאפשר למנהלי התקנים בטוחים, לא מורשים ובמרחב המשתמש לגשת להתקני קלט/פלט.

פרמטר ההגדרה	הגבלות	ערך ברירת המחדל	תיאור
`nodeVfioConfig.dmaEntryLimit`	הערך חייב להיות מספר שלם בין `65535` ל-`4194304`.	`65535`	מציינת את המספר המקסימלי של רשומות DMA (דפים) שאפשר למפות באמצעות מנהל ההתקן VFIO IOMMU מסוג 1 למאגר. המגבלה הזו משפיעה על הכמות הכוללת של זיכרון המארח שאפשר להצמיד לגישה ישירה למכשיר, שלעיתים קרובות היא קריטית למכשירים עם ביצועים גבוהים כמו TPU ו-GPU. ההגדרה הזו תואמת לפרמטר הליבה הבא: `/sys/module/vfio_iommu_type1/parameters/dma_entry_limit`. יכול להיות שיהיה צורך בערכים גבוהים יותר לעומסי עבודה שממפים אזורי זיכרון גדולים. האפשרות זמינה בגרסאות GKE‏ 1.36.0-gke.3009000 ואילך.

אפשרויות ההגדרה של מתזמן הקלט/פלט של הדיסק ב-Linux

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

פרמטר ההגדרה	ערכים נתמכים	ערך ברירת המחדל	תיאור
`diskIoScheduler.nodeSystemIoScheduler`	`mq-deadline`,‏ `bfq`,‏ `kyber`,‏ `none`	‫`bfq` לקובץ אימג' של מערכת ההפעלה שמותאמת לקונטיינרים, `none` לתמונה של Ubuntu	מגדיר את מתזמן הקלט/פלט לדיסק האתחול או ל-SSD המקומי הזמני שמריץ עומסי עבודה של מערכת הצמתים. זמין בגרסאות GKE‏ 1.36.0-gke.3009000 ואילך.
`diskIoScheduler.nodeAttachedDiskIoScheduler`	`mq-deadline`,‏ `bfq`,‏ `kyber`,‏ `none`	`none`	מגדיר את מתזמן הקלט/פלט לדיסקים המצורפים. זמין בגרסאות GKE‏ 1.36.0-gke.3009000 ואילך.

אפשרויות לשינוי הגדרות ברירת המחדל של ליבת Linux

אתם יכולים להשתמש בקובץ תצורה של מערכת הצומת כדי לשנות פרמטרים ספציפיים של ליבת Linux, כולל שורת הפקודה של הליבה והגדרות Multi-Gen LRU. ההגדרות האלה נתמכות באשכולות שפועלים בגרסאות GKE‏ 1.35.0-gke.1018000 ואילך.

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

בטבלה הבאה מתוארות האפשרויות של שורת הפקודה של הליבה שאפשר לשנות.

פרמטר ההגדרה	ערכים נתמכים	תיאור
`specRstackOverflow`	`SPEC_RSTACK_OVERFLOW_OFF`	משנה את ההשבתה הזמנית של אותות האכיפה של גלישת מחסנית החזרה הספקולטיבית (SRSO). הערך הנתמך היחיד הוא `SPEC_RSTACK_OVERFLOW_OFF`.
`initOnAlloc`	`INIT_ON_ALLOC_OFF`	שינוי הפרמטר `init_on_alloc` בשורת הפקודה של הליבה. הערך הנתמך היחיד הוא `INIT_ON_ALLOC_OFF`.

אפשרויות הגדרה של Multi-Gen LRU

בטבלה הבאה מתוארות האפשרויות של Multi-Gen LRU שאפשר לשנות.

פרמטר ההגדרה	ערכים נתמכים	תיאור
`enabled`	`true`, `false`	הפעלה או השבתה של Multi-Gen LRU. ההגדרה הזו קובעת את מתג ההשבתה.
`minTtlMs`	מספר שלם חיובי	זה שינוי אופציונלי. הגדרה של ערך מניעת ה-thrashing של `min_ttl_ms` ל-Multi-Gen LRU.

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

אתם יכולים להשתמש בקובץ תצורה של מערכת הצמתים כדי להוסיף רשומות לקובצי תצורה ספציפיים של מערכת ההפעלה בצמתים. ההגדרות האלה נתמכות באשכולות שפועלים בגרסאות GKE‏ 1.35.0-gke.1018000 ואילך.

רשומות נוספות של ‎/etc/hosts

השדה הזה מוסיף רשומות לקובץ /etc/hosts, כמו בדוגמה הבאה:

linuxConfig:
  additionalEtcHosts:
    - ip: 1.2.3.4
      host: myownpersonaldomain.com
    - ip: 5.6.7.8
      host: otherpersonaldomain.com

ערכים נוספים של ‎/etc/systemd/resolved.conf

השדה הזה מוסיף /etc/systemd/resolved.conf רשומות של קבצים. השדה הזה מקבל מערך של צמדי מפתח/ערך. אלה המקשים הנתמכים:

DNS
FallbackDNS
Domains
LLMNR
MulticastDNS
DNSSEC
DNSOverTLS
Cache
CacheFromLocalhost
DNSStubListener
DNSStubListenerExtra
ReadEtcHosts
ResolveUnicastSingleLabel
StaleRetentionSec

בדוגמה הבאה מוסיפים שני ערכים של שרת DNS‏ (8.8.8.8 ו-8.8.4.4) למפתח DNS וערך דומיין (myownpersonaldomain.com) למפתח Domains:

linuxConfig:
  additionalEtcSystemdResolvedConf:
    - key: DNS
      value:
        - 8.8.8.8
        - 8.8.4.4
    - key: Domains
      value:
        - myownpersonaldomain.com

ערכים נוספים של ‎/etc/resolv.conf

השדה הזה מוסיף /etc/resolv.conf רשומות של קבצים. בשדה הזה מזינים מערך של צמדי מפתח/ערך. אלה המקשים הנתמכים:

nameserver
search
sortlist
options

בדוגמה הבאה, ערך של שרת DNS‏ (1.1.1.1) נוסף למפתח nameserver וערך של דומיין (myownpersonaldomain.com) נוסף למפתח search:

linuxConfig:
  additionalEtcResolvConf:
    - key: nameserver
      value:
        - 1.1.1.1
    - key: search
      value:
        - myownpersonaldomain.com

הגדרת אזור הזמן

בשדה timeZone מגדירים את אזור הזמן בצומת, לדוגמה America/Los_Angeles. ההגדרה הזו נתמכת באשכולות שפועלים בגרסאות GKE‏ 1.35.0-gke.1018000 ואילך.

בדוגמה הבאה, השדה timeZone מוגדר ל-America/Los_Angeles:

linuxConfig:
  timeZone: America/Los_Angeles

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

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

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

לפני שמתחילים

הוספת הגדרת מערכת של צומת

שימוש ב-ComputeClass להגדרת מערכת הצמתים

יצירת ComputeClass

פריסת עומס עבודה שבוחר את ComputeClass

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

יצירת קובץ תצורה

הוספת ההגדרה למאגר צמתים רגיל

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

‫CLI של gcloud

Terraform

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

‫CLI של gcloud

Terraform

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

עדכון באמצעות עדכון בזמן אמת שלא משבש את הפעילות

איך פועלים העדכונים בזמן אמת

דרישות מוקדמות לעדכונים בזמן אמת

החלת עדכון בזמן אמת

איך לשחזר אחרי עדכון בזמן אמת שנכשל

ביטול עדכון בזמן אמת שהושלם

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

עריכת הגדרות המערכת של הצומת

ב-ComputeClasses

שיטה 1: עדכון ה-ComputeClass הקיים

שיטה 2: יצירת ComputeClass חדש

לקובצי תצורה

עריכה באמצעות יצירת מאגר צמתים

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

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

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

מחיקת הגדרות המערכת של צומת

ב-ComputeClasses

לקובצי תצורה

אפשרויות הגדרה של kubelet

ניהול המעבד (CPU)

ניהול זיכרון ופינוי מקום

ניהול PID

רישום ביומן

איסוף אשפה של תמונות

שליפת תמונה

אבטחה ופעולות לא בטוחות

מנהלי משאבים

השהיה בהפעלה מחדש של קונטיינר

סגירה מבוקרת של מכונות וירטואליות במודל Spot ב-GKE

הזמנת משאבי מערכת

אימות הזמנות בפועל

אפשרויות הגדרה של Sysctl

פרמטרים של מערכת הקבצים (fs.*)

פרמטרים של ליבה (kernel.*)

פרמטרים של רשת (net.*)

פרמטרים של זיכרון וירטואלי (vm.*)

אפשרויות הגדרה של מצב cgroup ב-Linux

אימות ההגדרות של cgroup

‫CLI של gcloud

kubectl

אפשרויות הגדרה של דפים גדולים ב-Linux

דפים ענקיים שהוקצו מראש

דפים ענקיים שקופים (THP)

אפשרות לסנכרון זמן מדויק ב-Linux

אפשרויות הגדרה של Linux VFIO

אפשרויות ההגדרה של מתזמן הקלט/פלט של הדיסק ב-Linux

אפשרויות לשינוי הגדרות ברירת המחדל של ליבת Linux

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

אפשרויות הגדרה של Multi-Gen LRU

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

רשומות נוספות של ‎/etc/hosts

ערכים נוספים של ‎/etc/systemd/resolved.conf

ערכים נוספים של ‎/etc/resolv.conf

הגדרת אזור הזמן

המאמרים הבאים

התאמה אישית של הגדרות המערכת של הצומת

אפשרויות הגדרה של `kubelet`

פרמטרים של מערכת הקבצים (`fs.*`)

פרמטרים של ליבה (`kernel.*`)

פרמטרים של רשת (`net.*`)

פרמטרים של זיכרון וירטואלי (`vm.*`)