Кога започнувате со Kubernetes, вообичаено е да заборавите да поставите ресурси за контејнери. Во овој момент, доволно е да се осигура дека сликата на Docker работи и може да се распореди во кластерот Kubernetes.
Но, подоцна апликацијата треба да се распореди во производствен кластер заедно со други апликации. За да го направите ова, треба да одвоите ресурси за контејнерот и да се уверите дека има доволно од нив за да се активира апликацијата и дека другите апликации што работат нема да имаат проблеми.
Тим преведе статија за ресурси за контејнери (CPU & MEM), барања и ограничувања на ресурсите. Ќе ги дознаете придобивките од овие поставки и што ќе се случи ако не ги поставите.
Пресметувачки ресурси
Имаме два вида ресурси со следните единици:
- Централна процесорска единица (CPU) - јадра;
- Меморија (MEM) - бајти.
Ресурсите се наведени за секој контејнер. Во следната датотека Pod YAML, ќе видите дел за ресурси што ги содржи бараните и ограничените ресурси:
- Requested Pod Resources = збир на барани ресурси од сите контејнери;
- Pod Resource Limit = Збир на сите ограничувања на ресурси на Pod.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiПример за барани и ограничени ресурси
столб resources.requested од спецификацијата Pod е еден од елементите што се користи за пронаоѓање на саканиот јазол. Веќе можете да планирате распоредување на Pod за тоа. Како да пронајдете соодветен јазол?
Kubernetes се состои од неколку компоненти, вклучувајќи главен јазол или главен јазол (Kubernetes Control Plane). Главниот јазол има неколку процеси: kube-apiserver, kube-controller-manager и kube-scheduler.
Процесот на кубе-распоредувач е одговорен за прегледување на новосоздадените подлоги и за наоѓање можни работни јазли што одговараат на сите барања за подлоги, вклучувајќи го и бројот на бараните ресурси. Списокот на јазли пронајдени од kube-scheduler е рангиран. Подлогата е закажана на јазолот со највисоки оценки.
Каде ќе биде поставена виолетова подлога?
На сликата можете да видите дека кубе-распоредувачот треба да закаже нов виолетов Pod. Кластерот Kubernetes содржи два јазли: A и B. Како што можете да видите, kube-распоредувачот не може да закаже Pod на јазолот A - достапните (небараните) ресурси не се совпаѓаат со барањата на пурпурниот Pod. Значи, меморијата од 1 GB што ја бара пурпурниот Pod нема да се вклопи во јазолот А, бидејќи достапната меморија е 0,5 GB. Но, јазолот Б има доволно ресурси. Како резултат на тоа, кубе-распоредувачот одлучува дека дестинацијата на пурпурниот Pod е јазол Б.
Сега знаеме како бараните ресурси влијаат на изборот на јазол за да се изврши Pod. Но, какво е влијанието на маргиналните ресурси?
Ограничувањето на ресурсите е граница што CPU/MEM не може да ја премине. Сепак, ресурсот на процесорот е флексибилен, така што контејнерите што ги достигнуваат границите на процесорот нема да предизвикаат излез на Pod. Наместо тоа, ќе започне пригушувањето на процесорот. Ако се достигне ограничувањето за употреба на MEM, контејнерот ќе биде запрен поради OOM-Killer и ќе се рестартира ако е дозволено со поставката RestartPolicy.
Детално барани и максимални ресурси
Комуникација со ресурси помеѓу Docker и Kubernetes
Најдобар начин да се објасни како функционираат барањата за ресурси и ограничувањата на ресурсите е да се воведе односот помеѓу Kubernetes и Docker. На сликата погоре можете да видите како се поврзани полињата Kubernetes и знаменцата за стартување на Docker.
Меморија: барање и ограничување
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Како што споменавме погоре, меморијата се мери во бајти. Базирано на , можеме да ја одредиме меморијата како број. Обично тоа е цел број, на пример 2678 - односно 2678 бајти. Можете исто така да користите суфикси G и Gi, главната работа е да се запамети дека тие не се еквивалентни. Првиот е децимален, а вториот е бинарен. Како примерот споменат во документацијата на k8s: 128974848, 129e6, 129M, 123Mi - тие се практично еквивалентни.
Опција Kubernetes limits.memory одговара на знамето --memory од Докер. Во случај на request.memory Нема стрелка за Docker бидејќи Docker не го користи ова поле. Можеби ќе прашате, дали е ова воопшто потребно? Да треба. Како што реков претходно, теренот е важен за Кубернетес. Врз основа на информациите од него, kube-распоредувачот одлучува кој јазол да го закаже Pod.
Што се случува ако поставите недоволна меморија за барање?
Ако контејнерот ги достигнал границите на бараната меморија, тогаш Pod се става во група Pods кои застануваат кога нема доволно меморија во јазолот.
Што се случува ако го поставите ограничувањето на меморијата премногу ниско?
Ако контејнерот го надмине ограничувањето на меморијата, ќе се прекине поради OOM-Killed. И ќе се рестартира ако е можно врз основа на RestartPolicy каде што е стандардната вредност Always.
Што се случува ако не ја наведете бараната меморија?
Kubernetes ќе ја земе граничната вредност и ќе ја постави како стандардна вредност.
Што може да се случи ако не наведете ограничување на меморијата?
Контејнерот нема ограничувања, може да користи онолку меморија колку што сака. Ако почне да ја користи целата достапна меморија на јазолот, тогаш OOM ќе го убие. Контејнерот потоа ќе се рестартира ако е можно врз основа на RestartPolicy.
Што се случува ако не наведете ограничувања на меморијата?
Ова е најлошото сценарио: распоредувачот не знае колку ресурси бара контејнерот и тоа може да предизвика сериозни проблеми на јазолот. Во овој случај, би било убаво да има стандардни ограничувања на именскиот простор (поставен од LimitRange). Нема стандардни ограничувања - Pod нема ограничувања, може да користи онолку меморија колку што сака.
Ако бараната меморија е повеќе од она што јазолот може да го понуди, Pod нема да се закаже. Важно е да се запамети тоа Requests.memory - не минималната вредност. Ова е опис на количината на меморија доволна за да може контејнерот да работи постојано.
Обично се препорачува да се постави истата вредност за request.memory и limit.memory. Ова осигурува дека Kubernetes нема да закаже Pod на јазол што има доволно меморија за да го стартува Pod, но нема доволно за да го стартува. Имајте на ум: планирањето на Kubernetes Pod само го зема предвид requests.memoryИ limits.memory не зема предвид.
Процесор: барање и ограничување
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Со процесорот сè е малку покомплицирано. Враќајќи се на сликата за односот помеѓу Кубернетес и Докер, можете да го видите тоа request.cpu соответствует --cpu-sharesсо оглед на тоа што limit.cpu одговара на знамето cpus во Докер.
Процесорот што го бара Kubernetes се множи со 1024, соодносот на циклусите на процесорот. Ако сакате да побарате 1 целосно јадро, мора да додадете cpu: 1како што е прикажано погоре.
Ако барате целосно јадро (пропорција = 1024) не значи дека вашиот контејнер ќе го добие. Ако вашата домаќинска машина има само едно јадро и користите повеќе од еден контејнер, тогаш сите контејнери мора да го делат достапниот процесор помеѓу нив. Како се случува ова? Ајде да ја погледнеме сликата.
Барање на процесорот - Еднојадрен систем
Ајде да замислиме дека имате еднојадрен домаќин систем кој работи со контејнери. Мама (Кубернетес) испече пита (процесор) и сака да ја подели на деца (контејнери). Три деца сакаат цела пита (пропорција = 1024), друго дете сака половина пита (512). Мама сака да биде фер и прави едноставна пресметка.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Врз основа на пресметката, три деца ќе добијат 28% од јадрото, а не од целото јадро. Четвртото дете ќе добие 14% од целосниот кернел, а не половина. Но, работите ќе бидат поинакви ако имате систем со повеќе јадра.
Барање процесорски - Мулти-јадрен (4) систем
На сликата погоре можете да видите дека три деца сакаат цела пита, а едно сака половина. Бидејќи мама испече четири пити, секое нејзино дете ќе добие колку што сака. Во повеќејадрен систем, ресурсите на процесорот се дистрибуираат низ сите достапни процесорски јадра. Ако контејнерот е ограничен на помалку од едно целосно јадро на процесорот, тој сепак може да го користи на 100%.
Горенаведените пресметки се поедноставени за да се разбере како процесорот се дистрибуира меѓу контејнерите. Се разбира, покрај самите контејнери, постојат и други процеси кои исто така користат ресурси на процесорот. Кога процесите во еден контејнер се неактивен, другите можат да го користат неговиот ресурс. CPU: "200m" соответствует CPU: 0,2, што значи приближно 20% од едно јадро.
Сега да разговараме за limit.cpu. Процесорот што го ограничува Kubernetes се множи со 100. Резултатот е времето што садот може да го користи на секои 100 µs (cpu-period).
limit.cpu се совпаѓа со знамето Докер --cpus. Ова е нова комбинација на стари --cpu-period и --cpu-quota. Со негово поставување, покажуваме колку достапни ресурси на процесорот може максимално да ги искористи контејнерот пред да започне пригушувањето:
- процесор - комбинација
cpu-periodиcpu-quota. cpus = 1.5еквивалентно на поставувањеcpu-period = 100000иcpu-quota = 150000; - Период на процесорот - период , стандардно 100 микросекунди;
- процесорска-квота - број на микросекунди внатре
cpu-period, кој е ограничен со контејнерот.
Што се случува ако инсталирате недоволно баран процесор?
Ако на контејнерот му треба повеќе отколку што има инсталирано, тој ќе го украде процесорот од други процеси.
Што се случува ако го поставите лимитот на процесорот премногу ниско?
Бидејќи ресурсот на процесорот е прилагодлив, гаснењето ќе се вклучи.
Што се случува ако не наведете барање за процесорот?
Како и кај меморијата, вредноста на барањето е еднаква на лимитот.
Што се случува ако не наведете ограничување на процесорот?
Контејнерот ќе користи онолку процесор колку што му треба. Ако стандардната политика на процесорот (LimitRange) е дефинирана во именскиот простор, тогаш оваа граница се користи и за контејнерот.
Што се случува ако не наведете барање или ограничување на процесорот?
Како и со меморијата, ова е најлошото сценарио. Распоредувачот не знае колку ресурси му се потребни на вашиот контејнер и тоа може да предизвика сериозни проблеми на јазолот. За да го избегнете ова, треба да поставите стандардни ограничувања за именските простори (LimitRange).
Запомнете: ако побарате повеќе процесор отколку што можат да обезбедат јазлите, Pod нема да се закаже. Requests.cpu - не минималната вредност, туку вредност доволна за стартување на Pod и работа без дефекти. Ако апликацијата не врши сложени пресметки, најдобра опција е да се инсталира request.cpu <= 1 и лансирајте онолку реплики колку што е потребно.
Идеален износ на барани ресурси или ограничување на ресурсите
Научивме за ограничувањето на компјутерските ресурси. Сега е време да одговориме на прашањето: „Колку ресурси бара мојот Pod за да ја изврши апликацијата без никакви проблеми? Која е идеалната количина?
За жал, нема јасни одговори на овие прашања. Ако не знаете како функционира вашата апликација или колку процесор или меморија и треба, најдобрата опција е да и дадете на апликацијата многу меморија и процесор и потоа да извршите тестови за перформанси.
Покрај тестовите за изведба, следете го однесувањето на апликацијата при мониторинг една недела. Ако графиконите покажуваат дека вашата апликација троши помалку ресурси отколку што баравте, можете да ја намалите количината на бараниот процесор или меморија.
Како пример видете го ова . Ја прикажува разликата помеѓу бараните ресурси или ограничување на ресурсите и тековното користење на ресурсите.
Заклучок
Барањето и ограничувањето ресурси помага да се одржи здрав кластерот Kubernetes. Правилната конфигурација на лимитот ги минимизира трошоците и ги одржува апликациите да работат постојано.
Накратко, има неколку работи што треба да ги имате на ум:
- Бараните ресурси се конфигурација што се зема предвид при стартување (кога Kubernetes планира да ја хостира апликацијата). Спротивно на тоа, ограничувањето на ресурсите е важно при извршување - кога апликацијата веќе работи на јазолот.
- Во споредба со меморијата, процесорот е регулиран ресурс. Ако нема доволно процесор, вашиот Pod нема да се исклучи и механизмот за пригушување ќе се вклучи.
- Бараните ресурси и ограничувањето на ресурсите не се минимални и максимални вредности! Со дефинирање на бараните ресурси, гарантирате дека апликацијата ќе работи без проблеми.
- Добра практика е да го поставите барањето за меморија еднакво на ограничувањето на меморијата.
- Во ред се бара инсталација
CPU <=1, доколку апликацијата не врши сложени пресметки. - Ако побарате повеќе ресурси отколку што се достапни на еден јазол, Pod никогаш нема да биде закажан за тој јазол.
- За да го одредите точниот износ на бараните ресурси/ограничувања на ресурси, користете тестирање и мониторинг на оптоварување.
Се надевам дека оваа статија ќе ви помогне да го разберете основниот концепт на ограничување на ресурсите. И ќе можете да го примените ова знаење во вашата работа.
Среќа!
Што друго да прочитате:
- .
- .
- .
Извор: www.habr.com