Kubernetes 1.8: RBAC стабилен, CRD в beta - смотрим на операторы

Kubernetes 1.8 вышел на прошлой неделе. Два события заслуживают внимания: RBAC переведён в v1 stable (то самое финальное «больше не трогаем API»), и Custom Resource Definitions выходят в beta. Мы обновили managed-кластеры и сразу уткнулись в любопытную возможность.

RBAC: stable означает именно stable

Технически RBAC был GA с 1.6, но rbac.authorization.k8s.io/v1 как финальная версия API появляется только сейчас. В 1.8 из кода убраны заглушки совместимости с alpha-объектами, и это хорошо: меньше неявных конвертаций, поведение предсказуемее.

Мы переработали RBAC-манифесты в июле под v1beta1. При обновлении до 1.8 всё мигрировало автоматически - apiserver конвертирует объекты при чтении и хранит в новой версии. Проверили выборочно через kubectl get clusterrolebinding -o yaml - версия правильная, объекты в порядке.

Одно практическое изменение: аудит-лог в 1.8 стал заметно подробнее. Теперь можно задать policy-файл с уровнями None / Metadata / Request / RequestResponse на уровне отдельных групп ресурсов. До этого аудит был либо весь либо никакой - сейчас можно писать только то что реально нужно, без мегабайтов JSON про get pods от kube-controller-manager.

CRD: это не просто хранилище конфигов

Custom Resource Definitions - это механизм добавить в kube-apiserver собственный тип объектов. Синтаксически это простой манифест:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: etcdclusters.etcd.database.coreos.com
spec:
  group: etcd.database.coreos.com
  names:
    kind: EtcdCluster
    plural: etcdclusters
  scope: Namespaced
  version: v1beta1

После применения этого манифеста кластер понимает kubectl get etcdclusters - такой же объект первого класса как Pod или Deployment. Сохраняется в etcd, возвращается через API, работает с kubectl apply и kubectl delete.

Само по себе это просто хранилище. Ценность появляется когда рядом запускается контроллер - процесс который смотрит на состояние этих объектов и приводит реальный мир в соответствие. Такая связка называется оператором.

До CRD расширить API можно было через ThirdPartyResources - предшественник, который 1.8 официально удалил. Если у кого остались объекты под extensions/v1beta1 с kind: ThirdPartyResource - пора мигрировать, это уже не работает.

etcd-operator: первая практическая проба

Мы смотрим на etcd-operator от CoreOS как на первый реальный случай использования CRD. Задача простая: автоматизировать бэкапы etcd, которые сейчас делаются вручную через скрипты на cron.

etcd-operator делает следующее: создаёт CRD EtcdCluster, запускает контроллер-под, и дальше достаточно создать объект:

apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: etcd-backup-target
  namespace: kube-system
spec:
  size: 3
  version: "3.2.3"
  backup:
    backupIntervalInSecond: 1800
    maxBackups: 5
    storageType: S3
    s3:
      s3Bucket: our-k8s-etcd-backups
      awsSecret: aws-s3-creds

Контроллер подхватывает объект и управляет кластером etcd, включая периодические снапшоты в S3. Разворачивать не торопимся - хочется понять поведение при сбоях прежде чем доверять этому продуктивный etcd. Но на тестовом стенде выглядит убедительно: оператор восстановил кластер после убийства одного из трёх подов без нашего участия.

Почему это меняет подход к автоматизации

Раньше для чего-то подобного писали: bash-скрипт + cron + набор if-ов для проверки что snaphot удался + алерт в случае провала. Это работает, но логика размазана между несколькими местами.

Оператор переносит логику управления в кластер. Декларируешь желаемое состояние - оператор сам следит чтобы реальное состояние ему соответствовало. Это та же модель что у Deployment и ReplicaSet, просто для произвольного сложного сервиса.

Понятно что CRD в beta значит отсутствие гарантий стабильности API и возможные изменения. Мы это учитываем - на продуктив идём только после понимания граничных случаев, не сразу.

Что ещё в 1.8

Кратко о вещах которые потрогали:

• Volume Snapshots в alpha - создание снапшотов PersistentVolume через API. На AWS EBS в теории работает, на практике alpha-фичи на продуктив не берём.
• PodDisruptionBudget переведён в policy/v1beta1 - стало удобнее работать с rolling update при наличии ограничений на минимум доступных реплик.
• kubectl rollout history теперь показывает change-cause если аннотацию выставить - мелочь, но приятно когда разбираешь что и когда менялось.

Обновление с 1.7 на 1.8 прошло без происшествий - стандартный drain каждой ноды по очереди, обновление kubeadm и компонентов control plane. Единственный момент: если на кластере есть ThirdPartyResources - сначала их мигрировать, потом обновляться.

Продолжаем смотреть на экосистему операторов. CRD открывает возможность описывать сложные stateful-сервисы в терминах Kubernetes - это интереснее чем кажется на первый взгляд.