Готовность-Зонд другой Сервис по загрузке Pod - PullRequest
Новая
       62

Готовность-Зонд другой Сервис по загрузке Pod

0 голосов
/ 11 июля 2019

На моей установке Kubernetes у меня есть 2 службы - A и B.
Служба B зависит от того, была ли запущена служба A.Теперь я хотел бы установить датчик готовности TCP в модулях службы B, чтобы они проверяли, работает ли какая-либо часть службы A.

раздел ReadinessProbe развертывания в службе B выглядит следующим образом: 

readinessProbe:
  tcpSocket:
    host: serviceA.mynamespace.svc.cluster.local
    port: 1101 # same port of Service A Readiness Check

Я могу применить эти изменения, но пробник готовности не работает с: 

Readiness probe failed: dial tcp: lookup serviceB.mynamespace.svc.cluster.local: no such host

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

Есть ли у кого-нибудь идея заставить готовность работать для другого сервиса или сделать какой-то другой вид проверки зависимостей между сервисами?Спасибо:)

1 Ответ

0 голосов
/ 18 июля 2019

В связи с тем, что показатели готовности и жизнедеятельности зонды полностью управляются kubelet агентом узла, а kubelet наследует службу обнаружения DNS от конкретной конфигурации узла, вы не можете разрешить внутренний сервер имен K8s DNS записи:

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

Вы можете рассмотреть сценарий, когда ваш источник Pod A потребляет IP-адрес узла, передавая параметр hostNetwork: true, таким образом, kubelet может достичь и успешно проверить готовность изнутри Pod B , как описано в официальной документации k8s : 

tcpSocket:
  host: Node Hostname or IP address where Pod A residing
  port: 1101

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

...