GVK resolution fails if metrics-server is unavailable

Aberta
#335 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
kubernetes, rust
Domínio
api, cli

Direção de pesquisa

Reproduza a falha com kubectl -n kube-system delete pods -l k8s-app=metrics-server && stackablectl release install dev e, em seguida, inspecione a descoberta de GVK em src/client/builder.rs:199 e o tratamento de erros em torno de src/client/mod.rs:467. A correção deve permitir que a instalação do release continue quando metrics-server estiver indisponível, preservando ao mesmo tempo a resolução dos grupos de API de que stackablectl precisa.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Rust
Estrelas
10
Forks
5
Merge médio
4h 41min
PRs com merge (30d)
4

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de stackabletech/stackablectl

Todas as issues de stackabletech/stackablectl

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.