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