Я тут к тому, что форк уже немного вырос из ползунков. В отличие, от тех, кто просто взял 1.14.8 и пытается его продавать не добавив нового функционала (нескучные обои не в счёт)
Увы, пока не густо. Но учитывая, что он апи-совместим с волтом, всякие KV настраиваются обычным модулем от волта. Я юзал vault-operator для базовых настроек + собственные уникальные технологии (костыли на ansible) для нарезки разделов под команды
Секреты кодированы в base64. Но можно на уровне api-server включить шифрование при хранении в etcd. При этом их в любом случае можно прочитать через `kubectl get`
Для 13 версии MetalLB есть смысл добавить описание L2Advertisment, он позволяет указать интерфейс для анонса и выбрать ноды, что может быть принципиально, если ExternalTraficPolicy: Local
Аннотация ingress.class в 1.22 была объявлена как deprecated. https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/ Честно говоря не понимаю практический смысл ручного поднятия куба. Если чисто для себя, есть уже замыленная статья "Kubernetes hard way" где всё описано. Есть kubespray который позволяет штамповать кластера под копирку и при этом можно легко добавлять/удалять ноды.
В документациях говорят о том, что решение с MetalB на балансировку api не совсем корректное: если будут какие-то проблемы с daemonset, то ip не поднимется и мы получим тыкву (c Ingress такая же история). В интернетах предлагаю решение kube-vip, которое запускается как static pod и позволяет перевозить ip между мастерами. Вот как это включается на kubespray https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kube-vip.md
По идеи это как metalB, только static под на мастер-ноде, но считается, более надёжным
Даже в кубе кто-то эти CRD должен развернуть и настроить, если нет девопса на проекте то приётся кого-то просить с уважением и ждать. Пробежался по решению внешне выглядит как оператор vault и по мне лучше его и внедрить т.к. он более популярен. Но за решение спасибо, почитаю еще раз внимательнее
1) Как организовать версионирование секрета и откат/накат
2) Всё-таки где-то должны храниться исходные данные, которые вы помещаете в нужную среду
В случае если мы какие-то сторонние решения используем, то возникает вопрос их высокой доступности и кто их обслуживает. В случае хранения в репе обеспечение доступности сервиса лежит не нас.
По коммитам vault завезли "16 Jul 2020" я честно говоря пропустил этот момент, т.к. инструмент начал использовать гораздо раньше. KMS опять же не целевая архитектура для корпоратов: я долгое время работал в банке и внешние системы не рассматриваю. Спасибо, что указали на неточность, я в документации по sops вычитал интересную вещь: он может запушить секреты из файла в vault: sops publish $file
В случае helm secrets и sops все хранится в репе и ничего дополнительно не нужно. И потом можно разворачивать инфраструктурные решения и перезжать туда.
Келси Хайтауэр, ты ли это? Хотя это не важно — в любом случае будем рады увидеться 9 декабря на VK Kubernetes Conference: сможете поделиться своими знаниями с комьюнити
DL360 g5p 2012r2 встала без проблем. Были косяки с emulex'овскими hba-адаптерами, пришлось шить их, а потом поочереди накатывать дрова до последней версии (допер эмпирическим путем) производитель сказал, что они не будут работать с 2012 и дров на них нет.
Полтора года и ни единого разрыва :)
мощно, красавцы 👍
А зачем мы делали declare -a IPS=(*IP мастер-ноды* IP-воркер-ноды)) , если оно нигде не используется?
Наверное потому. что раньше был скрипт. который генерировал конфиг, а его убрали ?))
Я тут к тому, что форк уже немного вырос из ползунков. В отличие, от тех, кто просто взял 1.14.8 и пытается его продавать не добавив нового функционала (нескучные обои не в счёт)
Увы, пока не густо. Но учитывая, что он апи-совместим с волтом, всякие KV настраиваются обычным модулем от волта. Я юзал vault-operator для базовых настроек + собственные уникальные технологии (костыли на ansible) для нарезки разделов под команды
Секреты кодированы в base64. Но можно на уровне api-server включить шифрование при хранении в etcd. При этом их в любом случае можно прочитать через `kubectl get`
Для 13 версии MetalLB есть смысл добавить описание L2Advertisment, он позволяет указать интерфейс для анонса и выбрать ноды, что может быть принципиально, если ExternalTraficPolicy: Local
https://habr.com/ru/company/ru_mts/blog/695242/ я в самом начале писал, про ingress canary. Istio тоже можно, но сложнее
"auth/approle/*" { capabilities = [ "create", "read", "update", "delete", "list" ] }path "sys/policies/acl/*" { capabilities = [ "create", "read", "update", "delete", "list" ] }Возможно я где-то что-то проглядел, но получается, что пользователь может сам себе политику поменять на любые права и забиндить любую роль.
А чем https://strimzi.io/ то не устроил ? Можно к его crd свой контроллер добавить и не пилить всё с нуля
Аннотация
ingress.classв 1.22 была объявлена как deprecated. https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/ Честно говоря не понимаю практический смысл ручного поднятия куба. Если чисто для себя, есть уже замыленная статья "Kubernetes hard way" где всё описано. Есть kubespray который позволяет штамповать кластера под копирку и при этом можно легко добавлять/удалять ноды.В документациях говорят о том, что решение с MetalB на балансировку api не совсем корректное: если будут какие-то проблемы с daemonset, то ip не поднимется и мы получим тыкву (c Ingress такая же история). В интернетах предлагаю решение kube-vip, которое запускается как static pod и позволяет перевозить ip между мастерами. Вот как это включается на kubespray https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kube-vip.md
По идеи это как metalB, только static под на мастер-ноде, но считается, более надёжным
Даже в кубе кто-то эти CRD должен развернуть и настроить, если нет девопса на проекте то приётся кого-то просить с уважением и ждать. Пробежался по решению внешне выглядит как оператор vault и по мне лучше его и внедрить т.к. он более популярен. Но за решение спасибо, почитаю еще раз внимательнее
Вижу несколько проблем:
1) Как организовать версионирование секрета и откат/накат
2) Всё-таки где-то должны храниться исходные данные, которые вы помещаете в нужную среду
В случае если мы какие-то сторонние решения используем, то возникает вопрос их высокой доступности и кто их обслуживает. В случае хранения в репе обеспечение доступности сервиса лежит не нас.
А где вы их храните и как они попадают в нужную среду ?
По коммитам vault завезли "16 Jul 2020" я честно говоря пропустил этот момент, т.к. инструмент начал использовать гораздо раньше. KMS опять же не целевая архитектура для корпоратов: я долгое время работал в банке и внешние системы не рассматриваю. Спасибо, что указали на неточность, я в документации по sops вычитал интересную вещь: он может запушить секреты из файла в vault:
sops publish $fileНапример, вы сидите в любой крупной корпоративной конторе и вам просто запрещено выносить что-либо за пределы контролируемой зоны.
В случае helm secrets и sops все хранится в репе и ничего дополнительно не нужно. И потом можно разворачивать инфраструктурные решения и перезжать туда.
Келси Хайтауэр, ты ли это? Хотя это не важно — в любом случае будем рады увидеться 9 декабря на VK Kubernetes Conference: сможете поделиться своими знаниями с комьюнити
Полтора года и ни единого разрыва :)