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

Standard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. יוצרים ComputeClass שכולל את צמד השדה-ערך spec.nodePoolAutoCreation.enabled: true ומציינים את הגדרות המערכת בשדה priorityDefaults.
2. פורסים עומס עבודה שבוחר את 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. אפשר להגדיר את המערכת של הצמתים גם במצב Autopilot של GKE, אבל בשלבים שבמסמך הזה מוסבר איך ליצור קובץ תצורה ולהשתמש בו במצב Standard של GKE.

כדי להשתמש בקובץ תצורה של מערכת הצמתים במצב 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 .

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

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

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

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

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

   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 תלויה בזמינות המשאבים לשינוי. השבתת השדרוגים האוטומטיים של הצמתים לא מונעת את השינוי הזה.

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

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

ב-ComputeClasses

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

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

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

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

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

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

kubectl apply -f custom-sysconfig.yaml

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

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

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

לקובצי תצורה

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

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

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

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: {}

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

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

‫ComputeClasses

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

1. מסירים את בורר הצמתים cloud.google.com/compute-class מהמפרט של עומס העבודה.
2. מחילים את המפרטים המעודכנים של עומס העבודה. ‫GKE יוצר מחדש את עומסי העבודה בצומתי ברירת המחדל. בסופו של דבר, המידרוג האוטומטי של האשכול יצמצם אנכית וימחק את הצמתים שהוקצו ל-ComputeClass.

3. מוחקים את אובייקט ComputeClass מהאשכול:

   kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
   

לקובצי תצורה

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

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

אפשרויות הגדרה של 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).
reservedSystemCPUs (גרסת טרום-השקה (Preview))	חייבת להיות רשימה של ליבות מעבד ספציפיות להקצאה (לדוגמה, ‫0-1 או 0,1 להקצאת ליבות 0 ו-1). בגלל שהאינדקס של הליבות מתחיל באפס, הערכים חייבים להיות קטנים ממספר ה-vCPUs בסוג המכונה.	none	שומרת במפורש ליבות מעבד ספציפיות לשירותי המערכת המארחת, כמו דימונים של מערכת ההפעלה והשירות kubelet. כברירת מחדל, השירותים האלה יכולים לפעול בכל ליבת מעבד (CPU), מה שעלול לגרום לבעיות בביצועים של עומסי עבודה שרגישים למעבד. ההגדרה cpuManagerPolicy: static מקצה ליבות ייעודיות לפודים של Guaranteed עם בקשות CPU של מספרים שלמים, אבל היא לא מונעת משירותי המערכת המארחת להשתמש בליבות האלה. הוספת ההגדרה reservedSystemCPUs מגבילה את שירותי המערכת המארחת לליבות השמורות שלהם, ומונעת מהם להפריע לליבות הבלעדיות של עומסי העבודה. כדי לבצע את המשימה הזו, GKE מצמיד באופן אוטומטי את ה-cgroup של system.slice לליבות השמורות בזמן ההפעלה של הצומת. הקצאת מעבדי CPU של המערכת מפחיתה את הקיבולת הכוללת שניתן להקצות לצמתים. למרות ש-Pods של Burstable ו-BestEffort עדיין יכולים לפעול על ליבות שמורות כאלה, בקשות ה-CPU שלהם, כולל בקשות חלקיות מ-GKE DaemonSets, עדיין נספרות כחלק מהקיבולת הניתנת להקצאה של הצומת. בגלל שעומסי עבודה בלעדיים של Guaranteed דורשים ליבות שלמות, אפילו בקשות קטנות של חלקי ליבות מפחיתות את מספר הליבות הבלעדיות הזמינות. חשוב לוודא ששומרים מספיק ליבות מעבד (CPU) ב-reservedSystemCPUs. אם שומרים מעט מדי ליבות, יכול להיות שהתהליכים של מערכת ההפעלה והדימונים של המערכת המארחת יוגבלו על ידי המעבד (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	ההגדרה הזו מייצגת את צומתי ה-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	הגבלות	הגדרת ברירת המחדל	תיאור
allowedUnsafeSysctls	רשימה של sysctl שמות או קבוצות. הקבוצות sysctl המותרות הן: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	ההגדרה הזו מגדירה רשימת היתרים מופרדת בפסיקים של שמות sysctl או קבוצות sysctl לא בטוחים שאפשר להגדיר ב-Pods.
insecureKubeletReadonlyPortEnabled	הערך חייב להיות בוליאני, כלומר true או false.	false	ההגדרה הזו משביתה את היציאה הלא מאובטחת kubelet לקריאה בלבד 10255 בכל מאגר צמתים חדש באשכול. אם מגדירים את ההגדרה הזו בקובץ הזה, אי אפשר להשתמש בלקוח GKE API כדי לשנות את ההגדרה ברמת האשכול.

מנהלי משאבים

ב-Kubernetes יש חבילה של מנהלי משאבים. אתם יכולים להגדיר את מנהלי המשאבים האלה כדי לתאם ולייעל את ההתאמה של משאבי הצומת לפודים שמוגדרים עם דרישות ספציפיות למשאבי מעבדים, מכשירים וזיכרון (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	ההגדרות האלה קובעות את ההגדרה של Topology Manager ב-kubelet באמצעות שדות המשנה policy ו-scope. מנהל הטופולוגיה מתאם את קבוצת הרכיבים שאחראים לאופטימיזציות של ביצועים שקשורות לבידוד של המעבד, לזיכרון ולמיקום המכשיר. אפשר להגדיר את המדיניות ואת ההגדרות של ההיקף בנפרד. מידע נוסף על ההגדרות האלה זמין במאמר היקפים וכללי מדיניות של מנהל הטופולוגיה. ההגדרה הזו נתמכת במשאבי 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. אפשר להגדיר את ההגדרה הזו למאגרי צמתים מסוג Standard שפועלים ב-GKE בגרסה 1.35 ואילך.

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

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

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

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

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

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

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

תצוגה מקדימה

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

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

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

הגדרות אישיות של kubelet	הגבלות	הגדרת ברירת המחדל	תיאור
reservedResourcesConfig.memoryReservedMib	הערך חייב להיות מספר שלם. הערך חייב להיות גדול או שווה להקצאת הזיכרון שמוגדרת כברירת מחדל למאגרי צמתים שנוצרו בגרסה 1.37 ואילך, וקטן מ-50% מקיבולת הזיכרון הכוללת של הצומת.	מידע נוסף על הקצאות זיכרון	נפח הזיכרון שצריך לשריין לרכיבי המערכת, במבי-בייט (MiB).
reservedResourcesConfig.cpuReservedMillicore	הערך חייב להיות מספר שלם. הערך חייב להיות גדול או שווה להקצאת ברירת המחדל של המעבד (CPU) למאגרי צמתים שנוצרו בגרסה 1.37 ואילך, וקטן מ-50% מקיבולת המעבד הכוללת של הצומת.	מידע נוסף על הקצאת מעבד	כמות המעבד (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. ההגדרות האלה קובעות את הפונקציונליות של ליבת ה-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 מותרות. מידע נוסף זמין במאמר בנושא פריצות למקש Magic System Request ב-Linux.
kernel.keys.maxbytes	הערך חייב להיות בין [20000, 2097152].	ההגדרה הזו מגדירה את המספר המקסימלי של בייטים שמשתמש לא מורשה יכול להחזיק בקטע המטען הייעודי (payload) של כל המפתחות שלו.
kernel.keys.maxkeys	הערך צריך להיות בין 200 ל-1,048,576.	ההגדרה הזו קובעת את המספר המקסימלי של מפתחות שיכולים להיות בבעלות של משתמש שאינו משתמש בסיסי.

פרמטרים של רשת (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, 2147483647].	ההגדרה הזו קובעת את המגבלה של צבר המשימות של 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 מופעל באשכול. הערכים הנתמכים הבאים תלויים בסוג התמונה: ‫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 ל-86, 400.	ההגדרה הזו קובעת את משך הזמן, בשניות, של חיבורים לא פעילים לפני שהם נמחקים באופן אוטומטי מטבלת מעקב החיבורים. זמין בגרסאות 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].	ההגדרה הזו קובעת את אחוז הזיכרון של המערכת שאפשר למלא בדפים מלוכלכים לפני ששרשורי ה-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.	הגדרה זו מגדירה את הגיל המקסימלי, במאיות השנייה, שנתונים מלוכלכים יכולים להישאר בזיכרון לפני שתהליכי שטיפה של ליבת מערכת ההפעלה כותבים אותם לדיסק.
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.	ההגדרה הזו מגדירה את המרווח, במאיות השנייה, שבו השרשורים של כלי הניקוי של ליבת המערכת מתעוררים כדי לכתוב נתונים ישנים ולא נקיים לדיסק.
vm.overcommit_memory	הערך צריך להיות {0, 1, 2}.	ההגדרה הזו קובעת את האסטרטגיה של הליבה לטיפול בהקצאת יתר של זיכרון. אלה הערכים: ‫0: דחיית הקצאות גדולות ‫1: בלי הגבלת שימוש (ערך ברירת המחדל) ‫2: מניעת הקצאה מעבר ל-swap + יחס של RAM ההגדרה הזו לא נתמכת במחשבים עם זיכרון קטן מ-15 GB.
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

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

זמן הריצה של הקונטיינר ו-kubelet משתמשים ב-cgroups של ליבת Linux לניהול משאבים, כמו הגבלת כמות המעבד או הזיכרון שלכל קונטיינר ב-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 באופן מפורש. שדרוג של מאגר צמתים קיים שמשתמש ב-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: שימוש בהגדרת ברירת המחדל של GKE cgroup.

כדי להשתמש ב-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 של הצמתים במאגר הצמתים הזה, בוחרים צומת ומתחברים אליו לפי ההוראות הבאות:

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

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

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

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

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

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

• כדי לוודא שהצומת לא תפוסה במלואה על ידי דפי ענק, הגודל הכולל של דפי הענק שהוקצו לא יכול לחרוג מאף אחת מהמגבלות הבאות:
  • במחשבים עם זיכרון של פחות מ-30 GB: ‏ 60% מהזיכרון הכולל. לדוגמה, במכונה מסוג e2-standard-2 עם זיכרון בנפח 8GB, אי אפשר להקצות יותר מ-4.8GB ל-hugepages.
  • במחשבים עם זיכרון בנפח של יותר מ-30GB: ‏ 80% מהזיכרון הכולל. לדוגמה, במכונות c4a-standard-8 עם זיכרון בנפח 32GB, הגודל של hugepages לא יכול לחרוג מ-25.6GB.
• ‫1 GB hugepages זמין רק בסוגי המכונות 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: 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 בגרסה ‎1.33.2-gke.4655000 ואילך של GKE. התכונה THP לא מופעלת כשמשדרגים מאגרי צמתים קיימים לגרסה נתמכת או לגרסה חדשה יותר.

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

אם סנכרון זמן מדויק ומעקב אחרי הדיוק של סנכרון הזמן חשובים לעומסי העבודה שלכם, אתם יכולים להגדיר זמן מדויק כדי לסנכרן את השעון של ה-VM עם השעון של המארח באמצעות chrony ו-ptp_kvm. סנכרון מדויק של השעה זמין ב-GKE מגרסה 1.36.0-gke.3241000 ואילך. התצורה הזו נועדה להשיג דיוק של עד 1 אלפית השנייה בהגדרות נתמכות. מידע נוסף על סוגי מכונות נתמכים, מערכות הפעלה נתמכות ותחומים נתמכים זמין במאמר הגדרת זמן מדויק למכונות וירטואליות ב-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 cgroupv2
• איך מוסיפים ומנהלים מאגרי צמתים
• איך מתאימים אישית את ההגדרות של containerd בצמתי GKE
• כך מבצעים אתחול אוטומטי של צמתי GKE באמצעות DaemonSets.