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

רגילה

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

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

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

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

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

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

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

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

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

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

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

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

לפני שמתחילים, חשוב לבצע את הפעולות הבאות:

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

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

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

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

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

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

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

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

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

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

kubeletConfig:
  cpuManagerPolicy: static

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

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

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

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

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

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

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

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

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

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

   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: הנתיב לקובץ שמכיל את ההגדרות של kubelet ושל sysctl

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

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

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

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

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

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

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

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

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

כדי לערוך את הגדרת המערכת הקיימת של מאגר צמתים קיים, פועלים לפי ההוראות שבכרטיסייה Update node pool (עדכון מאגר צמתים) בקטע adding the configuration to a node pool (הוספת ההגדרה למאגר צמתים). כשמעדכנים את הגדרות המערכת של צומת, וההגדרות החדשות מבטלות את הגדרות המערכת הקיימות של מאגר הצמתים, צריך ליצור מחדש את הצמתים. אם משמיטים פרמטרים במהלך עדכון, הפרמטרים מוגדרים לערכי ברירת המחדל שלהם.

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

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

זהירות: כשמעדכנים את הגדרות צומת Linux על סמך הפלט הזה, צריך לציין את הפרמטרים בשדה linuxConfig בפקודת העדכון. הפקודה describe מציגה את ההגדרות האלה בקטע linuxNodeConfig, אבל כדי לעדכן אותן, השדה הנכון הוא linuxConfig. שימוש בשדה הפלט 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, למשל:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

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

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

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

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

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

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

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

הגדרות תצורה kubelet	הגבלות	הגדרת ברירת המחדל	תיאור
cpuCFSQuota	הערך חייב להיות true או false.	true	ההגדרה הזו אוכפת את מגבלת המעבד של ה-Pod. הגדרה של הערך הזה ל-false פירושה שמגבלות ה-CPU של ה-Pods מתעלמות. התעלמות ממגבלות ה-CPU עשויה להיות מועילה בתרחישים מסוימים שבהם ה-Pods רגישים למגבלות ה-CPU. הסיכון בהשבתת cpuCFSQuota הוא ש-Pod לא רצוי עלול לצרוך יותר משאבי CPU מהמתוכנן.
cpuCFSQuotaPeriod	חייב להיות משך זמן.	"100ms"	ההגדרה הזו קובעת את ערך התקופה של מכסת ה-CPU CFS, ‏ cpu.cfs_period_us, שמציין את התקופה שבה צריך להקצות מחדש את הגישה של cgroup למשאבי ה-CPU. האפשרות הזו מאפשרת לכם לשנות את התנהגות ויסות הנתונים (throttle) של יחידת העיבוד המרכזית (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.	ההגדרה הזו קובעת אם התהליכים במאגר נסגרים בגלל חוסר זיכרון בנפרד או כקבוצה. זמין בגרסאות 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	ההגדרה הזו מייצגת את ה-inodes של nodefs שפנויים לפני הוצאה רכה. מגדיר את עוצמת האות nodefs.inodesFree ב-kubelet .
imagefsAvailable	הערך צריך להיות בין 15% ל-50%.	none	ההגדרה הזו מייצגת את imagefs שזמינים לפני הוצאה זמנית של תמונות. ההגדרה מגדירה את כמות האות imagefs.available ב-kubelet .
imagefsInodesFree	הערך צריך להיות בין 5% ל-50%.	none	ההגדרה הזו מייצגת את ה-inodes של imagefs שפנויים לפני הוצאה רכה. ההגדרה קובעת את עוצמת האות imagefs.inodesFree ב-kubelet.
pidAvailable	הערך צריך להיות בין 10% ל-50%.	none	ההגדרה הזו מייצגת את מזהי התהליך שזמינים לפני הוצאה רכה. ההגדרה קובעת את עוצמת האות pid.available ב-kubelet.

ניהול PID

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

הגדרות תצורה kubelet	הגבלות	הגדרת ברירת המחדל	תיאור
podPidsLimit	הערך צריך להיות בין 1024 ל-4194304.	none	ההגדרה הזו קובעת את המספר המקסימלי של מזהי תהליכים (PIDs) שכל 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	הגבלות	הגדרת ברירת המחדל	תיאור
allowedUnsafeSysctls	רשימה של sysctl שמות או קבוצות. אלה הקבוצות המותרות: sysctl kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	ההגדרה הזו מגדירה רשימת היתרים של שמות או קבוצות לא בטוחים של sysctl או sysctl, שמופרדים באמצעות פסיקים, שאפשר להגדיר ב-Pods.
insecureKubeletReadonlyPortEnabled	הערך חייב להיות בוליאני, כלומר true או false.	true	ההגדרה הזו משביתה את יציאת הקריאה בלבד 10255 הלא מאובטחת kubelet בכל מאגר צמתים חדש באשכול. אם מגדירים את ההגדרה הזו בקובץ הזה, אי אפשר להשתמש בלקוח GKE API כדי לשנות את ההגדרה ברמת האשכול.

מנהלי משאבים

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

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

הגדרות תצורה kubelet	הגבלות	הגדרת ברירת המחדל	תיאור
cpuManagerPolicy	הערך חייב להיות none או static.	none	ההגדרה הזו קובעת את kubelet מדיניות ניהול המעבד. ערך ברירת המחדל הוא none, שהוא סכמת זיקה (affinity) של CPU שמוגדרת כברירת מחדל, ולא מספקת זיקה מעבר למה שתזמן מערכת ההפעלה עושה באופן אוטומטי. הגדרת הערך הזה ל-static מאפשרת להקצות מעבדי CPU בלעדיים ל-Pods שנמצאים גם במחלקת 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	ההגדרות האלה שולטות בהגדרות של kubelet Topology Manager באמצעות שדות המשנה policy ו-scope. מנהל הטופולוגיה מתאם בין קבוצת הרכיבים שאחראים לאופטימיזציות של הביצועים שקשורות לבידוד ה-CPU, לזיכרון ולמיקום המכשיר. אפשר להגדיר את המדיניות ואת ההיקף בנפרד. מידע נוסף על ההגדרות האלה זמין במאמר היקפים ומדיניות של Topology Manager. ההגדרה הזו נתמכת במשאבי GKE הבאים: אשכולות שמישור הבקרה שלהם מריץ את GKE בגרסה ‎1.32.3-gke.1785000 ואילך. במקרים של אשכולות עם מישור בקרה וצמתים שפועלת בהם גרסה 1.33.0-gke.1712000 ואילך, Topology Manager מקבל גם מידע על טופולוגיית ה-GPU. צמתים עם סוגי המכונות הבאים: A2, ‏ A3, ‏ A4, ‏ C3, ‏ C4, ‏ C4A, ‏ C4N, ‏ G2, ‏ G4, ‏ M3, ‏ N4

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

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

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

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

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

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

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

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

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

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

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

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

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

פרמטר Sysctl	הגבלות	תיאור
fs.aio-max-nr	הערך חייב להיות בין [65536, 4194304].	ההגדרה הזו מגדירה את המספר המקסימלי של בקשות קלט/פלט אסינכרוניות בכל המערכת.
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. ההגדרות האלה קובעות את הפונקציות העיקריות של ליבת המערכת, כולל הקצאת זיכרון משותף.

פרמטר Sysctl	הגבלות	תיאור
kernel.shmmni	הערך חייב להיות בין [4096, 32768].	ההגדרה הזו מגדירה את המספר המקסימלי של קטעי זיכרון משותפים בכל המערכת. אם הערך הזה לא מוגדר, ברירת המחדל היא 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, 1000000]‎.	ההגדרה הזו מגדירה מגבלה גלובלית על משך הזמן שבו אפשר להשתמש בתזמון בזמן אמת.
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: bitmask של פונקציות sysrq מותרות. מידע נוסף זמין במאמר Linux Magic System Request Key Hacks.
kernel.keys.maxbytes	הערך חייב להיות בין [20000, 2097152].	ההגדרה הזו מגדירה את המספר המקסימלי של בייטים שמשתמש שאינו משתמש root יכול להחזיק בקטע המטען הייעודי (payload) של כל המפתחות שלו.
kernel.keys.maxkeys	הערך חייב להיות בין [200, 1048576].	ההגדרה הזו מגדירה את המספר המקסימלי של מפתחות שמשתמש שאינו משתמש root יכול להיות הבעלים שלהם.

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

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

פרמטר 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, 2147483647].	ההגדרה הזו מגדירה את המגבלה של ה-backlog של 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 שלא מצורפים ל-handle של קובץ משתמש כלשהו.
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 מופעל באשכול. הערכים הנתמכים הבאים תלויים בסוג התמונה: ‫COS: 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, 3600].	ההגדרה הזו מגדירה את התקופה, בשניות, שבה חיבורי ה-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 עלולה לגרום לשימוש מוגזם במטמון ולפגוע בביצועים.
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].	ההגדרה הזו מגדירה את אחוז זיכרון המערכת שאפשר למלא בדפים לא נקיים לפני שמתחילים שרשורים של ניקוי ליבת הרקע לביצוע כתיבה חוזרת. הערך חייב להיות קטן מהערך של השדה vm.dirty_ratio.
vm.dirty_background_bytes	הערך חייב להיות בין [0, 68719476736].	ההגדרה הזו מגדירה את כמות הזיכרון המלוכלך שבה השרשורים של מנקה הליבה ברקע מתחילים לכתוב בחזרה. חשוב לדעת ש-vm.dirty_background_bytes הוא המקביל של vm.dirty_background_ratio. אפשר לציין רק אחת מההגדרות האלה.
vm.dirty_expire_centisecs	הערך חייב להיות בין [0, 6000].	ההגדרה הזו מגדירה את הגיל המקסימלי, במאיות השנייה, שבו נתונים לא נקיים יכולים להישאר בזיכרון לפני ששרשורי ניקוי של ליבת המערכת כותבים אותם לדיסק.
vm.dirty_ratio	הערך חייב להיות בין [1, 100].	ההגדרה הזו מגדירה את אחוז זיכרון המערכת שאפשר למלא בדפים לא נקיים לפני שתהליכים שמבצעים כתיבות נאלצים להיחסם ולכתוב נתונים לא נקיים באופן סינכרוני.
vm.dirty_bytes	הערך חייב להיות בין [0, 68719476736].	ההגדרה הזו מגדירה את כמות הזיכרון המלוכלך שבה תהליך שיוצר כתיבות לדיסק מתחיל לכתוב בעצמו. הערך המינימלי המותר של vm.dirty_bytes הוא שני עמודים בבייטים. המערכת תתעלם מכל ערך שיהיה נמוך מהמגבלה הזו, וההגדרה הישנה תישמר. חשוב לדעת ש-vm.dirty_bytes הוא המקביל של vm.dirty_ratio. אפשר לציין רק אחת מההגדרות האלה.
vm.dirty_writeback_centisecs	הערך חייב להיות בין [0, 1000].	ההגדרה הזו מגדירה את המרווח, במאיות של שנייה, שבו השרשורים של הכלי לניקוי הליבה מתעוררים כדי לכתוב נתונים ישנים שצריך לנקות לדיסק.
vm.overcommit_memory	חייב להיות בין {0, 1, 2}.	ההגדרה הזו קובעת את האסטרטגיה של ליבת מערכת ההפעלה לטיפול בהקצאת יתר של זיכרון. הערכים האפשריים הם: ‫0: דחיית הקצאות גדולות ‫1: תמיד מותר (ערך ברירת מחדל) ‫2: מניעת ביצוע commit מעבר ל-swap + יחס של RAM ההגדרה הזו לא נתמכת במחשבים עם זיכרון קטן מ-15 GB.
vm.overcommit_ratio	הערך חייב להיות בין 0 ל-100.	ההגדרה הזו מגדירה את אחוז ה-RAM הפיזי שמותר להקצאת יתר כשהערך של השדה vm.overcommit_memory מוגדר ל-2.
vm.vfs_cache_pressure	הערך חייב להיות בין 0 ל-100.	ההגדרה הזו משנה את ההעדפה של ליבת המערכת לגבי שחרור זיכרון שמשמש למטמון של dentry (ספרייה) ו-inode.
vm.swappiness	הערך צריך להיות בין [0, 200].	ההגדרה הזו קובעת את הנטייה של ליבת מערכת ההפעלה להעביר תהליכים מזיכרון פיזי לדיסק ההחלפה. ערך ברירת המחדל הוא 60.
vm.watermark_scale_factor	הערך צריך להיות בין [10, 3000].	ההגדרה הזו קובעת את רמת האגרסיביות של kswapd. הוא מגדיר את הזיכרון שנותר לפני ש-kswapd מתעורר ואת הזיכרון שצריך לפנות לפני שהוא נכנס למצב שינה. ערך ברירת המחדל הוא 10.
vm.min_free_kbytes	הערך חייב להיות בין [67584, 1048576].	ההגדרה הזו מגדירה את הזיכרון הפנוי המינימלי לפני שגיאת OOM. ערך ברירת המחדל הוא 67584.

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

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

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

שימו לב: בגרסה 1.31 של GKE,‏ cgroupv1 הוצא משימוש, ובגרסה 1.35, התמיכה ב-cgroupv1 הוסרה. מידע נוסף על המעבר של GKE אל cgroupv2 ועל האופן שבו אפשר להכין את האשכולות למעבר הזה זמין במאמר העברת צמתים אל Linux cgroupv2.

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

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

אתם יכולים להשתמש בהגדרת המערכת של הצומת כדי לשנות את ההגדרה של מאגר צמתים לשימוש ב-cgroupv1 או ב-cgroupv2 באופן מפורש. שדרוג של מאגר צמתים קיים שמשתמש ב-cgroupv1 לגרסה 1.26 לא משנה את ההגדרה ל-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 לצמתים במאגר צמתים באמצעות gcloud CLI או כלי שורת הפקודה 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 לצמתים במאגר הצמתים הזה, בוחרים צומת ומתחברים אליו באמצעות ההוראות הבאות:

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

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

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

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

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

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

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

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

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

דפים גדולים שקופים (THP)

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

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

פרמטר להגדרה	ערכים נתמכים	ערך ברירת המחדל	תיאור
transparentHugepageEnabled	‫TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: transparent hugepage מופעל בכל המערכת. ‫TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: transparent hugepage מופעל באזורי 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 ב-GKE בגרסה ‎1.33.2-gke.4655000 ואילך. התכונה THP לא מופעלת כשמשדרגים מאגרי צמתים קיימים לגרסה נתמכת או לגרסה חדשה יותר.

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

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

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

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

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

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

• איך מעבירים צמתים ל-Linux cgroupv2
• איך מוסיפים ומנהלים מאגרי צמתים
• איך מתאימים אישית את ההגדרות של containerd בצמתי GKE
• כך מבצעים אתחול אוטומטי של צמתי GKE באמצעות DaemonSets.