Metal3 использует под капотом ironic. Что прикольно: IP адреса и ноды выделяются кластерам полностью в динамическом режиме. С другой стороны там по прежнему имеется процесс установки ОС на хост и, на мой взгляд, несколько переусложнённая логика. Чтобы разобраться и настроить всё это вам потребуется протратить не один день.
Отличная статья, но на мой взгляд местами too opinionated :)
Ничего не имею против Werf, я люблю стандартизацию подходов и тулза у вас вышла отличная, но тем не менее выскажу немного критики по содержанию:
CI/CD у нас обычно несколько окружений (production, staging, development и т. д.). И конфигурация приложения может отличаться для разных окружений.
Технически Helm позволяет конфигурировать описанный chart параметрами, через которые передаются образы приложения и выбранное окружение. Однако конкретный путь — как это делать — не стандартизован. Пользователю Helm приходится решать это самому.
На счёт "не стандартизован" соглашусь, вариантов достичь желаемого достаточно много: можно передавать параметры через опции CLI или переменные окружения; можно пилить umbrela-чарты с оверрайдами для каждого энвайромента, но считаю что подход с использованием нескольких values файлов наиболее стандартным и популярным:
-f base.yaml -f stage.yaml
-f base.yaml -f prod.yaml
Кстати, аналогичным образом можно передавать и секреты.
Если я правильно понял, werf позволяет реализовать тот же паттерн, но в виду упомянутого вами гитерминизма, по прежнему, не является правильным. К слову, тот же Helmfile позволяет указать набор параметров для хельма в зависимости от конкретного энвайромента.
Таким образом у меня по прежнему возникает вопрос: каким образом в werf правильно хранить и передавать параметры для разных энвайроментов? :)
werf должна поддерживать GitOps-подход
GitOps в общем виде — это подход, при котором для развертывания приложений в Kubernetes используется единственный источник правды — Git-репозиторий. Через декларативные действия в Git вы управляете реальным состоянием инфраструктуры, запущенной в Kubernetes. Этот паттерн «из коробки» работает в werf.
У нас есть собственный взгляд на то, как должен быть реализован GitOps для CI/CD (уже упомянутый Giterminism). GitOps в werf поддерживает не только хранение Kubernetes-манифестов в Git, но и версионирование собираемых образов, связанное с Git. Откат до предыдущей версии приложения выполняется без сборки выкатывавшихся ранее образов (при условии, что версия учитывается политиками очистки). Другие существующие реализации GitOps не дают этой гарантии.
Можно долго ходить вокруг да около GitOps (огромное "спасибо" Weaveworks за то что придумали такой неоднозначный термин). Хранение правды в Git да, но всё-таки оно немного не про то.
Использование GitOps подразумевает наличие контроллера или GitOps-оператора (называйте как хотите), который делает непрерывный синк состояния Git-репозитория с Kubernetes-кластером.
По сути — это такой же reconciling loop, по аналогии с тем как контроллеры Kubernetes создают нижестоящие ресурсы. Например Deployment генерирует ReplicaSet, ReplicaSet генерирует Pods. Таким же образом должен работать и GitOps-оператор, отрендерив код описанного приложения в Git-репозитории, он должен непрерывно перекладывать его в Kubernetes.
Оба решения Helm и Werf не обладают данной характеристикой. Однако иметь контроллер Werf для Flux2, думаю, было бы весьма здорово.
Для организации GitOps, в том понимании в котором он изначально задумывался, таких решения сейчас два: ArgoCD и FluxCD. Второй более нативен к хельму, так как непосредственно использует его для деплоя в кластер.
Забавен тот факт, что применение GitOps может быть вообще не завязано на использование Git. Вышеупомянутые тулзы могут следить и работать также с Helm-registry и даже S3-бакетами.
У нас есть собственный взгляд на то, как должен быть реализован GitOps для CI/CD (уже упомянутый Giterminism). GitOps в werf поддерживает не только хранение Kubernetes-манифестов в Git, но и версионирование собираемых образов, связанное с Git. Откат до предыдущей версии приложения выполняется без сборки выкатывавшихся ранее образов (при условии, что версия учитывается политиками очистки). Другие существующие реализации GitOps не дают этой гарантии.
Здесь стоит упомянуть про kbld и kapp и другие утилиты от Caravel, которые делают примерно тоже самое что и Werf, но без жёсткой привязки к конкретному стеку.
И Gitkube, решения, которое может выступать в качестве гейтвея для деплоя с помощью простого git push, оно также умеет собирать образы и подставлять дайджест в темплейты.
Так как оно представляет своего рода гейтвей Git-to-Kubernetes, оно в принципе не позволяет запушить неисправный коммит в кластер. Таким образом, скрепя зубами, его всё таки можно назвать push-based GitOps-решением, однако оно не развивается уже как 3 года и я не советовал бы его использовать.
Моё мнение, что текущий вектор развития Werf, если вы держите курс на GitOps, должен основываться на изложенных выше идеях. При этом вам не потребуется существенно изменять функционал и логику работы Werf. Наоборот, вам просто нужно дополнить её соответствующим контроллером.
В этом плане мне подход Google Cloud нравится больше. Где у вас по прежнему есть только один аккаунт на сотрудника, но основная единица разделения — это проекты.
То есть вам ничто не мешает иметь несколько проектов за одним аккаунтом, и управлять ими по отдельности, как и подключить несколько аккаунтов к одному проекту.
Кстати, а что произойдет с кластером, если мы восстановим бекап etcd?
Ничего не произойдёт. Kube-apiserver спроектирован так, чтобы по возможности не хранить никакого состояния, поэтому он просто подхватит изменения в etcd. Это работает даже без перезапуска apiserver.
Он резко постарается привести себя в то состояние, в котором был и начнет шедулить 100500 недостающих подов?
Это зависит не от apiserver, а скорее от controller-manager и scheduler. После того как вы востановите бэкап, все ваши ноды будут находиться в том же состоянии на момент которого был сделан бэкап. То есть если они были в Ready, то такими они и останутся до поры до времени. И только спустя 30 секунд (таймаут по умолчанию), если кубелеты не сообщили о своём состоянии аписерверу, controller-manager начнёт переводить их в NotReady и триггерить создание новых подов.
Старые поды при этом останутся работать без изменений, то есть кубелеты самостоятельно не предпринимают никаких действий по удалению подов в случае невозможности связаться с apiserver.
про failed proposals, частые re-elect
Про это мне сказать пока что нечего, если кому есть чем дополнить статью, милости прошу в комментарии :)
На счёт 404 понял. Ошибка будет возникать при попытке кубелета смаунтить несуществующий секрет в под.
Кажется я нашёл более изящное решение: можно просто пропатчить все секреты, удалив из них .data.token и тогда controller-manager перегенирирует токены в секретах с тем же именем.
Возможно я не совсем правильно выразился, но основная цель статьи была как раз в том чтобы разобраться как восстановить кластер при полной потере всех сертификатов и заменить их на новые.
PS: Использовал ServiceAccountTokenVolumeProjection для Konnectivity, очень удобно так как в этом случае токен перевыпускается и обновляются в поде автоматически.
Хороший вопрос. Думаю разницы в терминах особой нет, но попробую выразить своё субъективное мнение на этот счёт.
Формально управлением контейнеров занимается docker, containerd или другой CRI-демон. Kubernetes — грубо говоря, это плоскость управления для таких вот CRI, со своим API и шедуллером.
То есть вы сообщаете Kubernetes что конкретно должно быть запущенно, с какими параметрами и в скольких экземплярах. Он находит свободные ноды и и даёт команду на запуск контейнеров на них. Чем не оркестрация?
Спасибо за отзыв!
Metal3 использует под капотом ironic. Что прикольно: IP адреса и ноды выделяются кластерам полностью в динамическом режиме. С другой стороны там по прежнему имеется процесс установки ОС на хост и, на мой взгляд, несколько переусложнённая логика. Чтобы разобраться и настроить всё это вам потребуется протратить не один день.
Краткое содержание статьи ;)
Отличная статья, но на мой взгляд местами too opinionated :)
Ничего не имею против Werf, я люблю стандартизацию подходов и тулза у вас вышла отличная, но тем не менее выскажу немного критики по содержанию:
На счёт "не стандартизован" соглашусь, вариантов достичь желаемого достаточно много: можно передавать параметры через опции CLI или переменные окружения; можно пилить umbrela-чарты с оверрайдами для каждого энвайромента, но считаю что подход с использованием нескольких values файлов наиболее стандартным и популярным:
Кстати, аналогичным образом можно передавать и секреты.
Если я правильно понял, werf позволяет реализовать тот же паттерн, но в виду упомянутого вами гитерминизма, по прежнему, не является правильным. К слову, тот же Helmfile позволяет указать набор параметров для хельма в зависимости от конкретного энвайромента.
Таким образом у меня по прежнему возникает вопрос: каким образом в werf правильно хранить и передавать параметры для разных энвайроментов? :)
Можно долго ходить вокруг да около GitOps (огромное "спасибо" Weaveworks за то что придумали такой неоднозначный термин). Хранение правды в Git да, но всё-таки оно немного не про то.
Использование GitOps подразумевает наличие контроллера или GitOps-оператора (называйте как хотите), который делает непрерывный синк состояния Git-репозитория с Kubernetes-кластером.
По сути — это такой же reconciling loop, по аналогии с тем как контроллеры Kubernetes создают нижестоящие ресурсы. Например Deployment генерирует ReplicaSet, ReplicaSet генерирует Pods. Таким же образом должен работать и GitOps-оператор, отрендерив код описанного приложения в Git-репозитории, он должен непрерывно перекладывать его в Kubernetes.
Оба решения Helm и Werf не обладают данной характеристикой. Однако иметь контроллер Werf для Flux2, думаю, было бы весьма здорово.
Для организации GitOps, в том понимании в котором он изначально задумывался, таких решения сейчас два: ArgoCD и FluxCD. Второй более нативен к хельму, так как непосредственно использует его для деплоя в кластер.
Забавен тот факт, что применение GitOps может быть вообще не завязано на использование Git. Вышеупомянутые тулзы могут следить и работать также с Helm-registry и даже S3-бакетами.
Здесь стоит упомянуть про kbld и kapp и другие утилиты от Caravel, которые делают примерно тоже самое что и Werf, но без жёсткой привязки к конкретному стеку.
И Gitkube, решения, которое может выступать в качестве гейтвея для деплоя с помощью простого
git push, оно также умеет собирать образы и подставлять дайджест в темплейты.Так как оно представляет своего рода гейтвей Git-to-Kubernetes, оно в принципе не позволяет запушить неисправный коммит в кластер. Таким образом, скрепя зубами, его всё таки можно назвать push-based GitOps-решением, однако оно не развивается уже как 3 года и я не советовал бы его использовать.
Моё мнение, что текущий вектор развития Werf, если вы держите курс на GitOps, должен основываться на изложенных выше идеях. При этом вам не потребуется существенно изменять функционал и логику работы Werf. Наоборот, вам просто нужно дополнить её соответствующим контроллером.
В этом плане мне подход Google Cloud нравится больше. Где у вас по прежнему есть только один аккаунт на сотрудника, но основная единица разделения — это проекты.
То есть вам ничто не мешает иметь несколько проектов за одним аккаунтом, и управлять ими по отдельности, как и подключить несколько аккаунтов к одному проекту.
Дельное замечание, про потерю кворума дополнил.
Ничего не произойдёт. Kube-apiserver спроектирован так, чтобы по возможности не хранить никакого состояния, поэтому он просто подхватит изменения в etcd. Это работает даже без перезапуска apiserver.
Это зависит не от apiserver, а скорее от controller-manager и scheduler. После того как вы востановите бэкап, все ваши ноды будут находиться в том же состоянии на момент которого был сделан бэкап. То есть если они были в
Ready, то такими они и останутся до поры до времени. И только спустя 30 секунд (таймаут по умолчанию), если кубелеты не сообщили о своём состоянии аписерверу, controller-manager начнёт переводить их вNotReadyи триггерить создание новых подов.Старые поды при этом останутся работать без изменений, то есть кубелеты самостоятельно не предпринимают никаких действий по удалению подов в случае невозможности связаться с apiserver.
Про это мне сказать пока что нечего, если кому есть чем дополнить статью, милости прошу в комментарии :)
Имелось ввиду скорее второе утверждение чем первое, что etcd лежит в основе Kubernetes.
Исправил пунктуацию, спасибо :)
Ох и правда, побежал обновляться!
Вот бы они ещё решили 21-летний баг с Ctrl+Q и цены бы им не было.
https://bugzilla.mozilla.org/show_bug.cgi?id=52821
I don't care about cookies!
UPD: Выше отписал что нашёл более изящное решение.
Имя секретов теперь не меняется, так что это утверждение вновь становится верным.
На счёт 404 понял. Ошибка будет возникать при попытке кубелета смаунтить несуществующий секрет в под.
Кажется я нашёл более изящное решение: можно просто пропатчить все секреты, удалив из них
.data.tokenи тогда controller-manager перегенирирует токены в секретах с тем же именем.Статью обновил, огромное спасибо за наводку ;)
Возможно я не совсем правильно выразился, но основная цель статьи была как раз в том чтобы разобраться как восстановить кластер при полной потере всех сертификатов и заменить их на новые.
Спасибо,
Но это при условии что данные поды ломятся в API, не так-ли?
А каким образом можно передать apiserver'у оба сертификата? — в смысле обычным бандлом?
Дельное замечание, спасибо, исправил!
PS: Использовал ServiceAccountTokenVolumeProjection для Konnectivity, очень удобно так как в этом случае токен перевыпускается и обновляются в поде автоматически.
Хороший вопрос. Думаю разницы в терминах особой нет, но попробую выразить своё субъективное мнение на этот счёт.
Формально управлением контейнеров занимается docker, containerd или другой CRI-демон. Kubernetes — грубо говоря, это плоскость управления для таких вот CRI, со своим API и шедуллером.
То есть вы сообщаете Kubernetes что конкретно должно быть запущенно, с какими параметрами и в скольких экземплярах. Он находит свободные ноды и и даёт команду на запуск контейнеров на них. Чем не оркестрация?
А чего только стоил shoutcast, и вещать прямо из winamp можно было!
А мне официальный Bento очень зашёл.
Кстати, тем кому не хватает винампа, этот скин по прежнему продолжает жить в foobar2000
А ещё там пасхалка была, нужно было на рыбку кликать, она крутилась и обороты считала :)
Очень захватывающе, спасибо! Всегда с большим увлечением читаю новости о GPT-3.
Не подскажете: какое минимальное железо требуется чтобы запустить хотя бы минимальную версию ruGPT?
В идеале хотелось бы готовый docker-image, который можно просто запустить на любом лэптопе и попробовать поиграться с сетью.