Кластеры 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 |
The v1.35 and v1.34 runs are accepted and published in the CNCF conformance repository, at
v1.35/cozystack and
v1.34/cozystack, filed
by Ænix as a distribution. The programme accepts the current Kubernetes release and the two
before it, and with v1.36 current those are the newest releases the platform offers.
| 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 под ними.
Nor does it cover what an AI workload needs from a platform beyond plain Kubernetes — accelerator exposure, gang scheduling, accelerator metrics. That is a separate programme, and our results for it are on the AI Conformance page.
Yes, for the releases in the CNCF record. Cozystack v1.6.1 is listed as a Certified Kubernetes distribution for Kubernetes v1.35 and v1.34, filed by Ænix and published in the CNCF’s own repository. A hosted platform built on Cozystack is listed separately for v1.33, v1.34 and v1.35. Beyond those, clusters created by Cozystack pass the suite in full on all five Kubernetes releases the platform offers, in the runs published here.
The Certified Kubernetes mark is granted to a named product at a named version and licensed to the entity that submitted it, so listings appear under the names of those entities rather than under the project name.
Кластеры тенантов можно создавать на версиях с v1.31 по v1.35. Каждая версия — это отдельный прогон соответствия на собственном кластере, и результаты приведены в таблице выше. Только три последних релиза Kubernetes можно подать в CNCF — программа принимает текущий релиз и два предыдущих — поэтому при текущем v1.36 заявки поданы для v1.35 и v1.34, а остальные опубликованы здесь.
Нет. Запись в реестре описывает один продукт одной версии. Запуск того же программного обеспечения с открытым исходным кодом самостоятельно не покрывается чужой сертификацией — именно поэтому самостоятельно управляемый прогон выше опубликован отдельно, со своими собственными артефактами.
Yes. A conformance submission consists of e2e.log and junit_01.xml from the run, and the
CNCF preserves both permanently. They are in the repository for the self-hosted
v1.35 and
v1.34 entries and for the
Hikube entries. Artifacts for the older runs are available on request.
Самостоятельно управляемые прогоны были выполнены 19 августа 2026 года на установке
Cozystack v1.6.1, с использованием Sonobuoy v0.57.5 в режиме certified-conformance с
плагином e2e, один прогон на версию Kubernetes на собственном кластере тенанта. Счётчики
пройденных и проваленных тестов взяты из сводки Ginkgo в e2e.log.
The v1.35 and v1.34 submissions were accepted and published in the CNCF conformance repository on 28 August 2026. The three older runs on this page are published here rather than filed, since the programme accepts only the three most recent Kubernetes releases.
«Certified Kubernetes» и логотип Certified Kubernetes являются знаками The Linux Foundation, лицензированными поставщику соответствующего продукта для продукта и версии, которую он сертифицировал. Ничто здесь не является сертификацией, предоставлением этой марки или заявлением о том, что проект Cozystack ей обладает.