Преводот на статијата е подготвен во пресрет на почетокот на курсот .
Како да заштедите на трошоците за облак кога работите со Kubernetes? Не постои единствено правилно решение, но овој напис опишува неколку алатки кои можат да ви помогнат поефикасно да управувате со вашите ресурси и да ги намалите трошоците за компјутерски облак.
Ја напишав оваа статија имајќи го предвид Kubernetes за AWS, но ќе се применува (речиси) токму на ист начин за другите даватели на облак. Претпоставувам дека вашиот кластер(и) веќе имаат конфигурирано автоматско скалирање (). Отстранувањето на ресурсите и намалувањето на вашето распоредување ќе ви заштеди пари само ако ја намали и вашата флота од работнички јазли (случаи EC2).
Оваа статија ќе опфати:
- чистење на неискористените ресурси ()
- Намалете го скалирањето за време на неработни часови ()
- користејќи хоризонтално автоматско скалирање (HPA),
- намалување на прекумерната резервација на ресурси (, VPA)
- користејќи Spot инстанци
Чистење на неискористени ресурси
Работата во средина со брзо темпо е одлична. Сакаме технолошки организации . Побрзата испорака на софтвер значи и повеќе распоредувања на односи со јавноста, околини за преглед, прототипови и аналитички решенија. Сè е распоредено на Кубернетес. Кој има време рачно да ги исчисти тест распоредувањата? Лесно е да се заборави за бришење на експеримент стар една недела. Сметката на облакот ќе заврши да расте поради нешто што заборавивме да го затвориме:
(Хенинг Џејкобс:
Жиза:
(цитати) Кори Квин:
Мит: Вашата сметка AWS е функција на бројот на корисници што ги имате.
Факт: Вашиот резултат AWS е во функција на бројот на инженери што ги имате.
Иван Курносов (како одговор):
Вистински факт: Вашиот резултат AWS е функција на бројот на работи што сте заборавиле да ги оневозможите/бришете.)
(kube-janitor) помага да се исчисти вашиот кластер. Конфигурацијата на чуварот е флексибилна и за глобална и за локална употреба:
- Правилата низ целиот кластер може да го дефинираат максималното време за живот (TTL) за распоредувања на ПР/тест.
- Индивидуалните ресурси може да бидат означени со 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/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-а кои не се монтирани од модул и кои не се референцирани од StatefulSet или CronJob:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor може да ви помогне да го одржите вашиот кластер чист и да спречите полека да се натрупуваат трошоците за облак компјутери. За инструкции за распоредување и конфигурација, следете .
Намалете го скалирањето за време на неработни часови
Системите за тестирање и распоредување обично се потребни за работа само за време на работното време. Некои производствени апликации, како што се алатките за back office/admin, исто така бараат само ограничена достапност и може да се оневозможат преку ноќ.
(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.
Но, што ако треба да работам за време на „застој“ на кластерот? Одредени распоредувања може трајно да се исклучат од скалирање со додавање на намалување/исклучување: вистинска прибелешка. Распоредувањата може привремено да се исклучат со помош на намалувачот/исклучување-до прибелешка со апсолутен временски печат во формат ГГГГ-ММ-ДД Ч:ММ (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Види , ако сте заинтересирани за инструкции за распоредување и дополнителни опции.
Користете хоризонтално автоматско скалирање
Многу апликации/услуги се занимаваат со шема на динамично вчитување: понекогаш нивните модули се неактивен, а понекогаш работат со полн капацитет. Ракувањето со постојана флота од мешунки за да се справите со максималното максимално оптоварување не е економично. Kubernetes поддржува хоризонтално автоматско скалирање низ ресурс (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: UtilizationZalando создаде компонента за лесно поврзување на сопствените метрики за скалирање: (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 m на јазол со 4 vCPU ќе остави само 3 vCPU достапни на другите места.
Слаба (вишок резерва) е разликата помеѓу бараните ресурси и вистинската употреба. На пример, pod што бара 2 GiB меморија, но користи само 200 MiB, има ~ 1,8 GiB „вишок“ меморија. Вишокот чини пари. Може грубо да се процени дека 1 GiB вишок меморија чини ~ 10 долари месечно.
(kube-resource-report) ги прикажува вишокот резерви и може да ви помогне да го одредите потенцијалот за заштеда:
го покажува вишокот собран по апликација и команда. Ова ви овозможува да најдете места каде што потребите за ресурси може да се намалат. Генерираниот HTML извештај дава само слика од користењето на ресурсите. Треба да го погледнете користењето на процесорот/меморијата со текот на времето за да одредите соодветни барања за ресурси. Еве Графана табела за „типична“ услуга тешка за процесорот: сите подлоги користат значително помалку од 3-те барани јадра на процесорот:
Намалувањето на барањето на процесорот од 3000m на ~400m ги ослободува ресурсите за други оптоварувања и овозможува кластерот да биде помал.
„Просечното користење на процесорот на примероците на EC2 често лебди во едноцифрениот процентуален опсег“, . Додека за EC2 Промената на некои барања за ресурси на Kubernetes во датотека YAML е лесно и може да донесе огромни заштеди.
Но, дали навистина сакаме луѓето да ги менуваат вредностите во датотеките YAML? Не, машините можат многу подобро! Кубернетис (VPA) го прави токму тоа: ги прилагодува барањата и ограничувањата за ресурси според обемот на работа. Еве еден пример график на барања за процесорот Prometheus (тенка сина линија) приспособена од VPA со текот на времето:
за инфраструктурни компоненти. Некритичните апликации можат да користат и VPA.
од Fairwind е алатка која создава VPA за секое распоредување во именскиот простор и потоа прикажува VPA препорака на неговата контролна табла. Може да им помогне на програмерите да ги постават точните барања за процесорот/меморијата за нивните апликации:
Напишав мало во 2019 година, а неодамна во .
Користење на EC2 Spot примери
Последно, но не и најмалку важно, трошоците за AWS EC2 може да се намалат со користење на Spot инстанци како работнички јазли на Kubernetes . Спотовите се достапни со попуст до 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 завршетоци, на пример со спојување на јазолот кога инстанцата е запрена
- Заландо користи официјално автоматско скалирање на кластери со приоритети на јазли
- Место јазли прифатете „регистрации“ на оптоварувања за работа во Spot
Краток преглед
Се надевам дека некои од презентираните алатки ви се корисни за намалување на вашата сметка за облак. Повеќето од содржините на статијата можете да ги најдете и на .
Кои се вашите најдобри практики за заштеда на трошоците за облак на Kubernetes? Ве молам известете ме на .
Всушност, помалку од 3 vCPU ќе останат употребливи бидејќи пропусната моќ на јазолот се намалува со резервирани системски ресурси. Kubernetes прави разлика помеѓу физички капацитет на јазол и „обезбедени“ ресурси ().
Пример за пресметка: еден m5.голем пример со 8 GiB меморија е ~ 84 $ месечно (eu-central-1, On-Demand), т.е. блокирањето на 1/8 јазол е приближно ~ $10/месец.
Има многу повеќе начини да ја намалите вашата сметка EC2, како што се резервирани примероци, план за штедење итн. - Нема да ги обработувам тие теми овде, но дефинитивно треба да ги разгледате!
Извор: www.habr.com