Server Side Apply

support v1.16+

Introduction

Server Side Apply helps users and controllers manage their resources via declarative configurations. It allows them to create and/or modify their objects declaratively, simply by sending their fully specified intent.

通过声明性配置帮助用户和控制器管理他们的资源。它允许它们以声明的方式创建和/或修改它们的对象，只需发送它们完全指定的意图

A fully specified intent is a partial object that only includes the fields and values for which the user has an opinion. That intent either creates a new object or is combined, by the server, with the existing object.

一个完全指定的intent是一个部分对象，它只包含用户有意见的字段和值。该意图要么创建一个新对象，要么由服务器与现有对象合并

The system supports multiple appliers collaborating on a single object.

系统支持多个应用程序在一个对象上协作。

This model of specifying intent makes it difficult to remove existing fields. When a field is removed from one’s config and applied, the value will be kept (the system assumes that you don’t care about that value anymore). If an item is removed from a list or a map, it will be removed if no other appliers care about its presence.

这种指定意图的模型使删除现有字段变得困难。当从配置中删除字段并应用该字段时，该值将被保留(系统假设您不再关心该值)。如果一个项目从列表或地图中删除，如果没有其他应用程序关心它的存在，它将被删除。

Changes to an object’s fields are tracked through a “field management” mechanism. When a field’s value changes, ownership moves from its current manager to the manager making the change. When trying to apply an object, fields that have a different value and are owned by another manager will result in a conflict. This is done in order to signal that the operation might undo another collaborator’s changes. Conflicts can be forced, in which case the value will be overridden, and the ownership will be transferred.

对对象字段的更改通过“字段管理”机制进行跟踪。当字段的值发生更改时，所有权将从当前管理器转移到进行更改的管理器。当尝试应用一个对象时，具有不同值且由另一个管理器拥有的字段将导致冲突。这样做是为了发出操作可能撤销其他合作者的更改的信号。冲突可以是强制的，在这种情况下，值将被覆盖，所有权将被转移。

It is meant both as a replacement for the original kubectl apply and as a simpler mechanism to write controllers.

它既可以替代原来的kubectl应用程序，也可以作为编写控制器的更简单的机制。

Field Management

Compared to the last-applied annotation managed by kubectl, Server Side Apply uses a more declarative approach, which tracks a user’s field management, rather than a user’s last applied state. This means that as a side effect of using Server Side Apply, information about which field manager manages each field in an object also becomes available.

与‘kubectl’管理的‘last-applied’注释相比，Server Side Apply使用了更具有声明特性的方法，它跟踪用户的字段管理，而不是用户最后应用的状态。这意味着，作为使用Server Side Apply的另一个方面的影响，关于哪个字段管理器管理对象中的对应的字段的信息也变得可能。

For a user to manage a field, in the Server Side Apply sense, means that the user relies on and expects the value of the field not to change. The user who last made an assertion about the value of a field will be recorded as the current field manager. This can be done either by changing the value with POST, PUT, or non-apply PATCH, or by including the field in a config sent to the Server Side Apply endpoint. When using Server-Side Apply, trying to change a field which is managed by someone else will result in a rejected request (if not forced, see Conflicts).

对于用户管理字段来说，在Server Side Apply意味着用户依赖并期望字段的值不会改变。最后一次断言字段值的用户将被记录为当前字段管理器。这可以通过改变“POST”、“PUT”或非应用“PATCH”的值来实现，也可以通过在发送到服务器端应用端点的配置中包含该字段来实现。在使用服务器端应用程序时，试图更改由其他人管理的字段将导致被拒绝的请求(如果不是强制的)
Field management is stored in a newly introduced managedFields field that is part of an object’s metadata.

A simple example of an object created by Server Side Apply could look like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-cm
  namespace: default
  labels:
    test-label: test
  managedFields:
  - manager: kubectl
    operation: Apply
    apiVersion: v1
    time: "2010-10-10T0:00:00Z"
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          f:test-label: {}
      f:data:
        f:key: {}
data:
  key: some value

Nevertheless it is possible to change metadata.managedFields through an Update operation. Doing so is highly discouraged, but might be a reasonable option to try if, for example, the managedFields get into an inconsistent state (which clearly should not happen).

The format of the managedFields is described in the API.

上面的对象在metada . managedfields中只包含一个管理器。管理器由关于管理实体本身的基本信息组成，如操作类型、api版本和由它管理的字段。

Conflicts

A conflict is a special status error that occurs when an Apply operation tries to change a field, which another user also claims to manage. This prevents an applier from unintentionally overwriting the value set by another user. When this occurs, the applier has 3 options to resolve the conflicts:

冲突是一种特殊的状态错误，当应用操作试图更改另一个用户也声称要管理的字段时，会发生这种错误。这可以防止应用程序无意中覆盖另一个用户设置的值。当这种情况发生时，应用程序有3个选项来解决冲突:

Overwrite value, become sole manager:
If overwriting the value was intentional (or if the applier is an automated process like a controller) the applier should set the force query parameter to true and make the request again. This forces the operation to succeed, changes the value of the field, and removes the field from all other managers’ entries in managedFields.

如果改写值是有意的(或者如果应用程序是一个像控制器一样的自动化过程)，应用程序应该将force查询参数设置为true并再次发出请求。这将强制操作成功，更改字段的值，并从managedFields中的所有其他管理器条目中删除该字段
Don’t overwrite value, give up management claim:
If the applier doesn’t care about the value of the field anymore, they can remove it from their config and make the request again. This leaves the value unchanged, and causes the field to be removed from the applier’s entry in managedFields.
不要覆盖值，放弃管理声明:如果应用程序不再关心字段的值，他们可以从配置中删除它并再次发出请求。这将保持值不变，并导致从managedFields中的applier条目中删除该字段。

Don’t overwrite value, become shared manager: If the applier still cares about the value of the field, but doesn’t want to overwrite it, they can change the value of the field in their config to match the value of the object on the server, and make the request again. This leaves the value unchanged, and causes the field’s management to be shared by the applier and all other field managers that already claimed to manage it.

不要覆盖值，成为共享管理器:如果应用程序仍然关心字段的值，但不想覆盖它，他们可以更改配置中的字段值以匹配服务器上的对象的值，并再次发出请求。这将使值保持不变，并使applier和所有其他已经声明对字段进行管理的字段管理器共享字段的管理。

Reference:
https://kubernetes.io/docs/reference/using-api/api-concepts/#server-side-apply