diff --git a/practice/17.hpa/01.hpa_v1/README.md b/practice/17.hpa/01.hpa_v1/README.md new file mode 100644 index 0000000..f157ad2 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/README.md @@ -0,0 +1,224 @@ +### HPA v1 + +--- + +**1. Запускаем Metric server (!!! только при выполнении практики на собственном кластере - Minikube и тд)** + +* Применяем манифесты Metric server + +Поскольку Metric server не устанавливается в Kubernetes кластер по умолчанию, первое что необходимо сделать - это установить его. Все необходимые манифесты находятся в каталоге `for-minikube-only-metric-server` и их можно сразу применить в кластер. Для этого необходимо в консоли выполнить команду: + +```bash +kubectl apply -f for-minikube-only-metrics-server/ -n kube-system +``` + +* Проверяем работу Metric server + +Metric server собирает данные с kubelet c периодичностью 1 раз в минуту. После установки необходимо подождать 1-2 минуты и выполнить команду: + +```bash +kubectl top node +``` + +Данная команда выведет текущую нагрузку на ноды. В результате выполнения команды на экран будут выведены примерно следующие данные: + +```bash +NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% +master-1.s000000.slurm.io 122m 12% 1693Mi 44% +master-2.s000000.slurm.io 114m 11% 1489Mi 38% +master-3.s000000.slurm.io 97m 9% 1423Mi 37% +node-1.s000000.slurm.io 59m 5% 1505Mi 39% +node-2.s000000.slurm.io 357m 35% 1389Mi 36% +``` + +Важной особенностью Metric Server является то, что он не хранит полученные данные, а только отображает последние полученные. По этому расценивать его как полноценную систему мониторинга нельзя. + +**2. Запускаем тестовое приложение** + +В качестве тестового приложения будет использоваться специальное приложение, предназначенное для тестирования HPA. Приложение написано на PHP, и при запросах генерирует высокую нагрузку. Для начала применим Deployment в кластер, выполнив команду: + +```bash +kubectl apply -f deploy/deployment.yml +``` + +Для работы HPA обязательным является наличие у Pod выставленных `request`. Обратите внимание на [deployment.yml](deploy/deployment.yml), в нем указано: + +```yaml +resources: + requests: + cpu: 100m +``` + +Теперь создадим Service. Для этого мы не будем использовать готовые манифесты, а воспользуемся ключом `expose` для kubectl. Данный ключ позволяет создать Service для Deployment без написания манифеста. В итоге получается следующая команда, которую необходимо выполнить в консоли: + +```bash +kubectl expose deployment php-apache --port 80 +``` + +**3. Устанавливаем HPA** + +Для запуска HPA так же воспользуемся возможностями kubectl. Для создания абстракции HPA без манифеста можно использовать ключ `autoscale`. Выполним команду: + +```bash +kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=5 +``` + +В результате выполнения команды будет создан HPA, который отслеживает состояние Deployment с именем `php-apache`. При достижении средней нагрузки на все Pod 50% (для расчетов суммируется процент нагрузки на каждый Pod и делится на их количество) scaling будет производиться в границах от 1-го Pod до 5 Pod. + +**4. Проверяем работу** + +* Смотрим на текущее количество Pod + +```bash +kubectl get pod +``` + +Должен быть запущен один Pod + +```bash +NAME READY STATUS RESTARTS AGE +php-apache-566d7644df-z9dtt 1/1 Running 0 15s +``` + +* Смотрим на HPA + +```bash +kubectl get hpa +``` + +Видим созданный HPA + +```bash +NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache 1%/50% 1 5 1 32s +``` + +Она будет скейлить Pod, как только их использование cpu начнет составлять 50% от request. + +* Создаем нагрузку + +Для генерации нагрузки создадим еще один Pod из образа busybox. Внутри Pod в цикле будет запущена утилита wget, которая будет обращаться к тестовому приложению по имени Service. В итоге получается следующая команда, которую необходимо выполнить в консоли: + +```bash +kubectl run load-generator --image=busybox -- /bin/sh -c "while true; do wget -q -O- http://php-apache; done" +``` + +* Проверяем текущее потребление cpu Pod + +Metric server может отдавать не только нагрузку по Node, но и по Pod. Для вывода информации по нагрузке от Pod выполните команду: + +``` +kubectl top pod +``` + +Видим, что нагрузка начинает увеличиваться. + +```bash +NAME CPU(cores) MEMORY(bytes) +php-apache-566d7644df-z9dtt 936m 11Mi +``` + +* Ждем когда начнет работать Autoscaling + +У kubectl есть ключ `-w`, который позволяет выводить в режиме реального времени все изменения для нашего текущего запроса. Выполним следующую команду в консоли, чтобы отслеживать изменения количества Pod: + +```bash +kubectl get pod -w +``` + +Спустя несколько минут количество Pod должно увеличиться до 5-ти. + +```bash +NAME READY STATUS RESTARTS AGE +load-generator-6b9cf94758-5qmbx 1/1 Running 0 2m16s +php-apache-566d7644df-4zvv7 1/1 Running 0 108s +php-apache-566d7644df-kv662 1/1 Running 0 93s +php-apache-566d7644df-tg8qw 1/1 Running 0 108s +php-apache-566d7644df-z9dtt 1/1 Running 0 13m +php-apache-566d7644df-zlwd7 1/1 Running 0 108s +``` + +Отлично, autoscaling сработал! + +* Проверяем работу в обратную сторону + +Удаляем Pod с тестовой нагрузкой выполнив команду: + +```bash +kubectl delete pod load-generator +``` + +* Проверяем нагрузку на поды + +```bash +kubectl top pod +``` + +Через какое-то время замечаем, что она упала + +```bash +NAME CPU(cores) MEMORY(bytes) +php-apache-566d7644df-4zvv7 1m 11Mi +php-apache-566d7644df-kv662 1m 11Mi +php-apache-566d7644df-tg8qw 1m 11Mi +php-apache-566d7644df-z9dtt 1m 11Mi +php-apache-566d7644df-zlwd7 1m 11Mi +``` + +* Проверяем, как autoscaling отработает в обратную сторону + +```bash +kubectl get pod -w +``` + +Видим, что ненужные поды умирают (в течение 5 минут). После снижения нагрузки scale down не происходит слишком быстро, чтобы избежать ситуации, когда значения по потреблению находятся в пограничном состоянии. + +```bash +NAME READY STATUS RESTARTS AGE +php-apache-566d7644df-4zvv7 0/1 Terminating 0 8m59s +php-apache-566d7644df-kv662 0/1 Terminating 0 8m44s +php-apache-566d7644df-tg8qw 0/1 Terminating 0 8m59s +php-apache-566d7644df-z9dtt 1/1 Running 0 20m +php-apache-566d7644df-zlwd7 0/1 Terminating 0 8m59s +``` + +Autoscaling вернул все к первоначальному варианту с одним Pod. + +**5. Чистим за собой кластер** + +```bash +kubectl delete all --all +``` + +#### Troubleshooting + +* Проверяем, что Metric server запущен + +```bash +kubectl get po -n kube-system | grep metrics-server +``` + +Поды должны быть в состоянии `STATUS: Running` и `READY 1/1`. Если Pod отсутствует, начинаем практику с первого пункта. Если состояние не `Running` или `0/1`, то смотрим причины, выполнив команду: + +```bash +kubectl describe po -n kube-system metrics-server- +``` + +* Проверяем, что метрики доступны + +Для проверки доступности метрик выполним команду: + +```bash +kubectl top node +``` + +Если не выводится потребления по Node, но в прошлом шаге не выявлено ошибок, то пробуем установить еще раз все абстракции, выполнив команду: + +```bash +kubectl apply -f ~/slurm/practice/8.hpa/v1/metrics-server -n kube-system +``` + +#### Полезные ссылки + +1. [k8s doc: HPA v1](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +2. [Metric server](https://github.com/kubernetes-sigs/metrics-server) diff --git a/practice/17.hpa/01.hpa_v1/deploy/deployment.yml b/practice/17.hpa/01.hpa_v1/deploy/deployment.yml new file mode 100644 index 0000000..08dc75e --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/deploy/deployment.yml @@ -0,0 +1,24 @@ +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: php-apache + name: php-apache +spec: + replicas: 1 + selector: + matchLabels: + app: php-apache + template: + metadata: + labels: + app: php-apache + spec: + containers: + - image: k8s.gcr.io/hpa-example + name: hpa-example + resources: + requests: + cpu: 100m +... diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/aggregated-metrics-reader.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/aggregated-metrics-reader.yaml new file mode 100644 index 0000000..cdf3415 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/aggregated-metrics-reader.yaml @@ -0,0 +1,12 @@ +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:aggregated-metrics-reader + labels: + rbac.authorization.k8s.io/aggregate-to-view: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" + rbac.authorization.k8s.io/aggregate-to-admin: "true" +rules: +- apiGroups: ["metrics.k8s.io"] + resources: ["pods"] + verbs: ["get", "list", "watch"] diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/auth-delegator.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/auth-delegator.yaml new file mode 100644 index 0000000..e3442c5 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/auth-delegator.yaml @@ -0,0 +1,13 @@ +--- +apiVersion: rbac.authorization.k8s.io/v1beta1 +kind: ClusterRoleBinding +metadata: + name: metrics-server:system:auth-delegator +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:auth-delegator +subjects: +- kind: ServiceAccount + name: metrics-server + namespace: kube-system diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/auth-reader.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/auth-reader.yaml new file mode 100644 index 0000000..f0616e1 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/auth-reader.yaml @@ -0,0 +1,14 @@ +--- +apiVersion: rbac.authorization.k8s.io/v1beta1 +kind: RoleBinding +metadata: + name: metrics-server-auth-reader + namespace: kube-system +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: extension-apiserver-authentication-reader +subjects: +- kind: ServiceAccount + name: metrics-server + namespace: kube-system diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-apiservice.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-apiservice.yaml new file mode 100644 index 0000000..08b0530 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-apiservice.yaml @@ -0,0 +1,14 @@ +--- +apiVersion: apiregistration.k8s.io/v1beta1 +kind: APIService +metadata: + name: v1beta1.metrics.k8s.io +spec: + service: + name: metrics-server + namespace: kube-system + group: metrics.k8s.io + version: v1beta1 + insecureSkipTLSVerify: true + groupPriorityMinimum: 100 + versionPriority: 100 diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-server-deployment.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-server-deployment.yaml new file mode 100644 index 0000000..fa8c009 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-server-deployment.yaml @@ -0,0 +1,40 @@ +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: metrics-server + namespace: kube-system +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: metrics-server + namespace: kube-system + labels: + k8s-app: metrics-server +spec: + selector: + matchLabels: + k8s-app: metrics-server + template: + metadata: + name: metrics-server + labels: + k8s-app: metrics-server + spec: + serviceAccountName: metrics-server + volumes: + # mount in tmp so we can safely use from-scratch images and/or read-only containers + - name: tmp-dir + emptyDir: {} + containers: + - name: metrics-server + args: + - --kubelet-preferred-address-types=InternalIP + - --kubelet-insecure-tls=true + image: k8s.gcr.io/metrics-server-amd64:v0.3.3 + imagePullPolicy: Always + volumeMounts: + - name: tmp-dir + mountPath: /tmp + diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-server-service.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-server-service.yaml new file mode 100644 index 0000000..ddf6f4a --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/metrics-server-service.yaml @@ -0,0 +1,16 @@ +--- +apiVersion: v1 +kind: Service +metadata: + name: metrics-server + namespace: kube-system + labels: + kubernetes.io/name: "Metrics-server" + kubernetes.io/cluster-service: "true" +spec: + selector: + k8s-app: metrics-server + ports: + - port: 443 + protocol: TCP + targetPort: 443 diff --git a/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/resource-reader.yaml b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/resource-reader.yaml new file mode 100644 index 0000000..4f98772 --- /dev/null +++ b/practice/17.hpa/01.hpa_v1/for-minikube-only-metrics-server/resource-reader.yaml @@ -0,0 +1,29 @@ +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: system:metrics-server +rules: +- apiGroups: + - "" + resources: + - pods + - nodes + - nodes/stats + verbs: + - get + - list + - watch +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:metrics-server +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:metrics-server +subjects: +- kind: ServiceAccount + name: metrics-server + namespace: kube-system diff --git a/practice/17.hpa/02.hpa_v2/README.md b/practice/17.hpa/02.hpa_v2/README.md new file mode 100644 index 0000000..6942ef9 --- /dev/null +++ b/practice/17.hpa/02.hpa_v2/README.md @@ -0,0 +1,283 @@ +### HPA v2 + +--- + +#### С чем будем работать + +* `Prometheus` устанавливается из Helm репозитория +* `Prometheus adapter` устанавливается из Helm репозитория +* `HPA v2` является стандартной абстракцией кластера Kubernetes +* Каталог `deploy` содержит необходимые для прохождения практики манифесты +* Бинарный файл `wrk` - утилита для генерации нагрузки на тестовое приложение +* В качестве тестового приложения будет выступать `nginx` + +#### Где будем выполнять практику + +* Данная практика выполняется на собственном кластере Kubernetes - Minikube и тд + +#### Практика + +**1. Подготовка кластера** + +* Устанавливаем Helm репозиторий + +Переходим к установке Prometheus. Сначала необходимо установить Helm репозиторий, в котором находится Prometheus Helm chart. Для этого выполним команду: + +```bash +helm repo add stable https://charts.helm.sh/stable +``` + +* Устанавливаем Prometheus + +Для прохождения практики нам потребуется только сам Prometheus и kube-state-metrics экспортер. Все остальные компоненты лучше отключить, сделать это можно через `values.yml` или прямое переопределение переменных через ключ `--set`. В итоге получается следующая команда, которую необходимо выполнить в консоли: + +```bash +helm upgrade --install prometheus stable/prometheus --namespace monitoring --create-namespace --set alertmanager.enabled=false --set pushgateway.enabled=false --set nodeExporter.enabled=false --set server.persistentVolume.enabled=false +``` + +* Ставим Prometheus adapter + +Устанавливаем Prometheus adapter, который необходим для доступа к метрикам Prometheus через kube-api (HPA умеет получать метрики только из kube-api). Он также устанавливается с помощью Helm chart. Через ключ `--set` указываем, по какому адресу и порту доступен Prometheus. Так как они находятся в одном namespace, можно указать просто имя сервиса. В итоге получается следующая команда, которую необходимо выполнить в консоли: + +```bash +helm upgrade --install prometheus-adapter stable/prometheus-adapter --namespace monitoring --set prometheus.url=http://prometheus-server --set prometheus.port=80 +``` + +* Проверяем, что всё заработало + +Проверяем, что все поды запустились. Для этого выполним команду: + +```bash +kubectl get po -n monitoring +``` + +Эта команда выведет данные обо всех Pod в namespace monitoring. Все Pod должны быть в состояние `STATUS: Running` и `READY 1/1` или `READY 2/2` в зависимости от количества контейнеров в Pod. Если какие-то Pod не в этом состояние, стоит повторить команду через 1-2 минуты. + +Теперь проверяем, что метрики Prometheus доступны через kube-api. Для этого можно послать прямой запрос к kube-api. C использованием утилиты `kubectl` и указав ключ `--raw` можно выполнить запрос к любому kube-api endpoint. Получим список доступных метрик, выполнив следующую команду: + +```bash +kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 +``` + +На экран будет выведен список всех доступных метрик. Список должен быть длинным. + +Теперь проверим, что Prometheus адаптер зарегистрировался в kube-api. Для этого выполним команду: + +```bash +kubectl get apiservices.apiregistration.k8s.io v1beta1.custom.metrics.k8s.io +``` + +Результат должен быть следующим: + +```bash +NAME SERVICE AVAILABLE AGE +v1beta1.custom.metrics.k8s.io monitoring/prometheus-adapter True 1m +``` + +Данный результат говорит, что при обращении к kube-api на endpoint `v1beta1.custom.metrics.k8s.io` запросы будут перенаправлены в Service с именем `prometheus-adapter` в namespace `monitoring`. Данный Service доставляет запросы в Pod с prometheus-adapter, который в свою очередь, преобразует метрики из вида Prometheus к виду kube-api. + +**2. Запускаем тестовое приложение** + +В качестве тестового приложения будет выступать Nginx, у которого мы будем запрашивать default page. Доступ к Pod будет открыт через Ingress. Для реализации данной схемы необходимо создать: Pod, Service и Ingress. + +* Создаем Deployment и Service + +Для начала применим Deployment в кластер, выполнив команду: + +```bash +kubectl apply -f deploy/deployment.yml -n default +``` + +Теперь создадим Service, для этого мы не будем использовать готовые манифесты, а воспользуемся ключом `expose` для kubectl. Данный ключ позволяет создать Service для Deployment без написания манифеста. В итоге получается следующая команда, которую необходимо выполнить в консоли: + +```bash +kubectl expose deployment hpa-v2-test --port 80 -n default +``` + +В результате выполнения данной команды будет создан Deployment и запущен Pod c Nginx версии 1.13. А так же будет создан Service, через который будет доступен данный Pod. + +* Создаем Ingress + +Зададим имя, по которому будет принимать запросы Ingress, для этого в файле `deploy/ingress.yml` необходимо заменить <Ваш номер студента> на номер своего студента. И применим данный манифест в кластер Kubernetes, выполнив команду: + +```bash +kubectl apply -f deploy/ingress.yml -n default +``` + +* Проверяем результат + +Для проверки, что все настроено верно, выполним запрос на `hpa-v2-test..nip.io`. Например, выполнив команду: + +```bash +curl -I hpa-v2-test..nip.io +``` + +Ответ должен быть примерно таким: +```bash +HTTP/1.1 200 OK +Date: Tue, 19 May 2020 19:57:28 GMT +Content-Type: text/html +Content-Length: 612 +Connection: keep-alive +Vary: Accept-Encoding +Last-Modified: Mon, 09 Apr 2018 16:01:09 GMT +ETag: "5acb8e45-264" +Accept-Ranges: bytes +``` + +**3. Настройка правил Prometheus** + +* Для начала попросим прометеус собирать метрики с ингресс контроллеров. Для этого +отредактируем деплоймент ингресса + +```bash +kubectl edit deployment -n ingress-nginx ingress-nginx-controller +``` + +В него нужно добавить на уровне темплейта пода две аннотации: + +```yaml + strategy: + rollingUpdate: + maxSurge: 25% + maxUnavailable: 25% + type: RollingUpdate + template: + metadata: + annotations: # <--- вот отсюда + prometheus.io/port: "10254" + prometheus.io/scrape: "true" +``` + +Для того чтобы поды смогли пересоздаться, придется вручную заскейлить +деплоймент до одной реплики + +```bash +kubectl scale deployment -n ingress-nginx --replicas=1 ingress-nginx-controller +``` + +Дождаться когда одна реплика обновится и после этого заскейлить обратно до двух реплик. + +* Обновляем настройки Prometheus + +Ingress-controller отдает в Prometheus метрику с общим количеством запросов, а не за промежуток времени. В то же время HPA не умеет работать с функциями для обработки метрик Prometheus, поэтому нам необходимо дописать в Prometheus `recording rule` для получения нужной нам метрики. + +Для этого получаем текущие значения Helm values для запущенного у нас Prometheus + +```bash +helm get values --all prometheus -n monitoring > values.yaml +``` + +Далее находим в файле `rules: {}` и заменяем на правило: + +```yaml +rules: + groups: + - name: Ingress + rules: + - record: nginx_ingress_controller_requests_per_second + expr: rate(nginx_ingress_controller_requests[5m]) +``` + +Не забудьте убрать пустой словарь `(скобки {})` после rules. + +Применяем изменения, для этого выполним команду: + +```bash +helm upgrade --install prometheus stable/prometheus --namespace monitoring -f values.yaml +``` + +После применения изменений в Prometheus появится новая метрика с именем `nginx_ingress_controller_requests_per_second`. + +Проверяем, что метрика `nginx_ingress_controller_requests_per_second` доступна через kube-api. + +Prometheus `начинает считать` данную метрику только после прохождения трафика через Ingress. Поэтому выполним несколько тестовых запросов, повторив 2-3 раза команду: + +```bash +curl -I hpa-v2-test..nip.io +``` + +Теперь проверим доступность метрики `nginx_ingress_controller_requests_per_second` через kube-api. Для этого выполним команду: + +```bash +kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | grep nginx_ingress_controller_requests_per_second +``` + +В результате выполнения этой команды на экран будет выведено: `nginx_ingress_controller_requests_per_second`. + +**3. Создаем HPA** + +Осталось добавить в кластер объект типа HPA. Важной особенностью HPA является то, что он не является cluster-wide, проще говоря он может взаимодействовать с Deployment только в том же namespace. Манифест для HPA уже подготовлен, и теперь его необходимо применить в кластер. Для этого выполните команду: + +```bash +kubectl apply -f deploy/hpa-v2.yml -n default +``` + +Проверяем, что манифест применился, для этого выполним команду: + +```bash +kubectl get hpa -n default +``` + +В результате выполнения этой команды на экран будет выведен список всех объектов типа HPA. В списке должен присутствовать HPA с именем: `hpa-v2-test`. + +**4. Тестирование работы HPA** + +* Создаем тестовую нагрузку + +Для создания тестовой нагрузки будем использовать утилиту wrk из текущего каталога. Для запуска выполним команду: + +```bash +./wrk -c 5 -t 2 -d 15m --latency http://hpa-v2-test..nip.io +``` + +* Проверка результата + +Через 5-10 минут (в другой консоли) проверьте, что HPA успешно отработал и Pod стало больше. Для этого выполните команду: + +```bash +kubectl get po -n default +``` + +Количество Pod `hpa-v2-test-XXX` должно было увеличиться. + +* Отключаем тестовую нагрузку + +Для отключения тестовой нагрузки в консоли, где запущен wrk, выполните: `CTRL + C`. + +Обратите внимание, что количество Pod уменьшится не сразу после прекращения нагрузки. Это связано с тем, что HPA производит scale down не сразу, что бы избежать ситуации, когда нагрузка находится у пороговых значений. Количество Pod будет уменьшено в течение нескольких минут. + +**5. Чистим за собой кластер** + +```bash +kubectl delete all --all -n default +kubectl delete apiservice v1beta1.custom.metrics.k8s.io +kubectl delete ns monitoring +``` + +#### Troubleshooting + +* Проверяем, что Prometheus запущен + +```bash +kubectl get po -n monitoring +``` + +Эта команда выведет данные о всех Pod в namespace monitoring. Все Pod должны быть в состоянии `STATUS: Running` и `READY 1/1` или `READY 2/2` в зависимости от количества контейнеров в Pod. Если какие-то Pod не в этом состоянии, стоит повторить команду через 1-2 минуты. Если что-то не работает, надо смотреть причину: `kubectl describe po -n monitoring `. Часто причина заключается в нехватке ресурсов, в этом случае необходимо удалить абстракции прошлых практик. + +* Проверяем, что метрики доступны + +!Перед проверкой доступности метрики необходимо выполнить несколько запросов к приложению.! + +```bash +kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | grep nginx_ingress_controller_requests_per_second +``` + +В результате выполнения этой команды на экран будет выведено: `nginx_ingress_controller_requests_per_second`. + +Если метрики недоступны, проверяем наличие и корректность добавления правил в Prometheus. Пункт 3. + +#### Полезные ссылки + +1. [k8s doc: HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) +2. [github: HPA](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md) diff --git a/practice/17.hpa/02.hpa_v2/deploy/deployment.yml b/practice/17.hpa/02.hpa_v2/deploy/deployment.yml new file mode 100644 index 0000000..3d1e630 --- /dev/null +++ b/practice/17.hpa/02.hpa_v2/deploy/deployment.yml @@ -0,0 +1,24 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + creationTimestamp: null + labels: + app: hpa-v2-test + name: hpa-v2-test +spec: + replicas: 1 + selector: + matchLabels: + app: hpa-v2-test + strategy: {} + template: + metadata: + creationTimestamp: null + labels: + app: hpa-v2-test + spec: + containers: + - image: nginx:1.13 + name: nginx + resources: {} +status: {} diff --git a/practice/17.hpa/02.hpa_v2/deploy/hpa-v2.yml b/practice/17.hpa/02.hpa_v2/deploy/hpa-v2.yml new file mode 100644 index 0000000..519ed4b --- /dev/null +++ b/practice/17.hpa/02.hpa_v2/deploy/hpa-v2.yml @@ -0,0 +1,25 @@ +--- +apiVersion: autoscaling/v2beta2 +kind: HorizontalPodAutoscaler +metadata: + name: hpa-v2-test +spec: + scaleTargetRef: + apiVersion: apps/v1 + kind: Deployment + name: hpa-v2-test + minReplicas: 1 + maxReplicas: 10 + metrics: + - type: Object + object: + metric: + name: nginx_ingress_controller_requests_per_second + describedObject: + apiVersion: networking.k8s.io/v1 + kind: Ingress + name: hpa-v2-test + target: + type: AverageValue + averageValue: 10 +... diff --git a/practice/17.hpa/02.hpa_v2/deploy/ingress.yml b/practice/17.hpa/02.hpa_v2/deploy/ingress.yml new file mode 100644 index 0000000..21c714d --- /dev/null +++ b/practice/17.hpa/02.hpa_v2/deploy/ingress.yml @@ -0,0 +1,18 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: hpa-v2-test +spec: + rules: + - host: hpa-v2-test..nip.io + http: + paths: + - pathType: Prefix + path: / + backend: + service: + name: hpa-v2-test + port: + number: 80 +... diff --git a/practice/17.hpa/02.hpa_v2/wrk b/practice/17.hpa/02.hpa_v2/wrk new file mode 100755 index 0000000..dae9551 Binary files /dev/null and b/practice/17.hpa/02.hpa_v2/wrk differ diff --git a/practice/17.hpa/README.md b/practice/17.hpa/README.md new file mode 100644 index 0000000..d33bfc8 --- /dev/null +++ b/practice/17.hpa/README.md @@ -0,0 +1,5 @@ +#### Список практических работ + +[1. HPA v1](01.hpa_v1/README.md) + +[2. HPA v2](02.hpa_v2/README.md)