What the certification logo actually guarantees

One-line summary

The certification logo is a promise that "the APIs that are GA and required behave the same as upstream," not a promise that "you can trust it in production," and a distribution such as EKS Distro layers other values on top of that promise: the build, patches, and a support period.

Why this was needed

Kubernetes is open source, so anyone can modify it and distribute it. When distributions grew to dozens, users became anxious about one thing: "Will a manifest that ran on A run exactly the same on B?" If vendors change APIs slightly or remove default behavior, the portability that was the reason for choosing Kubernetes is lost.

So the CNCF runs the Certified Kubernetes Conformance Program. A vendor runs a defined test suite on its own product, submits the results as a PR to a public repository, and gets certified if it passes review. The key point is that the tests are public and the results are public too. Anyone can rerun the same tests on their own cluster. The FAQ explains that even for an in-house cluster, if it passes the tests without certification it is conformant, and that certification is a procedure for using the logo.

How it works

What the tests are. According to instructions.md, the standard tests are those tagged [Conformance] in the Kubernetes e2e suite. The list is fixed per version in test/conformance/testdata/conformance.yaml of the Kubernetes repository. Counting the list at the v1.36.4 tag gives 446, in the order sig-node 106 · sig-api-machinery 99 · sig-storage 91 · sig-apps 60 · sig-network 47 (measured). Each entry has a testname, a codename, a description, the release in which it first entered, and a source file.

What can become a test. The criteria are set by SIG Architecture's Conformance Testing in Kubernetes. Only features that are GA and not optional, they must work on every provider, they must not depend directly on the kubelet API, and they must not require root privileges on the node or the public internet. Conversely, node-dependent features such as GPUs, optional features such as policy enforcement, and features specific to a cloud provider are explicitly out of scope. Tests that check output that can change from version to version, such as the contents of an Event or the reason and message of a Condition, are not included either.

How to run it. The results for submission are produced with Sonobuoy or Hydrophone. With Sonobuoy you need --mode=certified-conformance, and if you give the focus yourself, E2E_FOCUS=\[Conformance\] must be used and E2E_SKIP must be left empty. A certification run cannot skip a single test. The PR contains four files — README.md, e2e.log, junit_01.xml, and PRODUCT.yaml — and a bot first checks that all the required tests are present and that there are no failures. The versions that can be certified are the current release and the two before it, and even an already certified product must be certified again with a new version once a year to keep its status.

Why the versions must match. The test list grows with each version. The documentation says to run the conformance tests of a version using the ones built from that version's release branch. This lab VM uses the v1.36.4 test binary from dl.k8s.io with the server v1.36.4+k3s1. Counting with a dry-run, the [Conformance] focus picks 446 out of 7579 specs, exactly the same as the number in the list (measured).

What it looks like in the field

A k3s with the logo fails on a single machine. The v1.36/k3s submission README in the repository says it was tested with one control plane and one worker, and the result was 446 passed · 7133 skipped · about 2 hours 54 minutes. But when you run [sig-architecture] Conformance Tests should have at least two untainted nodes on this lab's single-machine k3s, it fails in 1.3 seconds with Conformance requires at least two nodes (measured). Certification is about the product, and it does not mean that the configuration you set up is conformant.

The same test catches a broken cluster. [sig-network] DNS should provide DNS for the cluster passed in 3.8 seconds on a healthy cluster. When you reduce CoreDNS to 0 and run it again, the test Pod records a failed lookup of kubernetes.default.svc.cluster.local every 5 seconds and waits 600 seconds. When the suite timeout was set to 60 seconds, the result was left as timedout (measured). Conformance tests are also for certification, but they can also be used as regression tests to check "is the basic behavior alive?" after an upgrade or a CNI swap.

What EKS Distro adds. The EKS Distro documentation describes EKS-D as a distribution of the same Kubernetes and dependencies that Amazon EKS uses. It bundles Kubernetes, etcd, CoreDNS, CNI plugins, and aws-iam-authenticator, and publishes container images based on Amazon Linux 2 to ECR Public. The FAQ says it is not a fork but an opinionated bundling of unmodified upstream, and that it provides security patches for up to 14 months even for versions whose community support has ended. The version notation is, like v1-36-eks-7, a release number after the minor channel, and the image tag is, like kube-apiserver:v1.36.2-eks-1-36-7, the channel and number after the upstream version. A new release also comes out when component versions change or when the base image or build tool (for example, Go) changes. The v1-36-eks-7 of 2026-08-18 has kube-apiserver v1.36.2, while upstream stable-1.36 at the same time was v1.36.4 (measured). A distribution's version may not equal the latest upstream. EKS-D has also been submitted as type distribution under v1.36 in the k8s-conformance repository.

What really matters in practice

The logo is the floor of portability, not the ceiling of quality. Certification says only that GA APIs behave the same. High-availability configuration, performance, security defaults, optional features such as whether a NetworkPolicy is actually enforced, upgrade procedures, and support period must all be checked separately.

A certification result is not the result of my cluster. If the configuration written in the submission README (number of nodes, OS, install flags) differs from mine, there may be tests that fail even for the same product. After an important change, choosing and running the conformance tests of the relevant area yourself is more reliable than trusting the logo.

Pin the version. If the versions of the server and the test binary diverge, the lists differ and you cannot compare the results. For a product like EKS-D, where the upstream patch version and the distribution release number move separately, you must record both numbers so that you can reproduce it later.

EKS-D itself was not installed on this lab VM. The installation paths (kOps, kubeadm, and so on) and the support path (EKS Anywhere) were checked only in the documentation.

What you will do in the next lab

On a k3s with its version pinned, you match the version of the test binary, read conformance.yaml, and find the tests of the DNS area. After counting the scope with a dry-run, you pass one DNS test, and confirm with JUnit that a single-machine configuration fails the two-node test. You reduce CoreDNS and watch the same DNS test fail by timeout, then revert and make it pass again, and summarize the results in the words of the certification rules.