Глава 23. Оператор

Паттерн Operator (Оператор) — это тот же паттерн Controller (Контроллер), но использующий определения нестандартных ресурсов (CustomResourceDefinition, CRD) для представления практических знаний в конкретной предметной области в алгоритмической и автоматизированной форме. Паттерн Operator (Оператор) позволяет расширить паттерн Controller (Контроллер), описанный в предыдущей главе, и обеспечивает большую гибкость и выразительность.

Задача

В главе 22 «Контроллер» вы узнали, как расширить возможности платформы Kubernetes простым способом без внедрения в ее реализацию. Однако в некоторых случаях обычных нестандартных контроллеров недостаточно, потому что они могут контролировать только внутренние ресурсы Kubernetes. Иногда бывает желательно добавить новые понятия в платформу Kubernetes, требующие введения дополнительных предметных объектов. Допустим, в качестве решения для мониторинга мы выбрали Prometheus и хотим добавить его в Kubernetes четко определенным образом. Было бы просто замечательно, если бы у нас имелся ресурс Prometheus, описывающий конфигурацию и все детали развертывания средств мониторинга, подобный другим ресурсам Kubernetes. Также было бы хорошо иметь ресурсы, описывающие, какие службы следует охватить мониторингом (например, с помощью селектора меток).

В таких ситуациях используются определения нестандартных ресурсов (CustomResourceDefinition, CRD). Они позволяют расширять Kubernetes API, добавляя нестандартные ресурсы в кластер Kubernetes и используя их, как если бы они были встроенными ресурсами. Нестандартные ресурсы вместе с паттерном Controller (Контроллером) для управления ими образуют паттерн Operator (Оператор).

Следующая цитата (http://bit.ly/2Fjlx1h) Джимми Зелински (Jimmy Zelinskie) как нельзя лучше описывает особенности паттерна Operator (Оператор):

Оператор — это контроллер Kubernetes, знающий две предметные области: Kubernetes и какую-то еще. Объединяя знания из обеих областей, он может автоматизировать задачи, обычно требующие участия оператора-человека, который понимает обе области.

Решение

В главе 22 «Контроллер» мы узнали о возможности эффективно реагировать на изменение состояния ресурсов, встроенных в Kubernetes. Теперь, понимая как работает первая половина паттерна Operator (Оператор), рассмотрим другую половину — представление нестандартных ресурсов в Kubernetes с использованием CRD.

Определения нестандартных ресурсов

Определения нестандартных ресурсов (CustomResourceDefinition, CRD) позволяют добавить в Kubernetes возможность управления понятиями из нашей предметной области. Нестандартные ресурсы управляются так же, как любые другие ресурсы, через Kubernetes API, и хранятся во внутреннем хранилище Etcd. Исторически предшественниками CRD были сторонние ресурсы ThirdPartyResource.

Фактически упомянутый выше сценарий реализован с помощью новых нестандартных ресурсов в виде оператора CoreOS Prometheus, который обеспечивает бесшовную интеграцию Prometheus с Kubernetes. В листинге 23.1 показано определение CRD Prometheus, где также можно увидеть большинство параметров CRD.

Листинг 23.1. CustomResourceDefinition

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

metadata:

  name: prometheuses.monitoring.coreos.com 

spec:

  group: monitoring.coreos.com             

  names:

    kind: Prometheus                       

    plural: prometheuses                   

  scope: Namespaced                        

  version: v1                              

  validation:

    openAPIV3Schema: ....                  

 Имя.

 Группа API, к которой принадлежит ресурс.

 Вид, используемый для идентификации экземпляров этого ресурса.

 Правило именования для создания формы множественного числа, используется для определения списка объектов.

 Область видимости — может ли ресурс создаваться на уровне кластера или только в некотором пространстве имен.

 Версия CRD.

 Схема OpenAPI V3 для проверки (здесь не показана).

Также можно указать схему OpenAPI V3, чтобы Kubernetes мог проверить правильность определения нестандартного ресурса. В простых случаях схему можно опустить, но в промышленном окружении обязательно следует определить схему, чтобы ошибки конфигурации можно было обнаружить на самой ранней стадии.

Также Kubernetes позволяет указать в каждом CRD два возможных вложенных ресурса в поле subresources:

scale

С помощью этого свойства можно указать, как определяется количество реплик ресурса. В этом параметре можно указать путь в формате JSON для поиска желаемого количества реплик: путь к свойству, в котором хранится фактическое количество запущенных реплик, и необязательный путь к селектору меток, который можно использовать для поиска копий экземпляров ресурса. Обычно этот селектор меток можно не указывать, но он обязательно должен быть определен, если вы хотите использовать свой нестандартный ресурс с механизмом горизонтального масштабирования подов HorizontalPodAutoscaler, описанным в главе 24 «Эластичное масштабирование».

status

После установки этого свойства становится доступен новый вызов API, позволяющий изменять только статус. Этот вызов API можно защитить отдельно и позволить с его помощью обновлять статус из-за пределов контроллера. С другой стороны, при обновлении ресурса в целом раздел status игнорируется точно так же, как для стандартных ресурсов Kubernetes.

Листинг 23.2 показывает, что пути к вложенным ресурсам определяются точно так же, как в обычных подах.

Листинг 23.2. Определение вложенных ресурсов в CustomResourceDefinition

kind: CustomResourceDefinition

# ...

spec:

  subresources:

    status: {}

    scale:

      specReplicasPath: .spec.replicas 

      statusReplicasPath: .status.replicas 

      labelSelectorPath: .status.labelSelector 

 Путь JSON к желаемому числу реплик.

 Путь JSON к числу активных реплик.

 Путь JSON к селектору меток для запроса количества активных реплик.

Определив CRD, легко можно создать такой ресурс, как в листинге 23.3.

Листинг 23.3. Нестандартный ресурс Prometheus

apiVersion: monitoring.coreos.com/v1

kind: Prometheus

metadata:

  name: prometheus

spec:

  serviceMonitorSelector:

    matchLabels:

      team: frontend

  resources:

    requests:

      memory: 400Mi

Раздел metadata: имеет тот же формат и правила проверки, что и в любых других ресурсах Kubernetes. Раздел spec: содержит настройки, характерные для CRD, и Kubernetes проверяет его, используя правило из CRD.

Сами по себе нестандартные ресурсы не имеют большого практического значения без активных компонентов, работающих с ними. Чтобы сделать их полезными, необходим уже известный нам контроллер, наблюдающий за жизненным циклом этих ресурсов и действующий в соответствии с объявлениями в них.

Классификация контроллеров и операций

Прежде чем углубиться в реализацию паттерна Operator (Оператор), познакомимся поближе с классификацией контроллеров, операторов и особенно CRD. Основываясь на действиях, операторы можно разбить на следующие обширные группы:

CRD для установки

Предназначены для установки и запуска приложений на платформе Kubernetes. Типичным примером является CRD Prometheus, который можно использовать для установки и управления Prome­theus.

Прикладные CRD

CRD этого типа используются для представления понятий предметной области и обеспечивают глубокую интеграцию приложений с Kubernetes, помогая объединить поведение Kubernetes с поведением конкретного приложения. Например, ServiceMonitor CRD используется оператором Prometheus для регистрации определенных служб Service в Kubernetes с целью наблюдения за сервером Prometheus. Оператор Prometheus заботится о соответствующей адаптации конфигурации сервера Prometheus.

Обратите внимание, что оператор может одновременно работать с разными типами CRD, как оператор Prometheus в данном случае. Граница между этими двумя категориями CRD весьма условна.

В нашей классификации паттернов Controller (Контроллер) и Operator (Оператор) оператор является контроллером, который использует определения нестандартных ресурсов CRD. Однако это отличие тоже несколько размыто из-за имеющихся вариаций.

Примером может служить контроллер, использующий ConfigMap как своеобразную замену CRD. Этот подход имеет смысл использовать в случаях, когда встроенных ресурсов Kubernetes недостаточно, а создание своего CRD невозможно. В таком случае ConfigMap может служить отличным промежуточным звеном, инкапсулирующим предметную логику. При использовании простого ConfigMap не нужно иметь права администратора кластера, необходимые для регистрации CRD, и это большое преимущество. В некоторых кластерах просто нет возможности зарегистрировать такой CRD (например, в общедоступных кластерах, таких как OpenShift Online).

Заменив определение CRD картой конфигурации ConfigMap с предметными настройками, можно использовать подход Наблюдение — Анализ — Действие, но при этом вы лишитесь поддержки инструментов для CRD, таких как kubectl get, возможности проверки на уровне API Server и поддержки управления версиями API. Кроме того, вы не сможете оказать большого влияния на моделирование поля status: в ConfigMap, тогда как в CRD можно определить свою модель статуса, какую пожелаете.

Еще одно преимущество CRD — наличие подробной модели разрешений, основанной на типе CRD, которую можно настраивать индивидуально. Этот вид защиты RBAC невозможен, когда вся предметная конфигурация заключена в ConfigMap, потому что все ConfigMap в пространстве имен имеют одинаковую настройку разрешений.

С точки зрения реализации важно, что именно реализуется — контроллер, ограниченный использованием встроенными объектами Kubernetes, или у нас есть нестандартные ресурсы, которыми контроллер должен управлять. В первом случае у нас на выбор есть все типы, доступные в клиентской библиотеке Kubernetes. Во втором случае у нас нет готовой информации о типах и мы можем использовать подход к управлению ресурсами CRD без использования схемы или должны сами определить типы, возможно, на основе схемы OpenAPI, содержащейся в определении CRD. Поддержка типизированных CRD зависит от используемой клиентской библиотеки и инфраструктуры.

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

Для операторов в Kubernetes существуют точки расширения с еще более широкими возможностями. Когда определений CRD, управляемых Kubernetes, оказывается недостаточно для представления предметной области, можно расширить Kubernetes API собственным слоем агрегирования. Мы можем добавить ресурс APIService с собственной реализацией как новый URL-путь к Kubernetes API.

 

Рис. 23.1. Спектр контроллеров и операторов

Чтобы подключить данную службу Service с именем custom-api-server для поддержки пода с вашей службой, вы можете использовать ресурс, представленный в листинге 23.4.

Листинг 23.4. Слой агрегирования с нестандартным ресурсом APIService

apiVersion: apiregistration.k8s.io/v1beta1

kind: APIService

metadata:

  name: v1alpha1.sample-api.k8spatterns.io

spec:

  group: sample-api.k8spattterns.io

  service:

    name: custom-api-server

  version: v1alpha1

Кроме определений службы Service и пода, необходимы также некоторые дополнительные настройки безопасности для учетной записи ServiceAccount, под которой будет выполняться под.

После установки этой настройки все запросы к API Server (https://<ip-адрес сервера API>/apis/sample-api.k8spatterns.io/v1alpha1/namespaces/<ns> /...) будут направляться в реализацию нашей службы Service. Эта реализация должна обрабатывать все запросы, включая сохранение ресурсов, управляемых через этот API. Этот подход отличается от предыдущего случая использования CRD, где все управление нестандартными ресурсами осуществляется самой платформой Kubernetes.

В лице собственной реализации API Server вы получаете гораздо больше свободы, что позволяет не только наблюдать за событиями жизненного цикла ресурса. С другой стороны, этот подход требует реализовать гораздо больше логики, поэтому в типичных случаях использования обычно ограничиваются операторами, работающими с простыми CRD.

Подробное исследование возможностей API Server выходит за рамки этой главы. Более полную информацию вы найдете в официальной документации (http://bit.ly/2uk7TWM) и в законченном примере sample-apiserver (http://bit.ly/2HJULSy). Также можете использовать библиотеку apiserver-builder (http://bit.ly/2JIhHEl), которая поможет вам реализовать агрегирование с API Server.

А теперь посмотрим, как реализовать и развернуть оператор, управляющий нашими собственными определениями CRD.

Разработка и развертывание оператора

На момент написания этих строк (2019 г.) разработка операторов являлась активно развивающейся областью Kubernetes и имелось несколько инструментов и фреймворков для создания операторов. Вот три основных из них:

• CoreOS Operator Framework;

• Kubebuilder, разработанный непосредственно в SIG API Machinery Kubernetes;

• Metacontroller из Google Cloud Platform.

Мы кратко коснемся их далее, но помните, что все эти проекты довольно молоды и могут со временем измениться или даже объединиться.

Operator Framework

Operator Framework предлагает обширную поддержку разработки операторов на Golang и состоит из следующих компонентов:

• Operator SDK предлагает API высокого уровня для доступа к кластеру Kubernetes и упрощает создание проекта оператора.

• Operator Lifecycle Manager управляет выпуском и обновляет операторы и их определения CRD. Его можно рассматривать как своеобразный «оператор операторов».

• Operator Metering упрощает добавление в операторы поддержки отчетов.

Мы не будем здесь вдаваться в детали Operator SDK, который продолжает активно развиваться, и остановимся на инструменте Operator Lifecycle Manager (OLM), предлагающем особенно ценную помощь при разработке операторов. Одна из проблем, связанных с ресурсами CRD, заключается в том, что их можно зарегистрировать только на уровне кластера, для чего необходимы привилегии администратора кластера. Обычные пользователи Kubernetes часто имеют возможность управлять всеми аспектами пространств имен, к которым им предоставлен доступ, но не могут просто использовать операторы без взаимодействия с администратором кластера.

OLM — это кластерная служба, действующая в фоновом режиме с привилегиями, разрешающими установку CRD. Вместе с OLM регистрируется выделенный ресурс CRD, называемый ClusterServiceVersion (CSV), позволяющий определить развертывание Deployment для оператора со ссылками на CRD, связанные с этим оператором. После создания такого ресурса CSV одна часть OLM ждет регистрации его и всех зависимых CRD. В этом случае OLM развертывает оператор, указанный в CSV. Другая часть OLM может использоваться для регистрации этих CRD от имени непривилегированного пользователя. Этот подход позволяет обычным пользователям кластера устанавливать свои операторы.

Kubebuilder

Kubebuilder — это проект группы SIG API Machinery с обширной документацией. Подобно Operator SDK, он поддерживает создание проектов на Golang и управление несколькими CRD в одном проекте.

В отличие от Operator Framework, Kubebuilder работает напрямую с Kubernetes API, тогда как Operator SDK добавляет дополнительный слой абстракции поверх стандартного API, что упрощает его использование (но ценой утраты некоторых возможностей).

Поддержка установки и управления жизненным циклом оператора не так сложна, как в OLM из Operator Framework. Тем не менее оба проекта во многом совпадают и в конечном итоге могут прийти к общему знаменателю.

Metacontroller

Metacontroller сильно отличается от двух других инструментов разработки операторов. Он расширяет Kubernetes API своими функциями, реализующими общие возможности создания пользовательских контроллеров. Он действует подобно диспетчеру Kubernetes Controller Manager, запуская несколько контроллеров, которые определяются динамически с помощью особых ресурсов CRD, поддерживаемых Metacontroller. Иначе говоря, это контроллер, который вызывает службу с фактической логикой контроллера.

Описать Metacontroller можно также с точки зрения декларативного поведения. Ресурсы CRD дают возможность хранить новые типы в Kubernetes API, а Metacontroller позволяет легко определять поведение стандартных или пользовательских ресурсов декларативно.

Определяя контроллер с помощью Metacontroller, мы должны указать функцию, которая реализует бизнес-логику нашего контроллера. Metacontroller берет на себя все хлопоты по взаимодействию с Kubernetes API, запускает цикл согласования от нашего имени и вызывает нашу функцию через заданную точку входа. Функции передается четко определенный набор данных, описывающий событие CRD. Так как функция должна возвращать значение, мы возвращаем определение ресурсов Kubernetes, которые требуется создать (или удалить) от имени нашей функции контроллера.

Такой способ, основанный на делегировании, позволяет писать функции на любом языке, способном обрабатывать HTTP и JSON, без всяких зависимостей от Kubernetes API или клиентских библиотек. Эти функции можно развертывать в Kubernetes, на стороне внешних поставщиков FaaS (Functions-as-a-Service — функция как услуга) или где-то еще.

Здесь у нас нет возможности подробно рассмотреть все варианты, но если вам требуется лишь дополнить Kubernetes простыми средствами автоматизации или управления и не нужны дополнительные функции, обратите внимание на Metacontroller, особенно если вы хотите реализовать свою бизнес-логику на языке, отличном от Go. В интернете можно найти примеры контроллеров, которые демонстрируют, как реализовать службу с состоянием, сине-зеленое развертывание, индексируемое задание и службу-одиночку только с использованием Metacontroller.

Пример

Рассмотрим конкретный пример реализации паттерна Operator (Оператор). Здесь мы расширим пример из главы 22 «Контроллер» и определим CRD типа ConfigWatcher. Экземпляр этого CRD определяет ссылку на ресурс ConfigMap для наблюдения и то, какие поды должны перезапускаться при его изменении. Такой подход помогает устранить зависимость от ConfigMap в подах, так как нам не нужно изменять сами ресурсы ConfigMap и добавлять в них аннотации, отвечающие за запуск логики. Кроме того, в упрощенном примере контроллера, основанного на аннотациях, мы можем подключить ConfigMap только к одному приложению. С использованием CRD возможны произвольные комбинации из ресурсов ConfigMap и подов.

В листинге 23.5 показано, как выглядит ресурс ConfigWatcher.

Листинг 23.5. Простой ресурс ConfigWatcher

kind: ConfigWatcher

apiVersion: k8spatterns.io/v1

metadata:

  name: webapp-config-watcher

spec:

  configMap: webapp-config  

  podSelector:              

    app: webapp

 Ссылка на ConfigMap для наблюдения.

 Селектор меток для выбора перезапускаемых подов.

В этом определении атрибут configMap ссылается на имя ConfigMap, за которым ведется наблюдение. Поле podSelector — это коллекция меток и их значений, которые идентифицируют перезапускаемые поды.

В листинге 23.6 показано определение типа этого ресурса в виде CRD.

Листинг 23.6. ConfigWatcher CRD

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

metadata:

  name: configwatchers.k8spatterns.io

spec:

  scope: Namespaced            

  group: k8spatterns.io        

  version: v1                  

  names:

    kind: ConfigWatcher        

    singular: configwatcher    

    plural: configwatchers

  validation:

    openAPIV3Schema:           

      properties:

        spec:

          properties:

            configMap:

              type: string

              description: "Name of the ConfigMap"

            podSelector:

              type: object

              description: "Label selector for Pods"

              additionalProperties:

                type: string

 Связано с пространством имен.

 Выделенная группа API.

 Начальная версия.

 Уникальный тип этого CRD.

 Метки ресурсов для использования с такими инструментами, как kubectl.

 Схема OpenAPI V3 для этого CRD.

Чтобы наш оператор мог управлять ресурсами этого типа, необходимо привязать учетную запись ServiceAccount с соответствующими разрешениями для развертывания нашего оператора. C этой целью определим выделенную роль Role, как показано в листинге 23.7, которую позже используем в RoleBinding для ее привязки к ServiceAccount.

Листинг 23.7. Определение роли Role, открывающей доступ к ресурсу

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: config-watcher-crd

rules:

- apiGroups:

  - k8spatterns.io

  resources:

  - configwatchers

  - configwatchers/finalizers

  verbs: [ get, list, create, update, delete, deletecollection,

           watch ]

Объявив все эти CRD, можно определить ресурсы, как показано в лис­тинге 23.5.

Чтобы придать этим ресурсам практическую ценность, нужно реализовать контроллер, который будет наблюдать за указанными в них ресурсами ConfigMap и перезапускать поды при их изменении.

Мы возьмем за основу сценарий контроллера из листинга 22.2 и изменим цикл обработки событий.

Наблюдая за изменениями в ConfigMap, вместо проверки конкретной аннотации мы будем запрашивать все ресурсы типа ConfigWatcher и проверять, указан ли изменившийся ConfigMap в атрибуте configMap:. В листинге 23.8 показан только цикл согласования. Полный пример вы найдете в репозитории Git, где также имеются подробные инструкции по установке этого оператора.

Листинг 23.8. Цикл согласования в контроллере WatchConfig

curl -Ns $base/api/v1/${ns}/configmaps?watch=true | \     

while read -r event

do

  type=$(echo "$event" | jq -r '.type')

 

  if [ $type = "MODIFIED" ]; then                         

 

    watch_url="$base/apis/k8spatterns.io/v1/${ns}/configwatchers"

    config_map=$(echo "$event" | jq -r '.object.metadata.name')

 

    watcher_list=$(curl -s $watch_url | jq -r '.items[]') 

 

    watchers=$(echo $watcher_list | \                     

               jq -r "select(.spec.configMap == \"$config_map\") |

               .metadata.name")

 

    for watcher in watchers; do                           

      label_selector=$(extract_label_selector $watcher)

      delete_pods_with_selector "$label_selector"

    done

  fi

done

 Запуск потока событий для наблюдения за изменениями в ConfigMap в заданном пространстве имен.

 Проверять только события MODIFIED.

 Получить список всех установленных ресурсов ConfigWatcher.

 Извлечь список всех элементов ConfigWatcher, ссылающихся на данный ConfigMap.

 Для каждого найденного ConfigWatcher остановить указанные поды через селектор. Логика для формирования селектора меток, а также остановки подов здесь опущена. Полную реализацию вы найдете в репозитории Git с примерами.

Этот контроллер можно протестировать с тем же примером веб-приложения в нашем репозитории Git, что и контроллер из главы 22 «Контроллер». Единственное его отличие в том, что здесь для настройки приложения используется неаннотированный ConfigMap.

Наш оператор на основе сценария командной оболочки получился достаточно функциональным, но также очевидно, что он по-прежнему довольно прост и не предусматривает обработку крайних случаев или ошибок. При желании вы сможете найти еще много интересных примеров промышленного уровня.

В списке Awesome Operators (http://bit.ly/2Ucjs0J) вы найдете множество действующих операторов, которые основаны на идеях, описанных в этой главе. Мы уже видели, как оператор Prometheus может управлять экземплярами Prometheus. Другой пример оператора, написанного на Golang, называется Etcd Operator и предназначен для управления хранилищем пар ключ/значение и автоматизации таких задач, как резервное копирование и восстановление базы данных.

Если вы ищете оператор, написанный на Java, обратите внимание на Strimzi Operator, который послужит вам отличным примером оператора, управляющего сложной системой обмена сообщениями в Kubernetes, такой как Apache Kafka. Еще одним интересным инструментом для разработки операторов на Java является JVM Operator Toolkit, который обес­печивает основу для создания операторов на Java и других языках JVM, таких как Groovy и Kotlin, а также содержит набор примеров.

Пояснение

Мы увидели, как можно расширить возможности платформы Kubernetes, но имейте в виду, что операторы не являются универсальным решением на все случаи жизни. Прежде чем приступать к созданию своего оператора, внимательно изучите свой случай, чтобы определить, соответствует ли он парадигме Kubernetes.

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

Операторы хорошо подходят для моделирования предметной логики, сочетающейся с декларативным способом обработки ресурсов в Kubernetes и использованием реактивных контроллеров.

В частности, операторы и CRD хорошо подходят в любой из следующих ситуаций, когда:

• требуется тесная интеграция с существующими инструментами Kubernetes, такими как kubectl;

• проект находится на старте и вы можете спроектировать приложение с нуля;

• очевидна выгода от концепций Kubernetes, таких как пути ресурсов, группы API, версии API и особенно пространства имен;

• необходима хорошая клиентская поддержка для доступа к API с часами, аутентификацией, авторизацией на основе ролей и селекторами метаданных.

Если ваш пользовательский сценарий соответствует этим критериям, но нужна большая гибкость в том, как пользовательские ресурсы могут быть реализованы и сохранены, подумайте об использовании пользовательского сервера API. При этом не стоит рассматривать точки расширения Kubernetes в качестве панацеи.

Если ваш случай использования не является декларативным, если данные для управления не подходят для модели ресурсов Kubernetes или вам не нужна тесная интеграция в платформу, вероятно, лучше всего написать свой автономный API и опубликовать его с помощью классического объекта Service или Ingress.

В документации Kubernetes также есть глава с предложениями по использованию контроллера, оператора, агрегации API или пользовательской реализации API.

Дополнительная информация

• Operator Example (http://bit.ly/2HvfIkV).

• Фреймворк оператора (http://bit.ly/2CKLYN1).

• OpenAPI V3 (http://bit.ly/2Tluk82).

• Kubebuilder (http://bit.ly/2I8w9mz).

• Клиентские библиотеки Kubernetes (http://bit.ly/2Sh1XYk).

• Metacontroller (https://metacontroller.app/).

• JVM Operator Toolkit (https://github.com/jvm-operators).

• Расширение API Kubernetes с помощью CustomResourceDefinitions (http://bit.ly/2uk6Iq5).

• Awesome Operators в действии (http://bit.ly/2Ucjs0J).

• Custom Resources и API Server Aggregations (http://bit.ly/2FrfR6I).

• Сравнение Kubebuilder, Operator Framework и Metacontroller (http://bit.ly/2FpO4Ug).

• TPR мертв! Kubernetes 1.7 включает CRD (http://bit.ly/2FQnCSA).

• Генерация кода для пользовательских ресурсов (https://red.ht/2HIS9Er).

• Простой Operator в Go (http://bit.ly/2UppsTN).

• Prometheus (http://bit.ly/2HICRjT).

• Etcd (http://bit.ly/2JTz8SK).

• Memhog (https://github.com/secat/memhog-operator).