Как решить, почему конечные точки в моем сервисе не обновляются?

Question

У меня работает кластер Kubernetes на Google Kubernetes Engine.

У меня есть развертывание, которое я вручную (с помощью редактирования объекта hpa) увеличил с 100 до 300, чтобы выполнить нагрузочное тестирование. Когда я тестировал развертывание путем отправки HTTP-запросов в службу, казалось, что не все модули получают одинаковый объем трафика, только около 100 модулей показывают, что они обрабатывают трафик (глядя на загрузку процессора и наши пользовательские метрики). Поэтому я подозреваю, что служба не распределяет нагрузку между запросами одинаково.

Если я проверил deployment, я мог видеть, что все 300 реплик были готовы.

$ k get deploy my-app --show-labels
NAME                DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       LABELS
my-app              300       300       300          300         21d       app=my-app

С другой стороны, когда я проверил service, я увидел это:

$ k describe svc my-app
Name:              my-app
Namespace:         production
Labels:            app=my-app
Selector:          app=my-app
Type:              ClusterIP
IP:                10.40.9.201
Port:              http  80/TCP
TargetPort:        http/TCP
Endpoints:         10.36.0.5:80,10.36.1.5:80,10.36.100.5:80 + 114 more...
Port:              https  443/TCP
TargetPort:        https/TCP
Endpoints:         10.36.0.5:443,10.36.1.5:443,10.36.100.5:443 + 114 more...
Session Affinity:  None
Events:            <none>

Что было для меня странным, так это часть

Endpoints:         10.36.0.5:80,10.36.1.5:80,10.36.100.5:80 + 114 more...

Я ожидал увидеть там 300 конечных точек, верно ли это предположение?

(я также нашел в этом посте , что касается аналогичной проблемы, но там автор испытывал задержку всего на несколько минут до обновления конечных точек, но для меня это не изменилось даже в полчаса.)

Как я могу решить, что происходит не так? Я прочитал, что это делается контроллером конечных точек, но я не смог найти никакой информации о том, где проверить его журналы.

Обновление : Нам удалось воспроизвести это еще пару раз. Иногда это было менее серьезно, например, 381 конечная точка вместо 445. Одна интересная вещь, которую мы заметили, заключается в том, что, если мы получим детали конечных точек:

$ k describe endpoints my-app
Name:         my-app
Namespace:    production
Labels:       app=my-app
Annotations:  <none>
Subsets:
  Addresses:          10.36.0.5,10.36.1.5,10.36.10.5,...
  NotReadyAddresses:  10.36.199.5,10.36.209.5,10.36.239.2,...

Тогда несколько IP-адресов были «застряли» в состоянии NotReadyAddresses (не те, которые «отсутствовали» в службе, хотя, если я суммировал количество IP-адресов в Addresses и NotReadyAddresses, это было еще меньше, чем общее количество готовых стручков). Хотя я не знаю, связано ли это вообще, я не смог найти много информации в Интернете об этом NotReadyAddresses поле.

Answer 1

Оказалось, что это вызвано использованием вытесняемых виртуальных машин в наших пулах узлов, и это не происходит, если узлы не являются преемблируемыми.
Мы не могли выяснить более подробную информацию о первопричине, но использование предикторов в качестве узлов в любом случае не является официально поддерживаемым сценарием, поэтому мы переключились на обычные виртуальные машины.

Answer 2

Я имею в виду вашу первую попытку с 300 стручками.

Я бы проверил следующее:

• kubectl get po -l app=my-app, чтобы увидеть, если вы получите список 300 предметов. Ваш сервис сообщает, что у вас есть 300 доступных модулей, что делает вашу проблему очень интересной для анализа.

• определил ли ваш модуль / манифест развертывания лимит и запрашивать ресурсы. В этом лучше помогает планировщик.

• есть ли какие-то порты на ваших узлах, несовместимые с вашим пакетом / манифестом развертывания

• есть ли в вашем манифесте модуля / развертывания датчики живучести и готовности (опубликуйте их)

• определен ли какой-либо объект resourceQuota, который ограничивает создание модулей / развертываний