Kubernetes对象深入学习之四：对象属性编码实战

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：github.com/zq2599/blog...

本篇概览

本文是《Kubernetes对象深入学习》系列的第四篇，前面咱们读源码和文档，从理论上学习了kubernetes的对象相关的知识，是时候自己动手来实战操作了
本篇的主要内容就是新建一个golang工程，里面运行一个基于client-go的Controller，监听两种资源类型的变化事件
面对两种不同类型的资源对象，咱们开发一个通用的方法，使用该方法可以获取各种类型的对象的属性，以此来验证前文学习的知识点
整个项目的功能如下图所示，其实挺简单的：用kubectl对资源做修改（修改label），api-server会向所有监听者发送变更事件，object-tutorials是个go开发的应用程序，里面使用client-go库，监听kubernetes上的pod和service所有变更事件，在收到事件后，object-tutorials中会对变更对象做一些读对象属性相关的操作

在k8s部署service和deployment

为了实战需要，首先请在kubernetes环境将service和deployment部署好，这里给出我的部署脚本作为参考
所有要部署的内容我都集中在这个名为nginx-deployment-service.yaml脚本中了

yml 复制代码

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: client-go-tutorials
  name: nginx-deployment
  labels:
    app: nginx-app
    type: front-end
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app
      type: front-end
  template:
    metadata:
      labels:
        app: nginx-app
        type: front-end
        # 这是第一个业务自定义label，指定了mysql的语言类型是c语言
        language: c
        # 这是第二个业务自定义label，指定了这个pod属于哪一类服务，nginx属于web类
        business-service-type: web
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          resources:
            limits:
              cpu: "0.5"
              memory: 128Mi
            requests:
              cpu: "0.1"
              memory: 64Mi
---
apiVersion: v1
kind: Service
metadata:
  namespace: client-go-tutorials
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx-app
    type: front-end
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30011

先执行以下命令创建namespace

shell 复制代码

kubectl create namespace client-go-tutorials

再执行以下命令即可完成资源的创建

shell 复制代码

kubectl apply -f nginx-deployment-service.yaml

来查看一下资源情况，如下图，service和pod都创建好了，准备工作完成，可以开始编码了

源码下载

如果您不想编写代码，也可以从GitHub上直接下载，地址和链接信息如下表所示(github.com/zq2599/blog...%25EF%25BC%259A "https://github.com/zq2599/blog_demos)%EF%BC%9A")

名称	链接	备注
项目主页	github.com/zq2599/blog...	该项目在GitHub上的主页
git仓库地址(https)	github.com/zq2599/blog...	该项目源码的仓库地址，https协议
git仓库地址(ssh)	git@github.com:zq2599/blog_demos.git	该项目源码的仓库地址，ssh协议

这个git项目中有多个文件夹，本篇的源码在object-tutorials文件夹下，如下图黄框所示：

编码：准备工程

执行命令名为go mod init object-tutorials，新建module
确保您的goproxy是正常的
执行命令go get k8s.io/client-go@v0.22.8，下载client-go的指定版本
现在工程已经准备好了，接着就是具体的编码

编码：梳理

咱们按照开发顺序开始写代码，如果您看过欣宸的《client-go实战》系列，此刻对使用client-go开发简易版controller应该很熟悉了，这里在简单提一下controller的基本套路

在整个controller中，核心是队列，或者说队列是唯一的一条线，其他知识点都是珍珠，被队列穿起来
当队列创建成功后，咱们接下来要做的就是往队列中生产数据，然后取出数据来消费
还要多考虑一些，例如多个协程并行消费，以及消费过程中发生异常时的处理逻辑
然后就是本篇的核心了：无视资源类型的不同，可以用同一段代买来处理各种资源对象的属性

这些编码要实现的功能，如下图所示，队列为线，其他知识点为珍珠

编码：数据结构

新建controller.go文件，先定义数据结构

go 复制代码

// 自定义controller数据结构，嵌入了真实的控制器
type Controller struct {
	// 本地缓存，关注的对象都会同步到这里
	indexer cache.Indexer
	// 消息队列，用来触发对真实对象的处理事件
	queue workqueue.RateLimitingInterface
	// 实际运行运行的控制器
	informer cache.Controller
}

编码：创建队列，生产数据

首先要创建队列，然后对k8s的api-server建立list&watch（list取得全量数据，watch监听数据变化的通知），再让整个监听和响应的逻辑运行起来
上述功能由以下两个方法组成，CreateAndStartController负责创建实例，并且队列的生产逻辑也在此方法中，Run方法负责让队列的生产和消费运转起来

go 复制代码

// Run 开始常规的控制器模式（持续响应资源变化事件）
func (c *Controller) Run(threadiness int, stopCh chan struct{}) {
	defer runtime.HandleCrash()

	// Let the workers stop when we are done
	defer c.queue.ShutDown()
	klog.Info("Starting Pod controller")

	go c.informer.Run(stopCh)

	// Wait for all involved caches to be synced, before processing items from the queue is started
	// 刚开始启动，从api-server一次性全量同步所有数据
	if !cache.WaitForCacheSync(stopCh, c.informer.HasSynced) {
		runtime.HandleError(fmt.Errorf("timed out waiting for caches to sync"))
		return
	}

	// 支持多个线程并行从队列中取得数据进行处理
	for i := 0; i < threadiness; i++ {
		go wait.Until(c.runWorker, time.Second, stopCh)
	}

	<-stopCh
	klog.Info("Stopping Pod controller")
}

// CreateAndStartController 为了便于外部使用，这里将controller的创建和启动封装在一起
func CreateAndStartController(c cache.Getter, objType objectruntime.Object, resource string, namespace string, stopCh chan struct{}) {
	// ListWatcher用于获取数据并监听资源的事件
	podListWatcher := cache.NewListWatchFromClient(c, resource, NAMESPACE, fields.Everything())

	// 限速队列，里面存的是有事件发生的对象的身份信息，而非对象本身
	queue := workqueue.NewRateLimitingQueue(workqueue.DefaultControllerRateLimiter())

	// 创建本地缓存并对指定类型的资源开始监听
	// 注意，如果业务上有必要，其实可以将新增、修改、删除等事件放入不同队列，然后分别做针对性处理，
	// 但是，controller对应的模式，主要是让status与spec达成一致，也就是说增删改等事件，对应的都是查到实际情况，令其与期望情况保持一致，
	// 因此，多数情况下增删改用一个队列即可，里面放入变化的对象的身份，至于处理方式只有一种：查到实际情况，令其与期望情况保持一致
	indexer, informer := cache.NewIndexerInformer(podListWatcher, objType, 0, cache.ResourceEventHandlerFuncs{
		AddFunc: func(obj interface{}) {
			key, err := cache.MetaNamespaceKeyFunc(obj)
			if err == nil {
				// 再次注意：这里放入队列的并非对象，而是对象的身份，作用是仅仅告知消费方，该对象有变化，
				// 至于有什么变化，需要消费方自行判断，然后再做针对性处理
				queue.Add(key)
			}
		},
		UpdateFunc: func(old interface{}, new interface{}) {
			key, err := cache.MetaNamespaceKeyFunc(new)
			if err == nil {
				queue.Add(key)
			}
		},
		DeleteFunc: func(obj interface{}) {
			key, err := cache.DeletionHandlingMetaNamespaceKeyFunc(obj)
			if err == nil {
				queue.Add(key)
			}
		},
	}, cache.Indexers{})

	controller := &Controller{
		informer: informer,
		indexer:  indexer,
		queue:    queue,
	}

	go controller.Run(1, stopCh)
}

编码：消费队列的数据

这里先写好业务代码，就是知道某个对象发生变化时，具体的业务逻辑是什么，如下所示

go 复制代码

// syncToStdout 这是业务逻辑代码，被调用意味着key对应的对象有变化(新增或者修改)
func (c *Controller) syncToStdout(key string) error {
	// 从本地缓存中取出完整的对象
	obj, exists, err := c.indexer.GetByKey(key)
	if err != nil {
		klog.Errorf("Fetching object with key %s from store failed with %v", key, err)
		return err
	}

	// 如果不存在，就表示这是个删除事件
	if !exists {
		fmt.Printf("Pod %s does not exist anymore\n", key)
	} else {
		// 这里无视了obj具体是什么类型的对象(deployment、pod这些都有可能)，
		// 用meta.Accessor转换出metav1.Object对象后就能获取该对象的所有meta信息
		objMeta, err := meta.Accessor(obj)

		if err != nil {
			klog.Errorf("get meta accessor error, [%s], failed with %v", key, err)
			return err
		}

		// 取得资源的所有属性
		labels := objMeta.GetLabels()

		if labels == nil {
			klog.Infof("name [%s], namespace [%s], label is empty", objMeta.GetName(), objMeta.GetNamespace())
			return nil
		}

		// 遍历每个属性，打印出来
		for key, value := range labels {
			klog.Infof("name [%s], namespace [%s], key [%s], value [%s]",
				objMeta.GetName(),
				objMeta.GetNamespace(),
				key,
				value)
		}
	}
	return nil
}

接下里要写的是从消费队列中的数据，即：取数据，然后调用上面的syncToStdout，这里由两个方法组成，runWorker负责建立一个无限循环，不断调用processNextItem方法

go 复制代码

// processNextItem 不间断从队列中取得数据并处理
func (c *Controller) processNextItem() bool {
	// 注意，队列里面不是对象，而是key，这是个阻塞队列，会一直等待
	key, quit := c.queue.Get()
	if quit {
		return false
	}
	// Tell the queue that we are done with processing this key. This unblocks the key for other workers
	// This allows safe parallel processing because two pods with the same key are never processed in
	// parallel.
	defer c.queue.Done(key)

	// 注意，这里的syncToStdout应该是业务代码，处理对象变化的事件
	err := c.syncToStdout(key.(string))

	// 如果前面的业务逻辑遇到了错误，就在此处理
	c.handleErr(err, key)

	// 外面的调用逻辑是：返回true就继续调用processNextItem方法
	return true
}

// runWorker 这是个无限循环，不断地从队列取出数据处理
func (c *Controller) runWorker() {
	for c.processNextItem() {
	}
}

编码：异常处理

还有个handleErr方法，在业务消费队列数据失败时的处理逻辑，可见这里的做法是将key重新放入队列，让业务逻辑再消费一次，这就是失败重试逻辑，这样的重复次数被限定在5次以内，超过了就不再放入队列中了

go 复制代码

// handleErr 如果前面的业务逻辑执行出现错误，就在此集中处理错误，本例中主要是重试次数的控制
func (c *Controller) handleErr(err error, key interface{}) {
	if err == nil {
		// Forget about the #AddRateLimited history of the key on every successful synchronization.
		// This ensures that future processing of updates for this key is not delayed because of
		// an outdated error history.
		c.queue.Forget(key)
		return
	}

	// 如果重试次数未超过5次，就继续重试
	if c.queue.NumRequeues(key) < 5 {
		klog.Infof("Error syncing pod %v: %v", key, err)

		// Re-enqueue the key rate limited. Based on the rate limiter on the
		// queue and the re-enqueue history, the key will be processed later again.
		c.queue.AddRateLimited(key)
		return
	}

	// 代码走到这里，意味着有错误并且重试超过了5次，应该立即丢弃
	c.queue.Forget(key)
	// 这种连续五次重试还未成功的错误，交给全局处理逻辑
	runtime.HandleError(err)
	klog.Infof("Dropping pod %q out of the queue: %v", key, err)
}

编码，主程序

最后是main.go文件中的main方法，作用是加载kubernetes的配置文件，以及决定要监听哪些资源的变化，这里通过调用两次CreateAndStartController方法，对pod和service的变化建立了监听

go 复制代码

package main

import (
	"flag"
	"path/filepath"

	v1 "k8s.io/api/core/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/clientcmd"
	"k8s.io/client-go/util/homedir"
	"k8s.io/klog/v2"
)

const (
	NAMESPACE = "client-go-tutorials"
)

func main() {
	var kubeconfig *string
	var master string

	// 试图取到当前账号的家目录
	if home := homedir.HomeDir(); home != "" {
		// 如果能取到，就把家目录下的.kube/config作为默认配置文件
		kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional) absolute path to the kubeconfig file")
		master = ""
	} else {
		// 如果取不到，就没有默认配置文件，必须通过kubeconfig参数来指定
		flag.StringVar(kubeconfig, "kubeconfig", "", "absolute path to the kubeconfig file")
		flag.StringVar(&master, "master", "", "master url")
		flag.Parse()
	}

	config, err := clientcmd.BuildConfigFromFlags(master, *kubeconfig)
	if err != nil {
		klog.Fatal(err)
	}

	clientset, err := kubernetes.NewForConfig(config)
	if err != nil {
		klog.Fatal(err)
	}

	stop := make(chan struct{})
	defer close(stop)

	CreateAndStartController(clientset.CoreV1().RESTClient(), &v1.Pod{}, "pods", NAMESPACE, stop)
	CreateAndStartController(clientset.CoreV1().RESTClient(), &v1.Service{}, "services", NAMESPACE, stop)

	select {}
}

运行程序，验证效果

现在将程序运行起来，用go build构建应用，或者直接用IDE运行，启动后可以看到输入如下，可见程序符合预期，将所有service和pod的label都在日志中打印出来了，值得注意的是service现在还没有任何label，这在日志中也有提示

shell 复制代码

Starting: /root/software/gopath/bin/dlv dap --listen=127.0.0.1:33405 --log-dest=3 from /root/github/blog_demos/tutorials/object-tutorials
DAP server listening at: 127.0.0.1:33405
Type 'dlv help' for list of commands.
I0723 08:20:14.695662 2256666 controller.go:131] Starting Pod controller
I0723 08:20:14.696133 2256666 controller.go:131] Starting Pod controller
I0723 08:20:14.796419 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wpnt7], namespace [client-go-tutorials], key [business-service-type], value [web]
I0723 08:20:14.796620 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wpnt7], namespace [client-go-tutorials], key [language], value [c]
I0723 08:20:14.796669 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wpnt7], namespace [client-go-tutorials], key [pod-template-hash], value [78f6b696d9]
I0723 08:20:14.796704 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wpnt7], namespace [client-go-tutorials], key [type], value [front-end]
I0723 08:20:14.796737 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wpnt7], namespace [client-go-tutorials], key [app], value [nginx-app]
I0723 08:20:14.796792 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wp4qf], namespace [client-go-tutorials], key [app], value [nginx-app]
I0723 08:20:14.796831 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wp4qf], namespace [client-go-tutorials], key [business-service-type], value [web]
I0723 08:20:14.796865 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wp4qf], namespace [client-go-tutorials], key [language], value [c]
I0723 08:20:14.796901 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wp4qf], namespace [client-go-tutorials], key [pod-template-hash], value [78f6b696d9]
I0723 08:20:14.796960 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-wp4qf], namespace [client-go-tutorials], key [type], value [front-end]
I0723 08:20:14.797007 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-j98xj], namespace [client-go-tutorials], key [pod-template-hash], value [78f6b696d9]
I0723 08:20:14.797047 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-j98xj], namespace [client-go-tutorials], key [type], value [front-end]
I0723 08:20:14.797100 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-j98xj], namespace [client-go-tutorials], key [app], value [nginx-app]
I0723 08:20:14.797139 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-j98xj], namespace [client-go-tutorials], key [business-service-type], value [web]
I0723 08:20:14.797174 2256666 controller.go:88] name [nginx-deployment-78f6b696d9-j98xj], namespace [client-go-tutorials], key [language], value [c]
I0723 08:20:14.797346 2256666 controller.go:82] name [nginx-service], namespace [client-go-tutorials], label is empty

现在修改资源对象试试，首先修改service，执行以下命令进入vi编辑模式

shell 复制代码

kubectl edit service nginx-service -n client-go-tutorial

下图红框中是新增的内容
保存退出，在程序的控制台可见以下日志输出，证明service的变更事件都被会咱们的object-tutorials程序响应，也能顺利取出service对象的属性并打印到日志中
接着修改一个pod的label，新增内容如下图黄色箭头所示
保存后，程序这边立即有日志输出，会打印该pod的所有label
至此，编码和验证都完成了，结果符合预期，meta.Accessor方法很好用，拿到属性对象后所有资源的属性信息都能轻易获取

欢迎关注掘金：程序员欣宸

学习路上，你不孤单，欣宸原创一路相伴...