Кластеры Kubernetes, созданные Cozystack, полностью проходят набор тестов на соответствие CNCF. Этот набор отвечает на один узкий вопрос, и это вопрос, с которого начинается каждая оценка: это настоящий Kubernetes или что-то в форме Kubernetes? Соответствующий кластер запускает стандартные манифесты, Helm-чарты и операторы без диалекта конкретного поставщика.
Ниже приведены два независимых набора результатов, из двух форм использования платформы — кластер, которым вы управляете самостоятельно, и хостинговая платформа, построенная на нём. Вместе они охватывают каждый релиз Kubernetes, который предлагает платформа.
Каждый прогон ниже — это кластер Kubernetes тенанта, созданный из каталога, протестированный
с помощью Sonobuoy в режиме certified-conformance на образе соответствия, зафиксированном
для конкретной версии. Все прогоны состоялись 19 августа 2026 года на установке Cozystack
v1.6.1.
| Kubernetes | Пройдено | Провалено | Тестов в наборе |
|---|---|---|---|
| v1.35.6 | 441 | 0 | 7355 |
| v1.34.9 | 424 | 0 | 7144 |
| v1.33.13 | 419 | 0 | 6741 |
| v1.32.13 | 411 | 0 | 6624 |
| v1.31.14 | 404 | 0 | 6607 |
Результаты для v1.35 и v1.34 отправлены в репозиторий соответствия CNCF. Программа принимает текущий релиз Kubernetes и два предыдущих, и, поскольку сейчас текущим является v1.36, это самые новые релизы, которые предлагает платформа.
| Kubernetes | Результат | Где |
|---|---|---|
| v1.35 | Пройдено | v1.35/hikube |
| v1.34 | Пройдено | v1.34/hikube |
| v1.33 | Пройдено | v1.33/hikube |
Записи Hikube — это официальные заявки CNCF, поданные Hidora как «hosted»-платформа и постоянно хранящиеся в собственном репозитории CNCF с полными журналами тестов. Два набора намеренно охватывают разные формы: дистрибутив, который вы устанавливаете и эксплуатируете, и управляемый сервис, который эксплуатирует кто-то другой за вас.
Различие между записью в реестре и прогоном стоит держать в голове. Запись в реестре CNCF сертифицирует конкретный продукт конкретной версии. Прогон соответствия говорит вам, что программное обеспечение ведёт себя так, как должен вести себя Kubernetes — и это то, что реально нужно знать большинству оценок.
Обратите внимание на более старые релизы. Соответствие держится на v1.31 так же, как на v1.35, что важно, если вы мигрируете с существующей платформы: вы можете перейти на Cozystack на той версии Kubernetes, которую используете сегодня, и обновиться позже, по своему графику, а не делать оба шага одновременно. При этом v1.33 и более старые версии больше не получают обновлений от вышестоящего проекта — только три последних минорных релиза их получают, — поэтому относитесь к ним как к пути миграции, а не как к пункту назначения.
Возьмём последний релиз в качестве примера:
Ran 441 of 7355 Specs in 7202.504 seconds
SUCCESS! -- 441 Passed | 0 Failed | 0 Pending | 6914 Skipped
API server: v1.35.6
Node health: 2/2
Pods health: 17/17
Кластер Kubernetes тенанта, предоставленный из каталога с kind: Kubernetes, два worker-узла,
протестированный с Sonobuoy в режиме certified-conformance на зафиксированном образе
соответствия для его точной версии. Не специальная сборка и не лабораторная установка: тот
же ресурс, который создаёт для себя тенант. Остальные четыре прогона следовали тому же
рецепту на своих собственных кластерах.
Два свойства кластера имели значение, и оба стоит планировать, а не обнаруживать по ходу дела:
Отдельный etcd. По умолчанию кластеры тенантов на одной установке делят один etcd, каждый
под собственным префиксом ключа. Сжатие (compaction) в etcd глобальное, а не по префиксу,
поэтому API-сервер работает с --etcd-compaction-interval=0 — сжатие в интересах одного
тенанта обрезало бы историю у соседей. Один тест соответствия ждёт сжатия, которое поэтому
никогда не наступает, и проваливается по тайм-ауту. Выделение тенанту собственного etcd
убирает это ограничение.
Включённое сжатие. При наличии отдельного etcd задайте интервал явно через спецификацию приложения, а не патчем деплоймента:
spec:
controlPlane:
apiServer:
extraArgs:
- --etcd-compaction-interval=5m
Решите оба вопроса на этапе создания. Перенос живого кластера на другой etcd не является поддерживаемой миграцией и оставляет существующие узлы не способными принимать новые поды.
Любую установку Cozystack можно протестировать, и во время оценки это разумная просьба.
sonobuoy version # зафиксируйте — версия инструмента является частью доказательства
kubectl version # образ соответствия должен совпадать с минорной версией кластера
sonobuoy run \
--mode=certified-conformance \
--plugin e2e \
--kube-conformance-image registry.k8s.io/conformance:v1.35.6 \
--wait
outfile=$(sonobuoy retrieve)
sonobuoy results "$outfile"
sonobuoy delete --wait
Используйте --mode=certified-conformance и знайте, что он включает обратно. Режим по
умолчанию пропускает тесты с тегом [Disruptive]; сертифицированный режим их запускает,
потому что прогон с пропущенными тестами не является валидным сертификационным прогоном. Эти
тесты намеренно помечают узлы, вытесняют поды и перезапускают компоненты, и выполняются
последовательно — поэтому сертифицированный прогон занимает часы, а не минуты.
Передавайте --plugin e2e на кластерах на базе Talos. Набор плагинов Sonobuoy по
умолчанию включает systemd-logs, который обходит каждый узел, собирая вывод журнала. В
Talos Linux нет systemd, поэтому этот плагин зависает, и агрегатор никогда не сообщает о
завершении прогона. Исключение его ничего не стоит для заявки: оба обязательных артефакта
поступают от плагина e2e.
Не доверяйте счётчику прогресса. sonobuoy status может застрять на Passed: 0, при
том что весь счёт остаётся неизменным на протяжении всего прогона, пока тесты нормально
завершаются. Следите за журналом пода e2e вместо этого, и помните, что тихий журнал — хороший
знак — ошибки — это то, что производит вывод.
Ожидайте два-три часа, несколько сотен короткоживущих подов и пространств имён, и как минимум два планируемых worker-узла. Направьте kubeconfig на кластер тенанта, а не на управляющий кластер: соответствие описывает кластер, куда попадают ваши рабочие нагрузки.
Набор тестов проверяет переносимое поведение, и только там, где это поведение общедоступно. Ведут ли себя основные API так, как указано в спецификации, работает ли планирование, маршрутизируются ли сервисы, изолируют ли пространства имён.
Альфа- и бета-API находятся за пределами профиля, как и большинство точек расширения, на которые опирается реальная рабочая нагрузка: контроллеры ingress, драйверы CSI и их классы хранения, предоставление LoadBalancer, применение NetworkPolicy, производительность и защита. Соответствие говорит, что код, написанный против стабильного API Kubernetes, ведёт себя здесь так, как указывает спецификация. Оно ничего не говорит о том, безопасен ли кластер, быстр или хорошо эксплуатируется — для этого см. CIS Benchmark и PCI DSS.
Оно также ничего не говорит о виртуальных машинах, управляемых базах данных или остальной части каталога. Это расширения, построенные на пользовательских ресурсах, и набор тестов проверяет Kubernetes под ними.
Кластеры, созданные Cozystack, полностью проходят набор тестов на соответствие — на всех пяти релизах Kubernetes, которые предлагает платформа, в прогонах, опубликованных здесь, и в собственном реестре CNCF для v1.33, v1.34 и v1.35 через хостинговую платформу, построенную на его основе. Заявки для самостоятельно управляемых прогонов v1.35 и v1.34 подаются в CNCF. Сама марка «Certified Kubernetes» присваивается конкретному продукту конкретной версии, поэтому записи в реестре появляются под именами организаций, подавших заявку, а не под именем проекта.
Кластеры тенантов можно создавать на версиях с v1.31 по v1.35. Каждая версия — это отдельный прогон соответствия на собственном кластере, и результаты приведены в таблице выше. Только три последних релиза Kubernetes можно подать в CNCF — программа принимает текущий релиз и два предыдущих — поэтому при текущем v1.36 заявки поданы для v1.35 и v1.34, а остальные опубликованы здесь.
Нет. Запись в реестре описывает один продукт одной версии. Запуск того же программного обеспечения с открытым исходным кодом самостоятельно не покрывается чужой сертификацией — именно поэтому самостоятельно управляемый прогон выше опубликован отдельно, со своими собственными артефактами.
Да. Заявка на соответствие состоит из e2e.log и junit_01.xml из прогона. Оба сохранены
для записей Hikube в репозитории CNCF, и оба сопровождают самостоятельно управляемые заявки
для v1.35 и v1.34. Артефакты для более старых прогонов доступны по запросу.
Самостоятельно управляемые прогоны были выполнены 19 августа 2026 года на установке
Cozystack v1.6.1, с использованием Sonobuoy v0.57.5 в режиме certified-conformance с
плагином e2e, один прогон на версию Kubernetes на собственном кластере тенанта. Счётчики
пройденных и проваленных тестов взяты из сводки Ginkgo в e2e.log.
Заявки для v1.35 и v1.34 подаются в репозиторий соответствия CNCF. До их принятия и публикации там эта страница сообщает о прогонах соответствия, а не о завершённой сертификации, и не претендует на марку.
«Certified Kubernetes» и логотип Certified Kubernetes являются знаками The Linux Foundation, лицензированными поставщику соответствующего продукта для продукта и версии, которую он сертифицировал. Ничто здесь не является сертификацией, предоставлением этой марки или заявлением о том, что проект Cozystack ей обладает.