Перейти к содержанию

Проверяемая структура Kustomize

Ненормативный пример для INF-K8S-001, INF-K8S-002, INF-K8S-004–INF-K8S-006 и INF-PKG-002. Он показывает структуру render, но не является готовым production deployment.

Состав и назначение

base/ содержит общие Deployment, Service и ServiceAccount. Overlays не копируют base:

Overlay Изменение Что он позволяет проверить
local namespace example-local базовый render и контракт probes
non-production namespace example-non-production отдельную среду без production topology
production 3 replicas, topology spread, PDB распределение replicas и ограничение добровольных disruptions

Deployment также показывает отключённый service-account token, non-root container, read-only filesystem, dropped capabilities, seccomp, requests, limits и три раздельных probe endpoint.

Ограничения применимости

Пример применим к stateless HTTP workload без persistent volumes и migration job. Production overlay иллюстрирует распределение replicas только между worker nodes и не задаёт отказоустойчивость control plane, storage, ingress, DNS или secret delivery.

Что требуется заменить

До использования в проекте:

  1. замените example-api на стабильное имя workload и labels;
  2. замените иллюстративный image на release reference из разрешённого registry;
  3. настройте requests и limits по измеренной нагрузке, а не по значениям примера;
  4. согласуйте пути и thresholds probes с фактическим startup/readiness/liveness контрактом приложения;
  5. выберите topology key по реально доступным failure domains;
  6. добавьте route, policy, secrets и observability resources только для объявленных manifest capabilities.

Детерминированный render

Выполняйте команды из этого каталога:

kubectl kustomize overlays/local >local.yaml
kubectl kustomize overlays/non-production >non-production.yaml
kubectl kustomize overlays/production >production.yaml

Повторный render того же commit и версии kubectl не должен менять файлы:

kubectl kustomize overlays/production >production.next.yaml
cmp production.yaml production.next.yaml

Полученные YAML-файлы являются build artifacts. Их не следует вручную редактировать или хранить как параллельный источник правды.

Проверки без изменения кластера

Клиентская проверка синтаксиса:

kubectl apply --dry-run=client --filename production.yaml

При наличии test-кластера server-side dry-run дополнительно проверяет доступные API, admission policies и schema:

kubectl apply --dry-run=server --filename production.yaml

Проверьте итоговый image и ключевые production-поля:

kubectl get --filename production.yaml \
  --output=jsonpath='{range .items[?(@.kind=="Deployment")]}image={.spec.template.spec.containers[0].image} replicas={.spec.replicas}{"\n"}{end}'

Ожидается immutable release image и replicas=3. Наличие трёх replicas само по себе не доказывает high availability: scheduler должен успешно распределить pods по выбранному topologyKey, а capacity и platform dependencies должны соответствовать заявленному failure-tolerance contract.

Что намеренно не показано

В примере нет APISIX route, certificate, NetworkPolicy, autoscaling, secrets, persistent data, migration job и telemetry resources. Их нельзя добавлять механически: сначала проект объявляет соответствующую capability и архитектурный контракт, затем выбирается инфраструктурная реализация.

Удаление локальных render artifacts:

rm -f local.yaml non-production.yaml production.yaml production.next.yaml