Девет совети за изведба на Kubernetes

Здраво на сите! Јас се викам Олег Сидоренков, работам во DomClick како шеф на инфраструктурниот тим. Кубик го користиме во производство повеќе од три години и за ова време доживеавме многу различни интересни моменти со него. Денес ќе ви кажам како, со правилен пристап, можете да исцедите уште повеќе перформанси од Kubernetes од ванила за вашиот кластер. Подготвени стабилно одете!

Сите добро знаете дека Kubernetes е скалабилен систем со отворен код за оркестрација на контејнери; добро, или 5 бинарни датотеки кои работат магично со управување со животниот циклус на вашите микроуслуги во опкружување на серверот. Покрај тоа, тоа е прилично флексибилна алатка која може да се состави како Lego за максимална приспособување за различни задачи.

И се чини дека сè е во ред: фрлете ги серверите во кластерот како огревно дрво во ложиште, и нема да знаете никаква тага. Но, ако сте за животната средина, ќе помислите: „Како да го одржам огнот запален и да ја поштедам шумата? Со други зборови, како да се најдат начини за подобрување на инфраструктурата и намалување на трошоците.

1. Следете ги ресурсите на тимот и апликациите

Еден од највообичаените, но ефективни методи е воведувањето на барања/лимити. Поделете ги апликациите по именски простори и именските простори по тимовите за развој. Пред распоредувањето, поставете ги вредностите на апликацијата за потрошувачка на време на процесорот, меморија и минливо складирање.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

Преку искуство, дојдовме до заклучок: не треба да ги надувате барањата од лимитите повеќе од двапати. Волуменот на кластерот се пресметува врз основа на барањата, и ако на апликациите им давате разлика во ресурсите, на пример, 5-10 пати, тогаш замислете што ќе се случи со вашиот јазол кога ќе се наполни со подлоги и одеднаш добива оптоварување. Ништо добро. На минимум, пригушување и максимум, ќе се збогувате со работникот и ќе добиете циклично оптоварување на преостанатите јазли откако мешунките ќе почнат да се движат.

Покрај тоа, со помош limitranges На почетокот, можете да поставите вредности на ресурси за контејнерот - минимум, максимум и стандардно:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

Не заборавајте да ги ограничите ресурсите на именскиот простор, така што еден тим не може да ги преземе сите ресурси на кластерот:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

Како што може да се види од описот resourcequotas, ако опс тимот сака да распореди подлоги што ќе трошат уште 10 процесорски процесори, распоредувачот нема да го дозволи тоа и ќе направи грешка:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

За да решите таков проблем, можете да напишете алатка, на пример, како овој, способни да складираат и да ја обврзат состојбата на командните ресурси.

2. Изберете оптимално складирање на датотеки

Овде би сакал да ја допрам темата за постојани волумени и потсистемот на дискот на работничките јазли на Kubernetes. Се надевам дека никој не ја користи „Коцката“ на HDD во производството, но понекогаш обичниот SSD веќе не е доволен. Наидовме на проблем кога дневниците го убиваа дискот поради операциите на В/И и нема многу решенија:

• Користете SSD-дискови со високи перформанси или префрлете се на NVMe (ако управувате со свој хардвер).

• Намалете го нивото на сеча.

• Направете „паметно“ балансирање на мешунките што го силуваат дискот (podAntiAffinity).

На екранот погоре се гледа што се случува под nginx-ingress-controller на дискот кога е овозможено евидентирање на access_logs (~ 12 илјади дневници/сек). Оваа состојба, се разбира, може да доведе до деградација на сите апликации на овој јазол.

Што се однесува до PV, за жал, не сум пробал се видови Постојани волумени. Користете ја најдобрата опција што ви одговара. Историски, кај нас се случувало мал дел од услугите да бараат RWX тома, а одамна почнале да користат NFS складирање за оваа задача. Ефтино и... доволно. Се разбира, тој и јас јадевме гомна - благослови си, но научивме да го средиме, а главата повеќе не ме боли. И ако е можно, преместете се во складирање на објекти S3.

3. Соберете оптимизирани слики

Најдобро е да користите слики оптимизирани за контејнери за да може Kubernetes да ги преземе побрзо и да ги изврши поефикасно. 

Оптимизирано значи дека сликите:

• содржи само една апликација или извршува само една функција;

• мали по големина, бидејќи големите слики се пренесуваат полошо преку мрежата;

• имаат крајни точки за здравје и подготвеност што му овозможуваат на Кубернетис да преземе акција во случај на прекин;

• користете оперативни системи погодни за контејнери (како Alpine или CoreOS), кои се поотпорни на конфигурациски грешки;

• користете повеќестепени градби за да можете да распоредите само компајлирани апликации, а не придружните извори.

Постојат многу алатки и услуги кои ви дозволуваат да ги проверувате и оптимизирате сликите во лет. Важно е секогаш да ги одржувате ажурирани и тестирани за безбедност. Како резултат добивате:

1. Намалено оптоварување на мрежата на целиот кластер.

2. Намалување на времето за стартување на контејнерот.

3. Помала големина на целиот ваш Docker регистар.

4. Користете DNS кеш

Ако зборуваме за големи оптоварувања, тогаш животот е прилично лош без подесување на DNS системот на кластерот. Некогаш, развивачите на Kubernetes го поддржаа нивното решение kube-dns. И тука беше имплементиран, но овој софтвер не беше особено подесен и не ги произведе потребните перформанси, иако се чинеше дека е едноставна задача. Потоа се појавија coredns, на кои се префрливме и немавме тага; подоцна стана стандардна DNS услуга во K8s. Во одреден момент, пораснавме до 40 илјади вртежи во секунда до системот DNS, а ова решение исто така стана недоволно. Но, за среќа, излезе Nodelocaldns, ака јазол локален кеш, ака NodeLocal DNSCache.

Зошто го користиме ова? Постои грешка во кернелот на Linux што, кога повеќекратни повици преку conntrack NAT преку UDP, доведува до состојба на трка за записи во табелите за conntrack, а дел од сообраќајот преку NAT се губи (секое патување низ услугата е NAT). Nodelocaldns го решава овој проблем со ослободување од NAT и надградба на врската со TCP до спротиводно DNS, како и локално кеширање нагоре DNS прашања (вклучувајќи краток негативен кеш од 5 секунди).

5. Ставете ги мешунките хоризонтално и вертикално автоматски

Можете ли со сигурност да кажете дека сите ваши микросервиси се подготвени за два до трикратно зголемување на оптоварувањето? Како правилно да ги распределите ресурсите на вашите апликации? Одржувањето на неколку подлоги да работат надвор од обемот на работа може да биде излишно, но ако ги чувате еден до друг, постои ризик од застој од ненадејно зголемување на сообраќајот до услугата. Услуги како што се Хоризонтален Pod Autoscaler и Вертикален Pod Autoscaler.

ВПА ви овозможува автоматски да ги подигате барањата/ограничувањата на вашите контејнери во подлогата во зависност од вистинската употреба. Како може да биде корисно? Ако имате мешунки кои поради некоја причина не можат да се намалат хоризонтално (што не е целосно доверливо), тогаш можете да се обидете да ги доверите промените во неговите ресурси на VPA. Неговата карактеристика е систем за препораки базиран на историски и тековни податоци од метричкиот сервер, па ако не сакате автоматски да ги менувате барањата/ограничувањата, можете едноставно да ги следите препорачаните ресурси за вашите контејнери и да ги оптимизирате поставките за зачувување на процесорот и меморија во кластерот.

Сликата е преземена од https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Распоредувачот во Kubernetes секогаш се заснова на барања. Без оглед на вредноста што ќе ја ставите таму, распоредувачот ќе бара соодветен јазол врз основа на него. Граничните вредности се потребни за кубелетот да разбере кога да го пригушува или убие мешунот. И бидејќи единствениот важен параметар е вредноста на барањата, VPA ќе работи со него. Секогаш кога ќе ја размерите апликацијата вертикално, вие дефинирате кои треба да бидат барањата. Што ќе се случи со границите тогаш? Овој параметар исто така ќе се скалира пропорционално.

На пример, тука се вообичаените поставки за pod:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

Моторот за препораки одредува дека вашата апликација бара 300m CPU и 500Mi за да работи правилно. Ќе ги добиете следните поставки:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

Како што споменавме погоре, ова е пропорционално скалирање врз основа на односот барања/ограничувања во манифестот:

• Процесор: 200m → 300m: сооднос 1:1.75;

• Меморија: 250Mi → 500Mi: сооднос 1:2.

Што се однесува до ХХН, тогаш механизмот на работа е потранспарентен. Метриките како што се процесорот и меморијата се ограничени, и ако просекот на сите реплики го надмине прагот, апликацијата се скалира со +1 под додека вредноста не падне под прагот или додека не се достигне максималниот број на реплики.

Сликата е преземена од https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Покрај вообичаените метрики како процесорот и меморијата, можете да поставите прагови на вашите сопствени метрики од Prometheus и да работите со нив ако мислите дека тоа е најточниот показател за тоа кога да ја зголемите вашата апликација. Штом апликацијата ќе се стабилизира под наведениот метрички праг, HPA ќе почне да ги намалува парчињата до минималниот број на реплики или додека оптоварувањето не го достигне наведениот праг.

6. Не заборавајте за Node Affinity и Pod Affinity

Не сите јазли работат на ист хардвер, а не сите подлоги треба да работат со компјутерски интензивни апликации. Kubernetes ви овозможува да ја поставите специјализацијата на јазлите и мешунките користејќи Афинитет на јазли и Афинитет на Pod.

Ако имате јазли кои се погодни за операции со интензивна пресметка, тогаш за максимална ефикасност подобро е да ги врзувате апликациите со соодветните јазли. За да го направите ова користете nodeSelector со ознака на јазол.

Да речеме дека имате два јазли: еден со CPUType=HIGHFREQ и голем број брзи јадра, друго со MemoryType=HIGHMEMORY повеќе меморија и побрзи перформанси. Најлесен начин е да се додели распоредување на јазол HIGHFREQсо додавање во делот spec овој селектор:

…
nodeSelector:
	CPUType: HIGHFREQ

Поскап и специфичен начин да го направите ова е да го користите nodeAffinity на терен affinity дел spec. Постојат две опции:

• requiredDuringSchedulingIgnoredDuringExecution: тешко поставување (распоредувачот ќе распореди подлоги само на одредени јазли (и никаде на друго место));

• preferredDuringSchedulingIgnoredDuringExecution: мека поставка (распоредувачот ќе се обиде да се распореди на одредени јазли, а ако тоа не успее, ќе се обиде да се распореди на следниот достапен јазол).

Можете да наведете специфична синтакса за управување со етикети на јазли, како на пр In, NotIn, Exists, DoesNotExist, Gt или Lt. Сепак, запомнете дека сложените методи во долгите списоци на етикети ќе го забават донесувањето одлуки во критични ситуации. Со други зборови, нека биде едноставно.

Како што споменавме погоре, Kubernetes ви овозможува да го поставите афинитетот на тековните мешунки. Односно, можете да направите одредени мешунки да работат заедно со други подлоги во истата зона на достапност (релевантна за облаците) или јазли.

В podAffinity маргини affinity дел spec достапни се истите полиња како во случајот со nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Единствената разлика е во тоа matchExpressions ќе ги поврзе мешунките за јазол кој веќе работи на подлога со таа ознака.

Кубернетес нуди и поле podAntiAffinity, што, напротив, не го врзува мешунот за јазол со специфични мешунки.

За изразите nodeAffinity Може да се даде истиот совет: обидете се да ги одржувате правилата едноставни и логични, не обидувајте се да ја преоптоварувате спецификацијата на подлогата со сложен сет на правила. Многу е лесно да се создаде правило кое нема да одговара на условите на кластерот, создавајќи непотребно оптоварување на распоредувачот и намалувајќи ги вкупните перформанси.

7. Дамки и толеранции

Постои уште еден начин за управување со распоредувачот. Ако имате голем кластер со стотици јазли и илјадници микросервиси, тогаш е многу тешко да не дозволите одредени подови да бидат хостирани на одредени јазли.

Механизмот на дамки - правила за забрана - помага во ова. На пример, во одредени сценарија можете да забраните одредени јазли да работат на подлоги. За да примените дамка на одреден јазол, треба да ја користите опцијата taint во кубектл. Наведете го клучот и вредноста и потоа обојте како NoSchedule или NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

Исто така, вреди да се напомене дека механизмот за дамка поддржува три главни ефекти: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule значи дека засега нема да има соодветен запис во спецификацијата на pod tolerations, нема да може да се распореди на јазолот (во овој пример node10).

• PreferNoSchedule - поедноставена верзија NoSchedule. Во овој случај, распоредувачот ќе се обиде да не додели мешунки кои немаат соодветен запис tolerations по јазол, но ова не е тешко ограничување. Ако нема ресурси во кластерот, тогаш мешунките ќе почнат да се распоредуваат на овој јазол.

• NoExecute - овој ефект предизвикува итна евакуација на мешунките кои немаат соодветен влез tolerations.

Интересно е што ова однесување може да се откаже со помош на механизмот за толеранција. Ова е погодно кога има „забранет“ јазол и треба само да поставите инфраструктурни услуги на него. Како да се направи тоа? Дозволете ги само оние мешунки за кои постои соодветна толеранција.

Еве како би изгледала спецификацијата на pod:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

Ова не значи дека следното прераспоредување ќе падне на овој конкретен јазол, ова не е механизмот Node Affinity и nodeSelector. Но, со комбинирање на неколку функции, можете да постигнете многу флексибилни поставки за распоредувачот.

8. Поставете приоритет за распоредување под

Само затоа што имате подлоги доделени на јазли не значи дека сите подлоги мора да се третираат со ист приоритет. На пример, можеби ќе сакате да распоредите некои подлоги пред други.

Kubernetes нуди различни начини за конфигурирање на Pod Priority и Preemption. Поставката се состои од неколку делови: објект PriorityClass и описи на терени priorityClassName во спецификацијата на под. Ајде да погледнеме на пример:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

Ние создаваме PriorityClass, дајте му име, опис и вредност. Повисокото value, толку е поголем приоритетот. Вредноста може да биде кој било 32-битен цел број помал или еднаков на 1. Повисоките вредности се резервирани за системски подлоги кои се критични за мисијата, кои генерално не можат да се превенираат. Поместувањето ќе се случи само ако мешунката со висок приоритет нема каде да се сврти, тогаш некои од мешунките од одреден јазол ќе бидат евакуирани. Ако овој механизам е премногу крут за вас, можете да ја додадете опцијата preemptionPolicy: Never, а потоа нема да има превенција, подлогата ќе стои прво во редот и ќе чека распоредувачот да најде бесплатни ресурси за него.

Следно, создаваме подлога во која го означуваме името priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

Можете да креирате онолку приоритетни класи колку што сакате, иако се препорачува да не се занесувате со ова (да речеме, ограничете се на низок, среден и висок приоритет).

Така, доколку е потребно, можете да ја зголемите ефикасноста на распоредувањето на критичните услуги како што се nginx-ingress-controller, coredns итн.

9. Оптимизирајте го ETCD кластерот

ETCD може да се нарече мозок на целиот кластер. Многу е важно да се одржи работата на оваа база на податоци на високо ниво, бидејќи брзината на операциите во Cube зависи од тоа. Прилично стандардно, а во исто време, добро решение би било да се задржи ETCD кластерот на главните јазли со цел да има минимално доцнење до kube-apiserver. Ако не можете да го направите ова, тогаш поставете го ETCD што е можно поблиску, со добар пропусен опсег помеѓу учесниците. Исто така, обрнете внимание на тоа колку јазли од ETCD може да испаднат без да му наштетат на кластерот

Имајте на ум дека прекумерното зголемување на бројот на членови во кластерот може да ја зголеми толеранцијата на грешки на сметка на перформансите, сè треба да биде умерено.

Ако зборуваме за поставување на услугата, има неколку препораки:

1. Имајте добар хардвер, врз основа на големината на кластерот (можете да прочитате тука).

2. Прилагодете неколку параметри ако сте рашириле кластер помеѓу пар DC или вашата мрежа и дискови оставаат многу да се посакуваат (можете да прочитате тука).

Заклучок

Оваа статија ги опишува точките со кои нашиот тим се обидува да се усогласи. Ова не е чекор-по-чекор опис на дејствата, туку опции кои можат да бидат корисни за оптимизирање на горните трошоци на кластерот. Јасно е дека секој кластер е уникатен на свој начин, а решенијата за конфигурација може многу да се разликуваат, па би било интересно да се добијат вашите повратни информации за тоа како го следите вашиот кластер Kubernetes и како ги подобрувате неговите перформанси. Споделете го вашето искуство во коментарите, ќе биде интересно да се знае.

Извор: www.habr.com