Кратко

  • implementable фиксирует решение approver из затронутых SIG допустить KEP к реализации; оно не фиксирует ни merge кода, ни присутствие в конкретном релизе, ни включение функции в каком-либо кластере.
  • Веха релиза, Production Readiness Review, тесты, feature gate, нумерованный артефакт и поддержка оператора — разные записи, за которые отвечают разные участники.
  • Короткая квитанция от предложения до эксплуатации сохраняет эти передачи и не превращает одобрение дизайна в несуществующую гарантию сервиса.

Implementable — это решение о дизайне с ограниченным мандатом

Механизм Kubernetes Enhancement Proposal — не простая картотека пожеланий. Он создаёт проверяемую запись о мотивации, дизайне, ответственности, целях стабильности и движении через несколько циклов. В открытом процессе KEP сказано, что approver выбираются из затронутых SIG и именно они решают, когда KEP становится implementable. Там же различаются provisional, implemented, deferred, rejected, withdrawn и replaced. Процесс KEP

Поэтому implementable — не пустая метка. Она означает, что люди с полномочием оценивать данный дизайн в пределах соответствующих SIG согласны перейти к реализации. Но предел утверждения здесь и проходит. Статус не показывает, что определённый commit был влит, что конкретный релиз его принял или что администратор включил значение в apiserver, kubelet либо другом компоненте. Тем более он не заменяет решения организации, которая несёт стоимость инцидентов и обещает клиентам поддержку.

Соблюдение этой границы не обесценивает работу SIG. Напротив, оно не позволяет языку раздуть их решение до обещания, которого они не давали. Approver дизайна рассматривают архитектуру, API и зависимости между SIG. Оператор рассматривает ёмкость, дополнения, version skew, телеметрию, возможность отката и договор об обслуживании. Если и то и другое назвать единым «одобрением», из записи исчезает тот, кто несёт второй вид потерь.

Для целевого релиза нужна новая цепочка доказательств

Шаблон KEP прямо описывает следующий рубеж. Чтобы изменение рассматривалось для целевого релиза, связанная с KEP issue об enhancement должна указывать на веху до Enhancement Freeze. Список signoff не ограничивается implementable: в нём есть детали дизайна, план тестирования, критерии graduation, завершённая и одобренная Production Readiness Review, история реализации, пользовательская документация и дополнительные материалы. Шаблон требует возвращаться к списку каждый раз, когда enhancement рассматривают для вехи. Шаблон KEP

Такое повторение не является накоплением формальностей. Дизайн может быть достаточно зрелым, чтобы начать реализацию, и всё ещё не иметь достаточной актуальной доказательной базы для нынешнего цикла: могут отсутствовать тесты, устареть документация или потребоваться новый ответ на операционный вопрос из прошлого цикла. И наоборот, issue у вехи не доказывает, что закрыт весь список. Подменить «нацелено» словом «выпущено» — та же ошибка в доказательствах, что и подменить «реализуемо» словом «влито».

Production Readiness Review добавляет ещё одну поверхность принятия решения. Kubernetes описывает её как работу команды, отдельной от SIG leads, которая смотрит на observability, масштабируемость, пригодность к поддержке, безопасную эксплуатацию и способность отключить функцию или выполнить rollback. Начиная с Kubernetes 1.21 одобрение PRR необходимо, чтобы enhancement стал частью релиза. Процесс Production Readiness Review

Это сильная upstream-граница для включения в проект, но не гарантия для каждой среды. PRR не решает, приемлема ли конкретная комбинация CNI, CSI, admission policy, ёмкости, дистрибутива или клиентского договора. Она доказывает, что независимая проверка выполнила собственную задачу; она не переносит операционную обязанность на другую организацию.

Feature gate описывает настройку компонента, а не всеобщее внедрение

Справочник feature gates определяет gate как пару key=value, задаваемую компоненту Kubernetes через --feature-gates. Каждый компонент поддерживает только gates, относящиеся к его функциям; справочник отдельно указывает Alpha, Beta, stable, а также версии появления и удаления. Kubernetes Feature Gates

Это ответ на вопрос «как можно настроить?», а не «кто настроил?». Наличие gate в документации не говорит, что он имеет значение true в данном кластере. Функции могут требовать согласованных настроек нескольких компонентов, дистрибутив может вводить свои ограничения, а оператор вправе оставить опцию выключенной, пока не проверит наблюдаемость, семантику хранения, version skew и путь отката. Upstream предоставляет ручку; он не поворачивает её вместо оператора.

Примеры graduation в шаблоне KEP сохраняют ту же ступенчатость. Alpha требует реализации за feature flag и первоначальных e2e-тестов. Beta требует выполнения функциональных требований, требований к безопасности, мониторингу и тестам, а также работы с известными пробелами. GA учитывает реальное использование, время для обратной связи и разрешение обратной связи из Beta; необязательными не являющиеся функции нуждаются также в conformance tests. Шаблон KEP Это доказательства зрелости в жизненном цикле проекта, а не разрешение конкретному оператору на внедрение.

Нумерованный релиз также не говорит от имени оператора

Страница релизов Kubernetes отдельно фиксирует ветки релиза, версии x.y.z, патчи и даты EOL. Это более сильная публичная квитанция, чем статус предложения: она позволяет найти артефакты, выпущенные проектом, и его окно поддержки на уровне проекта. Релизы Kubernetes Но это окно не сообщает, что упаковал управляемый сервис, совместим ли отдельный кластер или взял ли кто-то на себя обработку инцидентов.

Репозиторий enhancements полезен для наблюдения за KEP, issues и циклами, но он не служит доказательством внедрения. Kubernetes enhancements Прямой переход от KEP к релизу, от релиза к конфигурации и от конфигурации к поддержке на каждом шаге убирает единственного субъекта, который способен подтвердить следующий шаг.

Лучше хранить небольшую квитанцию от предложения до эксплуатации: идентификатор KEP и неизменяемую редакцию; владельца и затронутые SIG; approver и статус; веху и freeze; запрос PRR и его результат; редакции кода и тестов; gate, компонент и значение по умолчанию; нумерованный релиз и его заметку; границу дистрибутива; и явное заявление оператора о включении, поддержке, version skew и rollback. Такая квитанция не учреждает новую власть. Она возвращает каждое суждение его автору.

Это согласуется с различием, которое проводит Lu Heng: участие и экспертиза могут быть доказательством, но не создают автоматически мандат отсутствующих; операционные последствия должны ясно принимать на себя те, кто их несёт. The Multi-Stakeholder Mirage Running-Code Primacy

Чего эта запись не доказывает

Источники не доказывают статус именованного KEP, включение изменения в определённый релиз, активацию какого-либо gate в конкретном кластере или обязательство дистрибутива либо оператора по совместимости и поддержке. Они не оценивают поставщика, клиента, кластер или инцидент. Предложенная здесь квитанция — редакционная рекомендация Daniel Kade, а не правило Kubernetes.

Источники