DockOne微信分享(二四三):如何在Kubernetes中编写自定义控制器


【编者的话】随着云原生技术生态的日趋完善和各大云计算技术厂商提供PaaS平台能力的日臻成熟,创建Kubernetes集群以及在集群上部署应用变得非常容易。尽管Kubernetes Deployment可以实现对应用滚动升级和回滚的管理,但事实上程序的发布流程往往千差万别。在遵循Kubernetes的控制器模型和API编程范式的前提下,从“在Kubernetes中部署代码”晋级到“使用Kubernetes编写代码”是Kubernetes用户进阶的过程。

Kubernetes的控制器模型和声明式API对象

容器的本质是进程,因此容器里PID=1的进程是应用本身,其它的进程都是这个PID=1的进程的子进程。Pod只是一个逻辑概念,Kubernetes真正要处理的还是宿主机的Linux容器和Namespace和Cgroups。因此也可以认为Pod在扮演传统基础设施里“虚拟机”的角色,而容器,则是运行在这个虚拟机里的用户程序。Kubernetes提供一种实现Pod自动伸缩、滚动升级、回滚的机制叫控制器。

Kubernetes中提供很多控制器,如果我们查看pkg/controller目录:
ls **/pgk/controller

deployment/             job/                    podautoscaler/          
cloud/                  disruption/             namespace/              
replicaset/             serviceaccount/         volume/
cronjob/                garbagecollector/       nodelifecycle/   
replication/            statefulset/            daemon/
...

尽管以上每一个控制器负责不同资源资源的编排工作,但是它们都遵循最基本的控制循环(Control Loop)的原理,本节我将主要介绍Deployment。

首先我们一起来看一个deployment yaml文件:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
  app: nginx
template:
metadata:
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

简单将上述Deployment的作用就是为了确保携带app:nginx标签的Pod数量永远等于spec.replicass指定的数量3。

可以将控制器控制循环的实现原理作如下归纳:
  1. Deployment控制器从etcd中获取集群中携带特定标签的Pod数量(Pod的实际数量)
  2. Deployent Yaml文件中描述的Replicas字段的值 (Pod的期望数量)
  3. Deployment比较以上结果,确定是创建新的Pod还是删除老的Pod


像上面Deployment Yaml文件那样,具备以下几个特点的资源对象,就是声明式API对象:
  1. 通过一个定义好的API对象来“声明”期望的资源状态是什么样子
  2. 允许有多个API写端,以PATCH的方式对API对象进行修改,而无需关心原始YAML文件的内容
  3. 基于对API对象的增删改查在无需外接干预的情况下,完成对“实际状态”和“期望状态”的调谐过程


读到这里想必你已经发现声明式API对象与控制器模型相辅相成,声明式API对象定义出期望的资源状态,控制器模型则通过控制循环(Control Loop)将Kubernetes内部的资源调整为声明式API对象期望的样子。因此可以认为声明式API对象和控制器模型,才是Kubernetes项目编排能力“赖以生存”的核心所在。

声明式API对象的编程范式

API对象的组织方式

API对象在etcd里的完整资源路径是由 Group(API组)、Version(API版本)和Resource(API资源类型)三部分组成。

Kubernetes创建资源对象的流程:
  • 首先Kubernetes读取用户提交的yaml文件
  • 然后Kubernetes去匹配yaml文件中API对象的组
  • 再次Kubernetes去匹配yaml文件中API对象的版本号
  • 最后Kubernetes去匹配yaml文件中API对象的资源类型


因此我们需要根据需求先进行自定义资源(CRD - Custom Resource Definition),它将包括API对象组、版本号、资源类型:
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: myresources.spursyy
spec:
group: spursy
version: v1
names:
kind: MyResource
plural: myresources
scope: Namespaced

在上面的yaml文件中指定group: spursyy和version: v1API的组和版本号信息、也指定了CR资源类型叫做myResource,复数是myResources、同时还声明该资源是Namespaced的对象。

然后我们就可以使用刚才定义的资源对象:
  • 资源类型指定为myResource
  • 资源组为spursy
  • 资源的版本号为v1


apiVersion: spursy/v1
kind: MyResource
metadata:
name: myresources.spursyy
spec:
message: hello world
someValue: 13

如果只定义资源对象,而不定义相应的控制,资源对象并不能发挥任何效用。接下来我们一起看看如何自定义资源控制器。

自定义控制器的原理

控制器如何与APIServer通信
  • Informer是APIServer与Kubernetes相互通信的桥梁,它通过Reflector实现ListAndWatch方法来“获取”和“监听”对象实例的变化
  • 每当APIServer接收到创建、更新和删除实例的请求,Refector都会收到“事件通知”,然后将变更的事件推送到先进先出的队列中
  • Informer会不断从上一队列中读取增量,然后根据增量事件的类型创建或者更新本地对象的缓存
  • Informer会根据事件类型触发事先定义好的ResourceEventHandler(具体为AddFunc、UpdatedFunc和DeleteFunc,分别对应API对象的“添加”、“更新”和“删除”事件)
  • 同时每隔一定的时间Informer也会对本地的缓存进行一次强制更新


WorkQueue同步Informer跟控制循环(Control Loop)交互的数据

Controller Loop扮演这Kubernetes控制器的角色,确保期望与实际的运行的状态是一致的

以上工作原理如下图(引用深入剖析Kubernetes):
1.png

综上所述,如何使用控制器模式,同Kubernetes里API对象的“增、删、改、查”进行协作,进而完成用户业务逻辑的编写过程。这就是“Kubernetes 编程范式”。

编写自定义控制器

Operator

Operator是由CoreOS开发的,用来扩展Kubernetes API,特定的应用程序控制器,它用来创建、配置和管理复杂的有状态应用,如数据库、缓存和监控系统。接下来我将使用Operator SDK,自定义用来控制Pod数量的特定资源。简而言之就是实现类似Kubernetes ReplicaSet类型的资源。
在使用Operator SDK自定义资源前,我们需要明确两点:

Operator SDK的工作流
  • 使用SDK创建一个新的Operator项目
  • 通过添加自定义资源(CRD)定义新的资源API
  • 指定使用SDK API来watch的资源
  • 定义Operator的协调(reconcile)逻辑
  • 使用Operator SDK构建并生成Operator部署清单文件


明确第一资源和第二资源

像上述我们即将实现类ReplicaSet自定义资源中,第一资源是ReplicaSet自身(明确指定运行的Docker镜像和ReplicaSet中Pod的数量)、第二资源是运行的Pod。当ReplicaSet中属性发生变化(如自定的Docker镜像,或者指定Pod副本的数量)或者Pod的发生变化(如Pod的实际运行数量减少),Controller控制器通过前文讲的控制循环一旦发现上述变化,就会通过变更Pod中镜像的版本或者伸缩Pod的数量调谐(reconcile)集群中ReplicaSet资源的状态。

实践Operator SDK

安装Operator SDK

可参见官方文档:https://github.com/operator-framework/operator-sdk

生成Go项目框架

operator-sdk new podset-operator
2.png

添加自定义API

operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=PodSet

添加自定义控制器

operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=PodSet

修改*/podset-operator/pkg/apis/app/v1alpha1/podset_types.go文件中的PodSetSpec 和 PodSetStatus
type PodSetSpec struct {
Replicas int32 `json:"replicas"`
}
type PodSetStatus struct {
Replicas int32    `json:"replicas"`
PodNames []string `json:"podNames"`


注意:我们一旦对Operator SDK生成的框架做任何修改,都需要执行operator-sdk generate k8s,重新生成相应的pkg/apis/app/v1alpha1/zz_generated.deepcopy.go文件。

最后我们需要实现控制器中自动伸缩的代码

代码修改是在控制器Reconcile的函数中/podset-operator/pkg/controller/podset/podset_controller.go。

我需要明确一下逻辑:
  • PodSet或者归属于PodSet的Pod一旦发生变化都会触发reconcile函数
  • 无论是增加还是删除Pod,Reconcile函数每次都只能增删一个Pod,然后返回,等待下一次触发Reconcile函数
  • 确保归属于PodSet第一资源的Pod使用controllerutil.SetControllerReference()函数,这样当第一资源删除时,系统会自动将相应的Pod删除


以上代码实现可参见:https://github.com/spursy/pods ... 23L86

生成部署文件
  • 将Operator项目打包成镜像:operator-sdk build spursyy/podset-operator
  • 推送到docker hub:docker push spursyy/podset-operator
  • 修改operator.yaml文件:sed -i "" 's|REPLACE_IMAGE|spursyy/podset-operator|g' deploy/operator.yaml


部署到集群中

创建service account:create -f deploy/service_account.yaml

为service account做RBAC认证:
kubectl create -f deploy/role.yaml
kubectl create -f deploy/role_binding.yaml


部署CRD和Operator文件:
kubectl create -f deploy/crds/app_v1alpha1_podset_crd.yaml
kubectl create -f deploy/operator.yaml


最后部署一个3副本的podset:
echo "apiVersion: app.example.com/v1alpha1
kind: PodSet
metadata:
name: example-podset
spec:
replicas: 3" | oc create -f -

以上示例可参见:https://github.com/spursy/podset-operator

Q&A

Q:yaml文件如果最小化展示?
A:Kubernetes有很多默认属性的,这需要具体查文档。

Q:Operator本身挂了怎么办?依赖其他系统重新调度吗?
A:Operator本身要是挂了,自定义资源的控制器是不能工作的,这时其他的调度系统也不能代替的。

Q:怎么解决CRD升级的问题,比如更改字段,但是已有服务已经运行?
A:这是Kubernetes的控制器通过获取资源资源的实际运行状态与期望的状态对比,如果不相同则删除老的Pod然后拉起期望的Pod。

Q:假如我想通过CPU负载的预测值改变Pod数量,我如何将预测函数加入自定义控制器,从而改变Pod数量?
A:理论上讲这部分逻辑写到控制器的reconcile函数中是没问题的。但是我觉得更应该从调度策略上解决这个问题,即在调度时通过策略选择合适的节点。

Q:接着上面问题,改变Pod数量时,可否通过函数判断,先使用垂直伸缩在进行水平伸缩,那请问如何实现垂直伸缩?
A:不知你说的垂直伸缩是不是意味给Pod分配更多的资源。如果是可以通过自编控制时定义资源属性,用户可以自定义对应的资源属性实现垂直伸缩。

Q:能否讲解下reflector具体工作原理?
A:大致为下面:1. 通过反射器实现对指定类型对象的监控;2. DeltaFiFo队列,将上一步监控到有变化的对象加入到队列中;3.并将队列缓存到本地,并根据事件类型注册相应的事件;4. 最后将对象pop到work queue供control loop触发上一步注册的事件函数。

Q:如何在一个对象控制器的eventHander中触发另外一个资源controller的Reconcile入队呢?
A:理论上Kubernetes控制器是在监测到资源的创建/更新/删除事件后,会自动去触发reconcile函数。我觉得我们做Kubernetes二次开发首先要遵循Kubernetes的编程规范。

以上内容根据2019年12月26日晚微信群分享内容整理。 分享人阿布,云原生技术爱好者。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册