🥇Девет съвета за подобряване на производителността на Kubernetes

Здравейте всички! Казвам се Олег Сидоренков, работя в DomClick като ръководител на инфраструктурен екип. Използваме Cube за продажба повече от три години и през това време сме преживели много различни интересни моменти с него. Днес ще ви кажа как, с правилния подход, можете да изстискате още повече производителност от ванилия 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, ако командата ops иска да разположи pods, които ще консумират още 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. Надявам се, че никой не използва "Cube" на HDD в производството, но понякога дори обикновен SSD вече не е достатъчен. Сблъскахме се с такъв проблем, че регистрационните файлове убиваха диска чрез I / O операции и тук няма много решения:

Използвайте високопроизводителни SSD или преминете към NVMe (ако управлявате собствения си хардуер).
Намалете нивото на регистриране.
Направете "интелигентно" балансиране на шушулки, които изнасилват диска (podAntiAffinity).

Екранната снимка по-горе показва какво се случва под nginx-ingress-controller с диск, когато access_logs е активиран (~12k logs/sec). Такова състояние, разбира се, може да доведе до влошаване на всички приложения на този възел.

Колкото до PV, уви, не съм пробвал всичко. видове Постоянни обеми. Използвайте най-добрия вариант, който ви подхожда. Исторически се е случило в нашата страна, че малка част от услугите се нуждаят от RWX томове и преди много време те започнаха да използват NFS съхранение за тази задача. Евтино и ... достатъчно. Разбира се, ядохме лайна с него - бъдете здрави, но се научихме как да го настройваме и главата вече не го боли. И ако е възможно, преминете към съхранение на обекти S3.

3. Създайте оптимизирани изображения

Най-добре е да използвате изображения, оптимизирани за контейнери, така че Kubernetes да може да ги извлича по-бързо и да ги изпълнява по-ефективно.

Оптимизацията означава, че изображенията:

съдържат само едно приложение или изпълняват само една функция;
малък размер, тъй като големите изображения се предават по-лошо по мрежата;
имат крайни точки за здраве и готовност, които Kubernetes може да използва, за да предприеме действия в случай на прекъсване;
използвайте удобни за контейнери операционни системи (като Alpine или CoreOS), които са по-устойчиви на грешки в конфигурацията;
използвайте многоетапни компилации, така че да можете да разгръщате само компилирани приложения, а не придружаващите източници.

Има много инструменти и услуги, които ви позволяват да проверявате и оптимизирате изображения в движение. Важно е винаги да ги поддържате актуални и в безопасност. В резултат на това получавате:

Намалено мрежово натоварване на целия клъстер.
Намалено време за стартиране на контейнера.
По-малък размер на целия ви регистър на Docker.

4. Използвайте DNS кеш

Ако говорим за високи натоварвания, тогава без настройка на DNS системата на клъстера, животът е доста отвратителен. Имало едно време разработчиците на Kubernetes поддържаха своето kube-dns решение. Той също беше внедрен в нашата страна, но този софтуер не се настрои особено и не даде необходимата производителност, въпреки че изглежда задачата е проста. Тогава се появиха coredns, към които превключихме и не знаехме скръбта, по-късно стана DNS услугата по подразбиране в K8s. В един момент нараснахме до 40 хиляди rps към DNS системата и това решение също не беше достатъчно. Но по щастлива случайност се появи Nodelocaldns, известен още като локален кеш на възел, известен още като NodeLocal DNSCache.

Защо го използваме? Има грешка в ядрото на Linux, която при множество достъпи през conntrack NAT през UDP води до състояние на състезание за запис в conntrack таблиците и част от трафика през NAT се губи (всяко пътуване през услугата е NAT). Nodelocaldns решава този проблем, като се отървава от NAT и надстройва до TCP свързаност към DNS нагоре по веригата, както и локално кешира DNS заявки нагоре по веригата (включително кратък 5 секунден отрицателен кеш).

5. Мащабирайте капсулите хоризонтално и вертикално автоматично

Можете ли да кажете с увереност, че всичките ви микроуслуги са готови за дву- до трикратно увеличение на натоварването? Как правилно да разпределяте ресурси за вашите приложения? Поддържането на няколко подове, работещи над натоварването, може да бъде излишно, а поддържането им един до друг рискува прекъсване от внезапно увеличаване на трафика към услугата. Златната среда помага да се постигне заклинание за умножение такива услуги като Horizontal Pod Autoscaler и Автоматичен скалер за вертикален под.

СДП ви позволява автоматично да повишавате заявките/лимитите на вашите контейнери в под въз основа на действителното използване. С какво може да бъде полезно? Ако имате Pods, които по някаква причина не могат да бъдат мащабирани хоризонтално (което не е напълно надеждно), тогава можете да опитате да се доверите на VPA, за да промени ресурсите си. Неговата функция е система за препоръки, базирана на исторически и текущи данни от metric-server, така че ако не искате да променяте автоматично заявките/лимитите, можете просто да наблюдавате препоръчаните ресурси за вашите контейнери и да оптимизирате настройките, за да спестите CPU и памет в клъстера.

Изображението е взето от https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Планировчикът в Kubernetes винаги се основава на заявки. Каквато и стойност да поставите там, планировчикът ще търси подходящ възел въз основа на нея. Граничната стойност е необходима на kublet, за да знае кога да намали или убие капсула. И тъй като единственият важен параметър е стойността на заявките, VPA ще работи с него. Всеки път, когато мащабирате приложението си вертикално, вие определяте какви да бъдат заявките. И какво ще стане с лимитите тогава? Този параметър също ще бъде пропорционално мащабиран.

Например, тук са типичните настройки на под:

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

Както бе споменато по-горе, това е пропорционално мащабиране въз основа на съотношението заявки/лимити в манифеста:

CPU: 200m → 300m: съотношение 1:1.75;
Памет: 250Mi → 500Mi: съотношение 1:2.

по отношение на HPA, тогава механизмът на работа е по-прозрачен. Задават се прагове за показатели като процесор и памет и ако средната стойност на всички реплики надвиши прага, тогава приложението се мащабира с +1 под, докато стойността падне под прага или докато се достигне максималния брой реплики.

Изображението е взето от https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

В допълнение към обичайните показатели като CPU и памет, можете да зададете прагове на персонализираните показатели на Prometheus и да работите с тях, ако смятате, че това е най-точният начин да определите кога да мащабирате приложението си. След като приложението се стабилизира под определения праг на метрика, HPA ще започне да мащабира Pods до минималния брой реплики или докато натоварването достигне прага.

6. Не забравяйте за афинитета на възлите и афинитета на под

Не всички възли работят на един и същ хардуер и не всички подове трябва да изпълняват приложения с интензивни изчисления. Kubernetes ви позволява да укажете специализацията на използваните възли и pods Афинитет на възел и Под афинитет.

Ако имате възли, подходящи за операции с интензивни изчисления, тогава за максимална ефективност е по-добре да обвържете приложения към подходящите възли. За да направите това, използвайте nodeSelector с етикет на възел.

Да приемем, че имате два възела: един с CPUType=HIGHFREQ и голям брой бързи ядра, друг с MemoryType=HIGHMEMORY повече памет и по-бърза производителност. Най-лесният начин е да присвоите внедряване на pod към възел HIGHFREQчрез добавяне към раздела spec селектор като този:

…
nodeSelector:
	CPUType: HIGHFREQ

По-скъп и специфичен начин да направите това е да използвате nodeAffinity в полето affinity раздел spec. Има две възможности:

requiredDuringSchedulingIgnoredDuringExecution: твърда настройка (планировчикът ще разположи подове само на конкретни възли (и никъде другаде));
preferredDuringSchedulingIgnoredDuringExecution: мека настройка (планировчикът ще се опита да разположи към конкретни възли и ако не успее, ще се опита да разположи към следващия наличен възел).

Можете да зададете конкретен синтаксис за управление на етикети на възли, например, In, NotIn, Exists, DoesNotExist, Gt или Lt. Не забравяйте обаче, че сложните методи в дългите списъци с етикети ще забавят вземането на решения в критични ситуации. С други думи, не усложнявайте.

Както бе споменато по-горе, Kubernetes ви позволява да зададете обвързването на текущите подове. Това означава, че можете да накарате определени подове да работят заедно с други подове в същата зона на достъпност (от значение за облаците) или възли.

В podAffinity полета affinity раздел spec налични са същите полета, както в случая на nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Единствената разлика е, че matchExpressions ще обвърже pods към възел, който вече изпълнява pod с този етикет.

Още Kubernetes предлага поле podAntiAffinity, което, за разлика от това, не свързва pod към възел с конкретни pods.

Относно изразите nodeAffinity Същият съвет може да бъде даден: опитайте се да поддържате правилата прости и логични, не се опитвайте да претоварвате спецификацията на pod със сложен набор от правила. Много е лесно да създадете правило, което не съответства на условията на клъстера, което допълнително натоварва планировчика и влошава цялостната производителност.

7. Петна и толерантности

Има и друг начин за управление на планировчика. Ако имате голям клъстер със стотици възли и хиляди микроуслуги, е много трудно да попречите на определени подове да бъдат хоствани от определени възли.

Механизмът на петна - забраняващите правила - помага за това. Например, можете да попречите на определени възли да изпълняват подове в определени сценарии. За да приложите петна към конкретен възел, използвайте опцията taint в kubectl. Посочете ключ и стойност и след това опетнете подобно 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"

Това не означава, че по време на следващото пренасочване подът ще удари точно този възел, това не е механизмът за афинитет на възел и nodeSelector. Но като комбинирате няколко функции, можете да постигнете много гъвкава настройка на планировчика.

8. Задайте приоритет на разполагане на Pod

Това, че сте конфигурирали свързвания между подове и възли, не означава, че всички подове трябва да се третират с един и същ приоритет. Например, може да искате да внедрите някои Pods преди други.

Kubernetes предлага различни начини за задаване на Priority и Preemption на Pod. Обстановката се състои от няколко части: обект 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 000 000 000. По-високите стойности са запазени за критични за мисията системни модули, които обикновено не могат да бъдат изпреварени. Изгонването ще се случи само ако групата с висок приоритет няма къде да се обърне, тогава някои от групите от конкретен възел ще бъдат евакуирани. Ако този механизъм е твърде твърд за вас, тогава можете да добавите опцията preemptionPolicy: Never, и тогава няма да има изпреварване, pod ще бъде първият в опашката и ще чака планировчикът да намери свободни ресурси за него.

След това създаваме под, в който посочваме името 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 могат да изпаднат без увреждане на клъстера.

Имайте предвид, че прекомерното увеличаване на броя на участниците в клъстера може да увеличи устойчивостта на грешки за сметка на производителността, всичко трябва да бъде умерено.

Ако говорим за настройка на услугата, тогава има няколко препоръки:

Имайте добър хардуер, въз основа на размера на клъстера (можете да прочетете тук).
Променете няколко параметъра, ако сте разпространили клъстер между двойка DC или вашата мрежа и дискове оставят много да се желае (можете да прочетете тук).

Заключение

Тази статия описва точките, които нашият екип се опитва да спазва. Това не е описание стъпка по стъпка на действията, а опции, които могат да бъдат полезни за оптимизиране на режийните разходи на клъстер. Ясно е, че всеки клъстер е уникален по свой собствен начин и решенията за настройка могат да варират значително, така че би било интересно да получим обратна връзка от вас: как наблюдавате вашия клъстер Kubernetes, как подобрявате неговата производителност. Споделете опита си в коментарите, ще бъде интересно да го научите.

Източник: www.habr.com

Девет съвета за ефективност на Kubernetes