Kubernetes 如何处理同一资源的多个 API 版本？

Question

在 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) 被删除时，这会出现问题吗？
• 升级到 Kubernetes v1.22 会删除rbac.authorization.k8s.io/v1beta1、破坏已创建/存储的资源吗？
• 不同API版本之间的资源转换如何处理？

Answer 1

如果在新的 API 版本 (v1) 尚不存在时存储资源，那么当旧的 API 版本 (v1beta1) 被删除时，这会出现问题吗？

Kubernetes 支持庞大的弹性弃用系统，它允许您及时创建、迁移和维护 API 版本（跳到您的下一个问题，您有时应该手动将 API 版本升级到最新版本）

您可以查看Kubernetes 弃用策略指南，这是保持集群正常工作的非常重要的部分。

主要规则：

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

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

升级到 Kubernetes v1.22（删除 rbac.authorization.k8s.io/v1beta1）是否会破坏已创建/存储的资源？

我认为是的，您必须根据1.22 RBAC 弃用资源执行一些操作

不同API版本之间的资源转换如何处理？

检查要做什么

• 禁用已弃用的 API 进行测试

• 找到已弃用的 API 的使用情况

• 迁移到未弃用的 API