כוונון ביצועי הצומת

אחת הדרכים לשפר את הביצועים של אפליקציות מבוססות-קונטיינרים היא להגדיל את משאבי האשכול על ידי הוספת צמתים או משאבים, כמו מעבדים או זיכרון, לצמתים. עם זאת, הגישה הזו עלולה להיות יקרה. התאמה של צמתי האשכול לשיפור הביצועים עוזרת לכם לבצע אופטימיזציה של ניצול המשאבים עבור עומסי העבודה שלכם בצורה חסכונית. במאמר הזה נסביר איך להשתמש ב-Performance Tuning Operator כדי להתאים את צמתי העובדים ולבצע אופטימיזציה של ביצועי עומסי העבודה ב-Google Distributed Cloud.

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

  • מעבדים ייעודיים לעומסי עבודה שרגישים לביצועים
  • מעבדים מרכזיים שמורים לשירותים ולתהליכי Daemon סטנדרטיים של Kubernetes
  • גדלי דפי זיכרון גדולים יותר עם 1 GiB (גיביבייט) או 2 MiB (מביבייט) של דפים גדולים
  • חלוקת עומסי העבודה על סמך ארכיטקטורת המערכת, כמו מעבדים מרובי ליבות ו-NUMA

בעזרת Performance Tuning Operator, אתם יכולים להגדיר הגדרות ביצועים ברמת הצומת על ידי יצירת משאבים מותאמים אישית של Kubernetes שמחילים הגדרות ביצועים. אלה היתרונות:

  • ממשק הגדרה יחיד ומאוחד: באמצעות Performance Tuning Operator, אתם מעדכנים מניפסט אחד או יותר של PerformanceTuningProfile שאפשר להחיל על צמתי עובדים באמצעות בוררי צמתים. אתם לא צריכים להגדיר כל צומת בנפרד עם הגדרות מדיניות והגדרות תצורה מרובות. הגישה הזו מאפשרת לכם לנהל הגדרות ברמת הצומת וברמת המאגר בצורה יחידה ומאוחדת.

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

האופרטור Performance Tuning פועל באמצעות תיאום של התכונות והכלים הבאים שקשורים לביצועים ב-Kubernetes ובמערכת ההפעלה (OS):

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

דרישות מוקדמות ומגבלות

אלה הדרישות המוקדמות והמגבלות לשימוש באופרטור Performance Tuning:

  • Red Hat Enterprise Linux ‏ (RHEL) בלבד: יש תמיכה באופרטור Performance Tuning רק בצמתים שמופעלות בהם גרסאות נתמכות של RHEL.

  • אשכול משתמשים או אשכול היברידי עם צמתי עובדים: אפשר להשתמש ב-Performance Tuning Operator עם צמתי עובדים רק באשכולות משתמשים או באשכולות היברידיים. אין תמיכה בשימוש ב-Performance Tuning Operator כדי לבצע אופטימיזציה של צמתי מישור הבקרה. אופרטור כוונון הביצועים משתמש בבורר צמתים כדי לקבוע איך להחיל פרופילי כוונון. כדי לוודא שהפרופילים של ההתאמה יחולו רק על צמתי העובדים, המאפיין nodeSelector בכל משאב מותאם אישית של פרופיל צריך לכלול את התווית הסטנדרטית של צומת העובדים node-role.kubernetes.io/worker: "". אם nodeSelector בפרופיל אופטימיזציה תואם לתוויות בצומת של מישור הבקרה, הצומת הזה לא עובר אופטימיזציה ומוגדר מצב שגיאה. מידע נוסף על תנאי שגיאה זמין במאמר בדיקת הסטטוס. לפני שמתקינים את Performance Tuning Operator ומחילים פרופילי אופטימיזציה, צריך לוודא שהאשכול פועל בצורה תקינה.

  • ‫TuneD 2.22.0: כדי להשתמש באופרטור Performance Tuning, צריך להתקין מראש את TuneD בגרסה 2.22.0 בצמתי העובדים שרוצים לבצע בהם אופטימיזציה. מידע נוסף על TuneD, כולל הוראות התקנה, זמין במאמר Getting started with TuneD במסמכי Red Hat Enterprise Linux. האופרטור Performance Tuning משתמש ב-TuneD עם הפרופיל cpu-partitioning. אם אין לכם את הפרופיל הזה, אתם יכולים להתקין אותו באמצעות הפקודה הבאה:

    dnf install -y tuned-profiles-cpu-partitioning

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

  • משאבי הצמתים הזמינים: אפשר לראות את משאבי המעבד (CPU) והזיכרון של הצמתים. אפשר לקבל מידע מפורט על המעבד והזיכרון של הצומת בקבצים /proc/cpuinfo ו-/proc/meminfo בהתאמה. אפשר להשתמש גם בדגל kubectl get nodes כדי לאחזר את כמות משאבי החישוב והזיכרון (status.allocatable) שיש לצומת עובד וזמינים ל-Pods.

  • נדרש ניקוי: כחלק מתהליך הכוונון, האופרטור Performance Tuning מנקה תחילה את הצמתים ואז מחיל פרופיל כוונון. כתוצאה מכך, יכול להיות שהצמתים ידווחו על סטטוס NotReady במהלך כוונון הביצועים. מומלץ להשתמש באסטרטגיית עדכון מתגלגל (spec.updateStrategy.type: rolling) במקום בעדכון אצווה כדי למזער את חוסר הזמינות של עומס העבודה.

  • נדרשת הפעלה מחדש: כדי ששינויים בהתאמת הצומת ייכנסו לתוקף, Performance Tuning Operator מפעיל מחדש את הצומת אחרי החלת פרופיל ההתאמה.

התקנה של Performance Tuning Operator

האופרטור Performance Tuning מורכב בעיקר משני בקרי (Deployment ו-DaemonSet) שמבצעים אינטראקציה ביניהם כדי לכוון צמתים על סמך הגדרות הפרופיל. כברירת מחדל, Performance Tuning Operator לא מותקן עם Google Distributed Cloud. מורידים את מניפסטים של Performance Tuning Operator מ-Cloud Storage ומשתמשים ב-kubectl apply כדי ליצור משאבים של Performance Tuning Operator באשכול.

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

  1. יוצרים ספרייה בשם performance-tuning בתחנת העבודה של האדמין.

  2. מהספרייה performance-tuning, מורידים את חבילת Performance Tuning Operator העדכנית מקטגוריית הפרסום של Cloud Storage:

    gcloud storage cp gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 . --recursive

    הקבצים שהורדתם כוללים מניפסטים של performance-tuning-operatorDeployment ושל nodeconfig-controller-manager DaemonSet. הם כוללים גם מניפסטים של פונקציות קשורות, כמו בקרת גישה מבוססת-תפקידים (RBAC) ובקרת קבלה דינמית.

  3. כמשתמש הבסיס, מפעילים את כל המניפסטים של Performance Tuning Operator באופן רקורסיבי על אשכול המשתמש (או ההיברידי):

    kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG

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

בדיקת דרישות המשאבים של עומסי העבודה

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

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

כדי להקצות ל-Pods סיווג QoS של מובטח, הם צריכים לעמוד בדרישות הבאות:

  • לכל מאגר ב-Pod:
    • מציינים ערכים גם לבקשות של משאבי זיכרון (spec.containers[].resources.requests.memory) וגם למגבלות (spec.containers[].resources.limits.memory).
    • הערך של מגבלות הזיכרון חייב להיות שווה לערך של בקשות הזיכרון.
    • מציינים ערכים גם לבקשות למשאבי CPU ‏(spec.containers[].resources.requests.cpu) וגם למגבלות ‏(spec.containers[].resources.limits.cpu).
    • הערך של מגבלות השימוש במעבד חייב להיות שווה לערך של בקשות השימוש במעבד.

בקטע הבא ממפרט ה-Pod מוצגות הגדרות של משאבי CPU שעומדות בדרישות של מחלקת QoS מובטחת:

spec:
  containers:
  - name: sample-app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "128Mi"
        cpu: "2"
      limits:
        memory: "128Mi"
        cpu: "2"
  ...

כשמאחזרים פרטי פוד באמצעות kubectl get pods, הקטע status צריך לכלול את מחלקת ה-QoS שהוקצתה, כמו בדוגמה הבאה:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-09-22T21:05:23Z"
  generateName: my-deployment-6fdd69987d-
  labels:
    app: metrics
    department: sales
    pod-template-hash: 6fdd69987d
  name: my-deployment-6fdd69987d-7kv42
  namespace: default
  ...
spec:
  containers:
  ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-09-22T21:05:23Z"
    status: "True"
    type: Initialized
  ...
  qosClass: BestEffort
  startTime: "2023-09-22T21:05:23Z"

מידע נוסף על מחלקות QoS זמין במאמר Pod Quality of Service Classes (מחלקות איכות שירות של Pod) במאמרי העזרה של Kubernetes. הוראות להגדרת ה-Pods והקונטיינרים כך שיוקצה להם סיווג QoS מפורטות במאמר הגדרת איכות השירות (QoS) ל-Pods.

דרישות לגבי יחידת עיבוד מרכזית (CPU)

כשמבצעים אופטימיזציה של צומת, אפשר לציין קבוצה של ליבות CPU שמורות (spec.cpu.reservedCPUs) להרצת דמונים של מערכת Kubernetes, כמו kubelet וזמן ריצה של קונטיינר. אותה קבוצה של מעבדי CPU שמורים מריצה גם דמונים של מערכת ההפעלה, כמו sshd ו-udev. שאר ליבות המעבד (CPU) מוקצות כמבודדות. המעבדים המבודדים מיועדים לאפליקציות שמוגבלות על ידי המעבד, שנדרש להן זמן מעבד ייעודי ללא הפרעות מאפליקציות אחרות או מהפסקות של רשת או מכשירים אחרים.

כדי להקצות Pod במעבדי ה-CPU המבודדים של צומת עובד:

  • מגדירים את ה-Pod לאיכות שירות (QoS) מובטחת.

  • הדרישות והמגבלות של יחידת העיבוד המרכזית (CPU) צריכות להיות מספרים שלמים. אם מציינים משאבי CPU חלקיים במפרט ה-Pod, כמו cpu: 0.5 או cpu: 250m (250 מילי-ליבות), אי אפשר להבטיח תזמון.

דרישות זיכרון

כשמכווננים צומת באמצעות Performance Tuning Operator, אפשר ליצור דפי ענק ולקשר אותם לצמתים של גישה לזיכרון לא אחיד (NUMA) במכונה. על סמך ההגדרות של Pod ו-Node, אפשר לתזמן את ה-Pods עם זיקה לצומת NUMA.

יצירת פרופיל לשיפור הביצועים

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

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

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

מגדירים את מרחב השמות של המשאב המותאם אישית PerformanceTuningProfile ל-kube-system.

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

  1. עורכים את קובץ המניפסט PerformanceTuningProfile.

    מידע על כל שדה במניפסט ומניפסט לדוגמה זמינים במאמר PerformanceTuningProfile – חומר עזר.

  2. (אופציונלי) כדי להחיל פרופיל על צמתי העובדים, מוסיפים תוויות שתואמות לצמד המפתח/ערך spec.nodeSelector.

    אם לא מציינים זוג מפתח/ערך spec.nodeSelector במשאב המותאם אישית PerformanceTuningProfile, הפרופיל יוחל על כל צומתי העובדים.

  3. מחילים את המניפסט על האשכול.

    kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG

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

    • ‫PROFILE_MANIFEST: הנתיב של קובץ המניפסט של PerformanceTuningProfile המשאב המותאם אישית.
    • ‫KUBECONFIG: הנתיב לקובץ kubeconfig של האשכול.

הסרת פרופיל אופטימיזציה

כדי לאפס צומת למצב המקורי שלו, לפני הכוונון:

  1. מוחקים את המשאב המותאם אישית PerformanceTuningProfile מהאשכול.

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

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

השהיה של פרופיל אופטימיזציה

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

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

כדי להשהות את ההתאמה:

  1. עורכים את מניפסט המשאבים המותאם אישית PerformanceTuningProfile כדי להגדיר את spec.paused לערך true.

  2. משתמשים ב-kubectl apply כדי לעדכן את המשאב.

כשמשהים את כוונון הביצועים, בקר האופרטור של כוונון הביצועים מפסיק את כל הפעולות שלו. ההשהיה מונעת את הסיכון לפעולות של בקר Performance Tuning Operator שמתנגשות עם פעולות של בקר Google Distributed Cloud.

PerformanceTuningProfile הפניה למשאבים

בקטע הזה מתוארים כל השדות במשאב המותאם אישית PerformanceTuningProfile. המשאב הזה משמש ליצירת פרופיל אופטימיזציה לאחד או יותר מצמתי האשכול. אחרי שיוצרים את הפרופיל, אפשר לשנות את כל השדות במשאב. הפרופילים צריכים להיות במרחב השמות kube-system.

במניפסט של פרופיל לדוגמה numa של צמתים עם 8 ליבות CPU מוגדרות הקצאות המשאבים הבאות:

  • 4 ליבות CPU‏ (0-3) שמורות לתקורה של מערכת Kubernetes.

  • 4 ליבות מעבד (4-7) מוקצות לעומסי עבודה בלבד.

  • כברירת מחדל, הזיכרון של הצומת מחולק לדפים בגודל 2 מיגה-בייט, במקום לדפים בגודל 4 קילו-בייט כמו בדרך כלל.

  • 10 דפים של זיכרון בגודל 1GB מוקצים לשימוש על ידי צומת NUMA מספר 0.

  • 5 דפים של זיכרון בגודל 2 MiB מוקצים לשימוש על ידי צומת NUMA מספר 1.

  • מנהל הטופולוגיה משתמש במדיניות של מאמץ מרבי לתזמון עומסי עבודה.

apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
  name: numa
  namespace: kube-system
spec:
  cpu:
    isolatedCPUs: 4-7
    reservedCPUs: 0-3
  defaultHugepagesSize: 2M
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  pages:
  - count: 10
    numaNode: 0
    size: 1G
  - count: 5
    numaNode: 1
    size: 2M
  topologyManagerPolicy: best-effort

אפשר לאחזר את PerformanceTuningProfileהגדרת המשאב המותאם אישית הקשורה מקבוצת anthos.gke.io באשכול. הגדרת המשאב המותאם אישית מותקנת אחרי שמוסיפים את ההערה של תכונת התצוגה המקדימה למשאב של האשכול בניהול עצמי.

הגדרת המעבד (CPU)

מאפיין (property) תיאור
cpu.reservedCPUs חובה. ניתן לשינוי. מחרוזת. בשדה הזה מוגדרת קבוצה של ליבות CPU שיוזמנו עבור דמונים של מערכת Kubernetes, כמו kubelet, זמן הריצה של הקונטיינר וכלי לזיהוי בעיות בצומת. ליבות המעבד האלה משמשות גם לדמונים של מערכת ההפעלה (OS), כמו sshd ו-udev.

בשדה cpu.reservedCPUs מזינים רשימה של מספרי מעבדים או טווחים של מספרי מעבדים. מוודאים שרשימת המעבדים לא חופפת לרשימה שצוינה באמצעות cpu.isolatedCPUs. איחוד המעבדים שמופיעים בשני השדות האלה צריך לכלול את כל המעבדים של הצומת.
cpu.isolatedCPUs זה שינוי אופציונלי. ניתן לשינוי. מחרוזת. השדה cpu.isolatedCPUs מגדיר קבוצה של מעבדים שמשמשים באופן בלעדי לאפליקציות שרגישות לביצועים. הכלי לניהול מעבדים מתזמן קונטיינרים רק במעבדים שלא הוזמנו, בהתאם לסיווגים של איכות השירות (QoS) ב-Kubernetes. כדי לוודא שעומסי העבודה פועלים במעבדים המבודדים, צריך להגדיר את ה-Pods עם מחלקת ה-QoS המובטחת ולהקצות משאב CPU ל-Pod או ל-Container. כדי להבטיח תזמון של Pod, צריך לציין יחידות CPU של מספרים שלמים, ולא משאבי CPU חלקיים (cpu: "0.5"). 
apiVersion: v1
kind: Pod
...
spec:
  containers:
  ...
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "1"
  ...

מיקסום השימוש במעבדים מבודדים לעומסי עבודה מספק את היתרון הכי גדול בביצועים. בשדה הזה צריך להזין רשימה של מספרי מעבד או טווחים של מספרי מעבד. מוודאים שאין חפיפה בין רשימת המעבדים לבין הרשימה שצוינה באמצעות התג cpu.reservedCPUs, ושהאיחוד של הרשימות בשני השדות האלה כולל את כל המעבדים של הצומת.
cpu.balanceIsolated זה שינוי אופציונלי. ניתן לשינוי. בוליאני. ברירת מחדל: true. בשדה הזה מציינים אם קבוצת ה-CPU המבודדת עומדת בדרישות לאיזון עומסים אוטומטי של עומסי עבודה בין ליבות ה-CPU. כשמגדירים את השדה הזה לערך false, עומסי העבודה צריכים להקצות כל שרשור באופן מפורש למעבד ספציפי כדי לפזר את העומס בין המעבדים. הקצאות מפורשות של CPU מאפשרות לכם לקבל את הביצועים הכי צפויים עבור עומסי עבודה מובטחים, אבל הן מוסיפות מורכבות לעומסי העבודה.
cpu.globallyEnableIRQLoadBalancing חובה. ניתן לשינוי. בוליאני. ברירת מחדל: true. בשדה הזה מציינים אם להפעיל איזון עומסים של בקשות להפסקות (IRQ) עבור קבוצת המעבדים המבודדת.

הגדרת הזיכרון

מאפיין (property) תיאור
defaultHugePageSize זה שינוי אופציונלי. ניתן לשינוי. ערכי ספירה: 1G או 2M. בשדה הזה מוגדר גודל ברירת המחדל של דפי הזיכרון הגדולים בפרמטרים של אתחול הליבה. הקצאת ה-Hugepages מתבצעת בזמן האתחול, לפני שהזיכרון הופך למקוטע. חשוב לשים לב: הגדרת גודל ברירת המחדל של דפי הענק ל-1G מסירה את כל התיקיות שקשורות ל-2M מהצומת. גודל ברירת המחדל של דף ענק של 1G מונע מכם להגדיר דפים ענקיים של 2M בצומת.
pages זה שינוי אופציונלי. ניתן לשינוי. מספר שלם. בשדה הזה מציינים את מספר דפי הזיכרון הגדולים שייווצרו בזמן האתחול. בשדה הזה מזינים מערך של דפים. לפני שמציינים hugepages, צריך לבדוק את הזיכרון שזמין לצמתים. לא כדאי לבקש יותר דפי ענק ממה שצריך, וגם לא כדאי להקצות את כל הזיכרון לדפי ענק. גם עומסי העבודה שלכם צריכים זיכרון רגיל.

בחירת צומת

מאפיין (property) תיאור
nodeSelector חובה. ניתן לשינוי. בשדה הזה תמיד צריך להזין את התווית של צומת העובד ב-Kubernetes, ‏ node-role.kubernetes.io/worker:"", כדי להבטיח שכוונון הביצועים יתבצע רק בצמתי עובד. בשדה הזה מציינים תווית צומת אופציונלית כצמד מפתח/ערך. התוויות של צמדי מפתח/ערך משמשות לבחירת צמתי עובד ספציפיים עם תוויות תואמות. כשהתוויות nodeSelector תואמות לתוויות בצומת עובד, פרופיל הביצועים מוחל על הצומת הזה. אם לא מציינים תווית של צמד מפתח/ערך בפרופיל, היא חלה על כל צמתי העובדים באשכול.

לדוגמה, התג nodeSelector הבא מציין שפרופיל ההתאמה יוחל רק על צמתי עובדים עם תוויות תואמות app: database:

...
spec:
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  ...

הגדרות Kubelet

מאפיין (property) תיאור
topologyManagerPolicy זה שינוי אופציונלי. ניתן לשינוי. רשימה: none, best-effort, restricted או single-numa-node. ברירת מחדל: best-effort. בשדה הזה מצוין כלל המדיניות של Topology Manager ב-Kubernetes שמשמש להקצאת משאבים לעומסי העבודה, על סמך סיווג איכות השירות (QoS) שהוקצה. מידע נוסף על האופן שבו מוקצים סוגי QoS זמין במאמר הגדרת איכות השירות (QoS) עבור Pods.

פעולות בפרופיל

מאפיין (property) תיאור
paused זה שינוי אופציונלי. ניתן לשינוי. בוליאני. מגדירים את paused לערך true כדי למנוע באופן זמני מבקרי DaemonSet לכוונן צמתים נבחרים.
updateStrategy זה שינוי אופציונלי. ניתן לשינוי. הגדרה שקובעת את האסטרטגיה להחלת שינויים בהגדרות האופטימיזציה על צמתים נבחרים.
updateStrategy.rollingUpdateMaxUnavailalble זה שינוי אופציונלי. ניתן לשינוי. מספר שלם. ברירת מחדל: 1. מציין את המספר המקסימלי של צמתים שאפשר לכוונן בו-זמנית. השדה הזה רלוונטי רק אם הערך של type הוא rolling.
updateStrategy.type זה שינוי אופציונלי. ניתן לשינוי. ערכי ספירה: batch או rolling. ברירת מחדל: rolling. מציין איך להחיל עדכוני פרופיל על צמתים נבחרים. אם רוצים להחיל את העדכון על כל הצמתים שנבחרו בו-זמנית, מגדירים את type ל-batch. כברירת מחדל, העדכונים מושקים באופן הדרגתי לצמתים בודדים, אחד אחרי השני.

בדיקת הסטטוס

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

מאפיין (property) תיאור
conditions המאפיין Condition מייצג את התצפיות העדכניות ביותר שזמינות לגבי המצב הנוכחי של משאב הפרופיל.
conditions.lastTransitionTime תמיד מוחזר. מחרוזת (בפורמט של תאריך ושעה). הפעם האחרונה שבה התנאי עבר מסטטוס אחד לסטטוס אחר. הזמן הזה מציין בדרך כלל מתי השתנה המצב הבסיסי. אם השעה הזו לא ידועה, השעה מציינת מתי השדה ב-API השתנה.
conditions.message זה שינוי אופציונלי. מחרוזת. הודעה קריאה שמציינת פרטים על המעבר. יכול להיות שהשדה הזה ריק.
conditions.observedGeneration זה שינוי אופציונלי. מספר שלם. אם השדה הזה מוגדר, הוא מייצג את metadata.generation שהתנאי הוגדר על פיו. לדוגמה, אם metadata.generation הוא 12, אבל status.condition[x].observedGeneration הוא 9, התנאי לא עדכני לגבי המצב הנוכחי של המופע.
conditions.reason חובה. מחרוזת. הסיבה למעבר האחרון בין התנאים.
conditions.status חובה. סטטוס התנאי: True, False או Unknown.
conditions.type חובה. ‫Type הוא סוג התנאי: Stalled או Reconciling.
readyNodes מספר הצמתים שהפרופיל של כוונון המודל הוחל עליהם בהצלחה.
reconcilingNodes מספר הצמתים שנבחרו (או שנבחרו בעבר) שנמצאים בתהליך של התאמה לפרופיל ההתאמה העדכני על ידי nodeconfig-controller-manager DaemonSet.
selectedNodes מספר ההערות שנבחרו. כלומר, מספר הצמתים שתואמים לבורר הצמתים של PerformanceTuningProfile המשאב המותאם אישית הזה.

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