תשעה טיפים לביצועים של Kubernetes

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

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

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

1. עקוב אחר משאבי הצוות והאפליקציה

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

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

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

בנוסף, בעזרת העזרה limitranges אתה יכול להגדיר ערכי משאב עבור המיכל בהתחלה - מינימום, מקסימום וברירת מחדל:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

זכור להגביל את משאבי מרחב השמות כך שפקודה אחת לא תוכל לקחת את כל המשאבים של האשכול:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

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

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

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

2. בחר את אחסון הקבצים הטוב ביותר

כאן ברצוני לגעת בנושא של אמצעי אחסון מתמידים ותת-מערכת הדיסק של צמתי העבודה של Kubernetes. אני מקווה שאף אחד לא משתמש ב-"Cube" ב-HDD בייצור, אבל לפעמים אפילו SSD רגיל כבר לא מספיק. התמודדנו עם בעיה כזו שהלוגים הורגים את הדיסק על ידי פעולות I/O, ואין כאן הרבה פתרונות:

• השתמש בכונני SSD בעלי ביצועים גבוהים או עבור ל-NVMe (אם אתה מנהל את החומרה שלך).

• הורד את רמת הרישום.

• עשה איזון "חכם" של תרמילים שאונסים את הדיסק (podAntiAffinity).

צילום המסך שלמעלה מראה מה קורה תחת nginx-ingress-controller עם דיסק כאשר רישום access_logs מופעל (~12k יומנים/שנייה). מצב כזה, כמובן, יכול להוביל לפגיעה בכל היישומים בצומת זה.

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

3. בנה תמונות מותאמות

עדיף להשתמש בתמונות מותאמות למיכל כדי ש-Kubernetes יוכל להביא אותן מהר יותר ולבצע אותן ביעילות רבה יותר. 

אופטימיזציה פירושה שתמונות:

• להכיל רק יישום אחד או לבצע רק פונקציה אחת;

• גודל קטן, מכיוון שתמונות גדולות מועברות בצורה גרועה יותר דרך הרשת;

• יש נקודות קצה בריאות ומוכנות שבהן Kubernetes יכולה להשתמש כדי לנקוט בפעולה במקרה של השבתה;

• השתמש במערכות הפעלה ידידותיות למיכל (כמו Alpine או CoreOS) עמידות יותר בפני שגיאות תצורה;

• השתמש בבנייה מרובה שלבים כך שתוכל לפרוס רק יישומים מהודרים ולא את המקורות הנלווים.

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

1. עומס רשת מופחת על האשכול כולו.

2. זמן ההפעלה של מיכל הקטן.

3. גודל קטן יותר של כל הרישום של Docker שלך.

4. השתמש במטמון DNS

אם אנחנו מדברים על עומסים גבוהים, אז בלי לכוון את מערכת ה-DNS של האשכול, החיים די עלובים. פעם, מפתחי Kubernetes תמכו בפתרון kube-dns שלהם. היא יושמה גם בארצנו, אך התוכנה הזו לא התכווננה ​​במיוחד ולא נתנה את הביצועים הנדרשים, אם כי, כך נראה, המשימה פשוטה. ואז הופיעו coredns, אליהם עברנו ולא ידענו צער, מאוחר יותר זה הפך לשירות ה-DNS ברירת המחדל ב-K8s. בשלב מסוים, גדלנו ל-40 אלף rps למערכת ה-DNS, וגם הפתרון הזה לא הספיק. אבל, במקרה מזל, Nodelocaldns יצא, הלא הוא מטמון מקומי של צומת, aka NodeLocal DNSCache.

למה אנחנו משתמשים בזה? יש באג בליבת הלינוקס שכאשר גישה מרובת דרך conntrack NAT על UDP, מובילה לתנאי מירוץ לכתיבה לטבלאות conntrack, וחלק מהתנועה דרך NAT אובדת (כל נסיעה דרך השירות היא NAT). Nodelocaldns פותר בעיה זו על ידי היפטרות מ-NAT ושדרוג קישוריות TCP ל-DNS במעלה הזרם, כמו גם אחסון במטמון של שאילתות DNS במעלה הזרם באופן מקומי (כולל מטמון שלילי קצר של 5 שניות).

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

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

VPA מאפשר לך להעלות אוטומטית את הבקשות/הגבלות של המכולות שלך בתרמיל על סמך השימוש בפועל. איך זה יכול להיות שימושי? אם יש לך Pods שמסיבה כלשהי לא ניתן להרחיב אותם בצורה אופקית (וזה לא לגמרי אמין), אז אתה יכול לנסות לסמוך על VPA שתשנה את המשאבים שלו. התכונה שלו היא מערכת המלצות המבוססת על נתונים היסטוריים ועדכניים מ-metric-server, כך שאם אינך רוצה לשנות בקשות/מגבלות אוטומטית, אתה יכול פשוט לנטר את המשאבים המומלצים עבור הקונטיינרים שלך ולבצע אופטימיזציה של ההגדרות כדי לחסוך במעבד ובזיכרון באשכול.

התמונה נלקחה מ-https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

לדוגמה, להלן הגדרות הפוד האופייניות:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

מנוע ההמלצות קובע שהאפליקציה שלך זקוקה ל-300 מטר מעבד ו-500Mi כדי לפעול כהלכה. תקבל את ההגדרות הבאות:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

כפי שהוזכר לעיל, זהו קנה מידה פרופורציונלי המבוסס על יחס הבקשות/הגבלות במניפסט:

• CPU: 200m → 300m: יחס 1:1.75;

• זיכרון: 250Mi → 500Mi: יחס של 1:2.

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

התמונה נלקחה מ-https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

6. אל תשכח על זיקה לצומת וזיקת ​​פוד

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

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

נניח שיש לך שני צמתים: אחד עם CPUType=HIGHFREQ ומספר רב של ליבות מהירות, אחר עם MemoryType=HIGHMEMORY יותר זיכרון וביצועים מהירים יותר. הדרך הקלה ביותר היא להקצות פריסת פוד לצומת HIGHFREQעל ידי הוספה למדור spec בורר כזה:

…
nodeSelector:
	CPUType: HIGHFREQ

דרך יקרה וספציפית יותר לעשות זאת היא להשתמש nodeAffinity בתחום affinity סעיף spec. ישנן שתי אפשרויות:

• requiredDuringSchedulingIgnoredDuringExecution: הגדרה קשה (מתזמן יפרוס תרמילים רק בצמתים ספציפיים (ולא בשום מקום אחר));

• preferredDuringSchedulingIgnoredDuringExecution: הגדרה רכה (המתזמן ינסה לפרוס לצמתים ספציפיים, ואם היא נכשלת, הוא ינסה לפרוס לצומת הזמין הבא).

אתה יכול לציין תחביר ספציפי לניהול תוויות צומת, למשל, In, NotIn, Exists, DoesNotExist, Gt או Lt. עם זאת, זכרו ששיטות מורכבות ברשימות ארוכות של תוויות יאטו את קבלת ההחלטות במצבים קריטיים. במילים אחרות, אל תסבך יתר על המידה.

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

В podAffinity שדות affinity סעיף spec אותם שדות זמינים כמו במקרה של nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. ההבדל היחיד הוא זה matchExpressions יקשור תרמילים לצומת שכבר מריץ פוד עם התווית הזו.

More Kubernetes מציעה תחום podAntiAffinity, אשר, לעומת זאת, אינו קושר פוד לצומת עם תרמילים ספציפיים.

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

7. כתמים וסובלנות

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

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

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

ראוי גם לציין שמנגנון ההכתמה תומך בשלוש השפעות עיקריות: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule אומר שעד שיהיה ערך מתאים במפרט הפוד tolerations, לא ניתן לפרוס אותו לצומת (בדוגמה זו node10).

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

• NoExecute - אפקט זה מפעיל פינוי מיידי של תרמילים שאין להם ערך תואם tolerations.

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

כך ייראה מפרט הפוד:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

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

8. הגדר עדיפות פריסת תרמילים

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

Kubernetes מציעה דרכים שונות להגדיר עדיפות ו-Preemption של Pod. ההגדרה מורכבת מכמה חלקים: אובייקט PriorityClass ותיאורי שדות priorityClassName במפרט התרמיל. שקול דוגמה:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

אנחנו יוצרים PriorityClass, תן לו שם, תיאור וערך. הגבוה יותר value, ככל שהעדיפות גבוהה יותר. הערך יכול להיות כל מספר שלם של 32 סיביות קטן או שווה ל-1. ערכים גבוהים יותר שמורים לתרמילים של מערכת קריטיים למשימה, שבדרך כלל לא ניתן להקדים אותם. הפינוי יתרחש רק אם לתרמיל העדיפות הגבוהה אין לאן להסתובב, אז חלק מהפודים מצומת מסוים יפונו. אם המנגנון הזה נוקשה מדי בשבילך, אז אתה יכול להוסיף את האפשרות preemptionPolicy: Never, ואז לא תהיה מקדמה, הפוד יהיה הראשון בתור וימתין למתזמן כדי למצוא עבורו משאבים פנויים.

לאחר מכן, אנו יוצרים תרמיל, שבו אנו מציינים את השם priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

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

כך, במידת הצורך, תוכל להגביר את היעילות של פריסת שירותים קריטיים, כגון nginx-ingress-controller, coredns וכו'.

9. בצע אופטימיזציה של אשכול ה-ETCD שלך

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

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

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

1. יש חומרה טובה, על סמך גודל האשכול (תוכל לקרוא כאן).

2. כוונן כמה פרמטרים אם פיזרת אשכול בין זוג DCs או הרשת שלך ודיסקים משאירים הרבה מה לרצות (תוכל לקרוא כאן).

מסקנה

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

מקור: www.habr.com