i
Но тут конечно организация базы такая в наследство досталось
Size: a a a
2020 September 24
i
Но в целом - исполнение кода даже на фоне сходить в сеть обычно малозаметно, если не числодробилка
i
А в питоне числодробилки на C
k
один из вариантов это cluster-mesh, второй вариант - запускать вебхуки с
hostNetwork: true а аписервер с --enable-aggregator-routing=trueКажется я нашёл смешную третью опцию
https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/
https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/
i
Может я тупой, но не понял зачем это
i
Кастомерам и так можно https давать аписервера
i
Или чтобы ноды без сертов что ли ходили
k
Может я тупой, но не понял зачем это
Это для control-plane to nodes communication
GG
Это для control-plane to nodes communication
??///
GG
ты слишком умный
i
Это для control-plane to nodes communication
Нет, общую суть я конечно уловил - остался вопрос зачем
k
Нет, общую суть я конечно уловил - остался вопрос зачем
Ну в моём случае api-server запускается в отдельном от нод в кластере и как следствие вебхуки не работают, мне нужно пофиксить как-то.
Полагаю что Konnectivity как раз решит эту задачу, т.к. спроксирует все запросы от api-server непосредственно в кластер
Полагаю что Konnectivity как раз решит эту задачу, т.к. спроксирует все запросы от api-server непосредственно в кластер
GG
Ну в моём случае api-server запускается в отдельном от нод в кластере и как следствие вебхуки не работают, мне нужно пофиксить как-то.
Полагаю что Konnectivity как раз решит эту задачу, т.к. спроксирует все запросы от api-server непосредственно в кластер
Полагаю что Konnectivity как раз решит эту задачу, т.к. спроксирует все запросы от api-server непосредственно в кластер
а веб-хуки ходят в поды ?
i
Ну в моём случае api-server запускается в отдельном от нод в кластере и как следствие вебхуки не работают, мне нужно пофиксить как-то.
Полагаю что Konnectivity как раз решит эту задачу, т.к. спроксирует все запросы от api-server непосредственно в кластер
Полагаю что Konnectivity как раз решит эту задачу, т.к. спроксирует все запросы от api-server непосредственно в кластер
так хуки апи-сайд
GG
а зачем ? почему их эндпойнты не на самом апи сервере держать ?
i
апи-то какая разница, прогнал запрос через хуки, получил результат (если все таки хуки без контроллеров запускаемых в другом месте) ну и что-то сделал или не сделал
k
а веб-хуки ходят в поды ?
по умолчанию вебхуки ходят из api-server'а на ClusterIP.
Если на сервере на котором запущен api-server нету kube-proxy (ака сервисы не работают), предусмотрен флаг
Проблема в том что в моём случае apiserver вообще запущен в отдельном кластере а достучаться до подов мне как-то надо.
Если на сервере на котором запущен api-server нету kube-proxy (ака сервисы не работают), предусмотрен флаг
--enable-aggregator-routing=true, который заставляет apiserver стучаться напрямую в эндпоинты сервисов.Проблема в том что в моём случае apiserver вообще запущен в отдельном кластере а достучаться до подов мне как-то надо.
i
Он все равно только с etcd работает
k
Как вариант вывешивать вебхуки с
hostNetwork: true и заставить apiserver ходить на эндпоинты, но хочется сделать более универсальноi
по умолчанию вебхуки ходят из api-server'а на ClusterIP.
Если на сервере на котором запущен api-server нету kube-proxy (ака сервисы не работают), предусмотрен флаг
Проблема в том что в моём случае apiserver вообще запущен в отдельном кластере а достучаться до подов мне как-то надо.
Если на сервере на котором запущен api-server нету kube-proxy (ака сервисы не работают), предусмотрен флаг
--enable-aggregator-routing=true, который заставляет apiserver стучаться напрямую в эндпоинты сервисов.Проблема в том что в моём случае apiserver вообще запущен в отдельном кластере а достучаться до подов мне как-то надо.
Хм, а куда ходит аписервер?