2 min read | by Jordi Prats
With kubectl api-resources we can get the list of available objects, but the same object can be defined using different API versions, for example the Ingress object is different on v1beta1 compared to v1. Using kubectl api-versions we can get the list of all the available API versions on our kubernetes cluster
Just as with kubectl api-resources, the list of available API versions that we can see with kubectl api-versions is considerably shorter on a k3s cluster compared to other Kubernetes cluster du to the fact that most of the alpha and beta APIs are striped down:
$ kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
discovery.k8s.io/v1beta1
events.k8s.io/v1
events.k8s.io/v1beta1
extensions/v1beta1
flowcontrol.apiserver.k8s.io/v1beta1
helm.cattle.io/v1
k3s.cattle.io/v1
metrics.k8s.io/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1
If the API we need it's not on this list, we will have to look for another Kubernetes cluster to deploy the application
Posted on 16/03/2021