Summary: способы расширить Kubernetes

Большая часть «полезного», что ставят в production-кластер, — расширения, а не built-in компоненты. cert-manager, Prometheus, Istio, ArgoCD, Linkerd, External Secrets, KEDA, Strimzi — всё это extensions. Этот урок собирает все шесть механизмов расширения Kubernetes в один граф решений и даёт ясные критерии: «у меня есть задача X, какой механизм мне подходит?».

Шесть механизмов расширения Kubernetes

1. CRD + Custom Controller (Operator) — 99% случаев. Декларативный новый kind в API + Pod-controller, реконсилирующий состояние.
2. Aggregated API server — отдельный API server рядом с kube-apiserver. Для случаев, когда нужно custom storage или нестандартные subresources.
3. Admission webhooks (mutating и validating) — middleware между authn/authz и записью в etcd. Для validation/mutation на admission time.
4. Authentication webhooks — custom authentication (token validators). Если корпоративная identity не покрывается built-in OIDC.
5. Authorization webhooks — custom authorization (Sentinel, OPA-style RBAC поверх external policy engine).
6. CSI / CNI / CRI / Device plugins — расширения для storage drivers, network plugins, container runtimes, hardware devices (GPU, FPGA, RDMA).

Decision tree: какой механизм для какой задачи

Discovery: что установлено в кластере

Все extension механизмы оставляют следы в API server discovery — kubectl api-resources показывает всё:

# Полный список — built-in + CRDs + aggregated
kubectl api-resources

# Только CRDs
kubectl get crd

# Только определённая group (всё в этой group — либо built-in, либо CRD, либо AAS)
kubectl api-resources --api-group=cert-manager.io
kubectl api-resources --api-group=metrics.k8s.io

# Webhook configurations
kubectl get mutatingwebhookconfigurations
kubectl get validatingwebhookconfigurations
kubectl get validatingadmissionpolicy
kubectl get validatingadmissionpolicybinding

# Aggregated APIs
kubectl get apiservice                 # status Available покажет, какие работают
kubectl get apiservice | grep -v Local # только aggregated

# CSI drivers
kubectl get csidriver
kubectl get csinode

# Device plugins регистрируются через kubelet — проверить через node capacity
kubectl describe node | grep -A 10 Capacity
# Capacity: nvidia.com/gpu: 4 — есть Device Plugin для NVIDIA

Почему extensibility — это killer feature K8s

Сравнение с предшественниками:

• Apache Mesos — мощный планировщик, но extensibility — через Mesos frameworks (Marathon, Chronos), каждый — свой dialect. Нет единого API для third-party.
• Docker Swarm — простой и закрытый. Extensions через Swarm plugins ограничены networking/storage.
• HashiCorp Nomad — конкурент K8s по orchestration; имеет plugin system, но экосистема меньше.

Kubernetes выиграл потому, что дал universal extension API: любой vendor может написать operator под свой продукт, и пользователи получают единообразный интерфейс — kubectl get <my-thing>. Это превратило K8s в универсальный control plane: не «оркестратор контейнеров», а «декларативная платформа для любых ресурсов». Crossplane даже provisioning AWS S3 buckets через K8s API делает.

CKAD task examples

Типичные задачи на экзамене (или production) по теме extension:

1. Discover, что в кластере установлено:

   kubectl get crd
   kubectl api-resources | grep -v 'true' | head -50  # фильтр built-in
   kubectl get apiservice | grep -v Local

2. Найти CR instances данного типа:

   kubectl get certificates -A
   kubectl get prometheuses -A
   kubectl get applications -n argocd

3. Понять, почему CR не реконсилируется:

   # Описание CR — что в .status?
   kubectl describe certificate my-cert
   # Если status пустой / Pending → controller не работает
   kubectl get deployment -A | grep -i controller
   kubectl logs -n cert-manager deployment/cert-manager --tail=100

4. Диагностика admission блока:

   # 'Error from server: admission webhook denied: ...' — ясно из текста
   kubectl create -f my-deployment.yaml
   # 'admission webhook "policy.kyverno.io" denied the request: require-labels'

5. Diagnose metrics-server:

   kubectl top pod  # Error: Metrics API not available
   kubectl get apiservice v1beta1.metrics.k8s.io  # Available=False
   kubectl logs -n kube-system deployment/metrics-server

Killer-моменты

• CRD + Operator покрывают 99% задач. Прежде чем рассматривать AAS / authn-webhook / etc — проверь, можно ли решить через CRD.
• Все extension механизмы интегрированы в discovery. kubectl api-resources показывает built-in рядом с CRDs рядом с aggregated. Пользователю не нужно знать, как именно реализован resource.
• Extensibility — это причина победы Kubernetes. Crossplane делает K8s universal control plane; cert-manager + Prometheus Operator + ArgoCD делают K8s self-contained platform. Без extension механизмов это был бы просто оркестратор контейнеров.
• Расширения тоже могут сломать кластер. Webhook с failurePolicy: Fail и упавшим Pod-ом блокирует все matching requests. Сложный operator с багом может удалить нужный StatefulSet. К extensions нужно относиться как к production code.
• CKAD требует discovery скиллы, не development. Знать команды kubectl get crd, kubectl api-resources, читать .status CR — всё, что нужно.