در هزینه های ابری Kubernetes در AWS صرفه جویی کنید

ترجمه مقاله در آستانه شروع دوره آماده شد "پلتفرم زیرساخت مبتنی بر Kubernetes".

چگونه هنگام کار با Kubernetes در هزینه های ابری صرفه جویی کنیم؟ هیچ راه حل درستی وجود ندارد، اما این مقاله چندین ابزار را شرح می دهد که می تواند به شما کمک کند منابع خود را به طور موثرتری مدیریت کنید و هزینه های رایانش ابری خود را کاهش دهید.

من این مقاله را با در نظر گرفتن Kubernetes برای AWS نوشتم، اما (تقریبا) دقیقاً به همان روش برای سایر ارائه دهندگان ابری اعمال خواهد شد. من فرض می‌کنم خوشه(های) شما قبلاً مقیاس خودکار پیکربندی شده است (Cluster-autoscaler). حذف منابع و کاهش استقرار شما تنها در صورتی در هزینه شما صرفه جویی می کند که ناوگان گره های کارگر شما را نیز کاهش دهد (نمونه های EC2).

این مقاله پوشش خواهد داد:

• پاکسازی منابع استفاده نشده (کوبه سرایدار)
• کاهش پوسته پوسته شدن در ساعات غیر کاری (kube-downscaler)
• با استفاده از مقیاس خودکار افقی (HPA)،
• کاهش رزرو بیش از حد منابع (kube-resource-report، VPA)
• با استفاده از نمونه های Spot

پاکسازی منابع استفاده نشده

کار کردن در یک محیط پر سرعت عالی است. ما سازمان های فناوری می خواهیم شتاب گرفت. تحویل سریعتر نرم افزار همچنین به معنای استقرار بیشتر روابط عمومی، محیط های پیش نمایش، نمونه های اولیه و راه حل های تحلیلی است. همه چیز در Kubernetes مستقر شده است. چه کسی برای پاکسازی دستی استقرارهای آزمایشی وقت دارد؟ فراموش کردن حذف آزمایش یک هفته ای آسان است. صورت حساب ابری به دلیل چیزی که فراموش کرده‌ایم ببندیم بالا می‌رود:

(هنینگ جیکوبز:
ژیزا:
(نقل قول) کوری کوئین:
باور غلط: حساب AWS شما تابعی از تعداد کاربرانی است که دارید.
واقعیت: امتیاز AWS شما تابعی از تعداد مهندسانی است که دارید.

ایوان کورنوسوف (در پاسخ):
واقعیت واقعی: امتیاز AWS شما تابعی از تعداد چیزهایی است که فراموش کرده اید غیرفعال/حذف کنید.)

سرایدار کوبرنتیس (kube-janitor) به تمیز کردن خوشه شما کمک می کند. پیکربندی سرایدار برای استفاده جهانی و محلی انعطاف پذیر است:

• قوانین کلستری می توانند حداکثر زمان برای زنده ماندن (TTL) را برای استقرار PR/آزمایش تعریف کنند.
• منابع فردی را می توان با janitor/ttl حاشیه نویسی کرد، به عنوان مثال برای حذف خودکار سنبله/نمونه اولیه پس از 7 روز.

قوانین کلی در فایل YAML تعریف شده است. مسیر آن از طریق پارامتر عبور می کند --rules-file در کوبه-سرایدار. در اینجا یک قانون مثال برای حذف همه فضاهای نام وجود دارد -pr- به نام پس از دو روز:

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

مثال زیر استفاده از برچسب برنامه روی پادهای Deployment و StatefulSet را برای همه Deployments/StatefulSet های جدید در سال 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.

پوسته پوسته شدن را در ساعات غیر کاری کاهش دهید

سیستم‌های تست و مرحله‌بندی معمولاً برای کار فقط در ساعات کاری مورد نیاز هستند. برخی از برنامه‌های تولید، مانند ابزارهای پشتیبان/ادمین، تنها به دسترسی محدود نیاز دارند و ممکن است یک شبه غیرفعال شوند.

Kubernetes Downscaler (kube-downscaler) به کاربران و اپراتورها اجازه می دهد تا در ساعات غیر کاری سیستم را کاهش دهند. Deployments و 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) حذف کرد. در صورت لزوم، کل خوشه را می توان با استقرار یک pod با حاشیه نویسی کوچک کرد downscaler/force-uptimeبه عنوان مثال، با راه اندازی nginx blank:

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). استفاده از CPU اغلب یک شاخص خوب برای مقیاس بندی است:

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 Metrics (kube-metrics-adapter) یک آداپتور معیارهای عمومی برای Kubernetes است که می تواند معیارهای سفارشی و خارجی را برای مقیاس خودکار افقی pods جمع آوری و ارائه دهد. از مقیاس بندی بر اساس معیارهای 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 نیازهای CPU/حافظه آنها را از طریق "درخواست منابع" تعیین می کند. منابع CPU در هسته های مجازی یا معمولاً در "میلی کور" اندازه گیری می شوند، برای مثال 500 متر به معنای 50٪ vCPU است. منابع حافظه بر حسب بایت اندازه گیری می شوند و می توان از پسوندهای رایج مانند 500Mi به معنی 500 مگابایت استفاده کرد. ظرفیت درخواست‌های منبع در گره‌های کارگر "قفل" می‌شود، به این معنی که یک غلاف با درخواست CPU 1000 متر روی یک گره با 4 vCPU تنها 3 vCPU را در دسترس سایر pod‌ها قرار می‌دهد. [1]

سستی (ذخایر اضافی) تفاوت بین منابع درخواستی و استفاده واقعی است. به عنوان مثال، یک پاد که 2 گیگابایت حافظه درخواست می کند اما فقط از 200 مگابایت استفاده می کند، 1,8 گیگابایت حافظه "اضافی" دارد. مازاد هزینه دارد. تقریباً می توان تخمین زد که 1 گیگابایت حافظه اضافی حدود 10 دلار در ماه هزینه دارد. [2]

گزارش منبع Kubernetes (kube-resource-report) ذخایر اضافی را نشان می دهد و می تواند به شما در تعیین پتانسیل پس انداز کمک کند:

گزارش منبع Kubernetes مازاد تجمیع شده توسط برنامه و دستور را نشان می دهد. این به شما امکان می‌دهد مکان‌هایی را بیابید که می‌توان تقاضای منابع را کاهش داد. گزارش HTML تولید شده فقط یک عکس فوری از استفاده از منابع ارائه می دهد. برای تعیین درخواست های منابع کافی، باید به مصرف CPU/حافظه در طول زمان نگاه کنید. در اینجا نمودار Grafana برای یک سرویس "معمولی" با CPU سنگین آمده است: همه پادها به طور قابل توجهی کمتر از 3 هسته CPU درخواستی استفاده می کنند:

کاهش درخواست CPU از 3000 متر به 400 متر، منابع را برای بارهای کاری دیگر آزاد می کند و به خوشه اجازه می دهد کوچکتر شود.

"متوسط ​​استفاده از CPU از نمونه های EC2 اغلب در محدوده درصد تک رقمی قرار دارد." کوری کوین می نویسد. در حالی که برای EC2 تخمین اندازه مناسب ممکن است تصمیم بدی باشدتغییر برخی پرس و جوهای منابع Kubernetes در یک فایل YAML آسان است و می تواند صرفه جویی زیادی را به همراه داشته باشد.

اما آیا ما واقعاً می خواهیم که افراد در فایل های YAML مقادیر را تغییر دهند؟ نه، ماشین ها می توانند این کار را خیلی بهتر انجام دهند! کوبرنتیس مقیاس کننده خودکار غلاف عمودی (VPA) دقیقاً این کار را انجام می دهد: درخواست های منابع و محدودیت ها را با توجه به حجم کار تطبیق می دهد. در اینجا یک نمودار نمونه از درخواست های CPU Prometheus (خط آبی نازک) است که توسط VPA در طول زمان اقتباس شده است:

Zalando از VPA در تمام خوشه های خود استفاده می کند برای اجزای زیرساخت برنامه های غیر بحرانی نیز می توانند از VPA استفاده کنند.

Goldilocks از Fairwind ابزاری است که یک VPA برای هر استقرار در یک فضای نام ایجاد می کند و سپس یک توصیه VPA را در داشبورد خود نمایش می دهد. این می تواند به توسعه دهندگان کمک کند تا درخواست های CPU/حافظه صحیح را برای برنامه های خود تنظیم کنند:

کوچک نوشتم پست وبلاگ در مورد VPA در سال 2019 و اخیراً در انجمن کاربر نهایی CNCF موضوع VPA را مورد بحث قرار داد.

با استفاده از نمونه های نقطه ای EC2

آخرین اما نه کم اهمیت، هزینه های AWS EC2 را می توان با استفاده از نمونه های Spot به عنوان گره های کارگر Kubernetes کاهش داد. [3]. نمونه های نقطه ای با تخفیف تا 90٪ در مقایسه با قیمت های درخواستی در دسترس هستند. اجرای Kubernetes در EC2 Spot ترکیب خوبی است: شما باید چندین نوع نمونه مختلف را برای دسترسی بیشتر مشخص کنید، به این معنی که می‌توانید گره بزرگ‌تری را با قیمت یکسان یا پایین‌تر دریافت کنید، و ظرفیت افزایش‌یافته می‌تواند توسط بارهای کاری کانتینری‌شده Kubernetes استفاده شود.

چگونه Kubernetes را در EC2 Spot اجرا کنیم؟ چندین گزینه وجود دارد: از یک سرویس شخص ثالث مانند SpotInst استفاده کنید (که اکنون "Spot" نامیده می شود، از من نپرسید چرا) یا به سادگی یک Spot AutoScalingGroup (ASG) را به خوشه خود اضافه کنید. به عنوان مثال، در اینجا یک قطعه CloudFormation برای یک Spot ASG "بهینه سازی ظرفیت" با چندین نوع نمونه آورده شده است:

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 را مدیریت کنید، برای مثال با ادغام گره زمانی که نمونه متوقف می شود
• Zalando استفاده می کند چنگال مقیاس خودکار خوشه رسمی با اولویت های مجموعه گره
• گره های نقطه ای می تواند مجبور شود "ثبت نام" بارهای کاری را برای اجرا در Spot بپذیرید

خلاصه

امیدوارم برخی از ابزارهای ارائه شده در کاهش صورتحساب ابری خود را مفید بیابید. همچنین می توانید بیشتر مطالب مقاله را در اینجا بیابید سخنرانی من در DevOps Gathering 2019 در YouTube و در اسلایدها.

بهترین روش های شما برای صرفه جویی در هزینه های ابری در Kubernetes چیست؟ لطفا به من اطلاع دهید در توییتر (@try_except_).

[1] در واقع، کمتر از 3 vCPU قابل استفاده باقی می‌مانند زیرا توان عملیاتی گره توسط منابع رزرو شده سیستم کاهش می‌یابد. Kubernetes بین ظرفیت گره فیزیکی و منابع "تهیه شده" تمایز قائل می شود (گره قابل تخصیص).

[2] مثال محاسبه: یک نمونه m5.large با 8 گیگابایت حافظه ~ 84 دلار در ماه است (eu-central-1، On-Demand)، یعنی. مسدود کردن گره 1/8 تقریباً 10 دلار در ماه است.

[3] راه‌های زیادی برای کاهش صورت‌حساب EC2 شما وجود دارد، مانند موارد رزرو شده، طرح پس‌انداز، و غیره.

درباره دوره بیشتر بدانید.

منبع: www.habr.com