Operators и CRDs
Тема дорожной карты · Kubernetes
Операторы Kubernetes — программные расширения, использующие CustomResourceDefinitions (CRD) и пользовательские контроллеры для кодирования предметно-специфичных операционных знаний — например, провизирование баз данных, планирование резервного копирования или ротация сертификатов — непосредственно в API Kubernetes. Оператор отслеживает изменения своих пользовательских ресурсов через механизм informer/reflector Kubernetes и согласует состояние кластера с желаемой спецификацией, следуя тому же паттерну цикла управления, что и встроенные контроллеры Deployment и ReplicaSet. Популярные операторы: prometheus-operator для управления Prometheus, Alertmanager и ресурсами ServiceMonitor; cert-manager для автоматизации TLS-сертификатов через CRD Certificate и Issuer; и strimzi для запуска Apache Kafka на Kubernetes. Операторы обычно устанавливаются через kubectl apply или Helm-чарты, а их CRD управляются через kubectl get crds и kubectl describe crd <name>. Operator Framework, Kubebuilder SDK и библиотека Kopf для Python — распространённые инструменты для создания пользовательских операторов; готовые операторы распространяются через OperatorHub.io.
Как это работает
Operators и CRDs покрывает day-2 работу эксплуатации Kubernetes-кластера: обновления, node maintenance, capacity planning, backup и DR, оптимизация стоимости, multi-tenancy изоляция. Обновления следуют графику deprecation Kubernetes (один minor каждые 4 месяца); node maintenance использует cordon + drain; backups через Velero или CSI snapshots. DR требует регулярных тренировок — не только документации.
Когда применять
Установите Operators и CRDs практики до того, как кластер станет критичным для выручки. Запланируйте первую DR-тренировку в течение 30 дней после go-live; задокументируйте процедуру обновления до того, как первая версия станет EOL; настройте cost-дашборды (Kubecost, OpenCost) до того, как счёт станет сюрпризом. Operations-долг копится тихо — гасите его по каденции, не в режиме паники.
Типичные ошибки
Ловушки cluster operations: пропуск minor-обновлений до принуждения (3+ версий позади = кошмар обновления); cluster-wide cluster-admin tokens, которые никто не ротирует; нет задокументированного runbook на случай "control plane умер" (реальная возможность на self-managed кластерах); cost-сюрпризы (idle GPU-ноды, over-provisioned requests, orphan PVCs). Тренируйте incident response на non-production кластере ежемесячно.