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

Подготовка образа с хуком

Если посмотреть на скрипт, то видно, что используются команды kubectl и jq. Это означает, что в образе должны быть следующие вещи: наш хук, shell-operator, который будет следить за событиями и запускать хук, а также используемые хуком команды (kubectl и jq). На hub.docker.com уже есть готовый образ, в котором упакованы shell-operator, kubectl и jq. Остаётся добавить хук простым Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

$ docker build -t registry.example.com/my-operator:v1 . 
$ docker push registry.example.com/my-operator:v1

Запуск в кластере

Ещё раз посмотрим на хук и на этот раз выпишем, какие действия и с какими объектами он производит в кластере:

1. подписывается на события создания namespace’ов;
2. создаёт секрет в namespace’ах, отличных от того, где запущен.

Получается, что pod, в котором будет запущен наш образ, должен иметь разрешения на эти действия. Это можно сделать с помощью создания своего ServiceAccount. Разрешение нужно делать в виде ClusterRole и ClusterRoleBinding, т.к. нам интересны объекты со всего кластера.

Итоговое описание в YAML получится примерно таким:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

Запустить собранный образ можно в виде простого Deployment:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

Для удобства создаётся отдельный namespace, где будет запускаться shell-operator и применяются созданные манифесты:

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

На этом всё: shell-operator запустится, подпишется на события создания namespace’ов и будет запускать хук, когда нужно.

Таким образом, простой shell-скрипт превратился в настоящий operator для Kubernetes и работает как составная часть кластера. И всё это — без сложного процесса разработки операторов на Golang:

Есть и другая иллюстрация на этот счёт…

Её смысл мы раскроем подробнее в одной из следующих публикаций.

Фильтрация

Слежение за объектами — это хорошо, но зачастую бывает необходимость реагировать на изменение каких-то свойств объекта, например, на изменение количества реплик в Deployment«е или на изменение лейблов объекта.

Когда приходит событие, shell-operator получает JSON-манифест объекта. Можно выделить в этом JSON интересующие нас свойства и запускать хук только при их изменениях. Для этого предусмотрено поле jqFilter, где нужно указать выражение jq, которое будет применено к JSON-манифесту.

Например, чтобы реагировать на изменение лейблов у объектов Deployment, нужно отфильтровать поле labels из поля metadata. Конфиг будет такой:

cat <


Это выражение в jqFilter превращает длинный JSON-манифеста Deployment’а в короткий JSON с лейблами:

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

[{ "binding": "every 10 min"}]

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH