Skip to content

chore(deps): update dependency kubernetes to v36 #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Varashi merged 1 commit into from
May 30, 2026
Merged

chore(deps): update dependency kubernetes to v36 #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ LABEL org.opencontainers.image.licenses="MIT"
WORKDIR /app

RUN pip install --no-cache-dir --disable-pip-version-check \
pyVmomi==9.1.0.0 kubernetes==31.0.0
pyVmomi==9.1.0.0 kubernetes==36.0.1
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot May 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Python kubernetes client 36.0.1 release notes: were there breaking changes to kubernetes.config.load_incluster_config, kubernetes.config.load_kube_config, kubernetes.client.CoreV1Api, or kubernetes.client.rest.ApiException/status compared with 31.0.0?

💡 Result:

There were breaking auth-related changes/regressions in kubernetes Python client v36.0.0 (the release line that includes 36.0.1) compared with v31.0.0, affecting: 1) kubernetes.config.load_incluster_config Yes. In v36, load_incluster_config writes the service-account token into Configuration.api_key['authorization'], but Configuration.auth_settings/auto-generated auth code expects the token in api_key['BearerToken'] (so Authorization headers are not sent). This manifests as 401 Unauthorized/system:anonymous responses after upgrading from v35 to v36. [1][2][3] 2) kubernetes.config.load_kube_config Likely yes (paired regression). An issue notes the same loader-side mismatch for load_kube_config (kube_config.py writes the old key shape) causing BearerToken-authed requests to go anonymous in v36. [2] 3) kubernetes.client.CoreV1Api Not a direct client-API breaking change by itself. CoreV1Api is just an API class; the breakage reported occurs when making calls via CoreV1Api after load_incluster_config/load_kube_config in v36, due to the auth/header mismatch. [1][3] 4) kubernetes.client.rest.ApiException / status No explicit breaking change to ApiException itself or a status field was identified in the sources returned. The reported failures are HTTP-level 401/403 responses triggered by missing/incorrect Authorization headers, which then surface via exceptions. [1][3] What you should do if upgrading to 36.x - If you rely on load_incluster_config/load_kube_config, treat v36 as having a breaking auth regression unless you apply the upstream fix or pin to <36.0.0 as suggested in the issues. [2] Confidence: Medium (high confidence about load_incluster_config/load_kube_config auth token key mismatch; lower confidence about ApiException/status because the returned sources didn’t show a concrete change log item for those symbols).

Citations:

Kubernetes v36.0.1 client upgrade breaks auth loader—pin or apply workaround before merge.

Dockerfile pins kubernetes==36.0.1. The kubernetes Python client has a known breaking auth regression in the v36.0.0+/36.0.1 release line: load_incluster_config (and likely load_kube_config) writes the service-account token to Configuration.api_key['authorization'], while the generated auth code expects Configuration.api_key['BearerToken'], resulting in missing Authorization headers (e.g., 401 system:anonymous) on CoreV1Api calls.
Action: pin kubernetes to <36.0.0 or apply the upstream fix/workaround so BearerToken is populated before creating/using CoreV1Api.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Dockerfile` at line 12, The Kubernetes client upgrade breaks auth loading:
either pin the kubernetes package in the Dockerfile to a safe version (<36.0.0)
or add a workaround after calling load_incluster_config()/load_kube_config to
copy Configuration.api_key['authorization'] into
Configuration.api_key['BearerToken'] before instantiating/using CoreV1Api;
update the Dockerfile dependency pin or modify the code path that creates
CoreV1Api/uses Configuration so BearerToken is populated (reference
load_incluster_config, load_kube_config, Configuration.api_key, and CoreV1Api).


COPY controller.py .

Expand Down
Loading