CODEWITHSUNDEEP
kuberneteskubernetes-apiserver
MichaelAttard
MichaelAttard

Reputation: 2158

How does Kubernetes handle multiple API versions for the same resource?

In Kubernetes we can request resources using different API versions:

kubectl get roles.v1.rbac.authorization.k8s.io foo -n bar -oyaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: foo
  namespace: bar
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  - secrets
  verbs:
  - create
  - get
  - watch
  - list
  - update

kubectl get roles.v1beta1.rbac.authorization.k8s.io foo -n bar -oyaml

Warning: rbac.authorization.k8s.io/v1beta1 Role is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 Role
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: foo
  namespace: bar
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  - secrets
  verbs:
  - create
  - get
  - watch
  - list
  - update

Upvotes: 5

Views: 2761

Answers (2)

xinnjie
xinnjie

Reputation: 732

api_changes should answer the quesionts from Kubernetes developer's view.

Would the API version used to create a resource have an impact on the resource stored in ETCD?

No. Usually the latest stable version is stored in ETCD. Which version you use to create a resource would be transformed to latest stable version and stored in ETCD

If a resource was stored when the newer API version (v1) did not exist yet, would this be a problem when the older API version (v1beta1) is removed?

If v1beta1 is no longer supported, all v1beta1 resources should migrate to newer version before the cluster is upgraded.

Would upgrading to Kubernetes v1.22, which removes rbac.authorization.k8s.io/v1beta1, break already created/stored resources?

You need to migrate them before upgrading.

How are resource transformations between different API versions handled?

Usually there is a internal structure. Any supported API versions could transform from an to the internal structure without loss of information.

What I mean "usually" is that develpers could choose their ways to manage API versions. api_changes just give us a good practice to help with compatibility and maintainability of managing API version.

Upvotes: 0

Vit
Vit

Reputation: 8411

If a resource was stored when the newer API version (v1) did not exist yet, would this be a problem when the older API version (v1beta1) is removed?

Kubernetes supports a huge elastic deprecation system, which allows you to create, migrate and maintain API versions in time, however(jumping to your next question, you should sometimes manually upgrade API versions to up-to-date ones)

You can check Kubernetes Deprecation Policy guide, that is very important part of keeping cluster in work condition.

Main rules:

  • Rule #1: API elements may only be removed by incrementing the version of the API group.
  • Rule #2: API objects must be able to round-trip between API versions in a given release without information loss, with the exception of whole REST resources that do not exist in some versions.
  • Rule #3: An API version in a given track may not be deprecated until a new API version at least as stable is released.
  • Rule #4a: Other than the most recent API versions in each track, older API versions must be supported after their announced deprecation for a certain duration.
  • Rule #4b: The "preferred" API version and the "storage version" for a given group may not advance until after a release has been made that supports both the new version and the previous version

You can check also table that describes which API versions are supported in a series of subsequent releases.

Would upgrading to Kubernetes v1.22, which removes rbac.authorization.k8s.io/v1beta1, break already created/stored resources?

I think yes and you have to do some actions according to 1.22 RBAC deprecation resources

enter image description here

How are resource transformations between different API versions handled?

Check What to do

Upvotes: 3

Related Questions