Kubernetes ObjectMacher

本文介绍K8S ObjectMatcher库的使用与实现原理,针对Operator频繁更新问题提供解决方案。文章详细展示了三路合并策略及如何避免不必要更新。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 环境说明

源码链接:https://github.com/banzaicloud/k8s-objectmatcher
版本/Tag:v1.8.0

适用场景:用于匹配K8S资源对象

作者写该库的动机:在编写一些诸如Istio, Vault, Kafka的复制Operator的时候,遇到了大量的不必要的对象更新。大多数Operator都是通过reflect.DeepEquals来匹配给定对象的Spec。不幸的是,这个解决方案并不完美,因为每个Kubernetes对象在提交的时候会被修改默认值,作者写这个库的目标是为了能够提供更加精细的对象匹配功能,以避免不必要的更新和客户端的可观测性

工作原理:作者使用three way merge方法计算补丁。然后,为了能够使three way merge能够正常工作,我们需要跟踪对象的最后应用版本,我们称它为original。不幸的是,Kubernetes并不会跟踪我们之前提交的对象版本;万幸的是,我们可以通过模仿kubectl apply在对象提交的时候注入Annotation用于记录当前对象的配置信息。下一次查询的时候我们就能够去对象的current状态,并且从original中获取对象以前的状态。一旦我们有了original, current, modified,剩下的时候就可以交给这个库了。

2. 3-Way Merge

TODO

3. Demo

我们以v1.Service来举例该库的使用

首先,我们创建一个Service,用Annotation标注它,然后再提交

original := &v1.Service{
  ...
}

if err := patch.DefaultAnnotator.SetLastAppliedAnnotation(original); err != nil {
  ...
}

client.CoreV1().Services(original.GetNamespace()).Create(original)

当我们需要更新的时候,需要调用patch.DefaultPatchMaker.Calculate()方法计算currentmodified的不同,然后再去更新

modified := &v1.Service{
  ...
}

current, err := client.CoreV1().Services(modified.GetNamespace()).Get(modified.GetName(), metav1.Getoptions{})

patchResult, err := patch.DefaultPatchMaker.Calculate(current, modified)
if err != nil {
  return err
}

if !patchResult.IsEmpty() {
  if err := patch.DefaultAnnotator.SetLastAppliedAnnotation(modified); err != nil {
  	...
  }
  client.CoreV1().Services(modified.GetNamespace()).Update(modified)
}

4. 源码分析

TODO

var DefaultPatchMaker = NewPatchMaker(DefaultAnnotator, &K8sStrategicMergePatcher{}, &BaseJSONMergePatcher{})

type Maker interface {
	Calculate(currentObject, modifiedObject runtime.Object, opts ...CalculateOption) (*PatchResult, error)
}

type PatchMaker struct {
	annotator *Annotator

	strategicMergePatcher StrategicMergePatcher
	jsonMergePatcher      JSONMergePatcher
}

func NewPatchMaker(annotator *Annotator, strategicMergePatcher StrategicMergePatcher, jsonMergePatcher JSONMergePatcher) Maker {
	return &PatchMaker{
		annotator: annotator,

		strategicMergePatcher: strategicMergePatcher,
		jsonMergePatcher:      jsonMergePatcher,
	}
}

func (p *PatchMaker) Calculate(currentObject, modifiedObject runtime.Object, opts ...CalculateOption) (*PatchResult, error) {
	current, err := json.ConfigCompatibleWithStandardLibrary.Marshal(currentObject)
	if err != nil {
		return nil, errors.Wrap(err, "Failed to convert current object to byte sequence")
	}

	modified, err := json.ConfigCompatibleWithStandardLibrary.Marshal(modifiedObject)
	if err != nil {
		return nil, errors.Wrap(err, "Failed to convert current object to byte sequence")
	}

	for _, opt := range opts {
		current, modified, err = opt(current, modified)
		if err != nil {
			return nil, errors.Wrap(err, "Failed to apply option function")
		}
	}

	current, _, err = DeleteNullInJson(current)
	if err != nil {
		return nil, errors.Wrap(err, "Failed to delete null from current object")
	}

	modified, _, err = DeleteNullInJson(modified)
	if err != nil {
		return nil, errors.Wrap(err, "Failed to delete null from modified object")
	}

	original, err := p.annotator.GetOriginalConfiguration(currentObject)
	if err != nil {
		return nil, errors.Wrap(err, "Failed to get original configuration")
	}

	var patch []byte

	switch currentObject.(type) {
	default:
		patch, err = p.strategicMergePatcher.CreateThreeWayMergePatch(original, modified, current, currentObject)
		if err != nil {
			return nil, errors.Wrap(err, "Failed to generate strategic merge patch")
		}
		// $setElementOrder can make it hard to decide whether there is an actual diff or not.
		// In cases like that trying to apply the patch locally on current will make it clear.
		if string(patch) != "{}" {
			patchCurrent, err := p.strategicMergePatcher.StrategicMergePatch(current, patch, currentObject)
			if err != nil {
				return nil, errors.Wrap(err, "Failed to apply patch again to check for an actual diff")
			}
			patch, err = p.strategicMergePatcher.CreateTwoWayMergePatch(current, patchCurrent, currentObject)
			if err != nil {
				return nil, errors.Wrap(err, "Failed to create patch again to check for an actual diff")
			}
		}
	case *unstructured.Unstructured:
		patch, err = p.unstructuredJsonMergePatch(original, modified, current)
		if err != nil {
			return nil, errors.Wrap(err, "Failed to generate merge patch")
		}
	}

	return &PatchResult{
		Patch:    patch,
		Current:  current,
		Modified: modified,
		Original: original,
	}, nil
}

内容概要:本文详细介绍了基于FPGA的144输出通道可切换电压源系统的设计与实现,涵盖系统总体架构、FPGA硬件设计、上位机软件设计以及系统集成方案。系统由上位机控制软件(PC端)、FPGA控制核心和高压输出模块(144通道)三部分组成。FPGA硬件设计部分详细描述了Verilog代码实现,包括PWM生成模块、UART通信模块和温度监控模块。硬件设计说明中提及了FPGA选型、PWM生成方式、通信接口、高压输出模块和保护电路的设计要点。上位机软件采用Python编写,实现了设备连接、命令发送、序列控制等功能,并提供了一个图形用户界面(GUI)用于方便的操作和配置。 适合人群:具备一定硬件设计和编程基础的电子工程师、FPGA开发者及科研人员。 使用场景及目标:①适用于需要精确控制多通道电压输出的实验环境或工业应用场景;②帮助用户理解和掌握FPGA在复杂控制系统中的应用,包括PWM控制、UART通信及多通道信号处理;③为研究人员提供一个可扩展的平台,用于测试和验证不同的电压源控制算法和策略。 阅读建议:由于涉及硬件和软件两方面的内容,建议读者先熟悉FPGA基础知识和Verilog语言,同时具备一定的Python编程经验。在阅读过程中,应结合硬件电路图和代码注释,逐步理解系统的各个组成部分及其相互关系。此外,实际动手搭建和调试该系统将有助于加深对整个设计的理解。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值