背景
OpenKruise 是阿里云开源的大规模应用自动化管理引擎，在功能上对标了 Kubernetes 原生的 Deployment / StatefulSet 等控制器，但 OpenKruise 提供了更多的增强功能如：优雅原地升级、发布优先级/打散策略、多可用区workload抽象管理、统一 sidecar 容器注入管理等，都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。
目前在阿里巴巴内部云原生环境中，绝大部分应用都统一使用 OpenKruise 的能力做 Pod 部署、发布管理，而不少业界公司和阿里云上客户由于 K8s 原生 Deployment 等负载不能完全满足需求，也转而采用 OpenKruise 作为应用部署载体。
今天的分享文章就从一个阿里云上客户对接 OpenKruise 的疑问开始。这里还原一下这位同学的用法（以下 YAML 数据仅为 demo）：
准备一份 Advanced StatefulSet 的 YAML 文件，并提交创建。如：
yaml apiVersion: apps.kruise.io/v1alpha1
kind: StatefulSet
metadata:
name: sample
spec:
# ...
template:
# ...
spec:
containers:
- name: main
image: nginx:alpine
updateStrategy:
type: RollingUpdate
rollingUpdate:
podUpdatePolicy: InPlaceIfPossible
然后，修改了 YAML 中的 image 镜像版本，然后调用 K8s api 接口做更新。结果收到报错如下：
shell metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
而如果使用 kubectl apply 命令做更新，则返回成功：
shell statefulset.apps.kruise.io/sample configured
问题在于，为什么同一份修改后的 YAML 文件，调用 api 接口更新是失败的，而用 kubectl apply 更新是成功的呢？这其实并不是 OpenKruise 有什么特殊校验，而是由 K8s 自身的更新机制所决定的。
从我们的接触来看，绝大多数用户都有通过 kubectl 命令或是 sdk 来更新 K8s 资源的经验，但真正理解这些更新操作背后原理的人却并不多。本文将着重介绍 K8s 的资源更新机制，以及一些我们常用的更新方式是如何实现的。
更新原理
不知道你有没有想过一个问题：对于一个 K8s 资源对象比如 Deployment，我们尝试在修改其中 image 镜像时，如果有其他人同时也在对这个 Deployment 做修改，会发生什么？
当然，这里还可以引申出两个问题：
如果双方修改的是同一个字段，比如 image 字段，结果会怎样？
如果双方修改的是不同字段，比如一个修改 image，另一个修改 replicas，又会怎么样？
其实，对一个 Kubernetes 资源对象做“更新”操作，简单来说就是通知 kube-apiserver 组件我们希望如何修改这个对象。而 K8s 为这类需求定义了两种“通知”方式，分别是 update 和 patch。在 update 请求中，我们需要将整个修改后的对象提交给 K8s；而对于 patch 请求，我们只需要将对象中某些字段的修改提交给 K8s。
那么回到背景问题，为什么用户提交修改后的 YAML 文件做 update 会失败呢？这其实是被 K8s 对 update 请求的版本控制机制所限制的。
Update 机制
Kubernetes 中的所有资源对象，都有一个全局唯一的版本号（metadata.resourceVersion）。每个资源对象从创建开始就会有一个版本号，而后每次被修改（不管是 update 还是 patch 修改），版本号都会发生变化。
官方文档告诉我们，这个版本号是一个 K8s 的内部机制，用户不应该假设它是一个数字或者通过比较两个版本号大小来确定资源对象的新旧，唯一能做的就是通过比较版本号相等来确定对象是否是同一个版本（即是否发生了变化）。而 resourceVersion 一个重要的用处，就是来做 update 请求的版本控制。
K8s 要求用户 update 请求中提交的对象必须带有 resourceVersion，也就是说我们提交 update 的数据必须先来源于 K8s 中已经存在的对象。因此，一次完整的 update 操作流程是：
首先，从 K8s 中拿到一个已经存在的对象（可以选择直接从 K8s 中查询；如果在客户端做了 list watch，推荐从本地 informer 中获取）；
然后，基于这个取出来的对象做一些修改，比如将 Deployment 中的 replicas 做增减，或是将 image 字段修改为一个新版本的镜像；
最后，将修改后的对象通过 update 请求提交给 K8s；
此时，kube-apiserver 会校验用户 update 请求提交对象中的 resourceVersion 一定要和当前 K8s 中这个对象最新的 resourceVersion 一致，才能接受本次 update。否则，K8s 会拒绝请求，并告诉用户发生了版本冲突（Conflict）。
用户修改 YAML 后提交 update 失败，是因为 YAML 文件中没有包含 resourceVersion 字段。对于 update 请求而言，应该取出当前 K8s 中的对象做修改后提交；
如果两个用户同时对一个资源对象做 update，不管操作的是对象中同一个字段还是不同字段，都存在版本控制的机制确保两个用户的 update 请求不会发生覆盖。
Patch 机制
如果要在其中新增一个 nginx 容器，如何 patch 更新？
如果要修改 app 容器的镜像，如何 patch 更新？
bash kubectl patch deployment/foo --type='json' -p \
'[{"op":"add","path":"/spec/template/spec/containers/1","value":{"name":"nginx","image":"nginx:alpine"}}]
bash kubectl patch deployment/foo --type='json' -p \
'[{"op":"replace","path":"/spec/template/spec/containers/0/image","value":"app-image:v2"}]
kubectl 封装
了解完了 K8s 的基础更新机制，我们再次回到最初的问题上。为什么用户修改 YAML 文件后无法直接调用 update 接口更新，却可以通过 kubectl apply 命令更新呢？
如果查询结果不存在，kubectl 将本次用户提交的数据记录到对象 A 的 annotation 中（key 为 kubectl.kubernetes.io/last-applied-configuration），最后将对象 A提交给 K8s 创建；
如果查询到 K8s 中已有这个资源，假设为对象 B：1. kubectl 尝试从对象 B 的 annotation 中取出 kubectl.kubernetes.io/last-applied-configuration 的值（对应了上一次 apply 提交的内容）；2. kubectl 根据前一次 apply 的内容和本次 apply 的内容计算出 diff（默认为 strategic merge patch 格式，如果非原生资源则采用 merge patch）；3. 将 diff 中添加本次的 kubectl.kubernetes.io/last-applied-configuration annotation，最后用 patch 请求提交给 K8s 做更新。
总结
