容器监控-Prometheus：2. Prometheus部署前奏-Helm&&Operator
文章目录
部署方案选择
-
手动部署
把每个组件配置好，必须了解Prometheus每个组件，如何协同工作，高可用，如何做配置复杂度高
-
Helm
类似于centos 的yum，是kubernetes的文件包管理工具。Helm 部署Prometheus要比手动部署简单，它会把Prometheus和相关组件都部署起来，跑在k8s里面。但是部署完有些工作，高可用、额外组件部署需要自己处理。
-
Prometheus Operator
更深入层面做了Prometheus部署管理工作。利用了kubernetes的Operator机制，本质是利用kubernetes GRD加控制器。
-
Helm+Prometheus Operator
非常优雅。使用这个两个东西必须要付出一些代价就先把这个两个东西搞清楚。
Helm
Helm简介
-
类似Ubuntu的apt-get 、centos 的yum,helm是kubernetes的文件包管理工具,一条命令就可以完成，软件包的安装卸载。
-
kubernetes的文件包管理
提供了kubernetes 软件包的部署、删除、升级、回滚各种强大的功能。
-
一个包一Chart(一个目录)
kubernetes的软件包是一个Chart本质上就是一个目录，打成一个tar.gz存储起来。发布者可以打包应用管理应用的依赖关系，让别人使用起来更加简单。
使用Helm就不用关心编写kubernetes的配置，可以通过helm一条命令下载，在kubernetes把你要的应用安装部署好。
Helm Architecture
-
首先有
Helm客户端，跟yum一样二进制文件， -
然后
chart Files是一个目录，里面存储了按照一定的目录结构和约定的名字，当然包括了kubernetes资源相关的yaml文件。 -
helm 存放在哪里对于本地来说这些东西存放在一个本地仓库，同样远端有一个
storage负责存储各种各样Helm软件包，本质也是一个web服务器，可以去下载软件包,并且提供了chart包的文件清单。共客户端查询，跟yu m源类似。helm也可以同时使用管理多个不同repod。
4. Tiller 是helm命令的服务端。用来接收helm的请求，并且对应的chart去生成kubernetes的配置文件，然后提交给你kubernetes去创建应用。也就是helm跟kubernetes之间的桥梁。
Operator
Operator实现原理
引：
其实Operator不太好理解，字面上的意思是操作者，
前面我们学会很多资源类型比如pod、deolyment、service、daemonSet都是kubernetes预先定义好的，
kubernetes有自己的控制器管理他们。控制器的本质是代码循环，不断去看部署预期的状态与真实状态的差别，并努力让他保持一致。
控制器解释
比如一个deolyment定义的实例数是3，现在只有1，控制器会再启动两个实例，达到一致
Kubernetes1.7以后就支持自定义资源类型(CRD),Operator就是利用Kubernetes 的CRD
- 自定义资源类型(CRD)+自定义控制器 去实现操作者的能力。
比如：
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
name: "example-etcd-cluster"
namespace: kubesphere-system
spec:
size: 3
version: "3.2.13"
自定义一个类型是EtcdCluster,然后再开发一个控制器，控制器的循环代码里面就可以拿到EtcdCluster的配置，通过调用kubernetes接口去实现一个预期的EtcdCluster集群创建的一个过程。
Pod 的创建和Pod的配置都是在自定义控制器里面完成的。所以Operator也能胜任类似于StatefulSet的工作，并且它是针对特定的服务。会比StatefulSet更加优雅的完成工作。不研究那么深，如何开发自定义控制器，知道原理就OK。
