在 Kubernetes 中我们可以使用不同的 API 版本请求资源:

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

• 用于创建资源的 API 版本是否会对存储在 ETCD 中的资源产生影响？
• 如果在较新的 API 版本 (v1) 尚不存在时存储资源，那么在删除较旧的 API 版本 (v1beta1) 时是否会出现问题？
• 升级到删除 rbac.authorization.k8s.io/v1beta1 的 Kubernetes v1.22 是否会破坏已经创建/存储的资源？
• 如何处理不同 API 版本之间的资源转换？

最佳答案

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 支持一个巨大的弹性弃用系统，它允许您及时创建、迁移和维护 API 版本，但是(跳到您的下一个问题，您有时应该手动将 API 版本升级到最新版本)

可以查看Kubernetes Deprecation Policy guide ，这是保持集群处于工作状态的非常重要的部分。

主要规则:

• 规则 #1:只能通过增加 API 组的版本来删除 API 元素。
• 规则 #2:API 对象必须能够在给定版本中的 API 版本之间来回传输而不会丢失信息，但某些版本中不存在的整个 REST 资源除外。
• 规则 3:在至少发布稳定的新 API 版本之前，不得弃用给定轨道中的 API 版本。
• 规则 #4a:除了每个轨道中的最新 API 版本外，较旧的 API 版本在宣布弃用一段时间后必须得到支持。
• 规则 #4b:给定组的“首选”API 版本和“存储版本”可能不会升级，直到发布了同时支持新版本和先前版本的版本

您还可以查看描述一系列后续版本支持哪些 API 版本的表格。

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

我认为是的，您必须根据 1.22 RBAC deprecation resources 执行一些操作

How are resource transformations between different API versions handled?

检查 What to do

• Test with deprecated APIs disabled

• Locate use of deprecated APIs

• Migrate to non-deprecated APIs

https://stackoverflow.com/questions/69914039/