חסוך בעלויות הענן של Kubernetes ב-AWS

תרגום המאמר הוכן ערב תחילת הקורס "פלטפורמת תשתית המבוססת על Kubernetes".

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

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

מאמר זה יכסה:

• ניקוי משאבים לא בשימוש (קוב-שרת)
• הקטנת קנה המידה בשעות שאינן עובדות (kube-downscaler)
• באמצעות קנה מידה אוטומטי אופקי (HPA),
• הפחתת שמירת משאבים מוגזמת (kube-resource-report, VPA)
• באמצעות מופעי Spot

ניקוי משאבים שאינם בשימוש

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

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

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

קוברנטס שוער (kube-janitor) עוזר לנקות את האשכול שלך. תצורת השוער גמישה לשימוש גלובלי ומקומי כאחד:

• כללים רחבי אשכול יכולים להגדיר את הזמן המרבי לחיים (TTL) עבור פריסות יחסי ציבור/בדיקות.
• ניתן להוסיף הערות למשאבים בודדים ב-janitor/ttl, למשל כדי להסיר אוטומטית את הספייק/אב-טיפוס לאחר 7 ימים.

כללים כלליים מוגדרים בקובץ YAML. הנתיב שלו עובר דרך הפרמטר --rules-file ב-kube-janitor. הנה כלל לדוגמה להסרת כל מרחבי השמות איתם -pr- בשם לאחר יומיים:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

הדוגמה הבאה מסדירה את השימוש בתווית האפליקציה בתרמילים של Deployment ו-StatefulSet עבור כל הפריסה/StatefulSets החדשים בשנת 2020, אך במקביל מאפשרת ביצוע בדיקות ללא תווית זו למשך שבוע:

- id: require-application-label
  # удалить deployments и statefulsets без метки "application"
  resources:
    - deployments
    - statefulsets
  # см. http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

הפעל הדגמה מוגבלת בזמן למשך 30 דקות באשכול הפועל על kube-janitor:

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

מקור נוסף להגדלת העלויות הוא נפחים מתמשכים (AWS EBS). מחיקת Kubernetes StatefulSet אינה מוחקת את הנפחים הקבועים שלו (PVC - PersistentVolumeClaim). נפחי EBS שאינם בשימוש יכולים בקלות לגרום לעלויות של מאות דולרים לחודש. ל-Kubernetes Janitor יש תכונה לניקוי PVC שאינם בשימוש. לדוגמה, כלל זה יסיר את כל ה-PVC שלא מותקנים על ידי מודול ושאינם מוזכרים על ידי StatefulSet או CronJob:

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor יכולה לעזור לך לשמור על האשכול שלך נקי ולמנוע עלויות מחשוב ענן להצטבר לאט. לקבלת הוראות פריסה ותצורה, בצע README kube-janitor.

הקטנת קנה המידה בשעות שאינן עובדות

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

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

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # не отключать компоненты инфраструктуры
  - --exclude-namespaces=kube-system,infra
  # не отключать kube-downscaler, а также оставить Postgres Operator, чтобы исключенными БД можно было управлять
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Mon-Fri 08:00-20:00 Europe/Berlin
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

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

הקטנה מ-~13 ל-4 צמתים עובדים בהחלט עושה הבדל ניכר בחשבון ה-AWS שלך.

אבל מה אם אני צריך לעבוד במהלך "זמן השבתה" של אשכול? ניתן למנוע לצמיתות פריסות מסוימות משינוי קנה מידה על ידי הוספת הערה להורדה/אי הכללה: אמת. ניתן להחריג באופן זמני פריסות באמצעות ההערה להורדה/אי הכללה-עד עם חותמת זמן מוחלטת בפורמט YYYY-MM-DD HH:MM (UTC). במידת הצורך, ניתן להקטין את האשכול כולו על ידי פריסת תרמיל עם ההערה downscaler/force-uptime, למשל, על ידי הפעלת nginx ריק:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # удалить развертывание через час
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

לראות README kube-downscaler, אם אתה מעוניין בהוראות פריסה ואפשרויות נוספות.

השתמש בקנה מידה אוטומטי אופקי

יישומים/שירותים רבים עוסקים בדפוס טעינה דינמי: לפעמים המודולים שלהם לא פעילים, ולפעמים הם עובדים בתפוקה מלאה. הפעלת צי קבוע של תרמילים כדי להתמודד עם עומס שיא מרבי אינו חסכוני. Kubernetes תומך בשינוי קנה מידה אוטומטי אופקי על פני משאב HorizontalPodAutoscaler (HPA). שימוש במעבד הוא לעתים קרובות אינדיקטור טוב לשינוי קנה מידה:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 100
        type: Utilization

Zalando יצרה רכיב כדי לחבר בקלות מדדים מותאמים אישית לשינוי קנה מידה: מתאם מדדי Kube (kube-metrics-adapter) הוא מתאם מדדים גנרי עבור Kubernetes שיכול לאסוף ולהגיש מדדים מותאמים אישית וחיצוניים עבור קנה מידה אוטומטי אופקי של פודים. הוא תומך בקנה מידה המבוסס על מדדי Prometheus, תורי SQS והגדרות אחרות. לדוגמה, כדי לשנות את קנה המידה של הפריסה שלך למדד מותאם אישית המיוצג על ידי האפליקציה עצמה כ-JSON ב-/metrics השתמש:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
    metric-config.pods.requests-per-second.json-path/json-key: "$.http_server.rps"
    metric-config.pods.requests-per-second.json-path/path: /metrics
    metric-config.pods.requests-per-second.json-path/port: "9090"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        averageValue: 1k
        type: AverageValue

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

צמצם רישום יתר של משאבים

עומסי העבודה של Kubernetes קובעים את צרכי המעבד/זיכרון שלהם באמצעות "בקשות משאבים". משאבי מעבד נמדדים בליבות וירטואליות או יותר נפוץ ב"מיליקורים", למשל 500m מרמז על 50% vCPU. משאבי זיכרון נמדדים בבתים, וניתן להשתמש בסיומות נפוצות, כמו 500Mi, כלומר 500 מגה. משאבים מבקשים "נעילת" קיבולת בצמתי עובדים, כלומר פוד עם בקשת מעבד של 1000 מ' בצומת עם 4 vCPUs ישאיר רק 3 vCPUs זמינים לתרמילים אחרים. [1]

רפיון (רזרבה עודפת) הוא ההבדל בין המשאבים המבוקשים לשימוש בפועל. לדוגמה, פוד שמבקש 2 GiB של זיכרון אבל משתמש רק ב-200 MiB יש ~1,8 GiB של זיכרון "עודף". עודף עולה כסף. אפשר להעריך באופן גס ש-1 GiB של זיכרון מיותר עולה ~$10 לחודש. [2]

דוח משאבי Kubernetes (kube-resource-report) מציג עתודות עודפות ויכול לעזור לך לקבוע פוטנציאל חיסכון:

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

צמצום בקשת ה-CPU מ-3000 מ' ל-~400 מ' מפנה משאבים לעומסי עבודה אחרים ומאפשר לאשכול להיות קטן יותר.

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

אבל האם אנחנו באמת רוצים שאנשים ישנו ערכים בקבצי YAML? לא, מכונות יכולות לעשות את זה הרבה יותר טוב! Kubernetes Autoscaler Pod אנכי (VPA) עושה בדיוק את זה: מתאים בקשות משאבים ואילוצים בהתאם לעומס העבודה. להלן גרף לדוגמה של בקשות מעבד Prometheus (קו כחול דק) שהותאמו על ידי VPA לאורך זמן:

Zalando משתמש ב-VPA בכל האשכולות שלו עבור רכיבי תשתית. יישומים לא קריטיים יכולים גם להשתמש ב-VPA.

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

כתבתי קטן פוסט בבלוג על VPA בשנת 2019, ולאחרונה ב קהילת משתמשי הקצה של CNCF דנה בנושא VPA.

שימוש ב-EC2 Spot Instances

אחרון חביב, ניתן להוזיל את עלויות AWS EC2 על ידי שימוש במופעי Spot כצומתי עבודה של Kubernetes [3]. מופעי ספוט זמינים בהנחה של עד 90% בהשוואה למחירי On Demand. הפעלת Kubernetes ב-EC2 Spot היא שילוב טוב: עליך לציין מספר סוגי מופעים שונים לזמינות גבוהה יותר, כלומר אתה יכול לקבל צומת גדול יותר באותו מחיר או נמוך יותר, והקיבולת המוגדלת יכולה לשמש עומסי עבודה של Kubernetes במכולות.

כיצד להפעיל את Kubernetes ב-EC2 Spot? ישנן מספר אפשרויות: השתמש בשירות צד שלישי כמו SpotInst (נקרא כעת "Spot", אל תשאל אותי למה), או פשוט הוסף Spot AutoScalingGroup (ASG) לאשכול שלך. לדוגמה, הנה קטע CloudFormation עבור ASG Spot "מותאם לקיבולת" עם מספר סוגי מופעים:

MySpotAutoScalingGroup:
 Properties:
   HealthCheckGracePeriod: 300
   HealthCheckType: EC2
   MixedInstancesPolicy:
     InstancesDistribution:
       OnDemandPercentageAboveBaseCapacity: 0
       SpotAllocationStrategy: capacity-optimized
     LaunchTemplate:
       LaunchTemplateSpecification:
         LaunchTemplateId: !Ref LaunchTemplate
         Version: !GetAtt LaunchTemplate.LatestVersionNumber
       Overrides:
         - InstanceType: "m4.2xlarge"
         - InstanceType: "m4.4xlarge"
         - InstanceType: "m5.2xlarge"
         - InstanceType: "m5.4xlarge"
         - InstanceType: "r4.2xlarge"
         - InstanceType: "r4.4xlarge"
   LaunchTemplate:
     LaunchTemplateId: !Ref LaunchTemplate
     Version: !GetAtt LaunchTemplate.LatestVersionNumber
   MinSize: 0
   MaxSize: 100
   Tags:
   - Key: k8s.io/cluster-autoscaler/node-template/label/aws.amazon.com/spot
     PropagateAtLaunch: true
     Value: "true"

כמה הערות על השימוש ב-Spot עם Kubernetes:

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

תקציר

אני מקווה שתמצא כמה מהכלים שהוצגו שימושיים בהפחתת חשבון הענן שלך. אתה יכול למצוא את רוב תוכן המאמר גם ב ההרצאה שלי ב-DevOps Gathering 2019 ב-YouTube ובשקופיות.

מהן השיטות המומלצות שלך לחיסכון בעלויות הענן ב-Kubernetes? אנא הודע לי ב- טוויטר (@try_except_).

[1] למעשה, פחות מ-3 מעבדי vCPU יישארו שמישים מכיוון שתפוקת הצומת מופחתת על ידי משאבי מערכת שמורים. Kubernetes מבחין בין קיבולת צומת פיזית לבין משאבים "מוספקים" (ניתן להקצאת צומת).

[2] דוגמה חישוב: מופע אחד m5.large עם 8 GiB של זיכרון הוא ~$84 ​​לחודש (eu-central-1, On-Demand), כלומר. חסימת צומת 1/8 היא בערך ~$10 לחודש.

[3] ישנן דרכים רבות נוספות להפחית את חשבון EC2 שלך, כגון מופעים שמורים, תוכנית חיסכון וכו' - אני לא אעסוק בנושאים האלה כאן, אבל בהחלט כדאי לך לבדוק אותם!

למידע נוסף על הקורס.

מקור: www.habr.com