Wergera gotarê di êvara destpêkirina kursê de hat amadekirin .
Dema ku bi Kubernetes re dixebitin meriv çawa li lêçûnên ewr xilas dike? Çareseriyek rast a yekane tune, lê ev gotar gelek amûran vedibêje ku dikarin ji we re bibin alîkar ku hûn çavkaniyên xwe bi bandortir îdare bikin û lêçûnên xweya hesabkirina ewr kêm bikin.
Min ev gotar bi Kubernetes ji bo AWS di hişê xwe de nivîsand, lê ew ê (hema hema) bi heman rengî ji bo pêşkêşkerên din ên ewr re bicîh bîne. Ez texmîn dikim ku kom(ên) we berê xwedan pîvandina otomatîkî hatine mîheng kirin (). Rakirina çavkaniyan û kêmkirina bicîhkirina we dê tenê drav bide we ger ew fîloya weya girêkên karker jî kêm bike (mînakên EC2).
Ev gotar dê veşêre:
- Paqijkirina çavkaniyên ku nehatine bikaranîn ()
- Di demjimêrên nexebitî de pîvanê kêm bikin ()
- bi karanîna xweseriya horizontî (HPA),
- kêmkirina rezerva çavkaniyê ya zêde (, VPA)
- bikaranîna mînakên Spot
Paqijkirina çavkaniyên nayên bikaranîn
Karkirina di hawîrdorek bilez de pir mezin e. Em rêxistinên teknolojî dixwazin . Radestkirina nermalavê zûtir jî tê vê wateyê ku bêtir bicîhkirina PR, hawîrdorên pêşdîtinê, prototîp, û çareseriyên analîtîk. Her tişt li ser Kubernetes tête bicîh kirin. Wextê kê heye ku bi destan ceribandinên ceribandinê paqij bike? Hêsan e ku meriv ceribandinek hefteyek jêbirin ji bîr bike. Dê fatûreya ewr bi dawî bibe ji ber tiştek ku me ji bîr kiriye ku em girtî bikin:
(Henning Jacobs:
Zhîza:
(gotin) Corey Quinn:
Mît: Hesabê weya AWS fonksiyonek ji hejmara bikarhênerên we ye.
Rastî: Pûana weya AWS fonksiyonek ji hejmara endezyarên we ye.
Ivan Kurnosov (di bersivê de):
Rastiya rastîn: Pûana weya AWS fonksiyonek ji hejmara tiştên ku we ji bîr kir ku neçalak bikin / jêbirin e.)
(kube-janitor) alîkariya paqijkirina koma we dike. Veavakirina janitor hem ji bo karanîna gerdûnî û hem jî ji bo herêmî maqûl e:
- Rêgezên dorfireh ên komê dikarin ji bo PR / bicîhkirina ceribandinê dema herî zêde ya zindî (TTL) diyar bikin.
- Çavkaniyên takekesî dikarin bi janitor/ttl-ê werin şîrove kirin, mînakî ku piştî 7 rojan bixweber spike/prototype jê bibe.
Rêzikên gelemperî di pelê YAML de têne diyar kirin. Riya wê di parametreyê re derbas dibe --rules-file li kube-janitor. Li vir qaîdeyek mînak heye ku meriv pê re hemî cîhên navan jê bibe -pr- bi navê piştî du rojan:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dMînaka jêrîn karanîna nîşana serîlêdanê li ser podên Deployment û StatefulSet ji bo hemî Dabeşkirin/StatefulSetên nû yên di sala 2020-an de bi rê ve dibe, lê di heman demê de destûr dide ku ceribandinên bêyî vê etîketê ji bo hefteyekê bêne kirin:
- 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: 7dJi bo 30 hûrdeman demoyek dem-sînorkirî li ser komek kube-janitor dimeşîne bimeşînin:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mÇavkaniyek din a zêdebûna lêçûnên cildên domdar (AWS EBS) ye. Jêbirina Kubernetes StatefulSet cildên wê yên domdar jê nabin (PVC - PersistentVolumeClaim). Volumên EBS-ê yên nehatine bikar anîn dikarin bi hêsanî di mehê de bi sedan dolar lêçûnên encam bidin. Kubernetes Janitor xwedan taybetmendiyek e ku PVC-yên neyên bikar anîn paqij bike. Mînakî, ev qaîdeyek dê hemî PVC-yên ku ji hêla modulek ve nehatine hilanîn û ku ji hêla StatefulSet an CronJob ve nayên referans rakirin:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor dikare ji we re bibe alîkar ku hûn komika xwe paqij bikin û pêşî li lêçûnên berhevkirina ewr hêdî-hêdî berdin. Ji bo rêwerzên danîn û vesazkirinê, bişopînin .
Di demjimêrên ne-xebitî de pîvanê kêm bikin
Pergalên ceribandin û qonax bi gelemperî hewce ne ku tenê di demjimêrên karsaziyê de bixebitin. Hin serîlêdanên hilberînê, wekî amûrên paşîn/rêveberiyê, di heman demê de tenê hebûna tixûbdar hewce dike û dibe ku di şevekê de bêne asteng kirin.
(kube-downscaler) destûrê dide bikarhêner û operatoran ku di demjimêrên nexebitî de pergalê kêm bikin. Dabeşkirin û StatefulSets dikarin kopiyên sifir bikin. Dibe ku CronJobs were sekinandin. Kubernetes Downscaler ji bo tevhev, yek an çend cîhên navan, an çavkaniyên kesane tête mîheng kirin. Hûn dikarin "dema bêkar" an, berevajî, "dema xebatê" destnîşan bikin. Mînakî, ji bo kêmkirina pîvandinê bi qasî ku gengaz di şev û dawiya hefteyê de:
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-timeLi vir grafiyek ji bo pîvandina girêkên karkerên komê di dawiya hefteyê de heye:
Daxistina ji ~ 13 ber 4 girêkên karker bê guman di fatûreya weya AWS de cûdahiyek berbiçav çêdike.
Lê heke ez hewce bikim ku di dema komê "bêdawî" de bixebitim? Bi lêzêdekirina dakêşker/dervebirin: annotasyona rastîn, hin verastkirin dikarin bi domdarî ji pîvandinê werin derxistin. Bikarhêneran dikarin bi demkî bi karanîna dakêşker/dervebirin-heta annotasyonê ya bi mohra demkî ya mutleq di formata YYYY-MM-DD HH:MM (UTC) de bi demkî werin derxistin. Ger hewce be, bi danîna podek bi şirovekirinê re tevahiya komê dikare paşde were kêm kirin downscaler/force-uptimeMînakî, bi destpêkirina nginx vala:
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=trueBibînin , heke hûn bi rêwerzên bicîhkirinê û vebijarkên din re eleqedar in.
Xweseriya horizontî bikar bînin
Gelek serîlêdan / karûbar bi şêwazek barkirina dînamîkî re mijûl dibin: carinan modulên wan bêkar in, û carinan ew bi tevahî kapasîteya xwe dixebitin. Karkirina fîloya domdar a podan ji bo ku meriv bi bargiraniya herî zêde re mijûl bibe ne aborî ye. Kubernetes li seranserê çavkaniyekê pîvana otomatîkî ya horizontal piştgirî dike (HPA). Bikaranîna CPU bi gelemperî ji bo pîvandinê nîşanek baş e:
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 pêkhateyek afirandiye ku bi hêsanî metrîkên xwerû ji bo pîvandinê ve girêdide: (kube-metrics-adapter) ji bo Kubernetes adapterek metrîka gelemperî ye ku dikare pîvanên xwerû û derveyî ji bo pîvandina otomatîkî ya horizontî berhev bike û xizmet bike. Ew pîvana li ser bingeha metrîkên Prometheus, rêzikên SQS, û mîhengên din piştgirî dike. Mînakî, ji bo ku bicîhkirina xwe li gorî metrîka xwerû ya ku ji hêla serîlêdanê bixwe ve wekî JSON di karanîna /metrîkan de tê destnîşan kirin pîvandin:
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: AverageValueVeavakirina xweseriya horizontî ya bi HPA re divê yek ji wan kiryarên xwerû be ku ji bo karûbarên bêdewlet karûbariyê baştir bike. Spotify bi ezmûn û pêşniyarên xwe yên ji bo HPA re pêşkêşiyek heye: .
Zêdekirina çavkaniyê kêm bikin
Karên Kubernetes hewcedariyên xwe yên CPU / bîranînê bi "daxwazên çavkaniyê" diyar dikin. Çavkaniyên CPU di navokên virtual an bi gelemperî di "millicores" de têne pîvandin, mînakî 500m tê wateya 50% vCPU. Çavkaniyên bîrê bi byte têne pîvandin, û paşgirên hevpar dikarin bêne bikar anîn, wek 500Mi, ku tê wateya 500 megabyte. Daxwaza çavkaniyê li ser girêkên karker kapasîteya "qefilandinê" dike, tê vê wateyê ku podek bi daxwazek CPU ya 1000 m li ser girêkek bi 4 vCPU dê tenê 3 vCPU ji podên din re berdest bihêle.
Slack (rezerva zêde) ferqa di navbera çavkaniyên daxwazkirî û karanîna rastîn de ye. Mînakî, podek ku 2 GiB bîra daxwaz dike lê tenê 200 MiB bikar tîne ~ 1,8 GiB bîranîna "zêde" heye. Zêdeyî mesref dike. Mirov dikare texmîn bike ku 1 GiB bîranîna zêde mehê ~ 10 $ lêçû.
(kube-çavkaniyê-rapor) rezervên zêde nîşan dide û dikare ji we re bibe alîkar ku hûn potansiyela teserûfê diyar bikin:
Zêdebûna ji hêla serîlêdan û fermanê ve hatî berhev kirin nîşan dide. Ev dihêle hûn cîhên ku daxwazên çavkaniyê lê kêm bibin bibînin. Rapora HTML-ê ya hatî çêkirin tenê wêneyek karanîna çavkaniyê peyda dike. Pêdivî ye ku hûn bi demê re li karanîna CPU / bîranînê binêrin da ku daxwazên çavkaniyê yên têr diyar bikin. Li vir nexşeyek Grafana ji bo karûbarek CPU-giran a "tîpîkî" heye: hemî pod ji 3 core CPU-yên daxwazkirî pir kêmtir bikar tînin:
Kêmkirina daxwaza CPU ji 3000m ber ~400m çavkaniyên ji bo karên din azad dike û dihêle ku kom piçûktir bibe.
"Bikaranîna navînî ya CPU ya nimûneyên EC2 bi gelemperî di nav rêza sedî yek-hejmar de dimîne." . Dema ku ji bo EC2 Guhertina hin pirsên çavkaniyê yên Kubernetes di pelek YAML de hêsan e û dikare teserûfa mezin bîne.
Lê gelo em bi rastî dixwazin ku mirov di pelên YAML de nirxan biguhezînin? Na, makîneyên dikarin wê pir çêtir bikin! Kubernetes (VPA) tenê wiya dike: daxwazên çavkaniyê û astengiyan li gorî bargiraniyê adapte dike. Li vir grafiyek nimûne ya daxwazên CPU Prometheus (xêza şîn a zirav) ku ji hêla VPA ve bi demê re hatî adaptekirin heye:
ji bo pêkhateyên binesaziyê. Serlêdanên ne-krîtîk jî dikarin VPA bikar bînin.
ji Fairwind amûrek e ku ji bo her sazkirinê di nav cîhek navekî de VPA-yê diafirîne û dûv re pêşnîyarek VPA-yê li ser tabloya xwe nîşan dide. Ew dikare ji pêşdebiran re bibe alîkar ku ji bo serîlêdanên xwe daxwazên CPU / bîranîna rast destnîşan bikin:
Min piçûkek piçûk nivîsand di sala 2019 de, û vê dawiyê di .
Bikaranîna Mînakên Spot EC2
Dawî lê ne hindik, lêçûnên AWS EC2 dikare bi karanîna mînakên Spot wekî girêkên karkerê Kubernetes were kêm kirin. . Nimûneyên Spot li gorî bihayên Ser-Daxwaziyê bi erzanî heya 90% peyda dibin. Rakirina Kubernetes li ser EC2 Spot berhevokek baş e: hûn hewce ne ku ji bo hebûna bilind çend celeb nimûneyên cihêreng diyar bikin, tê vê wateyê ku hûn dikarin bi heman bihayê an kêmtir girêkek mezintir bistînin, û kapasîteya zêde dikare ji hêla barkêşên kar ên Kubernetes ên konteynirkirî ve were bikar anîn.
Meriv çawa Kubernetes li ser EC2 Spot dimeşîne? Gelek vebijark hene: karûbarek partiya sêyemîn mîna SpotInst bikar bînin (niha jê re "Spot" tê gotin, ji min nepirsin çima), an jî tenê Spot AutoScalingGroup (ASG) li koma xwe zêde bikin. Mînakî, li vir pişkek CloudFormation ji bo Spot ASG-ya "bi kapasîteya xweşbînkirî" ya bi gelek celeb nimûneyan heye:
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"Hin notên li ser karanîna Spot bi Kubernetes re:
- Pêdivî ye ku hûn bidawîhatinên Spot bi rê ve bibin, mînakî gava ku mînak tê sekinandin bi yekkirina girêkê
- Zalando bikar tîne otoscalkirina komê ya fermî bi pêşengên hewza nodê
- Nodên cihê "qeydên" barkêşên xebatê qebûl bikin ku li Spot bimeşînin
Nîqaş
Ez hêvî dikim ku hûn hin amûrên ku di kêmkirina fatûreya weya cloudê de têne pêşkêş kirin kêrhatî bibînin. Hûn dikarin piraniya naveroka gotarê jî li vir bibînin .
Ji bo teserûfkirina lêçûnên ewr li ser Kubernetes pratîkên weyên çêtirîn çi ne? Ji kerema xwe min agahdar bikin li .
Di rastiyê de, kêmtir ji 3 vCPU dê bêne bikar anîn ji ber ku berbi girêkê ji hêla çavkaniyên pergalê ve hatî veqetandin kêm dibe. Kubernetes di navbera kapasîteya nodê ya laşî û çavkaniyên "dabînkirî" de cuda dike ().
Mînaka hesabkirinê: mînakek m5.mezin bi 8 GiB bîra ~ 84$ e mehê (eu-navendî-1, Li ser Daxwazê), yanî. astengkirina 1/8 node bi qasî ~ $10/mehê ye.
Gelek awayên din hene ku hûn fatûreya EC2-ya xwe kêm bikin, wek mînak Nimûneyên Reserved, Plana Teserûfê, hwd.
Source: www.habr.com