监听Helm release资源

基于helm做部署管理工具时，可能想要管理用户已有环境，这时需要将已有环境中的release信息上报到业务系统中。当用户在环境中部署新的release时，也需要实时监听并上报回来。下面将讲解如何去监听release资源

helm release存储源码分析

查看helm install源码，在helm/pkg/action/install.go中的run方法会执行实际的release安装

在install.run()方法中首先通过install.createRelease()方法创建release，然后在解析组装完chart模版中资源文件后，通过storage.Storage的Create方法将release信息进行存储，实际使用的是driver.Driver的Create方法进行release信息的存储。driver.Driver有三种存储实现，在helm2中默认使用ConfigMaps；在helm3中默认使用Secrets；也可以使用内存存储即通过map存储



无论存储到K8s的ConfigMaps还是Secrets或者内存map中，其资源名称或者map的key的命名规则满足：sh.helm.release.v1.<release的名称>.<release的版本>

如何监听

监听K8s中的CRD资源一种方式是通过资源的Watch方法监听,类似如下方式

func (c *Client) WaitAndGetCompletedPodPhase(name string, timeout time.Duration) (v1.PodPhase, error) {client, _ := c.Factory.KubernetesClientSet()to := int64(timeout)watcher, err := client.CoreV1().Pods(c.namespace()).Watch(metav1.ListOptions{FieldSelector:  fmt.Sprintf("metadata.name=%s", name),TimeoutSeconds: &to,})for event := range watcher.ResultChan() {p, ok := event.Object.(*v1.Pod)if !ok {return v1.PodUnknown, fmt.Errorf("%s not a pod", name)}switch p.Status.Phase {case v1.PodFailed:return v1.PodFailed, nilcase v1.PodSucceeded:return v1.PodSucceeded, nil}}return v1.PodUnknown, err
}

• 所有K8s的资源都会存储在etcd中，当客户端通过APIServer操作资源时，会将资源存储在etcd中，而etcd在存储信息时会发送事件到APIServer。当APIServer接收到创建pod资源事件后，会将事件发给其他监听pod资源的监听器，这样我们也能监听到pod的变化做出响应的处理

另一中方式是使用operator-sdk，这种方式其实也是借助于K8s中CRD资源的Watch方法，但使用operator-sdk监听资源代码结构会更好，便于统一控制，而且当处理失败后还能重新接到事件继续处理，直到成功。具体使用方式可以参考官网

在这里我们要监听release信息可以通过监听ConfigMaps、Secrets资源，判断其名称是否是以sh.helm.release.v1.开头，如果是则认为是helm release发生变化，通过解析出的release名称和命名空间名称，可以使用helm go客户端获取到release的详细信息，将这些release信息处理后上报到业务系统，release的所有信息包括参数、其下各种资源详细都能获取并上报

但对于使用内存map存储的release资源无法监听处理，因为其是从当前执行的helm客户端中获取，两个helm客户端是不能共享其内存中的map缓存的