>>Еще один нюанс, на каждой ноде есть еще один процесс — kubelet. Он отвечает за то, чтобы было развернуто ровно столько подов, сколько попросили, определенное количество реплик приложения.
Тут тоже есть небольшой вопрос. Технически kubelet выкачивает себе манифест пода, в который шедулер прописал его имя. Поднимает его и тыкает кочергой на предмет того жив он или нет. При этом он не знает, что творится на соседней ноде и про количество реплик подов в кластере. Согласно доков как раз-таки kube-controller-manager следил за количеством реплик и нарезает манифесты подов в нужном количестве.
>>На каждом сервере, на каждой ноде есть программа. Она называется kube-proxy. Именно она принимает запрос от условного Nginx. И уже он балансирует нагрузку и понимает, в какой под нужно отправить запрос.
Всегда думал, что kube-proxy отвечает за реализацию абстракции service и нарезает правила iptables под это дело. И ни в коем случае не принимает никакой трафик. А вот за реализацию overlay-сети между подами отвечает CNI (который опять же сам непосредственно трафик не принимает)
Я тут к тому, что форк уже немного вырос из ползунков. В отличие, от тех, кто просто взял 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: сможете поделиться своими знаниями с комьюнити
>>Еще один нюанс, на каждой ноде есть еще один процесс — kubelet. Он отвечает за то, чтобы было развернуто ровно столько подов, сколько попросили, определенное количество реплик приложения.
Тут тоже есть небольшой вопрос. Технически
kubeletвыкачивает себе манифест пода, в который шедулер прописал его имя. Поднимает его и тыкает кочергой на предмет того жив он или нет. При этом он не знает, что творится на соседней ноде и про количество реплик подов в кластере. Согласно доков как раз-такиkube-controller-managerследил за количеством реплик и нарезает манифесты подов в нужном количестве.>>На каждом сервере, на каждой ноде есть программа. Она называется kube-proxy. Именно она принимает запрос от условного Nginx. И уже он балансирует нагрузку и понимает, в какой под нужно отправить запрос.
Всегда думал, что kube-proxy отвечает за реализацию абстракции
serviceи нарезает правила iptables под это дело. И ни в коем случае не принимает никакой трафик. А вот за реализацию overlay-сети между подами отвечает CNI (который опять же сам непосредственно трафик не принимает)мощно, красавцы 👍
А зачем мы делали 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: сможете поделиться своими знаниями с комьюнити