GVK resolution fails if metrics-server is unavailable

Abierto
#335 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
kubernetes, rust
Área
api, cli

Línea de trabajo

Reproduzca el fallo con kubectl -n kube-system delete pods -l k8s-app=metrics-server && stackablectl release install dev y, después, inspeccione el descubrimiento de GVK en src/client/builder.rs:199 y el manejo de errores alrededor de src/client/mod.rs:467. La corrección debe permitir que la instalación del release continúe cuando metrics-server no esté disponible, preservando al mismo tiempo la resolución de los grupos de API que necesita stackablectl.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

type/bug
Affected version

stackablectl 24.7.1

Current and expected behavior
  1. Run kubectl -n kube-system delete pods -l k8s-app=metrics-server && stackablectl release install dev
  2. 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
  1. 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:

  1. Limit GVK resolution to the apigroups we care about
  2. 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

Lenguaje dominante
Rust
Estrellas
10
Forks
5
Merge medio
4 h 41 min
PR fusionados (30 d)
4

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de stackabletech/stackablectl

Todos los issues de stackabletech/stackablectl

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.