GVK resolution fails if metrics-server is unavailable

Open

#335 opened on Nov 18, 2024 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 4/5
Estimated time: 3-5 days
Newbie friendliness: 38/100

Issue type: Bug
Clarity: Mostly clear
Activity status: Stale
Tech stack: kubernetes, rust
Domain: api, cli

Research direction

Reproduce the failure with kubectl -n kube-system delete pods -l k8s-app=metrics-server && stackablectl release install dev, then inspect GVK discovery from src/client/builder.rs:199 and error handling around src/client/mod.rs:467. The fix should let release installation continue when metrics-server is unavailable while preserving resolution for the API groups stackablectl needs.

Written by the indexing model from the issue text.

Description

type/bug

Affected version

stackablectl 24.7.1

Current and expected behavior

Run kubectl -n kube-system delete pods -l k8s-app=metrics-server && stackablectl release install dev
Observe that stackablectl crashes with the following error message:

  ERROR  failed with status 503 Service Unavailable
    at src/client/builder.rs:199

   WARN  Unsuccessful data error parse: service unavailable

    at src/client/mod.rs:467

An unrecoverable error occured: failed to execute release (sub)command

Caused by these errors (recent errors listed first):
 1: failed to create Kubernetes client
 2: failed to run GVK discovery
 3: ApiError: "service unavailable\n": Failed to parse error data (ErrorResponse { status: "503 Service Unavailable", message: "\"service unavailable\\n\"", reason: "Failed to parse error data", code: 503 })
 4: "service unavailable\n": Failed to parse error data

Observe that kubectl and k9s are able to manage the cluster just fine

I suspect that this comes down to metrics-server using K8s API aggregation, which allows it to provide a fake "resource" that is stored by itself rather than in etcd. This also means that that resource can be unavailable even if the apiserver and etcd are both doing fine.

Possible solution

We could either:

Limit GVK resolution to the apigroups we care about
Defer apigroup-specific resolution errors until accessing the relevant apigroup

Additional context

No response

Environment

Using k3s v1.31.0+k3s1 via k3d

Would you like to work on fixing this bug?

None

Dominant language: Rust
Stars: 10
Forks: 5
Avg merge: 4h 41m
Merged PRs (30d): 4

Contributor guide

No contributing guide indexed for this repository

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

perf: a definite-value return type (`--> Nil`, `--> True`) sends every call down the full path (~12 µs vs ~1 µs) Open

todo:perf

Difficulty 2/5 1-3 hours Newbie friendliness 84/100

tokuhirom/mutsu#9074 · Opened Sep 22, 2026
exposition.rs still carries its own DogSource label match Open

Difficulty 2/5 1-3 hours Newbie friendliness 88/100

shep-pm/shep#599 · Opened Sep 22, 2026
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Open

state:needs triage

Difficulty 2/5 1-3 hours Newbie friendliness 88/100

zed-industries/zed#64611 · Opened Sep 22, 2026
IntegrationStore's ?workspace search param has no reader since the plugin removal Open

Difficulty 2/5 1-3 hours Newbie friendliness 74/100

ontola/atomic-server#1625 · Opened Sep 22, 2026
PHIE parser rejects the empty object representation Open

Difficulty 2/5 1-3 hours Newbie friendliness 88/100

objectionary/phie#154 · Opened Sep 22, 2026

More Rust issues