What should your Kubernetes workload do during maintenance?

The Kubernetes project’s 27 October announcement describes a Workload Conformance Working Group developing runtime requirements, a verification method and upstream tooling. Specific requirements were still being defined in the material reviewed. The announcement is a starting point for shared expectations, not a finished test suite. (Kubernetes project / Nabarun Pal)

Keep the cluster and the application in different columns

CNCF’s existing Certified Kubernetes program verifies required APIs of Kubernetes distributions and platforms. That gives useful context for the infrastructure layer; it does not certify that a particular business application produces the correct results. (CNCF)

A team running an application still needs evidence about its own workload. The cluster operator may understand maintenance procedures while the application team understands requests, jobs and data. Put both perspectives into the discussion before a routine maintenance window becomes the first time they meet.

The working group’s charter focuses on objectively testable runtime behaviour, with application logic and running a certification program outside its scope. It does not mandate a packaging format or vendor verification tool. Any future certification program would depend on an approved standard. (Kubernetes community)

Ask for an operating record you can inspect now

The following matrix is an editorial proposal for teams already using Kubernetes. It is not the working group’s specification or an official conformance checklist. Complete it with the workload’s owners and evidence from an authorised environment; no tests were executed for this article.

Choose one important path first, such as a background job with a durable input reference and an identifiable output. Define what acceptable continuity means for that path. A container reaching a running state is only one observation; the record should show what the application owner needs to inspect as well.

A proposed maintenance rehearsal

Consider a hypothetical document-generation worker. It takes work from a queue and writes an output file. The team wants to understand a future node-maintenance event. This is an illustrative scenario, not a KIURO customer deployment or a rehearsal already performed.

First identify the selected job, its input reference, its intermediate state and the output location. Agree what evidence would distinguish a completed job, a safe retry and an unresolved job. Then design a controlled rehearsal in a representative isolated environment, with the cluster operator and application owner agreeing the interruption and recovery conditions.

After the proposed rehearsal, the useful record would connect the workload transition to the receiving system and output reference. Unexpected duplication or missing state would become a specific issue to investigate. The correctness of the document’s business content would require its own acceptance checks; a future workload-runtime result should not be used to sign off that separate question.

Keep a workload’s operating evidence alongside its deployment reference. This lets the next review ask what changed since the previous observation, rather than repeating a general claim that the application is “Kubernetes-ready”. If a dependency, privilege or storage assumption remains unknown, record an owner and a resolution condition.

Prepare evidence without inventing a new compliance badge

• Ask the application maintainer for the behaviours it expects during maintenance, with a person responsible for clarifying them.
• Ask the cluster operator which maintenance and upgrade scenarios must be understood before the planned window.
• Identify evidence that already exists, evidence that needs a controlled test and assumptions still awaiting confirmation.
• Keep business-function acceptance separate from runtime and infrastructure observations.
• Review the working group’s current requirements and tooling when concrete artifacts become available, rather than labelling today’s internal worksheet official conformance.

The announcement does not establish a final specification, a released test binary or a certification service ready to buy. No future-tool license or program price was verified for this guide. An internal rehearsal also needs time, representative infrastructure and agreed authority; none of those costs or permissions is created by a public announcement.

For an existing Kubernetes team, the next useful step is a joint application-and-operations discussion around one workload and one planned maintenance scenario. Keep the resulting evidence specific enough to review. Teams without Kubernetes do not need to adopt it to use this broader habit of asking what happens when the operating environment changes.