Kubernetes.HorizontalPodAutoscaler - теория. часть12

Thank you for reading this post, don't forget to subscribe!

В этой ста­тье рас­смот­рим исполь­зо­ва­ние HorizontalPodAutoscaler - объ­ек­тов, пред­на­зна­чен­ных для авто­ма­ти­че­ско­го мас­шта­би­ро­ва­ния коли­че­ства подов (Pods) в Replication ControllerReplica Set или Deployment, осно­вы­ва­ясь на исполь­зо­ва­нии CPU (или, при под­держ­ке custom metrics, на дру­гих мет­ри­ках приложения).

Сра­зу сто­ит отме­тить, что HorizontalPodAutoscaler не может быть при­ме­нен к объ­ек­там, кото­рые не пред­на­зна­че­ны для мас­шта­би­ро­ва­ния, напри­мер DaemonSets. Horizontal Pod Autoscaler состо­ит из Kubernetes ресур­са (объ­ек­та) и кон­трол­ле­ра, пове­де­ние кото­ро­го опи­сы­ва­ет­ся ресурсом.

C пери­о­дич­но­стью 15 секунд (мож­но изме­нить с помо­щью пара­мет­ра --horizontal-pod-autoscaler-sync-period), кон­трол­лер соби­ра­ет дан­ные по исполь­зо­ва­нию мет­рик, опре­де­лен­ных в мани­фе­сте ресур­са HorizontalPodAutoscaler. Мет­ри­ки соби­ра­ют­ся или с resource metrics API (мет­ри­ки исполь­зо­ва­ния ресур­сов пода­ми) или с custom metrics API (осталь­ные мет­ри­ки, напри­мер, мет­ри­ки приложения).

Для каж­до­го под­кон­троль­но­го пода, кон­трол­лер соби­ра­ет мет­ри­ки (напри­мер, исполь­зо­ва­ния CPU) с resource metrics API (metrics.k8s.io, предо­став­ля­ет­ся metrics-server). Далее, про­ис­хо­дит вычис­ле­ние теку­ще­го зна­че­ния исполь­зо­ва­ния CPU в про­цен­тах от запро­шен­ных ресур­сов (resource request) кон­тей­не­ра­ми каж­до­го пода, после чего это зна­че­ние срав­ни­ва­ет­ся с “целе­вым” (target) зна­че­ни­ем - поро­гом, после кото­ро­го коли­че­ство подов долж­но быть увеличено.

Рас­смот­рим кон­крет­ный при­мер. Созда­дим файл test-hpa.yaml с опи­са­ни­ем ресур­са HorizontalPodAutoscaler тако­го содержания:

Созда­дим дан­ный объ­ект в кла­сте­ре Kubernetes:

Про­ве­рим нали­чие объекта:

Спу­стя неко­то­рое вре­мя, вме­сто <unknown>, мы долж­ны уви­деть теку­щее исполь­зо­ва­ние CPU пода­ми в деп­лой­мен­те test-api-deploy, одна­ко в моем слу­чае это­го не про­изо­шло. Начи­на­ем раз­би­рать­ся - для нача­ла, убе­дим­ся, что metrics.k8s.io доступно:

Про­ве­рим, что мет­ри­ки исполь­зо­ва­ния CPU доступ­ны. Пер­вый вариант:

Вто­рой вари­ант (мет­ри­ки толь­ко одно­го кон­крет­но­го пода):

Как видим, мет­ри­ки доступ­ны. Полу­чим деталь­ное опи­са­ние наше­го HorizontalPodAutoscaler:

Здесь самое важ­ное - сооб­ще­ние the HPA was unable to compute the replica count: missing request for cpu. И дей­стви­тель­но, в мани­фе­сте раз­вер­ты­ва­ния (Deployment) не ука­за­ны resource requests для одно­го из кон­тей­не­ров (с име­нем envoy):

Важ­но! Если не ука­за­ны resource request хотя бы для одно­го из кон­тей­не­ров в Replication ControllerReplica Set или Deployment, то теку­щее зна­че­ние исполь­зо­ва­ние CPU пода­ми не может быть кор­рект­но опре­де­ле­но, и, в резуль­та­те, HorizontalPodAutoscaler не будет пред­при­ни­мать ника­ких дей­ствий по масштабированию.

После исправ­ле­ния этой досад­ной ошиб­ки, HorizontalPodAutoscaler, бази­ру­ясь на полу­чен­ных мет­ри­ках, начи­на­ет мас­шта­би­ро­вать поды в развертывании:

Фор­му­ла, по кото­рой HorizontalPodAutoscaler вычис­ля­ет тре­бу­е­мое коли­че­ство реплик выгля­дит так:

Напри­мер, если теку­щее зна­че­ние мет­ри­ки (currentMetricValue) рав­но 200m, а ожи­да­е­мое (desiredMetricValue) уста­нов­ле­но в 100m, то коли­че­ство реплик будет удво­е­но (200.0 / 100.0 == 2.0). Если же теку­щее зна­че­ние мет­ри­ки рав­но все­го лишь 50m, то коли­че­ство реплик долж­но быть умень­ше­но вдвое (50.0 / 100.0 == 0.5). Если соот­но­ше­ние теку­ще­го зна­че­ния мет­ри­ки к ожи­да­е­мо­му зна­че­нию доста­точ­но близ­ко к 1, то ника­ких дей­ствий не будет предпринято.

Так как мы ука­за­ли targetAverageUtilization при опи­са­нии ресур­са HorizontalPodAutoscaler, то теку­щее зна­че­ние мет­ри­ки (currentMetricValue) исполь­зо­ва­ния CPU рас­счи­ты­ва­ет­ся как сред­нее зна­че­ние этой мет­ри­ки для всех подов, кон­тро­ли­ру­е­мых дан­ным автоскейлером.

После того, как теку­щее зна­че­ние исполь­зо­ва­ния CPU сни­зи­лось и оста­ва­лось низ­ким в тече­нии 5 минут (уста­нав­ли­ва­ет­ся с помо­щью пара­мет­ра --horizontal-pod-autoscaler-downscale-stabilization), коли­че­ство реплик было авто­ма­ти­че­ски уменьшено: