Почему у разных ресурсов Kubernetes разные значения apiVersion?Kubernetes API организованы в группы (API groups)
Существует два типа API-групп:
🔹
Core-группа → Без названия группы, просто
apiVersion: v1🔹
Именованные группы → Например,
apps,
batch,
networking.k8s.io и др.
Например, можно задаться вопросом — почему
Service относится к core API?
🔹Такие ресурсы, как
Service,
Pod,
Namespace,
Secret и т.п., были частью оригинальной спецификации Kubernetes.
🔹Это базовые строительные блоки (primitive objects).
🔹Поэтому они находятся в core-группе (
apiVersion: v1).
А почему, например,
ReplicaSet — в API-группе
apps?
🔹
ReplicaSet — это контроллер, а не примитивный объект.
🔹Он появился позже как часть более продвинутой системы управления нагрузкой (вместе с
Deployment,
StatefulSet и др.).
🔹Поэтому он размещён в именованной группе —
apps.
Зачем вообще нужны API-группы?- Kubernetes логически и модульно организует ресурсы.
- Такое разделение позволяет:
🔹Версионировать функциональность независимо
🔹Развивать контроллеры, не затрагивая стабильность core-части
🔹Поддерживать обратную совместимость
🔹Core-ресурсы стабильны и зрелы (v1)
- Новые фичи проходят стадии:
🔹v1alpha1 (ранний этап)
🔹v1beta1 (предварительный релиз)
🔹v1 (стабильный релиз)
Примеры:
🔹batch/v1 → CronJob
🔹autoscaling/v2 → HPA
Надеюсь, теперь стало понятнее, зачем Kubernetes использует разные API-группы для разных типов ресурсов
👉
DevOps Portal 
