Home Search Books Tags About Github ARTICLE

Kubernetes Python Client v36.0.2 Patch Release

   |   3 minute read   |   Using 608 words

The Kubernetes Python client shipped v36.0.2 on June 1, 2026. This is the third tag in the v36.0.x line, landing about a week after v36.0.0 and four days after v36.0.1. The release notes from GitHub do not list individual fixes; the actual diff lives in the release-36.0 branch changelog, and this post walks through how to pull it in and where to look for the details.

The full release notes and downloads are on the GitHub release page. It is a stable cut (not a prerelease), so the kubernetes package on PyPI will resolve to it for any environment that allows it.

Install via pip

The maintainers publish the recommended install command in the release body:

pip install --pre --upgrade kubernetes

The --pre flag tells pip to accept prerelease versions. For a stable release like v36.0.2 it is not strictly required, but the maintainers keep --pre in the instructions because the v36 line went through release candidates first and operators who started on those will already have --pre in their pipelines. If you pin a fully resolved version string in requirements.txt, pyproject.toml, or a lockfile, drop --pre to keep your dependency resolver honest.

Install from source

For air gapped clusters or reproducible builds, the release page attaches a source zip with a known SHA. The documented flow is:

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

Note the setup-release.py filename instead of the usual setup.py. This script is the entry point the maintainers ship inside the release archive and it pulls in the generated OpenAPI models before installing.

Where the actual changes live

The release body does not enumerate merged PRs. Operators who want to see what moved between v36.0.1 and v36.0.2 should read the branch changelog:

Working code samples against the v36.0 API surface live in the same branch:

For projects that wrap the client (operators, controllers, scripts that call client.CoreV1Api), a patch level bump on the v36.0.x line should be a drop in upgrade as long as your imports match the existing v36.0 API. If you hit an AttributeError or a model field rename, that is a signal to read the changelog before forcing the upgrade.

Upgrade notes

There is no breaking change called out in the release body itself. Standard patch release hygiene applies:

  • Pin to kubernetes==36.0.2 in lockfiles and rerun your test suite against a real cluster (kind or k3d works fine for CI).
  • If you build images, rebuild against the new tag so the wheel cache reflects the patched version.
  • If you vendor the client into a private registry, mirror the new tag before the next pipeline run picks it up.
  • If you use pip-compile or uv pip compile to produce lockfiles, regenerate them so transitive constraints around urllib3, requests, and websocket-client stay aligned with what v36.0.2 expects.

The release is tagged on the release-36.0 branch, so kubectl style API compatibility tracks whatever Kubernetes minor that branch targets. The cadence of three tags (v36.0.0, v36.0.1, v36.0.2) inside roughly one week suggests the maintainers caught packaging or model generation issues quickly after the v36 cut. Operators who skipped v36.0.0 and v36.0.1 can jump straight to v36.0.2 without staging the intermediate tags.

Why three patches in one week

Patch tags on the Kubernetes Python client are usually driven by one of three causes: a regression in the autogenerated OpenAPI models, a packaging miss in the published wheel, or a fix in the watch and streaming code path. The release body for v36.0.2 does not say which one applies here, so the changelog is the source of truth. Read it before bumping production lockfiles.

Where to get it



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