Autoscaler не масштабируется, оставляя узлы в состоянии NotReady и модули в неизвестном состоянии - PullRequest
Новая
       7

Autoscaler не масштабируется, оставляя узлы в состоянии NotReady и модули в неизвестном состоянии

0 голосов
/ 10 октября 2018

Я запускаю кластер на GKE с одним пулом узлов.Он имеет 3 узла и может масштабироваться от 1 до 99 узлов.В кластере используется контроллер nginx-ingress

. В этом кластере я хочу развернуть apps . приложение ограничено пространством имен и состоит из 3 deployments и одного ingress (определяющего пути доступа к приложению из Интернета).Каждое развертывание запускает одну реплику контейнера.

Развертывание нескольких приложений работает нормально, но развертывание многих приложений (требующих увеличения пула узлов) разбивает все:

Все модули начинают получать предупреждения (включая те, которые были успешно развернуты ранее) 

kubectl get pods --namespace bcd
NAME                       READY     STATUS    RESTARTS   AGE
actions-664b7d79f5-7qdkw   1/1       Unknown   1          35m
actions-664b7d79f5-v8s2m   1/1       Running   1          18m
core-85cb74f89b-ns49z      1/1       Unknown   1          35m
core-85cb74f89b-qqzfp      1/1       Running   1          18m
nlu-77899ddbf-8pd7k        1/1       Running   1          27m

Все узлы становятся не готовыми : 

kubectl get nodes
NAME                                              STATUS     ROLES     AGE       VERSION
gke-clients-projects-default-pool-f9af73d4-gzwr   NotReady   <none>    42m       v1.9.7-gke.6
gke-clients-projects-default-pool-f9af73d4-p5l2   NotReady   <none>    21m       v1.9.7-gke.6
gke-clients-projects-default-pool-f9af73d4-wnxc   NotReady   <none>    37m       v1.9.7-gke.6

Удаление пространства имен для удалениявсе ресурсы кластера также перестают работать, поскольку через некоторое время модули остаются активными, но все еще находятся в неизвестном состоянии.

Как можно безопасно добавить дополнительные приложения и разрешить автоматическое масштабирование кластера?

1 Ответ

0 голосов
/ 11 октября 2018

Причина, по-видимому, заключается в том, что, не зная ресурсов, необходимых для каждого модуля, планировщик планирует их на любом доступном узле, потенциально истощая доступные ресурсы и переводя демон Docker в несогласованное состояние.

Решение заключается в том,указать ресурсы запросов и лимиты: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container

...