Home Search Books Tags About Github ARTICLE

Kubernetes Python Client v36.0.0 Stable Release Notes

   |   3 minute read   |   Using 628 words

The official Kubernetes Python client tagged v36.0.0 on May 20, 2026. The published GitHub release is intentionally short and points users at the install commands and the full changelog on the release-36.0 branch. This post collects what is on the release page, plus the practical bits operators usually want before bumping the version in production code.

The full release notes and downloads are on the GitHub release page. The repository keeps a per release CHANGELOG under the release-36.0 branch, which is where the actual list of API changes lives.

What the release page tells you

The release page itself does not enumerate the changes. It contains two install paths and two links: one to the examples directory pinned to the 36 series, and one to the CHANGELOG. That is normal for this project. The maintainers keep the diff in the branch and use the GitHub release mostly as a tag and a binary attachment.

If you are looking for the list of what changed between v35 and v36, read the CHANGELOG on the release branch. The Python client is generated from the Kubernetes OpenAPI spec, so most majors mean some method signatures, enum values, or model fields shift.

Installing v36.0.0

Two paths are listed.

From PyPI:

pip install --pre --upgrade kubernetes

The --pre flag is unusual for a stable tag. If you only want stable releases, pin the version explicitly:

pip install --upgrade 'kubernetes==36.0.0'

That removes any chance of pip picking up a future pre release if the package metadata changes.

From source, the release ships a zip attached to the GitHub release page:

unzip client-python-v36.0.0.zip
cd client-python-v36.0.0
python setup-release.py install

This path is useful in offline builds or when CI must run against a known artifact rather than whatever PyPI resolves on the day. Keep the zip in your internal package mirror if you maintain one.

What to check before bumping

The Python client is generated against a specific Kubernetes server version. Read the README on the release-36.0 branch to confirm which server versions are in scope before you upgrade fleet code.

A few areas tend to break on major bumps:

  • Watcher loops and informer style code paths. Re run any list and watch tests against a real cluster, not against a mock.
  • Code that imports model classes directly from kubernetes.client.models. Field renames here are silent at import time and only show up at runtime.
  • Anything using the dynamic client from kubernetes.dynamic. Resource discovery behaviour is the area most likely to shift between majors.

If you maintain a library that depends on kubernetes, do not loosen the upper bound to <37 until your downstream users have a few weeks with the new client. The Python ecosystem in this space (Argo workflows SDKs, KServe, Kubeflow, Strimzi tooling) usually caps the client version, and bumping the client without bumping the wrapper has burned operators before.

Examples and migration

The examples directory pinned to this release lives at https://github.com/kubernetes-client/python/tree/release-36.0/examples. If you are writing a new controller or a one shot script, those examples are the cleanest reference for v36, since the snippets in random blog posts may still be on v25 or v26.

If the CHANGELOG flags breaking changes in your code paths, the safest migration order is:

  1. Pin to the previous stable in a branch and run the test suite.
  2. Bump to kubernetes==36.0.0, run the same suite, fix imports and field renames.
  3. Re run integration tests against a real cluster (kind, k3d, or a dev namespace) before merging.

A dry pip resolve against your full requirements file is also worth doing. The client is a transitive dependency of many tools, and a hard pin upstream of you can block the upgrade.

Where to get it



Page link: /posts/kubernetes-client-python-v36-0-0-stable-release/
denis256 at denis256.dev