Подсистемите могат да бъдат създадени като самостоятелни обекти или като част от набор от мащабируеми реплики или разполагане. Всеки от последните два обекта се използва за разполагане не само на една шушулка, но множество от тях. Целта тук е, че шушулките могат да бъдат заменими, ако някой има твърде много трафик, още два могат да се появят и да поемат допълнително бреме. Важно е обаче да се отбележи тук, че както репликите, така и обектите за разполагане имат твърдо кодиран брой реплики на под, които възнамеряват да изпълнят.

Ако броят на репликите е зададен на 100 и търсенето е твърде малко, дори тогава 100-те шушулки ще бъдат пуснати в действие. Това води до загуба на ресурсите на процесора и паметта. Да, той предлага надеждност, в смисъл, че ако възел се срине и шушулките в него умрат, контролерът Replica Set ще се опита да върне броя на шушулките до 100, като хвърля хайвера в други възли. Приложението остава онлайн.

В по-абстрактен смисъл, Комплектът реплики ще се опита да постигне желано състояние на клъстера и би погледнал на сегашно състояние и разберете как може да постигне желаното състояние.

Бихме искали обаче нещо малко по-чувствително към реалното търсене. Въведете Автоматичен скалер за хоризонтални шушулки. Работата на Horizontal Pod Autoscaler е да мащабира приложението, когато има нужда от него и след това да го мащабира обратно, след като натоварването падне.

Защо да използвате Horizontal Pod Autoscaler?

Както подсказва името, този компонент автоматично ще мащабира приложението ви. В облака това наистина може да ви помогне да намалите изчислителните и паметта, за които ще ви таксуваме. Тъй като Autoscaler е чувствителен към използването на ресурсите, когато вижда, че много шушулки просто седят без работа, той намалява приложението и когато търсенето на тези шушулки се увеличава, той мащабира приложението чрез създаване на нови шушулки и натоварването се разпределя към тези.

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

Първоначалната настройка

Първо и най-важно изискване ще бъде да имате работещ клъстер Kubernetes. Използвайте Katacoda Playground, която е идеална за експерименти и изучаване на Kubernetes. Следващото нещо, което бихте изисквали, е метричен сървър.

Тази добавка към вашата система Kubernetes (пространство на имена на kube-системата) ще събира показатели като CPU и използване на паметта от две различни гледни точки:

1. Ресурс, използван от всяка шушулка
2. Ресурс, изразходван на всеки възел

Метриките от двете перспективи са решаващи за подпомагането на Autoscaler да реши какъв следва да бъде следващият му ход. За да добавите метричен сървър към вашия клъстер Kubernetes, следвайте това ръководство. Сега сме готови да видим Horizontal Pod Autoscaler в действие.

Използване на автоскалера

За да видим как Autoscaler работи, имаме нужда от тестово приложение. Нека създадем прост php-apache сървър и да го изложим като услуга.

$ kubectl стартира php-apache --image = k8s.gcr.io / hpa-example --requests = cpu = 200m --expose
--порт = 80

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

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

$ kubectl автоматични мащабирания / php-apache --cpu-процент = 50 --min = 1 --max = 10

В текущото състояние, тъй като никой не използва тази услуга, тя най-много ще хареса да остане на минималната стойност. Можете да проверите състоянието на цялото автоматично скалирано разполагане в пространството от имена по подразбиране, като изпълните:

$ kubectl вземете hpa
ИМЕ РЕФЕРЕНТНИ ЦЕЛИ MINPODS MAXPODS РЕПЛИКИ ВЪЗРАСТ
Разгръщане на php-apache / php-apache 0% / 50% 1 10 1 2m

Генериране на натоварване и тестване на функцията за автоматично скалиране

Можете да видите, че броят на репликите все още е само един и натоварването на процесора е незначително ниско. Можем да създадем допълнително натоварване и да видим как автоскалерът реагира на него. Услугата, която излага нашите php-apache шушулки, не е изложена на външния свят, затова ще създадем временна под и ще отворим интерактивна сесийна обвивка в тази под.

Това ще ни позволи да комуникираме с всички услуги, налични в клъстера, включително услугата php-apache.

$ kubectl run -i --tty busybox --image = busybox --restart = Никога - sh
/ #

Ще забележите, че подканата ще се промени, показвайки, че сме вътре в този контейнер. Нека сега се опитаме да натоварим нашата услуга, като многократно отправяме заявки. В новия ред нека изпълним следния цикъл while:

/ # докато е вярно; направете wget -q -O- http: // php-apache.по подразбиране.svc.клъстер.местна; Свършен

Отворете нов терминал, тъй като все още не можем да оставим този цикъл да се прекрати. При проверка на автоскалера ще видите използването на процесора и при изброяване на подгрупите ще видите, че вече има множество екземпляри на php-apache сървър,

$ kubectl вземете hpa
ИМЕ РЕФЕРЕНТНИ ЦЕЛИ MINPODS MAXPODS РЕПЛИКИ ВЪЗРАСТ
php-apache Разгръщане / php-apache 121% / 50% 1 10 4 1h
 
$ kubectl вземете шушулки
ИМЕ ГОТОВ СТАТУС ВЪЗСТАНОВЯВА ВЪЗРАСТ
busybox 1/1 Бягане 0 6м
php-apache-8699449574-7qwxd 1/1 Работи 0 28s
php-apache-8699449574-c9v54 1/1 Работи 0 10h
php-apache-8699449574-h9s5f 1/1 Работи 0 28s
php-apache-8699449574-sg4hz 1/1 Работи 0 28s

Прекратете цикъла while и броят на шушулките ще намалее до един за няколко минути.

Заключение

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