Question

Kuberentes具有支持CRD版本控制的机制。参见https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/。对我还不清楚的是，当您不能始终从v1 <-> v2转换时，您实际上如何支持CRD v1向CRD v2的演进。假设我们在v2中引入了一个不能由Web挂钩转换填充的新字段，那么也许我们所能做的就是将该字段保留为空？此外，当您请求api版本N时，即使它不是被编写为版本N，您也总是将对象取回为版本N，因此，控制器如何知道如何对待该对象？

Answer 1

您可以在Writing, reading, and updating versioned CustomResourceDefinition objects中阅读

如果更新现有对象，则将其重写为当前的存储版本。这是对象可以从一个版本更改为另一个版本的唯一方法。

Kubernetes会以您请求的版本将对象返回给您，但是在处理请求时，持久化的对象既不会在磁盘上更改，也不会以任何方式转换（除了更改apiVersion字符串）。

如果更新现有对象，则将其重写为当前的存储版本。这是对象可以从一个版本更改为另一个版本的唯一方法。

您以版本v1beta1读取对象，然后再次以版本v1读取对象。返回的两个对象都相同，除了apiVersion字段Upgrade existing objects to a new stored version

API服务器还支持Webhook转换，以在需要转换时调用外部服务。 Webhook处理API服务器发送的ConversionReview请求，并发回包装在ConversionResponse中的转换结果。您可以阅读有关here的网络图书。

Webhook转换在Kubernetes v1.13中作为Alpha功能引入。将Webhook服务器作为服务部署到Kubernetes集群中时，必须通过端口443上的服务公开它。在弃用版本并放弃支持时，请设计存储升级过程。

Answer 2

假设您具有如下所示的CRD规范。

// API v6.
type Frobber struct {
  Height int    `json:"height"`
  Param  string `json:"param"`
}

然后，您添加了一些名为Width的新规范。

// Still API v6.
type Frobber struct {
  Height int    `json:"height"`
  Width  int    `json:"width"`
  Param  string `json:"param"`
}

只要您可以使用控制器逻辑来处理此更改，就不需要任何版本更改。这意味着此添加将向后兼容。

但是让我们现在说一下，您正在如下更改先前的规范。

// Internal, soon to be v7beta1.
type Frobber struct {
  Height int
  Width  int
  Params []string
}

此处您更改了不向后兼容的现有规范。另外，您可能无法使用控制器逻辑来处理此更改。在这些更改中，最好使用版本升级。

有关kubernetes API版本更改的更多详细信息，请参考以下链接。

[1] https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md

[2] https://groups.google.com/forum/#!topic/operator-framework/jswZUe1rlho

Answer 3

在您描述的情况下，我认为您被迫为要引入的新必填字段定义某种“默认”值，因此可以将在此更改之前创建的自定义对象转换为更新的规范。但是，这变成了向后兼容的更改，因此无需定义v2，您可以保留在v1中。

如果无法为其定义默认值，或者根本无法从与当前v1兼容的自定义对象中存在的其他字段（即在引入此版本之前要遵循的模式）派生任何值（对于该强制性引入的字段）更新），则应确保v2为新存储的versione，然后手动更新所有现有的与v1兼容的自定义对象，以正确设置该必需参数。甚至定义一个新的自定义对象...

Kubernetes CRD版本控制

3 个答案: