Как узнать, что сервис Kubernetes готов после развертывания развертывания?

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

> kubectl create -f my-deployment.yaml
> kubectl create -f my-service.yaml
> kubectl rollout status deployment/my-deployment --watch --timeout 10m # This usually takes ~30 seconds

deployment "my-deployment" successfully rolled out

> curl "my-service" # This happens inside a pod, so the service DNS name should be available

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

Это похоже на поведение, которое я получил бы, если бы не было готовых модулей, согласно этому вопросу: Что происходит, когда служба получает запрос, но не имеет готовых модулей?

Я ожидал, что завершение развертывания означает гарантированную готовность сервиса к работе. Разве это не так? Есть ли какая-нибудь команда Kubernetes, чтобы «ждать» доступности сервиса? (Я заметил, что у сервисов нет условий, поэтому вы не можете делать _3 _...)


kubernetes kubernetes-deployment kubernetes-service
person tom    schedule 13.01.2020    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Чтобы узнать, готова ли служба, вы можете проверить, существует ли объект конечных точек с именем службы и имеет ли этот объект конечной точки IP-адреса или нет. Если IP есть, значит сервис готов. Но нет никакой гарантии, что он все равно не выйдет из строя, потому что в вашей инфраструктуре может возникнуть проблема с сетью.

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

Например, во время развертывания скользящего обновления готовится новый модуль. С другой стороны, служба, сетевая политика и балансировщик нагрузки еще не готовы для нового модуля по какой-либо причине (например, из-за медленной работы оборудования api, контроллера конечных точек, kube-proxy, iptables или программирования инфраструктуры). Это может вызвать нарушение работы службы или потерю серверной мощности. В крайних случаях, если последовательное обновление завершается до того, как какой-либо новый заменяющий модуль фактически начнет обслуживать трафик, это вызовет сбой в обслуживании.

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

person Arghya Sadhu    schedule 13.01.2020
comment
Вы уверены, что учитывается только то, созданы реплики или нет? По моему опыту запуска его с командой --watch кажется, что он ждет, пока модуль более или менее запустится. Я знаю, что он определенно ждет, когда, например, будут связаны постоянные требования тома модуля. Если у вас есть ссылка на его точное поведение, это будет полезно. Я знаком с зондами. Раньше я делал что-то вроде kubectl wait pod --label app=my-deployment-app --for=condition=ready. Вы хотите сказать, что ожидание такого состояния готовности модуля равносильно готовности службы? - person tom; 13.01.2020
comment
Не бери в голову первый вопрос. Я понимаю, что контейнер еще не создан, когда PVC все еще связывается. Итак, kubectl rollout status ждет, пока реплика будет создана, но не беспокоится о ее состоянии «Готово» или о чем-то еще. - person tom; 13.01.2020
comment
Я отредактировал свой ответ и добавил ссылку. Вкратце, состояние готовности модуля не будет эквивалентно готовности службы. - person Arghya Sadhu; 13.01.2020
comment
Понятно - что касается основного вопроса, то разве невозможно определить, готов ли сервис, используя обычные kubectl команды? (До этого предложения или чего-то подобного) - person tom; 13.01.2020
comment
Можете ли вы попробовать получить обслуживание и проверить, не пусты ли конечные точки - person Arghya Sadhu; 13.01.2020
comment
Хм, я могу попробовать. На этом этапе проще просто добавить логику повтора при подключении к службе. В любом случае, я думаю, что это в значительной степени отвечает на вопрос, поэтому я его принимаю. - person tom; 13.01.2020

arrow_upward
1
arrow_downward

Мой ответ немного отличается от того, о чем вы спрашиваете, но, вероятно, он будет вам полезен. Я предлагаю использовать Helm для улучшения процесса развертывания.

Чем это может вам помочь?

Helm имеет несколько флагов, например --wait что может быть применено во время обновления. Он убедится, что все ресурсы были успешно созданы, прежде чем двигаться дальше.

person Stepan Tsybulski    schedule 13.01.2020
comment
Спасибо, я знаком с Helm, и это интересное предложение. Я не хочу представлять Хельма в этом сценарии, но знаете ли вы, как Хелм это делает? (Учитывая, что выяснение этого в K8S кажется не полностью решенной проблемой - см. Это предложение из другого ответа: github.com/kubernetes/enhancements/blob/) - person tom; 13.01.2020