在Operator-SDK中，一个协调函数中有多个补丁

Question

我正在用operator-sdk实现operator。

我对operator SDK(client.Client)中的Patch接口有一些疑问。

Patch API有两种：Client.Patch和Client.Status().Patch。

据我所知，除资源中的Status外，第一个(Client.Patch)将作为补丁字段。另一个(Client.Status().Patch)用于修补资源中的Status字段。

在这一点上，我是否可以在一个协调函数中多次使用Patch(无论是Client.Status().Patch还是Client.Patch) API？

我认为Patch API会改变资源版本，所以当我在一个协调函数中多次调用Patch API时，API不能很好地工作，然而API(Patch)工作得很好(实际上我在一个协调函数中调用了2次)。

如果有我误解的知识，请给我建议。

谢谢。

Answer 1

我找到了一篇博客文章，标题是：7 Best Practices for Writing Kubernetes Operators: An SRE Perspective

第四点是：

4:一次修改一个自定义资源

每当控制器正在监视的自定义资源发生更改时，协调循环都会再次运行。这包括用户所做的更改，也包括您在协调函数或其子例程中所做的更改。通常，您需要更新正在操作的自定义资源以添加信息。GCP项目操作员的一个示例是它在GCP中创建的项目的ID。此更新将导致协调循环获取自定义资源的更新版本，并开始另一次协调运行。

您需要意识到这一点，因为更改自定义资源并继续处理可能会导致新创建的请求出现争用情况。如果启用了并行处理，它会立即开始运行协调函数。在这种情况下，您必须考虑在代码的每一行中可能同时有第二个请求在此资源上工作。即使不并行处理请求，在一次又一次地更新CustomResource时，协调请求也会堆积起来，使操作员不必要地忙碌。

为了降低竞争条件的风险并避免堆积请求，请确保您不会在一次协调运行中对自定义资源或相关操作执行多个更改。每当您更新您正在观察的自定义资源时，只需退出协调循环，并让下一次运行继续。您之前执行的所有幂等函数都不会执行任何操作，您可以从上次停止的地方继续执行。

因此，如果我理解正确的话，您可以在一次协调函数运行中进行几次更改，但这通常被认为是糟糕的做法。