10 טעויות נפוצות בשימוש ב-Kubernetes

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

במהלך שנות השימוש ב-Kubernetes, עבדנו עם מספר רב של אשכולות (הן מנוהלים והן לא מנוהלים - ב-GCP, AWS ו-Azure). עם הזמן התחלנו לשים לב שכמה טעויות חוזרות על עצמן כל הזמן. אולם, אין בכך בושה: את רובם עשינו בעצמנו!

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

1. משאבים: בקשות ומגבלות

פריט זה בהחלט ראוי לתשומת הלב הקרובה ביותר ולמקום הראשון ברשימה.

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

BestEffort (מְאוֹד לא מוּמלָץ):

resources: {}

בקשת מעבד נמוכה במיוחד (מאוד לא מוּמלָץ):

   resources:
      Requests:
        cpu: "1m"

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

מבחר מוגזם (התחייבות יתר) בעיות זיכרון יכולות להוביל לבעיות גדולות יותר. הגעה למגבלת ה-CPU כרוכה בדילוג על מחזורי שעון, בעוד שהגעה למגבלת הזיכרון כרוכה בהריגת הפוד. האם אי פעם התבוננת OOMkill? כן, על זה בדיוק אנחנו מדברים.

האם אתה רוצה למזער את הסבירות שזה יקרה? אל תקצה יתר על המידה זיכרון והשתמש ב-Guaranteed QoS (איכות שירות) על ידי הגדרת בקשת הזיכרון למגבלה (כמו בדוגמה למטה). קרא עוד על זה ב מצגות הנינג ג'ייקובס (מהנדס ראשי בזלנדו).

מתפרץ (סיכוי גבוה יותר להיהרג OOM):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

מובטח:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

מה עשוי לעזור בעת הגדרת משאבים?

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

kubectl top pods
kubectl top pods --containers
kubectl top nodes

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

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

שימוש יעיל בכוח המחשוב אינו משימה קלה. זה כמו לשחק טטריס כל הזמן. אם אתה משלם יותר מדי עבור כוח מחשוב עם צריכה ממוצעת נמוכה (נניח ~10%), אנו ממליצים להסתכל על מוצרים המבוססים על AWS Fargate או Virtual Kubelet. הם בנויים על מודל חיוב ללא שרת/תשלום לפי שימוש, שעשוי להתברר כמוזל יותר בתנאים כאלה.

2. בדיקות חיוניות ומוכנות

כברירת מחדל, בדיקות חיוניות ומוכנות אינן מופעלות ב-Kubernetes. ולפעמים הם שוכחים להדליק אותם...

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

מבחנים אלה מבולבלים לעתים קרובות אחד עם השני:

• חי - בדיקת "הישרדות", אשר מפעילה מחדש את הפוד אם הוא נכשל;
• מוכנות - בדיקת מוכנות, אם היא נכשלת, היא מנתקת את הפוד משירות Kubernetes (ניתן לבדוק זאת באמצעות kubectl get endpoints) והתנועה לא מגיעה אליו עד שהבדיקה הבאה תושלם בהצלחה.

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

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

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

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

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

3. LoadBalancer עבור כל שירות HTTP

סביר להניח שיש לך שירותי HTTP באשכול שלך שתרצה להעביר לעולם החיצון.

אם תפתח את השירות בתור type: LoadBalancer, הבקר שלו (בהתאם לספק השירות) יספק וינהל משא ומתן על LoadBalancer חיצוני (לא בהכרח פועל על L7, אלא אפילו על L4), וזה עשוי להשפיע על העלות (כתובת IPv4 סטטית חיצונית, כוח מחשוב, חיוב לשנייה ) בשל הצורך ליצור מספר רב של משאבים כאלה.

במקרה זה, הרבה יותר הגיוני להשתמש במאזן עומסים חיצוני אחד, פתיחת שירותי כ type: NodePort. או יותר טוב, הרחב משהו כמו nginx-ingress-controller (או טראפיק), מי יהיה היחיד NodePort נקודת קצה המשויכת למאזן העומס החיצוני ותנתב את התנועה באשכול באמצעות חדירה-משאבי Kubernetes.

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

4. קנה מידה אוטומטי של אשכול מבלי לקחת בחשבון את התכונות שלו

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

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

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

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

5. הזנחת יכולות IAM/RBAC

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

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

שכח מ-kube2iam ועבור ישר לתפקידי IAM עבור חשבונות שירות (כמתואר ב פתק באותו שם סטפן ורוני):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

הערה אחת. לא כזה קשה, נכון?

כמו כן, אל תעניק הרשאות לחשבונות שירות ופרופילי מופעים admin и cluster-adminאם הם לא צריכים את זה. זה קצת יותר קשה ליישום, במיוחד ב-RBAC K8s, אבל בהחלט שווה את המאמץ.

6. אל תסתמך על אנטי זיקה אוטומטית לתרמילים

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

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

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

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

כאן אנחנו מדברים על podAntiAffinity בצמתים שונים: topologyKey: "kubernetes.io/hostname", - ולא על אזורי זמינות שונים. כדי ליישם HA מן המניין, תצטרך לחפור עמוק יותר בנושא זה.

7. התעלמות מ-PodDisruptionBudgets

תאר לעצמך שיש לך עומס ייצור על אשכול Kubernetes. מעת לעת, יש לעדכן (או לבטל) את הצמתים ואת האשכול עצמו. PodDisruptionBudget (PDB) הוא משהו כמו הסכם ערבות שירות בין מנהלי אשכולות ומשתמשים.

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

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

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

אתה יכול לקרוא עוד על זה כאן.

8. מספר משתמשים או סביבות באשכול משותף

מרחבי שמות של Kubernetes (מרחבי שמות) לא מספקים בידוד חזק.

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

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

9. מדיניות תנועה חיצונית: אשכול

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

יחד עם זאת, תרמילים אמיתיים המשויכים לשירות NodePort הנ"ל זמינים בדרך כלל רק על מסויים תת-קבוצה של צמתים אלה. במילים אחרות, אם אני מתחבר לצומת שאין לו את הפוד הנדרש, הוא יעביר תנועה לצומת אחר, הוספת הופ והגדלת השהיה (אם צמתים ממוקמים באזורי זמינות/מרכזי נתונים שונים, ההשהיה יכולה להיות די גבוהה; בנוסף, עלויות תעבורת יציאה יגדלו).

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

יש סיכוי גבוה שאתה כבר משתמש במשהו כמו טראפיק או nginx-ingress-controller כנקודת קצה של NodePort (או LoadBalancer, המשתמשת גם ב-NodePort) לניתוב תעבורת כניסת HTTP, והגדרת אפשרות זו יכולה להפחית משמעותית את ההשהיה עבור בקשות כאלה.

В פרסום זה אתה יכול ללמוד עוד על externalTrafficPolicy, היתרונות והחסרונות שלה.

10. אל תקשור לאשכולות ואל תתעלל במישור השליטה

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

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

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

מצד שני, אתה לא צריך להיסחף עם מניפולציות. עם הזמן שכבת הבקרה עלולה להיות איטית. סביר להניח שזה נובע ממספר רב של אובייקטים שנוצרו ללא סיבובם (מצב שכיח בשימוש בהלם עם הגדרות ברירת מחדל, וזו הסיבה שהמצב שלו במפות configmap/סודות לא מתעדכן - כתוצאה מכך, אלפי אובייקטים מצטברים ב- שכבת הבקרה) או עם עריכה מתמדת של אובייקטי kube-api (עבור קנה מידה אוטומטי, עבור CI/CD, עבור ניטור, יומני אירועים, בקרים וכו').

בנוסף, אנו ממליצים לבדוק את הסכמי SLA/SLO עם ספק Kubernetes המנוהל ולשים לב לערבות. הספק יכול להבטיח שליטה בזמינות שכבת (או רכיבי המשנה שלו), אבל לא עיכוב p99 של בקשות שאתה שולח אליו. במילים אחרות, אתה יכול להיכנס kubectl get nodes, וקבל תשובה רק לאחר 10 דקות, וזאת לא תהיה הפרה של תנאי הסכם השירות.

11. בונוס: שימוש בתגית האחרונה

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

ECR שומר על אי-שינוי של תגיות תמונה; אנו ממליצים שתכיר את התכונה המדהימה הזו.

תקציר

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

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

מי שרוצה להוסיף לרשימת השגיאות המופיעה במאמר זה יכול לפנות אלינו בטוויטר (@MarekBartik, @MstrsObserver).

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «עיצוב אשכולות Kubernetes: כמה צריכים להיות?";
• «ה-ABC של אבטחה ב-Kubernetes: אימות, הרשאה, ביקורת";
• «קנה מידה אוטומטי וניהול משאבים ב- Kubernetes"(ביקורת ודיווח וידאו);
• «ConfigMaps ב-Kubernetes: ניואנסים שכדאי לדעת עליהם".

מקור: www.habr.com