не смог собрать достаточное количество аргументов для принятия хоть какого-то решения, то предлагаю вынести вопрос и собрать мнение общественности.
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
etcdclient же должен сам знать все endpoints. А с headles сервисом он зарезолвит ип адрес в конкретный под и будет ходить только в него
третий вариант. Запилить entrypoint, который через dns srv будет вытаскивать все endpoint'ы из headles сервиса и проставит их в etcdserver
Я может чего-то непонимаю, но dns возвращает сразу три адреса: / # nslookup generic-kubernetes-etcd Server: 10.96.0.10 Address: 10.96.0.10#53 Name: generic-kubernetes-etcd.kubefarm-generic.svc.cluster.local Address: 10.112.1.49 Name: generic-kubernetes-etcd.kubefarm-generic.svc.cluster.local Address: 10.112.1.99 Name: generic-kubernetes-etcd.kubefarm-generic.svc.cluster.local Address: 10.112.1.190
угу, и получается твой клиент возьмет один из них
Так не выйдет кстати, куб добавляет эндпоинты headless-сервиса только те поды, которые Ready, если не проставлено publishNotReadyAddresses: true
И в srv тоже? Ну можно kubectl'ом достать на крайняк
Судя по документу https://etcd.io/docs/v3.4/learning/design-client/ (есть тонкости в зависимости от версии клиента), лучше всего список эндпойнтов. Но headless сервис тоже подойдет, потому что при ошибке клиент заново слукапит эндпойнты, заодно ответ на вопрос: что делать, когда ip адреса подов etcd поменяются-ничего не делать, все предусмотрено.
Обсуждают сегодня