Kubernetes并发控制与数据一致性的实现原理

标签：bee   and   实现原理   nil   nsa   文件   完整   ted   storage   

1. 获取当前更新请求中obj对象的ResourceVersion值，及服务器端最新obj对象(existing)的ResourceVersion值
2. 如果当前更新请求中obj对象的ResourceVersion值等于0，即客户端未设置该值，则判断是否要硬改写(AllowUnconditionalUpdate)，如配置为硬改写策略，将直接更新obj对象
3. 如果当前更新请求中obj对象的ResourceVersion值不等于0，则判断两个ResourceVersion值是否一致，不一致返回冲突错误(OptimisticLockErrorMsg)
   Patch
   相比Update请求包含整个obj对象，Patch请求实现了更细粒度的对象更新操作，其请求中只包含需要更新的字段。例如要更新pod中container的镜像，可使用如下命令：
   kubectl patch pod my-pod -p ‘{"spec":{"containers":[{"name":"my-container","image":"new-image"}]}}‘
   服务器端只收到以上的patch信息，然后通过如下代码将该patch更新到Etcd中。
   func (p *patcher) patchResource(ctx context.Context) (runtime.Object, error) {
   p.namespace = request.NamespaceValue(ctx)
   switch p.patchType {
   case types.JSONPatchType, types.MergePatchType:
   p.mechanism = &jsonPatcher{patcher: p}
   case types.StrategicMergePatchType:
   schemaReferenceObj, err := p.unsafeConvertor.ConvertToVersion(p.restPatcher.New(), p.kind.GroupVersion())
   if err != nil {
   return nil, err
   }
   p.mechanism = &smpPatcher{patcher: p, schemaReferenceObj: schemaReferenceObj}
   default:
   return nil, fmt.Errorf("%v: unimplemented patch type", p.patchType)
   }
   p.updatedObjectInfo = rest.DefaultUpdatedObjectInfo(nil, p.applyPatch, p.applyAdmission)
   return finishRequest(p.timeout, func() (runtime.Object, error) {
   updateObject, _, updateErr := p.restPatcher.Update(ctx, p.name, p.updatedObjectInfo, p.createValidation, p.updateValidation, false, p.options)
   return updateObject, updateErr
   })
   }
   基本流程为：
   1.首先判断patch的类型，根据类型选择相应的mechanism
   2.利用DefaultUpdatedObjectInfo方法将applyPatch(应用Patch的方法)添加到admission chain的头部
   3.最终还是调用上述Update方法执行更新操作
   在步骤2中将applyPatch方法挂到admission chain的头部，与admission行为相似，applyPatch方法会将patch应用到最新获取的服务器端obj上，生成一个已更新的obj，再对该obj继续执行admission chain中的Admit与Validate。最终调用的还是update方法，因此冲突检测的机制与上述Update方法完全一致。
   相比Update，Patch的主要优势在于客户端不必提供全量的obj对象信息。客户端只需以patch的方式提交要修改的字段信息，服务器端会将该patch数据应用到最新获取的obj中。省略了Client端获取、修改再提交全量obj的步骤，降低了数据被修改的风险，更大大减小了冲突概率。 由于Patch方法在传输效率及冲突概率上都占有绝对优势，目前Kubernetes中几乎所有更新操作都采用了Patch方法，我们在编写代码时也应该注意使用Patch方法。
   附：
   ResourceVersion字段在Kubernetes中除了用在上述并发控制机制外，还用在Kubernetes的list-watch机制中。Client端的list-watch分为两个步骤，先list取回所有对象，再以增量的方式watch后续对象。Client端在list取回所有对象后，将会把最新对象的ResourceVersion作为下一步watch操作的起点参数，也即Kube-Apiserver以收到的ResourceVersion为起始点返回后续数据，保证了list-watch中数据的连续性与完整性。

Kubernetes并发控制与数据一致性的实现原理

标签：bee   and   实现原理   nil   nsa   文件   完整   ted   storage   

原文地址：http://blog.51cto.com/13762283/2320508