kubernetes: kubectl get pods.v1beta1.metrics.k8s.io fails, but should succeed

Metrics v1beta1 resources can’t be listed by kubectl 1.10. It’s probably an artifact of kind vs resource split, but this is broken and should work (this is a valid aggregated api with a valid discovery doc).

$ kubectl get pods.v1beta1.metrics.k8s.io
error: the server doesn't have a resource type "pods"
$ kubectl describe pods.v1beta1.metrics.k8s.io
error: the server doesn't have a resource type "pods"
$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}

Expected:

kubectl get should have listed the types by trying to get custom columns for the metrics endpoint (which will be the next bug) or fall back to default display output. This violates our rules that well formed aggregated APIs should be automatically be listable or describable via the CLI.

I consider this a 1.12 release blocker since this is a beta api that is part of the core

@kubernetes/sig-cli-bugs @kubernetes/sig-autoscaling-bugs

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 19 (18 by maintainers)

Commits related to this issue

Most upvoted comments

@DirectXMan12

(partially, the 1.12 client seems to be sending an Accept header that’s being rejected by default, unless you -o json)

Hm, if the server is old enough it might be the case that it does not accept as=Table

EDIT: explains why -o json does work, since we only send the as=Table bits in the case of a humanreadable output