Certified Kubernetes makes API compatibility a versioned claim

An application that uses Kubernetes APIs depends on more than a vendor calling its platform Kubernetes. It depends on the objects and operations behaving as the project specifies. As providers add installation systems and infrastructure integrations, users need a way to identify a common implementation baseline. The Certified Kubernetes Conformance Program launches today with offerings from 32 vendors and an automated test process for demonstrating that baseline.

CNCF certifies submissions after vendors run the conformance suite. The stated guarantee is that the complete Kubernetes API functions as specified. That makes compatibility a claim with a test and review process behind it, rather than an implication drawn from a product name. The program also makes the same open source suite available to users who want to confirm a provider's certification.

I value Kubernetes most where its API machinery gives applications a consistent way to declare and observe state. Conformance addresses a prerequisite for that value across products. A declaration cannot be meaningfully portable if each distribution gives the same object a different interpretation.

Certification follows a public beta

The October 19 program introduction invited vendors to run the suite and submit results during a beta period. It described more than sixty known Kubernetes platforms and distributions. The problem was therefore already concrete, with a substantial provider ecosystem offering different ways to obtain a cluster.

The beta announcement promised to list successful participants when the program became generally available. Today's launch identifies the first certified cohort. Its list includes cloud platforms, enterprise distributions and installation offerings, demonstrating that certification applies across different delivery models. A managed service and an installation tool can support the same API compatibility objective without becoming the same product.

The launch includes Google Kubernetes Engine, Red Hat OpenShift, CoreOS Tectonic and Canonical Distribution of Kubernetes among the offerings. It also lists Microsoft Azure ACS-Engine and Heptio AWS-Quickstart. These names matter as examples of the range being certified, not as a ranking of implementations or a statement that their operating procedures are identical.

The count should also retain the announcement's unit. CNCF describes thirty-two certified distributions and platforms and presents a list organized by vendors, some of which name several products. Treating that headline as a count of interchangeable installations would add a precision that the list does not provide. The substantive result is the initial cohort meeting the program's requirements.

Tests and certification perform different work

An automated test suite gives vendors a repeatable way to demonstrate conformance. Submission review and certification connect that result to the program's public claim. The launch explicitly invites any vendor to run the suite and submit its results, so the mechanism is not restricted to the first group of participants.

Making the suite open source also gives end users a way to examine the basis of the claim. The launch asks users to ensure their vendors certify their products and says they can confirm certification with the same suite. That is a stronger arrangement than relying entirely on a provider's private compatibility testing, because the test mechanism is shared.

The test suite does not define its own policy in isolation. The October introduction assigns SIG Architecture control over changes to what Certified Kubernetes means. SIG Testing works on the mechanics of the conformance tests, while the Conformance Working Group develops program process and policy. These are related responsibilities with different outputs.

That division provides a place to settle disagreements about what belongs in the compatibility requirement. A test's implementation and the architectural behavior it intends to verify are not automatically the same question. Assigning the definition to SIG Architecture gives the program a project-level authority for the API contract.

Compatibility has to follow Kubernetes versions

The October introduction states that certification is versioned alongside Kubernetes. Requirements change with Kubernetes versions as capabilities and architecture change. A successful result for one version cannot be treated as a timeless statement about every future version of the product.

Products must recertify annually for the current or previous Kubernetes version to remain certified. That requirement ties continuing use of the certification to ongoing participation in Kubernetes development. It reduces the possibility that an old passing result will indefinitely represent a product that has stopped tracking the project.

Version information also appears in the Certified Kubernetes mark described by the program. This links the visible claim to a particular compatibility context. For a software vendor supporting customers on different clusters, the relevant question becomes which Kubernetes baseline the customer's platform certifies, rather than whether the platform has ever passed some Kubernetes tests.

This is important for applications that depend directly on API operations. The 1.8 release makes RBAC stable while promoting the workload APIs to apps/v1beta2. A compatibility claim must be read against the available versioned APIs and their status. Certification cannot make an API introduced in one release exist in an older release that predates it.

Portable declarations still refer to infrastructure choices

Kubernetes' own resource model helps explain the boundary of portability. The 1.6 release announcement describes PersistentVolumeClaims as separating a storage request from the implementation providing the volume. StorageClasses let administrators expose different storage options with their own parameters. The common interface deliberately accommodates different backing systems.

A conformant API is valuable because the claim object and its operations have a common specified meaning. The storage class that the application asks for remains an administrative and infrastructure choice. A manifest referring to a locally chosen class name still depends on a suitable class existing in its destination environment. Certification of Kubernetes does not rename the target cluster's resources to match the source cluster.

The same reasoning applies to the work surrounding an application. Images must be available to the destination deployment, and the application's data must reach the storage it will use. Those requirements follow from the application's own references and state. An API compatibility test provides a baseline for Kubernetes behavior, while the migration still has concrete inputs to satisfy.

Storage lifecycle policy illustrates another distinction. The 1.6 announcement says dynamically provisioned volumes use the Delete reclaim policy by default. Applications that delete their claims must account for that behavior even on a conformant platform. Consistent semantics make that dependency easier to explain, but they do not decide whether deleting the underlying data is appropriate for a particular application.

This distinction does not diminish the program's purpose. It makes the promise more useful by identifying the part of migration that can share a common verification process. Users can reason about the Kubernetes API separately from the provider-specific resources that their workload requests through it.

A shared baseline supports different kinds of suppliers

Independent software vendors are an explicit audience in the beta introduction. They need confidence that their software behaves as expected when a customer uses a Certified Kubernetes product. A common conformance requirement gives them a basis for supporting multiple platforms without treating every distribution as an unrelated implementation.

Providers retain room to differ in their surrounding services and delivery mechanisms. The launch cohort itself illustrates this through its mix of cloud services and installation offerings. Conformance specifies a common Kubernetes claim across that diversity. It does not require every supplier to package the cluster, operate it or support customers in the same way.

Certification also belongs to the named offering. Microsoft's launch statement identifies ACS-Engine in the certified list and describes certification of AKS as work planned for the coming weeks. A supplier's participation therefore should not be expanded into an assertion that every product it offers has already passed. The product name remains necessary when checking what the announcement certifies.

The certification also grants specific trademark permissions, including the Certified Kubernetes logo and use of the Kubernetes mark with a product name. Those permissions give providers a visible way to communicate their participation. The technical value depends on the versioned requirement and reviewed test submission that the mark represents.

My interest in the program is therefore practical rather than decorative. It gives application and platform authors a common API baseline to ask for, a public suite to examine, and a recurring certification requirement to keep the claim current. The first cohort establishes that providers with different products can participate in that process while continuing to expose their own infrastructure choices through the shared Kubernetes model.