Релиз-цикл, API versioning, deprecation

Kubernetes — живой стандарт. Раз в четыре месяца релизится новая минорная версия, добавляются alpha-фичи, бывшие beta становятся GA, что-то deprecated и удаляется. Без понимания этого ритма легко получить ситуацию, когда YAML, работавший в одном кластере, не применяется в другом. Этот урок — про то, как читать версии Kubernetes и не оказаться в эту ловушку на проде или на экзамене.

Release cadence: 3 минорных в год

Kubernetes выпускает примерно три минорных релиза в год — раньше было четыре, с 2021 года перешли к трём (release-1.X каждые 4 месяца). Минорная версия — это номер вида 1.35. Примерные даты на ближайший cycle (на май 2026):

• v1.34 — август 2025
• v1.35 — декабрь 2025 (текущая stable на май 2026, target курса)
• v1.36 — апрель 2026
• v1.37 — август 2026 (ожидается)

Каждый минорный релиз состоит из стадий:

1. Enhancement freeze — после этой даты в релиз не попадают новые KEP (Kubernetes Enhancement Proposals).
2. Code freeze — заморозка кода, остаются только bug fixes.
3. Release — основной релиз v1.X.0.
4. Patch releases — v1.X.1, v1.X.2, … каждые ~2-4 недели с CVE/bugfixes.

Параллельно работают три release branches: текущая, N-1, N-2. То есть в любой момент поддерживается три минорные версии, плюс security patches на ещё одну в течение нескольких месяцев.

С версии v1.19 (август 2020) support window расширился: каждый минорный получает patches примерно 14 месяцев. До этого было 9 месяцев — слишком короткий цикл для энтерпрайз-апдейтов.

Версия = v1.X.Y, что значит каждая часть

Semantic versioning, но с особенностями Kubernetes:

• Major (1.X.Y) — за всю историю менялся один раз (с 0 на 1 в 2015). Изменение major означает breaking changes на уровне всего API.
• Minor (1.35.Y) — каждые 4 месяца. Может содержать deprecated API removals (после warning period), новые beta/GA features.
• Patch (1.35.3) — bug fixes, security, без новых features. Безопасны для применения на проде.

Версия клиента kubectl обычно совместима с одной минорной версией кластера в обе стороны: kubectl v1.35 работает с кластерами v1.34, v1.35, v1.36. Дальше — undefined behavior. На практике расхождение в 2-3 минорных часто работает, но это not supported.

kubectl version показывает обе версии:

$ kubectl version
Client Version: v1.35.2
Kustomize Version: v5.4.2
Server Version: v1.35.0

API Groups: как структурирован API

Kubernetes API — это не один монолит, а набор API groups. Каждая group версионируется отдельно. Это даёт стабильность core ресурсов (Pod, Service) при свободе экспериментов с новыми типами (HorizontalPodAutoscaler, NetworkPolicy).

Ключевые API groups, которые встретятся на CKAD:

В манифестах группа указывается через apiVersion:

# core API group (без префикса)
apiVersion: v1
kind: Pod

# apps API group
apiVersion: apps/v1
kind: Deployment

# networking API group
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

Команда kubectl api-versions показывает все доступные на кластере API groups и версии. kubectl api-resources — все типы объектов с группами:

$ kubectl api-resources --api-group=apps
NAME            SHORTNAMES   APIVERSION   NAMESPACED   KIND
deployments     deploy       apps/v1      true         Deployment
replicasets     rs           apps/v1      true         ReplicaSet
statefulsets    sts          apps/v1      true         StatefulSet
daemonsets      ds           apps/v1      true         DaemonSet

Versioning: alpha → beta → GA

Каждый API внутри группы проходит три стадии зрелости:

Alpha (v1alpha1, v1alpha2)

• Может содержать баги, ломаться между релизами без предупреждения.
• По умолчанию выключен — нужно явно включать через --feature-gates=.
• Может быть удалён в любом релизе без deprecation period.
• Не для production. Используется для early feedback от сообщества.

Beta (v1beta1, v1beta2)

• Хорошо протестирован, тесты CI зелёные.
• По умолчанию включён до версии v1.24. С v1.24 — новые beta API выключены по умолчанию (KEP-3136 — изменение политики после неконтролируемого использования CronJob и Ingress v1beta1).
• Schema стабилен, могут меняться defaults.
• Поддерживается минимум 9 месяцев или 3 минорных релиза, что больше.

GA / Stable (v1, v2)

• Production-ready, schema заморожен, обратная совместимость гарантирована в пределах major version.
• Поддерживается 12+ месяцев warning перед удалением.
• Удаляется только при выходе следующей major version или с предупреждением минимум за год.

Примеры из истории:

• Ingress прошёл путь extensions/v1beta1 → networking.k8s.io/v1beta1 → networking.k8s.io/v1. Старая версия extensions/v1beta1 удалена в v1.22 (август 2021), что сломало YAML многих организаций.
• CronJob дозрел: batch/v1beta1 → batch/v1 в v1.21, удалён старый в v1.25.
• HorizontalPodAutoscaler имеет несколько GA: autoscaling/v1 (basic), autoscaling/v2 (с custom metrics) — обе production-ready, но v2 — рекомендуемый.
• Sidecar containers (новый тип init container с restartPolicy: Always) прошёл alpha в v1.28, beta в v1.29, GA в v1.33.

Feature gates

Feature gates — флаги, включающие/выключающие конкретные фичи. Передаются через CLI компонентам:

kube-apiserver --feature-gates=InPlacePodVerticalScaling=true,EphemeralContainers=false
kubelet --feature-gates=InPlacePodVerticalScaling=true

В minicluster (kind/minikube) feature gates можно включить через конфиг:

# kind config
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  InPlacePodVerticalScaling: true

Для большинства CKAD-задач feature gates не понадобятся: все GA-фичи включены по умолчанию. Но знать, что они существуют, важно — иногда beta-фича не работает «потому что не включена», и kubectl explain показывает поле, которого нет в running cluster.

Deprecation policy: как фичи удаляют

Kubernetes публикует официальную deprecation policy. Ключевые правила:

• GA API не удаляется минимум 12 месяцев после deprecation announcement. На практике — дольше, потому что есть пользователи с медленными апдейтами.
• Beta API поддерживается минимум 9 месяцев или 3 минорных релиза после deprecation. Это меньше, чем GA, но достаточно для миграции.
• Alpha API может быть удалён в любом релизе без предупреждения.
• GA functionality не может быть удалена в пределах одной major version — обратная совместимость гарантирована.

Когда API depreciated, kubectl apply показывает warning:

Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+,
unavailable in v1.22+; use networking.k8s.io/v1 Ingress

Для миграции YAML между версиями есть утилита kubectl convert (часть kubectl или отдельный plugin):

kubectl convert -f old-ingress.yaml --output-version networking.k8s.io/v1 -o yaml > new-ingress.yaml

Managed K8s lag: что используется на проде

Managed-сервисы публикуют список поддерживаемых версий. Они почти всегда отстают от upstream — некоторые на месяцы, некоторые на год:

На EKS вы часто не увидите свежих API (alpha/beta features). Например, Gateway API (gateway.networking.k8s.io/v1) — это external CRD-проект SIG-Network, v1.0 (GA) релиз состоялся в октябре 2023, текущий stable на 2026 — v1.2/v1.3. Чтобы использовать его на любом кластере, CRDs Gateway API нужно установить отдельно (kubectl apply из релиза проекта); версия CRDs не привязана к минору Kubernetes.

Что важно для CKAD

На экзамене вы будете писать только GA API: Pod (v1), Deployment (apps/v1), Service (v1), ConfigMap/Secret (v1), Job/CronJob (batch/v1), Ingress (networking.k8s.io/v1), NetworkPolicy (networking.k8s.io/v1). Никаких alpha/beta — задачи не требуют экзотики.

Но знать, что такое versioning, важно: иногда задача требует, например, HPA — autoscaling/v2, а не autoscaling/v1. Если вы напишете старый — задача засчитается, но без custom metrics.