Кластерный автоскалер не уменьшает масштаб - PullRequest
Новая
       5

Кластерный автоскалер не уменьшает масштаб

0 голосов
/ 04 июня 2018

У меня настроен региональный кластер в google kubernetes engine (GKE) .Группа узлов - это один vm в каждом регионе (всего 3) .У меня есть развертывание с 3 минимальными репликами , управляемыми HPA.Группа узлов настроена на автоматическое масштабирование (автоматическое масштабирование кластера или CA).Сценарий проблемы:

Обновление образа развертывания.Kubernetes автоматически создает новые модули и CA определяет, что нужен новый узел.Теперь у меня 4. Старые модули удаляются после запуска всех новых модулей, что означает, что у меня точно такой же запрос ЦП, как и предыдущей минутой.Но после 10-минутного максимального времени сокращения у меня все еще есть 4 узла.

Запросы ЦП для узлов теперь: 

CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  358m (38%)    138m (14%)  516896Ki (19%)   609056Ki (22%)
--
  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  800m (85%)    0 (0%)      200Mi (7%)       300Mi (11%)
--
  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  510m (54%)    100m (10%)  410Mi (15%)      770Mi (29%)
--
  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ------------  ----------  ---------------  -------------
  823m (87%)    158m (16%)  484Mi (18%)      894Mi (33%)

Узел 38% работает: 

Namespace                  Name                                                            CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                  ----                                                            ------------  ----------  ---------------  -------------
  kube-system                event-exporter-v0.1.9-5c8fb98cdb-8v48h                          0 (0%)        0 (0%)      0 (0%)           0 (0%)
  kube-system                fluentd-gcp-v2.0.17-q29t2                                       100m (10%)    0 (0%)      200Mi (7%)       300Mi (11%)
  kube-system                heapster-v1.5.2-585f569d7f-886xx                                138m (14%)    138m (14%)  301856Ki (11%)   301856Ki (11%)
  kube-system                kube-dns-autoscaler-69c5cbdcdd-rk7sd                            20m (2%)      0 (0%)      10Mi (0%)        0 (0%)
  kube-system                kube-proxy-gke-production-cluster-default-pool-0fd62aac-7kls    100m (10%)    0 (0%)      0 (0%)           0 (0%)

Я подозреваю, что это не уменьшит масштаб, потому что heapster или kube-dns-autoscaler.Но в модуле 85% содержится: 

Namespace                  Name                                                            CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                  ----                                                            ------------  ----------  ---------------  -------------
  kube-system                fluentd-gcp-v2.0.17-s25bk                                       100m (10%)    0 (0%)      200Mi (7%)       300Mi (11%)
  kube-system                kube-proxy-gke-production-cluster-default-pool-7ffeacff-mh6p    100m (10%)    0 (0%)      0 (0%)           0 (0%)
  my-deploy                  my-deploy-54fc6b67cf-7nklb                                      300m (31%)    0 (0%)      0 (0%)           0 (0%)
  my-deploy                  my-deploy-54fc6b67cf-zl7mr                                      300m (31%)    0 (0%)      0 (0%)           0 (0%)

Подушки fluentd и kube-proxy присутствуют на каждом узле, поэтому я предполагаю, что они не нужны без узла.Это означает, что мое развертывание может быть перенесено на другие узлы, так как запрос имеет только 300 м (31%, поскольку только 94% процессорного узла узла может быть выделено).

Поэтому я решил, что я проверю журналы.Но если я запускаю kubectl get pods --all-namespaces, то в GKE для CA нет видимых модулей.И если я использую команду kubectl get configmap cluster-autoscaler-status -n kube-system -o yaml, она только скажет мне, собирается ли она масштабироваться, а не почему или почему нет.Другой вариант - посмотреть на /var/log/cluster-autoscaler.log в главном узле.Я SSH: редактировал во всех 4 узлах и нашел только файл gcp-cluster-autoscaler.log.pos, который говорит: /var/log/cluster-autoscaler.log 0000000000000000 0000000000000000, то есть файл должен быть прямо там, но пуст.Последний вариант, согласно FAQ , заключается в проверке событий для модулей, но, насколько я могу судить, они пусты.

Кто-нибудь знает, почему он не уменьшает или, по крайней мере, где найтижурналы?

Ответы [ 2 ]

0 голосов
/ 18 июня 2018

Отвечаю за видимость.

Проблема заключается в том, что ЦС никогда не рассматривает возможность перемещения чего-либо, если все требования, упомянутые в FAQ , не выполнены одновременно.Допустим, у меня 100 узлов с 51% запросов к процессору.Он по-прежнему не учитывает масштабирование.

Одним из решений является увеличение значения, при котором CA проверяет, теперь 50%.Но, к сожалению, это не поддерживается GKE, см. Ответ службы поддержки Google @GalloCedrone:

Более того, я знаю, что это значение может показаться слишком низким, и кому-то может быть интересно сохранить также 85% или 90%.%, чтобы избежать вашего сценария.В настоящее время существует открытый запрос функции, чтобы дать пользователю возможность изменить флаг «--scale-down-utilization-threshold», но он еще не реализован.

Обходное решение, которое я обнаружил, -чтобы уменьшить запрос ЦП (100 м вместо 300 м) модулей и сделать так, чтобы горизонтальный модуль автоматического масштабирования (HPA) создавал больше по требованию.Это хорошо для меня, но если ваше приложение не подходит для многих небольших случаев, вам не повезло.Возможно, задание cron, которое блокирует узел, если общее использование низкое?

0 голосов
/ 13 июня 2018

Я согласен, что согласно Документации кажется, что "gke-name-cluster-default-pool" можно безопасно удалить, условия:

  • Сумма процессора иЗапросы памяти всех модулей, работающих на этом узле, составляют менее 50% от выделенного узла.
  • Все модули, работающие на узле (кроме тех, которые запускаются на всех узлах по умолчанию, например, модули манифеста или модули, созданные наборами демонов) могут быть перемещены на другие узлы.
  • У него нет отключенной аннотации с уменьшением масштаба. Поэтому его следует удалить через 10 минут, поскольку он считается ненужным.

Однако, проверяя документацию Я обнаружил:

Какие типы модулей могут помешать CA удалить узел?

[...] Системные модули Kube, которые по умолчанию не запускаются на узле, * [..]

heapster-v1.5.2 --- работает на узле и является Kube-системный модуль, который не запускается на узле по умолчанию.

Я обновлю ответ, если найду более интересную информацию.

ОБНОВЛЕНИЕ

Тот факт, что это последний узел в зоне, не является проблемой.

Чтобы доказать это, я протестировал на совершенно новом кластере с 3 узлами каждый в другой зоне, один из которых был без какой-либо рабочей нагрузки, кроме "kube-proxy" и "fluentd" и был правильно удален, даже еслиэто сводило размер зоны к нулю.

...