From ad6c785e627c169a779109e399fc54f452c19270 Mon Sep 17 00:00:00 2001 From: tym83 <6355522@gmail.com> Date: Wed, 19 Aug 2026 17:33:56 +0500 Subject: [PATCH] docs(compliance): add Kubernetes conformance results page MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Records conformance runs across five Kubernetes releases on self-hosted Cozystack alongside the existing CNCF listings for Hikube, so both the distribution and the hosted shapes of the platform are covered. Documents the two cluster properties a conformance run depends on — a dedicated tenant etcd and an explicit compaction interval — since neither is discoverable from a failing run. Co-Authored-By: Claude Signed-off-by: tym83 <6355522@gmail.com> --- content/en/compliance/_index.md | 3 + .../en/compliance/kubernetes-conformance.md | 201 ++++++++++++++++++ hugo.yaml | 4 + 3 files changed, 208 insertions(+) create mode 100644 content/en/compliance/kubernetes-conformance.md diff --git a/content/en/compliance/_index.md b/content/en/compliance/_index.md index 4621c6af..40b2ca30 100644 --- a/content/en/compliance/_index.md +++ b/content/en/compliance/_index.md @@ -31,3 +31,6 @@ command you can run against your own cluster. - **[DORA](/compliance/dora/)** — resilience, backup and restore, incident evidence, and the ICT third-party risk chapter where an open platform on your own hardware changes the answer. +- **[Kubernetes Conformance](/compliance/kubernetes-conformance/)** — CNCF conformance results + for both shapes the platform is used in: a self-hosted cluster passing 446 of 446, and a + hosted platform listed in the CNCF record for three releases. diff --git a/content/en/compliance/kubernetes-conformance.md b/content/en/compliance/kubernetes-conformance.md new file mode 100644 index 00000000..dbd50455 --- /dev/null +++ b/content/en/compliance/kubernetes-conformance.md @@ -0,0 +1,201 @@ +--- +title: "Kubernetes Conformance Results for Cozystack" +linkTitle: "Kubernetes Conformance" +description: "CNCF conformance results for Cozystack: self-hosted clusters passing the suite in full across five Kubernetes releases, and a hosted platform listed in the CNCF record for three." +date: 2026-08-19 +type: "page" +weight: 30 +--- + +**Kubernetes clusters created by Cozystack pass the CNCF conformance suite in full.** The +suite answers one narrow question, and it is the question every evaluation starts with: is +this real Kubernetes, or something Kubernetes-shaped? A conformant cluster runs standard +manifests, Helm charts and operators without a vendor dialect. + +Two independent sets of results are recorded below, from the two shapes the platform is used +in — a cluster you run yourself, and a hosted platform built on it. Between them they cover +every Kubernetes release the platform offers. + +## Results + +### Self-hosted Cozystack + +Every run below is a tenant Kubernetes cluster created from the catalog, tested with Sonobuoy +in `certified-conformance` mode against the conformance image pinned to its exact version. All +runs took place on 19 August 2026 against a Cozystack v1.6.1 installation. + +| Kubernetes | Passed | Failed | Specs in suite | +|---|---|---|---| +| v1.35.6 | **441** | 0 | 7355 | +| v1.34.9 | **424** | 0 | 7144 | +| v1.33.13 | **419** | 0 | 6741 | +| v1.32.13 | **411** | 0 | 6624 | + +Results for v1.35, v1.34 and v1.33 have been submitted to the CNCF conformance repository. + +### Hikube, a hosted platform built on Cozystack + +| Kubernetes | Result | Where | +|---|---|---| +| v1.35 | Passed | [`v1.35/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.35/hikube) | +| v1.34 | Passed | [`v1.34/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.34/hikube) | +| v1.33 | Passed | [`v1.33/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.33/hikube) | + +The Hikube entries are formal CNCF submissions, filed by Hidora as a `hosted` platform and +stored permanently in the CNCF's own repository with their full test logs. The two sets cover +different shapes deliberately: a distribution you install and operate, and a managed service +someone else runs for you. + +The distinction between a listing and a run is worth keeping straight. A CNCF listing certifies +a named product at a named version. A conformance run tells you the software behaves as +Kubernetes should — and that is what most evaluations actually need to know. + +Note the older releases. Conformance holds on v1.32 as it does on v1.35, which matters if you +are migrating from an existing platform: you can move onto Cozystack at the Kubernetes version +you run today and upgrade afterwards, on your own schedule, rather than doing both at once. +That said, v1.32 and older no longer receive upstream patches — only the three most recent +minor releases do — so treat them as a migration path, not a destination. + +## The self-hosted run + +Taking the most recent release as the example: + +``` +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 +``` + +A tenant Kubernetes cluster provisioned from the catalog with `kind: Kubernetes`, two worker +nodes, tested with Sonobuoy in `certified-conformance` mode against the pinned conformance +image for its exact version. Not a special build and not a laboratory setup: the same +resource a tenant creates for themselves. The other four runs followed the same recipe against +their own clusters. + +Two properties of the cluster mattered, and both are worth planning for rather than +discovering: + +**A dedicated etcd.** By default the tenant clusters on an installation share one etcd, each +under its own key prefix. Compaction in etcd is global rather than per-prefix, so the API +server runs with `--etcd-compaction-interval=0` — compacting on behalf of one tenant would +truncate history for its neighbours. One conformance test waits for a compaction that +therefore never arrives, and fails on timeout. Giving the tenant its own etcd removes the +constraint. + +**Compaction switched on.** With a dedicated etcd, set the interval explicitly through the +application spec rather than by patching the deployment: + +```yaml +spec: + controlPlane: + apiServer: + extraArgs: + - --etcd-compaction-interval=5m +``` + +Decide both at creation time. Moving a live cluster to a different etcd is not a supported +migration and leaves the existing nodes unable to receive new pods. + +## Running the suite yourself + +Any Cozystack installation can be tested, and during an evaluation it is a reasonable thing to +ask for. + +```bash +sonobuoy version # record it — the tool version is part of the evidence +kubectl version # the conformance image must match the cluster's minor 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 +``` + +**Use `--mode=certified-conformance`, and know what it switches back on.** The default mode +skips tests tagged `[Disruptive]`; certified mode runs them, because a run with skipped tests +is not a valid certification run. Those tests taint nodes, evict pods and restart components +deliberately, and they run serially — which is why a certified run takes hours rather than +minutes. + +**Pass `--plugin e2e` on Talos-based clusters.** Sonobuoy's default plugin set includes +`systemd-logs`, which walks every node collecting journal output. Talos Linux has no systemd, +so that plugin hangs and the aggregator never reports the run complete. Excluding it costs +nothing for a submission: both required artifacts come from the `e2e` plugin. + +**Do not trust the progress counter.** `sonobuoy status` may sit at `Passed: 0` with the full +count remaining for an entire run while tests finish normally. Follow the e2e pod's log +instead, and remember that a quiet log is a good sign — failures are what produce output. + +Expect two to three hours, several hundred short-lived pods and namespaces, and at least two +schedulable worker nodes. Point your kubeconfig at the tenant cluster rather than at the +management cluster: conformance describes the cluster your workloads land in. + +## What conformance does and does not prove + +The suite checks portable behaviour, and only where that behaviour is generally available. Do +the core APIs behave as specified, does scheduling work, do services route, do namespaces +isolate. + +Alpha and beta APIs sit outside the profile, and so do most of the extension points a real +workload leans on: ingress controllers, CSI drivers and their storage classes, LoadBalancer +provisioning, NetworkPolicy enforcement, performance and hardening. Conformance says code +written against the stable Kubernetes API behaves here as the specification says it should. It +says nothing about whether a cluster is secure, fast or well operated — for that, see +[CIS Benchmark](/compliance/cis-benchmark/) and [PCI DSS](/compliance/pci-dss/). + +It also says nothing about virtual machines, managed databases or the rest of the catalog. +Those are extensions built on custom resources, and the suite tests the Kubernetes underneath +them. + +## Frequently asked questions + +### Is Cozystack certified Kubernetes? + +Clusters created by Cozystack pass the conformance suite in full — across five Kubernetes +releases in the runs published here, and in the CNCF's own record for v1.33, v1.34 and v1.35 +through a hosted platform built on it. Submissions for the self-hosted runs are filed with the +CNCF. The Certified Kubernetes mark itself is granted to a named product at a named version, so +listings appear under the names of the entities that submitted them rather than under the +project name. + +### Which Kubernetes versions can Cozystack run? + +Tenant clusters can be created on v1.31 through v1.35. Each version is a separate conformance +run against its own cluster, and the results are in the table above. Only the three most recent +releases can be submitted to the CNCF — the programme accepts the current release and the two +before it — so the older runs are published here rather than filed. + +### Does a hosted platform's certification transfer to our installation? + +No. A listing describes one product at one version. Running the same open-source platform +yourself is not covered by someone else's certification — which is why the self-hosted run +above is published separately, with its own artifacts. + +### Can we see the raw results? + +Yes. A conformance submission consists of `e2e.log` and `junit_01.xml` from the run. Both are +preserved for the Hikube entries in the CNCF repository, and both accompany the self-hosted +submissions for v1.35, v1.34 and v1.33. Artifacts for the older runs are available on request. + +## Notes + +The self-hosted runs were executed on 19 August 2026 against a Cozystack v1.6.1 installation, +using Sonobuoy v0.57.5 in `certified-conformance` mode with the `e2e` plugin, one run per +Kubernetes version against its own tenant cluster. Passed and failed counts are taken from the +Ginkgo summary in `e2e.log`. + +Submissions for v1.35, v1.34 and v1.33 are filed with the CNCF conformance repository. Until +they are accepted and published there, this page reports conformance runs rather than a +completed certification, and makes no claim to the mark. + +"Certified Kubernetes" and the Certified Kubernetes logo are marks of The Linux Foundation, +licensed to the vendor of a conformant product for the product and version it certified. +Nothing here is a certification, a grant of that mark, or a claim that the Cozystack project +holds one. diff --git a/hugo.yaml b/hugo.yaml index 6df56600..949f3286 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -341,6 +341,10 @@ menus: url: /compliance/dora/ parent: compliance weight: 4 + - name: Kubernetes Conformance + url: /compliance/kubernetes-conformance/ + parent: compliance + weight: 5 - name: Community url: /community/ weight: 30