🥇 په AWS کې د Kubernetes کلاوډ لګښتونو خوندي کول

د مقالې ژباړه د کورس د پیل په ماښام چمتو شوې وه "د زیربنا پلیټ فارم د Kubernetes پر بنسټ".

د کبرنیټس سره کار کولو پرمهال د بادل لګښتونو څنګه خوندي کول؟ هیڅ یو سم حل شتون نلري، مګر دا مقاله ډیری وسیلې تشریح کوي چې کولی شي ستاسو سره ستاسو سرچینې په اغیزمنه توګه اداره کړي او ستاسو د کلاوډ کمپیوټر لګښتونه کم کړي.

ما دا مقاله د AWS لپاره د Kubernetes سره په ذهن کې لیکلې، مګر دا به (تقریبا) په ورته ډول د نورو بادل چمتو کونکو لپاره پلي شي. زه ګومان کوم چې ستاسو کلسترونه لا دمخه د اتوماتیک کولو تنظیم شوي (کلستر-آټوسکلر). د سرچینو لرې کول او ستاسو د ګمارنې اندازه کول به یوازې ستاسو پیسې خوندي کړي که دا ستاسو د کارګر نوډونو بیړۍ هم کموي (EC2 مثالونه).

دا مقاله به پوښي:

د غیر استعمال شوي سرچینو پاکول (kube - janitor)
د غیر کاري ساعتونو په جریان کې اندازه کول کم کړئ (kube-downscaler)
د افقی اتوماتیک کولو (HPA) کارول،
د زیاتو سرچینو ذخیره کمول (kube-resource-report, VPA)
د Spot مثالونو کارول

د غیر استعمال شوي سرچینو پاکول

په ګړندۍ چاپیریال کې کار کول خورا ښه دي. موږ تخنیکي سازمانونه غواړو ګړندی شوی. د ګړندي سافټویر تحویل د PR ډیر ګمارنې ، د لید چاپیریال ، پروټوټایپونو ، او تحلیلي حلونو معنی هم لري. هرڅه په کبرنیټس کې ځای په ځای شوي. څوک وخت لري چې په لاسي ډول د ازموینې ګمارنې پاکې کړي؟ دا اسانه ده چې د یوې اونۍ زاړه تجربې حذف کولو په اړه هیر کړئ. د بادل بل به د هغه څه له امله لوړ شي چې موږ یې بندول هیر کړل:

(هینینګ جیکبز:
ژیزا:
کوری کوین:
افسانه: ستاسو د AWS حساب د هغو کاروونکو شمیر دی چې تاسو یې لرئ.
حقیقت: ستاسو د AWS نمرې د انجینرانو شمیره ده چې تاسو یې لرئ.

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

Kubernetes Janitor (کیوب-جانیټر) ستاسو د کلستر پاکولو کې مرسته کوي. د جنیټر ترتیب د نړیوال او محلي کارونې لپاره انعطاف وړ دی:

د کلستر په کچه مقررات کولی شي د ژوند کولو اعظمي وخت (TTL) د PR/ټیسټ ګمارلو لپاره تعریف کړي.
انفرادي سرچینې د janitor/ttl سره تشریح کیدی شي، د بیلګې په توګه د 7 ورځو وروسته په اتوماتيک ډول سپیک / پروټوټایپ لرې کول.

عمومي قواعد د YAML فایل کې تعریف شوي. د هغې لاره د پیرامیټر له لارې تیریږي --rules-file په kube-janitor کې. دلته د ټولو نوم ځایونو لرې کولو لپاره د مثال قانون دی -pr- په نوم دوه ورځې وروسته:

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

لاندې مثال په 2020 کې د ټولو نوي ګمارلو/StatefulSets لپاره د پلي کولو او StatefulSet پوډونو کې د غوښتنلیک لیبل کارول تنظیموي ، مګر په ورته وخت کې د یوې اونۍ لپاره د دې لیبل پرته ازموینې اجرا کولو ته اجازه ورکوي:

- 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 دقیقو لپاره د وخت محدود ډیمو چلول په کلستر کې د کیوب - جانیټر چلول:

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

د لګښتونو د زیاتوالي بله سرچینه دوامداره حجم (AWS EBS) دي. د Kubernetes StatefulSet حذف کول د هغې دوامداره حجمونه (PVC - PersistentVolumeClaim) نه حذف کوي. د EBS نه کارول شوي حجمونه په اسانۍ سره په میاشت کې د سلګونو ډالرو لګښتونو پایله کولی شي. Kubernetes Janitor د غیر استعمال شوي PVCs پاکولو لپاره یو ځانګړتیا لري. د مثال په توګه، دا قاعده به ټول PVCs لرې کړي چې د ماډل لخوا ندي نصب شوي او د StatefulSet یا CronJob لخوا حواله شوي ندي:

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

د کبرنیټس جنیټر کولی شي تاسو سره ستاسو د کلستر پاک ساتلو کې مرسته وکړي او د کلاوډ کمپیوټري لګښتونو ورو ورو راټولیدو مخه ونیسي. د ګمارنې او ترتیب کولو لارښوونو لپاره، تعقیب کړئ README kube- janitor.

د غیر کاري ساعتونو په جریان کې اندازه کول کم کړئ

د ازموینې او سټینګ سیسټمونه عموما یوازې د سوداګرۍ ساعتونو په جریان کې د عملیاتو لپاره اړین دي. د تولید ځینې غوښتنلیکونه، لکه د بیک دفتر/اډمین وسیلې هم یوازې محدود شتون ته اړتیا لري او ممکن په شپه کې غیر فعال شي.

Kubernetes Downscaler (kube-downscaler) کاروونکو او چلونکو ته اجازه ورکوي چې د غیر کاري ساعتونو په جریان کې سیسټم اندازه کړي. ګمارنې او سټیټفول سیټونه کولی شي صفر نقلونو ته اندازه کړي. 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 بل کې د پام وړ توپیر رامینځته کوي.

مګر څه که زه اړتیا لرم د کلستر "ډاونټایم" په جریان کې کار وکړم؟ ځینې ګومارنې کولی شي په دایمي توګه د ښکته کولو / ایستلو په اضافه کولو سره له اندازه کولو څخه ایستل شي: ریښتیني تشریح. ګمارنې په لنډمهاله توګه د Downscaler/exclude-Tille په کارولو سره د مطلق مهال ویش سره د 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). د 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-adapter) د Kubernetes لپاره یو عمومي میټریک اډاپټر دی چې کولی شي د پوډونو افقی اتوماتیک کولو لپاره دودیز او بهرني میټریکونه راټول او خدمت وکړي. دا د Prometheus میټریکونو، SQS کتارونو، او نورو ترتیباتو پر بنسټ د اندازه کولو ملاتړ کوي. د مثال په توګه، د ګمرک میټریک ته ستاسو ګمارنه اندازه کول د غوښتنلیک لخوا پخپله د JSON په توګه په / میټریک کارولو کې ښودل شوي:

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 سرچینې په مجازی کور کې اندازه کیږي یا په عام ډول په "میلیکور" کې اندازه کیږي، د بیلګې په توګه 500m د 50٪ vCPU معنی لري. د حافظې سرچینې په بایټ کې اندازه کیږي، او عام ضمیمې کارول کیدی شي، لکه 500Mi، چې معنی یې 500 میګابایټ دی. سرچینې د کارګر نوډونو کې د "لاک" ظرفیت غوښتنه کوي ، پدې معنی چې د 1000 vCPUs سره په نوډ کې د 4m CPU غوښتنې سره پوډ به یوازې 3 vCPUs نورو پوډونو ته شتون پریږدي. [1]

سست (ډیری زیرمه) د غوښتل شوي سرچینو او حقیقي کارونې ترمنځ توپیر دی. د مثال په توګه، یو پوډ چې د 2 GiB حافظې غوښتنه کوي مګر یوازې 200 MiB کاروي د ~ 1,8 GiB "اضافي" حافظه لري. اضافي پیسې مصرفوي. یو څوک تقریبا اټکل کولی شي چې د 1 GiB بې ځایه حافظه په میاشت کې ~ $ 10 لګښت لري. [2]

د Kubernetes سرچینې راپور (kube-resource-report) اضافي زیرمې ښیي او کولی شي تاسو سره د سپما احتمال په ټاکلو کې مرسته وکړي:

د Kubernetes سرچینې راپور د غوښتنلیک او کمانډ لخوا راټول شوي اضافي ښیي. دا تاسو ته اجازه درکوي هغه ځایونه ومومئ چیرې چې د سرچینو غوښتنې کم کیدی شي. رامینځته شوی HTML راپور یوازې د سرچینو کارولو سنیپ شاټ چمتو کوي. تاسو باید د وخت په تیریدو سره د CPU/میموري کارول وګورئ ترڅو د منابعو کافي غوښتنې وټاکئ. دلته د "عمومي" CPU - دروند خدمت لپاره د ګرافانا چارټ دی: ټول پوډونه د 3 غوښتل شوي CPU کور څخه د پام وړ کم کاروي:

د CPU غوښتنې له 3000m څخه ~ 400m ته کمول د نورو کاري بارونو لپاره سرچینې خلاصوي او کلستر ته اجازه ورکوي چې کوچني شي.

"د EC2 مثالونو اوسط CPU کارول اکثرا د واحد عدد سلنې حد کې ځړول کیږي" کوري کوین لیکي. پداسې حال کې چې د EC2 لپاره د سمې اندازې اټکل کول ممکن بد پریکړه ويپه YAML فایل کې د ځینې Kubernetes سرچینو پوښتنو بدلول اسانه دي او کولی شي لوی سپما راوړي.

مګر ایا موږ واقعیا غواړو خلک د YAML فایلونو کې ارزښتونه بدل کړي؟ نه، ماشینونه دا ډیر ښه کولی شي! Kubernetes عمودی پوډ آټوسکلر (VPA) یوازې دا کوي: د کار بار سره سم د سرچینو غوښتنې او محدودیتونه تطبیقوي. دلته د Prometheus CPU غوښتنو (پتلی نیلي لاین) ګراف د وخت په تیریدو سره د VPA لخوا تطبیق شوی مثال دی:

Zalando په خپلو ټولو کلسترونو کې VPA کاروي د زیربناوو برخو لپاره. غیر مهم غوښتنلیکونه هم کولی شي VPA وکاروي.

ګولډلوکس له Fairwind څخه یوه وسیله ده چې په نوم ځای کې د هرې ګمارنې لپاره VPA رامینځته کوي او بیا په خپل ډشبورډ کې د VPA وړاندیز ښیې. دا کولی شي د پراختیا کونکو سره مرسته وکړي چې د دوی غوښتنلیکونو لپاره سم CPU/میموري غوښتنې تنظیم کړي:

ما یو کوچنی لیکلی د VPA په اړه بلاګ پوسټ په 2019 کې، او په دې وروستیو کې د CNCF پای کارونکي ټولنې د VPA مسلې په اړه بحث وکړ.

د EC2 سپاټ مثالونو کارول

وروستی مګر لږترلږه، د AWS EC2 لګښتونه د سپټ مثالونو په کارولو سره د Kubernetes کارګر نوډونو په توګه کم کیدی شي [3]. د ځای مثالونه د تقاضا د نرخونو په پرتله تر 90٪ تخفیف کې شتون لري. په EC2 ځای کې د کوبرنیټس چلول یو ښه ترکیب دی: تاسو اړتیا لرئ د لوړ شتون لپاره ډیری مختلف مثالونه مشخص کړئ ، پدې معنی چې تاسو کولی شئ د ورته یا ټیټ نرخ لپاره لوی نوډ ترلاسه کړئ ، او لوړ ظرفیت د کانټینر شوي کبرنیټس کاري بارونو لخوا کارول کیدی شي.

په EC2 ځای کې Kubernetes څنګه چلولی شئ؟ ډیری اختیارونه شتون لري: د دریمې ډلې خدمت وکاروئ لکه SpotInst (اوس د "Spot" په نوم یادیږي، له ما څخه پوښتنه مه کوئ چې ولې)، یا په ساده ډول خپل کلستر ته د Spot AutoScalingGroup (ASG) اضافه کړئ. د مثال په توګه، دلته د ډیری مثالونو ډولونو سره د "ظرفیت - مطلوب" ځای 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"

د Kubernetes سره د سپاټ کارولو په اړه ځینې یادښتونه:

تاسو اړتیا لرئ د Spot پای ته رسیدو اداره کړئ، د بیلګې په توګه د نوډ یوځای کولو سره کله چې مثال ودرول شي
Zalando کاروي فورک د نوډ پول لومړیتوبونو سره رسمي کلستر اتوماتیک کول
د ځای نوډونه مجبور کیدی شي په Spot کې د چلولو لپاره د کاري بارونو "رجسټریشن" قبول کړئ

لنډیز

زه امید لرم چې تاسو ځینې وسیلې ومومئ چې ستاسو د بادل بیل کمولو کې ګټور وي. تاسو کولی شئ د مقالې ډیری مینځپانګې هم دلته ومومئ زما خبرې په یوټیوب او سلایډونو کې د DevOps غونډې 2019 کې.

په Kubernetes کې د بادل لګښتونو خوندي کولو لپاره ستاسو غوره تمرینونه کوم دي؟ مهرباني وکړئ ما ته خبر راکړئ ټویټر (@try_except_).

[1] په حقیقت کې، د 3 vCPUs څخه کم به د کارونې وړ پاتې شي ځکه چې د نوډ د وسیلو له لارې د خوندي سیسټم سرچینو کم شوی. Kubernetes د فزیکي نوډ ظرفیت او "وړاندیز شوي" سرچینو ترمنځ توپیر کوي (د تخصیص وړ نوډ).

[2] د محاسبې بېلګه: د 5 GiB حافظې سره یو m8.large مثال په میاشت کې ~ $84 دی (eu-central-1, On-demand)، یعنی د 1/8 نوډ بندول نږدې ~ $10 / میاشت دي.

[3] ستاسو د EC2 بیل کمولو لپاره ډیری نورې لارې شتون لري، لکه خوندي شوي مثالونه، د سپما پلان، او نور. - زه به دلته هغه موضوعات نه پوښم، مګر تاسو باید ضرور وګورئ!

د کورس په اړه نور معلومات ترلاسه کړئ.

سرچینه: www.habr.com

په AWS کې د Kubernetes کلاوډ لګښتونه خوندي کړئ