DevOps Portal | Linux

Почему у разных ресурсов 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

Please open Telegram to view this post

VIEW IN TELEGRAM

Please open Telegram to view this post

VIEW IN TELEGRAM

👍21❤6

www.tgoop.com/loose_code/1206

4.58K viewsJul 11 at 06:35

Почему у разных ресурсов 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