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

Question

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

> 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 происходит слишком быстро, кажется, что сокет не может соединиться, и я получаю тайм-аут соединения.

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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