утащил к себе

Ну уж тогда для полного эффекта спрошу
А это чем поможет?

по дефолту в сертификате есть DNS "kubernetes". На любом клиенте который будет резолвить "kubernetes" => твой новый ip apiserver, будет работать коннект с apiserver

Вот спасибо. Теперь пойду изучать хардвэй

Ребятушки, подскажите кто как деплоит новую версию приложения и при этом поддерживается принцип infrastructure as a code

у меня kustomize используется, в одном репозитории описано все приложения для всех environment, но вот когда собирается новая версия приложения, она обновляется просто обновлением имеджа в кубере
и получается репозиторий с kustomize как бы всегда устаревает по версии имеджа

Придерживаюсь следующей практики:

Отдельно происходит релиз дистрибутива приложения с docker-имаджами и helm-чартом конкретной версии.

И отдельный репо для деплоя этого приложения в кластер, а то и в несколько, где описанны все параметры специфичные для конкретного энвайромента😉

тоесть у тебя следующий пайплайн при обновлении кода
- сборка и регистрация имеджа
- сборка и регистрация helm chart
-  деплой нового хелм чарта ?

Народ, а кто с dex-k8s-auth ковырялся, подскажите плз.
Установил сам 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 параметры, или это прявлялось бы по другому?

Ну у нас схема ещё далека от идеала, так что опишу к чему стремлюсь:

В одном репо ведётся разработка приложения, пайплайн там такой (стреляет на создание тэга):
- юнит-тесты
- сборка и пуш докер-имаджа
- сборка и пуш helm-чарта
- возможно деплой в тестовый кластер и запуск интеграционные тестов
- создание релиза

Отдельный репо для деплоя в кластер.
Пайплайн в принципе не нужен, т.к. можно воспользоваться какой-нибудь GitOps-тулзой: ArgoCD или FluxCD.
Стреляет при пуше в master или в ветку конуретного окружения staging / production.

Ты кьюб апи параметры менял?

Через терраформ

да, я ж написал.
В терраформе это выглядит как

resource "scaleway_k8s_cluster" "john" {
...
  open_id_connect_config {
    issuer_url      = "https://dex.domain.com”
    client_id       = "k8s-scaleway-staging”
    username_claim  = "email"
    groups_claim    = ["groups"]
  }
}

resource "scaleway_k8s_cluster" "john" {
...
  open_id_connect_config {
    issuer_url      = "https://dex.domain.com”
    client_id       = "k8s-scaleway-staging”
    username_claim  = "email"
    groups_claim    = ["groups"]
  }
}

Что-то не то

Oidc привязка к kubernetes api выглядит по-другому, не ?

Или может так, но параметры точно верные? Посмотри на подход banzai-cloud - они вообще хитро сделали

Объединили dex и сервисные учетки (они по сути он деманд создаются)

у них сейчас скидка 50% на beta.kodekloud. Если нужен купон, пишите

ну в доке это выглядит так во всяком случае.