А, прямо плейнтекстом

Я подумал что это параметры для конфигмапы

параметры для конфигмапы можно передавать вот так: "config": ||| ksonnet.is=%s ksonnet.isalso=%s ||| % ["good", "interesting"],

вообще ктонить руками крутил coredns вне кубов?

@elvis_live а чего ты хочешь решить?

@elvis_live а чего ты хочешь решить?

мне делегировали зону на кластер. в сервисе вместе с externalIPs я указываю externalDNS или что то вроде. И тут происходит красота

В более простом мире - просто dns сервер, который у меня крутится кубе.

bind мне сильно не люб

нашел https://github.com/kubernetes-incubator/external-dns но пока не понял, то ли это что я хочу. пока читаю

а dnsmasq?

раньше dnsmasq укрощали, теперь из coredns'а dnsmasq хотят

а dnsmasq?

не практиковал

но есть мнение, что coredns лучше в дизайн ляжет

целевое - интегарция с сервисами

С CoreDNS можно метрики промом собирать из коробки, а файлы зон как у bind (надо помнить о SOA, в отличие от dnsmasq)

When using external-dns with ingress objects it will automatically create DNS records based on host names specified in ingress objects that match the domain-filter argument in the external-dns deployment manifest. When those host names are removed or renamed the corresponding DNS records are also altered.

Красота, но почему отдельные интеграции на каждое облако, пока не понимаю.

Если ты в публичных облаках - норм

Потому как облака не договорились об API ?

А если я внтури своей инфры. И делегируют мне зону то ли из бинда, то ли из AD (вообще темный лес)

ну кстати да, если очень хочется, то можно сделать одну env для пода CONFIG_VERSION, и при изменении конфига просто обновлять переменную в поде, тогда и поды будут перезапускаться и rolling update работать будет

Хеш от полей включить в имя конфигмапы

но есть мнение, что coredns лучше в дизайн ляжет

Когда-нибудь потом. dnsmasq уже сколько лет пилят, оно точно работает уже сейчас.

То ли дело бинд

Oh, wai~

bind тяжело

Так ли это? Давайте спросим мнение экспертов

Ну когда bind можно законфигурировать просто командной строкой, тогда будет легче :)

Ну ты же сам понимаешь что у бинда куча фич которых у того же днсмаск просто нету

Ну кому они нужны, тот пусть и ставит :) в kube DNS от него надо было пробросить запросы наверх или во внутренний skydns ну и кешировать чуток

попробал ksonnet теперь доволен как слон, @rossmohax спасибо за наводку

Осторожно, от этой заразы сложно отвыкнуть

Осторожно, от этой заразы сложно отвыкнуть

А зачем отвыкать? Уже даже самые простые манифесты на него перевел)

@rossmohax слушай, а как ты хранишь пароли?

vault?

Погляжу, спс

hashicorp vault i mean

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

Просто хочется их как-нибудь декларативно в ksonnet описывать, а хранить пароли в git - это моветон

https://github.com/Boostport/kubernetes-vault

@rossmohax слушай, а как ты хранишь пароли?

Я пошел простым путем - внутри gitlab

В идеале научить бы ksonnet туда ходить, аля: получил пароль в переменную, сгенерил секрет

Я пошел простым путем - внутри gitlab

Отдельным репо или в environments?

Просто хочется их как-нибудь декларативно в ksonnet описывать, а хранить пароли в git - это моветон

Но по-хорошему их надо gpg шифровать и в гит, а в CI расшифровывать

Кстати отличная идея!

В идеале научить бы ksonnet туда ходить, аля: получил пароль в переменную, сгенерил секрет

не надо так, пусть этим занимается управлялка сикретами

Но по-хорошему их надо gpg шифровать и в гит, а в CI расшифровывать

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

не надо так, пусть этим занимается управлялка сикретами

В таком случае возникает вопрос, как они в управлялку попадают

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

Через gpg можно для разных лиц шифровать же

Емнип pass так умеет

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

В gitlab есть ci раннеры, можно создать отдельные для прода, у них свой ключ

Через gpg можно для разных лиц шифровать же

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

Отдельным репо или в environments?

Settings -> CI/cd -> secret variables

В таком случае возникает вопрос, как они в управлялку попадают

почитай про hashicorp vault, он - управлялка сикретами и умеет авторизовывать поды кубеней

Так вопрос не откуда брать секреты в рантайме, а при деплое :)

В рантайме кубовые secrets вполне годятся (хотя может какой-нибудь серьезный аудит и не пройдут)

https://github.com/Boostport/kubernetes-vault

https://github.com/Boostport/kubernetes-vault

Вы отвечаете не на тот вопрос :)

тогда объясни, что такое "при деплое"?

Вот есть секрет - EV сертификат. Как и куда его :)

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

Значит pass будет попробовать все три

он может быть в Vault PKI, например

Нет, секрет внешний, ваулт сам его создать не может

точно?

Точно

ну раз ты так говоришь, значит так и есть

а например креденшлы для google bigtable - это "внешний" секрет или какой?

Внешний если , с Гуглом интеграции волта нет

сломали что ли?

вчера была

то есть "внешний" - если нет плагина для волта

ок

Не настроили, нет желания, кто нибудь отвечающий за гугол не разрешает. Если жизнь вообщем

для многого есть, но для многого, разумеется, нету

но это уже демагогия

Конечно нет. Дел много, рук всего N*2

Волт это еще одна критичная рантайм зависимость

разумеется критичная

то есть "внешний" - если нет плагина для волта

пример с EV-сертификатом выше валидный, эта штука не делается автоматически

но если ты уже юзаешь кубеня, то +1 зависимость это уже ерунда

пример с EV-сертификатом выше валидный, эта штука не делается автоматически

ну эти сертификаты генерятся не каждый день же? значит можно просто сложить в статический сикрет

Я все выношу в деплой/конфиг тайм, чтобы рантайм был как можно тупее

и обновлять не очень автоматически

ну эти сертификаты генерятся не каждый день же? значит можно просто сложить в статический сикрет

Ну вот и приходим, что где то есть неописанный в гите процесс. Такое тоже надо минимизировать. Шифрованный файл в гите это решает, ваулт для этого не надо держать

Ну вот и приходим, что где то есть неописанный в гите процесс. Такое тоже надо минимизировать. Шифрованный файл в гите это решает, ваулт для этого не надо держать

ну либо ты берёшь нормальную систему управления сикретами, либо придумываешь костыли

ну эти сертификаты генерятся не каждый день же? значит можно просто сложить в статический сикрет

не-не, давайте не выискивать причины, по которым можно примеры отбрасывать

если костыли тебе ближе к телу - я не против

если костыли тебе ближе к телу - я не против

Я за костыли да, если они помогают не снижать надежность

как ты отважился кубернетис поставить вообще?

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

Или использовать целиком libsonnet как базу секретов, внутри обычный json. Затем его шифровать и хранить в git, под каждый уровень доступа иметь отдельный libsonnet просто

Потому что если куб пойдет попизде, все останется работать как было - контейнеры бегут, iptables правила на месте . Т.е. куб не рантайм зависимость

ну так выгрузка EV-сертификата в инит-контейнере - тоже не рантайм зависимость тогда

Да, мне тоже нравится нравится идея все в виде простых конфигов хранить. Если что-то сломается всегда можно передеплоить заново

ну так выгрузка EV-сертификата в инит-контейнере - тоже не рантайм зависимость тогда

В этом случае да. Но ваулт слишком приятная штука и надо очень постараться не юзать всего плюшки.

если стандартизируешь приезд сикретов в файлики, то он будет не "рантайм зависимостью" тоже

другое дело что какую-то ротацию сикретов тоже надо делать

но это очевидно снижает надёжность

Посоны, а кроме kubernetes-dashboard есть что интересное и свежее?

rancher

#проклято