注:本文已发布超过一年,请注意您所使用工具的相关版本是否适用
本来一开始只打算简单的了解一些 kubebuilder 的使用方法,知道基本上怎么使用就行了,但是看着看着就有点刹不住车了,文章数量也从预计的 5 篇左右翻了一个倍。
不过虽然时间花的久了一些,感觉还是挺值的,前面 9 篇文章除了高可用没有专门讲解之外,关于Operator 比较大的模块也算是都有涉及了,最开始的时候可能总是觉得 Operator 的编写可能会比较复杂,整个使用上风险也比较大,但是接触了 kubebuilder 发现,社区已经将相关的开发组件封装的很好了,整个体验也算是比较顺畅,基本上我们只需要知道相关的一些概念,就可以直接上手进行使用了。kubebuilder 的代码和设计上也是十分值得学习的,大量的使用到了接口,在降低学习成本的同时也留下了充分的扩展性,这是我在之前我们自己的一些代码和框架上没有看到的。因为一般来说想要做到这种只需要写一个函数就能完成业务开发的话,限制都会很大,二次开发也会很麻烦,kubebuilder 的平衡做的很好。
下面我们就简单的回顾一下之前学习的内容:
我们在第一篇文章中主要介绍了 K8s 有哪些扩展点,希望起到一个大纲的作用,之后如果有一些需求想要对 k8s 进行扩展的时候可以知道从哪里下手。核心就是下面这张图了

在这一篇文章中我们使用 kind 搭建了自己的本地开发环境,说简单其实也挺简单的 kind create cluster 一行命令就完事,不过最好还是有科学上网的环境,能够使我们的环境创建的过程顺畅很多。
这里面比较坑的就是 load image 的特性,当时卡了我很久,主要是因为默认的镜像拉取策略是 imagePullPolicy: Always ,这样无论什么怎么设置都会报拉取镜像错误,因为我们的镜像实际上是没有推送的。
这篇文章中,我们完成了 kubebuilder 的环境搭建,学习了如何使用的 kubebuilder 快速的创建一个 operator 项目骨架。
1 | |
kubebuilder 中的 YAML 文件都是通过 kustomize 生成的,如果不太清楚这个工具用起来可能会感觉到比较困惑,并且我们后面也要对默认的配置进行一些改造,所以就把这一篇文章往前放了一些。
这一篇文章主要是讲了 kustomize 的一个使用方法和项目布局,知道里面有哪些 api 可以对 yaml 文件怎么进行修改,kustomize 其实比较适合用于 gitops
从这一篇文章开始就进入到我们 NodePool Operator 的开发过程中了,这一篇主要是先分析了一下需求,然后大概想了一下方案,实现了 CURD 的一个能力。
除了基本的 CURD 之外我们还利用 Finalizers 实现了预删除,使用 OwnerReference 将两个资源进行了关联,保证了父资源删除子资源就会被自动删除。
在 K8s 中我们经常会看到很多资源都有一些 status 和 event,因为我们资源在被控制器不断的进行调整,所以它会处于一个变化的过程中,这时候通过 status 我们就可以很方便的知道当前资源的状态,是否存在问题等。status 中还会时常放置一些统计数据,例如 pod 数目这种。
通过 event 我们可以记录一些时序数据或者是关键的错误日志等信息,这样可以帮助我们更好的排查错误,因为可能现在存在这个问题,等一会儿再执行的时候这个问题就没了。
Operator 的测试真的是个老大难的问题,因为在 k8s 中控制器是不断在运行的,如果监听了一些系统资源的事件,那触发的频率会更高。
在这篇文章,我们抛砖引玉一起看了一个单元测试的案例和集成测试的案例,单元测试和一般的 go test 没有什么区别,集成测试我们直接在 kubebuilder 生成的测试代码的基础上写相关的测试逻辑就行了。
准入控制存在两种 WebHook,变更准入控制 MutatingAdmissionWebhook,和验证准入控制 ValidatingAdmissionWebhook,执行的顺序是先执行 MutatingAdmissionWebhook 再执行 ValidatingAdmissionWebhook。
这篇文章我们实现了两种准入控制的接口,并且部署到了集群中,同时还讲解了本地如何进行调试
Kubebuilder 是一个非常好用的 Operator 开发框架,不仅极大的简化了 Operator 的开发过程,并且充分的利用了 go interface 的特性留下了足够的扩展性。
这篇文章我们简单看了一些 kubebuilder 启动相关的源码,了解了我们代码是如何跑起来的,虽然不算是特别深入,但是也可以说 kubebuilder 对我们也不完全是黑盒了
注:本文已发布超过一年,请注意您所使用工具的相关版本是否适用
本来一开始只打算简单的了解一些 kubebuilder 的使用方法,知道基本上怎么使用就行了,但是看着看着就有点刹不住车了,文章数量也从预计的 5 篇左右翻了一个倍。
不过虽然时间花的久了一些,感觉还是挺值的,前面 9 篇文章除了高可用没有专门讲解之外,关于Operator 比较大的模块也算是都有涉及了,最开始的时候可能总是觉得 Operator 的编写可能会比较复杂,整个使用上风险也比较大,但是接触了 kubebuilder 发现,社区已经将相关的开发组件封装的很好了,整个体验也算是比较顺畅,基本上我们只需要知道相关的一些概念,就可以直接上手进行使用了。kubebuilder 的代码和设计上也是十分值得学习的,大量的使用到了接口,在降低学习成本的同时也留下了充分的扩展性,这是我在之前我们自己的一些代码和框架上没有看到的。因为一般来说想要做到这种只需要写一个函数就能完成业务开发的话,限制都会很大,二次开发也会很麻烦,kubebuilder 的平衡做的很好。
下面我们就简单的回顾一下之前学习的内容:
我们在第一篇文章中主要介绍了 K8s 有哪些扩展点,希望起到一个大纲的作用,之后如果有一些需求想要对 k8s 进行扩展的时候可以知道从哪里下手。核心就是下面这张图了

在这一篇文章中我们使用 kind 搭建了自己的本地开发环境,说简单其实也挺简单的 kind create cluster 一行命令就完事,不过最好还是有科学上网的环境,能够使我们的环境创建的过程顺畅很多。
这里面比较坑的就是 load image 的特性,当时卡了我很久,主要是因为默认的镜像拉取策略是 imagePullPolicy: Always ,这样无论什么怎么设置都会报拉取镜像错误,因为我们的镜像实际上是没有推送的。
这篇文章中,我们完成了 kubebuilder 的环境搭建,学习了如何使用的 kubebuilder 快速的创建一个 operator 项目骨架。
1 | |
kubebuilder 中的 YAML 文件都是通过 kustomize 生成的,如果不太清楚这个工具用起来可能会感觉到比较困惑,并且我们后面也要对默认的配置进行一些改造,所以就把这一篇文章往前放了一些。
这一篇文章主要是讲了 kustomize 的一个使用方法和项目布局,知道里面有哪些 api 可以对 yaml 文件怎么进行修改,kustomize 其实比较适合用于 gitops
从这一篇文章开始就进入到我们 NodePool Operator 的开发过程中了,这一篇主要是先分析了一下需求,然后大概想了一下方案,实现了 CURD 的一个能力。
除了基本的 CURD 之外我们还利用 Finalizers 实现了预删除,使用 OwnerReference 将两个资源进行了关联,保证了父资源删除子资源就会被自动删除。
在 K8s 中我们经常会看到很多资源都有一些 status 和 event,因为我们资源在被控制器不断的进行调整,所以它会处于一个变化的过程中,这时候通过 status 我们就可以很方便的知道当前资源的状态,是否存在问题等。status 中还会时常放置一些统计数据,例如 pod 数目这种。
通过 event 我们可以记录一些时序数据或者是关键的错误日志等信息,这样可以帮助我们更好的排查错误,因为可能现在存在这个问题,等一会儿再执行的时候这个问题就没了。
Operator 的测试真的是个老大难的问题,因为在 k8s 中控制器是不断在运行的,如果监听了一些系统资源的事件,那触发的频率会更高。
在这篇文章,我们抛砖引玉一起看了一个单元测试的案例和集成测试的案例,单元测试和一般的 go test 没有什么区别,集成测试我们直接在 kubebuilder 生成的测试代码的基础上写相关的测试逻辑就行了。
准入控制存在两种 WebHook,变更准入控制 MutatingAdmissionWebhook,和验证准入控制 ValidatingAdmissionWebhook,执行的顺序是先执行 MutatingAdmissionWebhook 再执行 ValidatingAdmissionWebhook。
这篇文章我们实现了两种准入控制的接口,并且部署到了集群中,同时还讲解了本地如何进行调试
Kubebuilder 是一个非常好用的 Operator 开发框架,不仅极大的简化了 Operator 的开发过程,并且充分的利用了 go interface 的特性留下了足够的扩展性。
这篇文章我们简单看了一些 kubebuilder 启动相关的源码,了解了我们代码是如何跑起来的,虽然不算是特别深入,但是也可以说 kubebuilder 对我们也不完全是黑盒了