k
На самом деле там даже два оператора - один для cilium, второй для etcd 🙈
Size: a a a
2021 March 30
DS
На самом деле там даже два оператора - один для cilium, второй для etcd 🙈
ну etcd-operator я бы не советовал, да и разрабы не советуют =)
DS
причем там cilium-etcd-operator, который деплоет etcd-operator, который деплоет etcd
c
Народ, а кто с dex-k8s-auth ковырялся, подскажите плз.
Установил сам Dex, связал с LDAP-ом, все работает нормально, example-app авторизуется, показывает группы, все ок.
далее деплою в куб dex-k8s-authenticator, его связываю с настроенным раннее Dex-ом, для kube-api прописываю oidc ключи как в доке.
Тут проблема в том, что это managed кластер Scaleway, и к kube-api у меня доступа нет, ни к логам, ни к процессам.
Но поскольку терраформом все заезжает, предполагаю что должно работать.
Далее, браузером иду на опубликованный dex-k8s-authenticator, успешно авторизуюсь, он корректно генерит мне kubeconfig.
Проблема только в том, что с этим конфигом не пускает сам куб, с ошибкой
Повторяюсь, к логам kube-api доступа у меня нет.
Чисто логически проблема может быть с тем, что kube-api таки не получил OIDC параметры, или это прявлялось бы по другому?
Установил сам Dex, связал с LDAP-ом, все работает нормально, example-app авторизуется, показывает группы, все ок.
далее деплою в куб dex-k8s-authenticator, его связываю с настроенным раннее Dex-ом, для kube-api прописываю oidc ключи как в доке.
Тут проблема в том, что это managed кластер Scaleway, и к kube-api у меня доступа нет, ни к логам, ни к процессам.
Но поскольку терраформом все заезжает, предполагаю что должно работать.
Далее, браузером иду на опубликованный dex-k8s-authenticator, успешно авторизуюсь, он корректно генерит мне kubeconfig.
Проблема только в том, что с этим конфигом не пускает сам куб, с ошибкой
"error: You must be logged in to the server (Unauthorized)”.Повторяюсь, к логам kube-api доступа у меня нет.
Чисто логически проблема может быть с тем, что kube-api таки не получил OIDC параметры, или это прявлялось бы по другому?
докладываю, я накосячил с client_id который несовпадал в настройках декса и куба.
Сам замыленным глазом не увидел, пошел в саппорт облака Scaleway, они меня перенаправили в слаку, где почему-то есть инженеры с доступом к логам. Что этим же инженерам мешает отвечать в тикеты - непонятно.
Ну а в слаке быстро помогли.
Сам замыленным глазом не увидел, пошел в саппорт облака Scaleway, они меня перенаправили в слаку, где почему-то есть инженеры с доступом к логам. Что этим же инженерам мешает отвечать в тикеты - непонятно.
Ну а в слаке быстро помогли.
k
причем там cilium-etcd-operator, который деплоет etcd-operator, который деплоет etcd
знатно упоролись
DS
Продакшн решение
ага. Этот костыль с 1.14 по 1.19 успешно выполнял свою задачу. kube-proxy не успевал запускаться =). благо поправили, он меня всегда смущал, но что поделать, опенсурс он такой
k
BTW, вчера с @gecube затронули интересную тему, так как я не смог собрать достаточное количество аргументов для принятия хоть какого-то решения, то предлагаю вынести вопрос и собрать мнение общественности.
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
GG
А аписервер норм с хедлес сервисом етсд работает ?
GG
Я просто не проверял
k
А аписервер норм с хедлес сервисом етсд работает ?
Да, без проблем вообще. Как и etcdctl, идёт на рандомный эндпоинт
DS
BTW, вчера с @gecube затронули интересную тему, так как я не смог собрать достаточное количество аргументов для принятия хоть какого-то решения, то предлагаю вынести вопрос и собрать мнение общественности.
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
etcdclient же должен сам знать все endpoints. А с headles сервисом он зарезолвит ип адрес в конкретный под и будет ходить только в него
DS
BTW, вчера с @gecube затронули интересную тему, так как я не смог собрать достаточное количество аргументов для принятия хоть какого-то решения, то предлагаю вынести вопрос и собрать мнение общественности.
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
Имеется Kubernetes и кластер etcd, оба запускаются в другом Kubernetes, соответсвенно мы имеем service discovery, балансировку и другие фишки куба прямо из коробки.
Вопрос в следующем:
Как лучше сконфигурить apiserver для доступа к etcd? То есть статично передать список эндпоинтов или скормить ему headless-сервис?
Готов выслушать аргументы "за" и "против"
третий вариант. Запилить entrypoint, который через dns srv будет вытаскивать все endpoint'ы из headles сервиса и проставит их в etcdserver
GG
третий вариант. Запилить entrypoint, который через dns srv будет вытаскивать все endpoint'ы из headles сервиса и проставит их в etcdserver
Зачем ?
GG
Я хочу автоскейл етсд
DS
Я хочу автоскейл етсд
Автоскейл etcd? Он же не скейлится. Ну мб на чтение чутка, и то не факт (не проверял). Да и для автоскейла тебе придется изрядно попотеть, либо оператор, либо умный entrypoint, что сможет серты и ключи сгенерить и endpoint сущсетвующие найти и так далее
GG
Ну, и речь не про етсд сервер сам, а про то как клиенты в него ходить будут
k
etcdclient же должен сам знать все endpoints. А с headles сервисом он зарезолвит ип адрес в конкретный под и будет ходить только в него
Я может чего-то непонимаю, но 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
GG
Я может чего-то непонимаю, но 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
Все правильно
GG
Клиент может их вынуть и сам внутри себя сделать балансировку
DS
Я может чего-то непонимаю, но 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
угу, и получается твой клиент возьмет один из них