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