מזינוקים לחיסכון: אופטימיזציה של עלויות Kubernetes
חשבון ה-AWS שלנו קפץ ב-34% ברבעון אחד. מפת הדרכים של המוצר לא הראתה שינויים. הסיבה הייתה פשוטה: אשכולות ה-Kubernetes שלנו בזבזו כסף.
מהנדסים מנחשים לעיתים קרובות כמה CPU וזיכרון שירות צריך. הם מעגלים כלפי מעלה כדי להיות בטוחים. זה יוצר קיבולת רפאים. אתם משלמים על משאבים שהאפליקציות שלכם לעולם לא משתמשות בהם.
הנה איך תיקנו את זה וחסכנו 34% מהעלויות החודשיות.
הבעיה המרכזית: Requests לעומת Limits
Requests הם מה שאתם מבטיחים. Kubernetes משתמש במספר הזה כדי למקם את ה-pod שלכם על node. המספר הזה הוא שמניע את החשבון שלכם.
Limits הם התקרה. אם pod מגיע למגבלת CPU, הוא מאט. אם הוא מגיע למגבלת זיכרון, הוא קורס.
צוותים רבים מגדירים requests שווים ל-limits. זה אומר שאתם משלמים על קיבולת שיא 24/7, גם כשהשירות שלכם במצב idle.
האסטרטגיה שלנו לחיסכון
- למדו לפני שאתם פועלים: השתמשו ב-Prometheus וב-Grafana כדי לראות שימוש בפועל.
- השתמשו באחוזונים (percentiles): הסתכלו על שימוש p95 לאורך 4 שבועות. אל תשתמשו בממוצעים. ממוצעים מסתירים זינוקים.
- התאימו את ה-requests לגודל הנכון: הגדירו requests לפי שימוש p95 בתוספת buffer של 20%.
- נהלו CPU limits: הימנעו מ-CPU limits צפופים בשירותים רגישים כדי למנוע throttling.
- אוטומציה של scaling: השתמשו ב-HPA עבור זינוקי תעבורה וב-VPA כדי לכוונן pods בודדים.
התוצאות
הפחתנו את מספר ה-nodes שלנו מ-40 ל-26. ממוצע ניצול ה-CPU עלה מ-14% ל-52%. עלויות המחשוב החודשיות ירדו מ-$48,200 ל-$31,900. ה-latency למעשה השתפר ב-35%.
אופטימיזציה היא לא פרויקט חד-פעמי. זו הרגל. אם אתם כותבים resource request המבוסס על ניחוש, אתם מבזבזים כסף.
צ'קליסט עבור ה-cluster שלכם:
• בנו דאשבורד שמציג שימוש ב-requested לעומת שימוש בפועל