Представляем shell-operator: создавать операторы для Kubernetes стало ещё проще

[alexesDev]

Про альтернативы… Есть metacontroller.app от гугла. Задача решается через CRD типа MyDevEnvironment, который на выходе даёт namespace + secret + ещё что нужно.

apiVersion: mycompany.ru/v1
kind: MyDevEnvironment
metadata:
  name: my-dev-environment135
spec:
  param1: value1

Декларативно. В стиле k8s.

[diafour]

MyDevEnvironment, который создаст namespace и secret наверное было бы круто и красиво… Но это дополнительная сущность в кластере, для которой придётся описать CRD, где-то её задокументировать, донести до всех участников процесса, что мы теперь почему-то не создаём обычный Namespace, а делаем только MyDevEnvironment.
Дальше нужно будет описать контроллер в yaml и sync скрипт, чтобы следить за референсным секретом и за новыми MyDevEnvironment.
В целом это конечно проще, чем ребят в командах обучить писать на Go и OperatorSDK, но всё равно это будет непонятный rocket science для задач, которые решаются запуском пары kubectl команд и выражением для jq.

Но за ссылку спасибо, надо будет изучить подробнее. И кстати есть план добавить поддержку CRD, чтобы хуки могли по onStartup определить свой CRD и в дальнейшем следить за событиями от создаваемых CR.

[alexesDev]

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

Пример однотипных деплоев — статика. CR с ссылкой на s3 с tar. metacontroller создаёт deployment с nginx и initContainer, который выкачивает с s3 и распаковывает. Если файлу на s3 давайть имя «sha1 от контента», то совсем хорошо, нет лишних перекатов.

apiVersion: mycompany.ru/v1
kind: StaticSites
metadata:
  name: mobile-master
  namespace: default
spec:
  archiveUrl: https://link-to-s3.tar.gz
  host: m.mycompany.ru

UPD: CR файл не сильно отличается от values.yml у helm. Только шаблон хранится внутри куба и с ним удобней работать, чем с репозиториями или submodule у git.

UPD: CR файл не сильно отличается от vars файлов ansible, только site.yml в кубе. К слову. В общем не rocket science.

[diafour]

metacontroller создаёт deployment с nginx и initContainer, который выкачивает с s3 и распаковывает.

Я правильно понимаю, что логику создания и логику выкачивания надо в js/py скрипте сделать? Сам metacontroller только за событиями следит и запросы к скрипту делает?

CR… не rocket science

Имел в виду, что rocket science это всё, что стоит за CR — для организации этой машинерии надо обладать каким-то опытом. Пока инженер поймёт, чем CompositeController отличается от DecoratorController, а ему надо всего лишь за лейблами на подах следить и kubectl apply сделать, да он всё бросит и крончик напишет.

Но вообще согласен, если умно выделить типы часто встречающихся задач и оформить в виде sync скриптов и CRD с документацией аргументов, то конечно проще будет CR написать нужный.

[alexesDev]

CompositeController берёт один json (CR) и перегоняет в другой json (базовые примитивы k8s) любым удобным инструментом (js удобней go тут) через webhook (pure function выходит, вся императивность реализована в metacontroller и k8s, т.е. не нашем коде, что очень классно). С DecoratorController не нужен CRD, он докинет объектов к deployment, к примеру, по label/metadata, но я такого сам не писал, только теория.

[alexesDev]

Я правильно понимаю, что логику создания и логику выкачивания надо в js/py скрипте сделать? Сам metacontroller только за событиями следит и запросы к скрипту делает?

Нет, выкачивает initContainer.

initContainers: [
  {
    name: 'download',
    image: 'busybox',
    command: [
      'sh',
      '-c',
      `wget -qO- ${parent.spec.archiveUrl} && tar xvf - -C /data`,
    ],
    volumeMounts: [
      {
        mountPath: '/data',
        name: 'data',
      },
    ],
  },
],
containers: [
  {
    name: 'nginx',

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