一 摘要
在研究 Prometheus 时，了解到它的本地存储存在的一些缺陷，以及 ClickHouse 的适用场景和优势。而业内也确实存在 Prometheus 存储方案采用 ClickHouse 的情况，所以对这点做了一个简单的调研。k8s 基于监控的自动扩容，目前了解到的方案主要是基于 Prometheus，所以深入了解 k8s 架构和 Prometheus 的相关技术与方案是目前在进行中的技术储备。
二 ClickHouse 安装
2.1 安装客户端和服务端
docker pull yandex/clickhouse-client
docker pull yandex/clickhouse-server
2.2 启动容器服务，加载镜像
docker run -d --name ck-server -p 34424:34424 -p 9000:9000 -p 9009:9009 -p 8123:8123 --volume=$HOME/Documents/ck2_database:/var/lib/clickhouse yandex/clickhouse-server
部分参数意义：
volume：冒号两侧的路径建立映射，当容器服务读取冒号后面的虚拟机内路径时，会去读冒号前面的本机路径。加这个参数的作用是自定义配置，这个参数可以比较简单的修改部分配置。
-p:暴露容器中的端口到本机端口中。本机端口：容器端口。
2.3 启动后，查看 docker 容器
代码语言：javascript复制shell flamingskys$ docker ps -a|grep clickhouse300033f6bfc6 yandex/clickhouse-server "/entrypoint.sh" 7 hours ago Up 7 hours 0.0.0.0:8123->8123/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:9009->9009/tcp, 0.0.0.0:34424->34424/tcp ck-server
2.4 进入容器
使用命令：docker exec -it ck-server /bin/bash，
输出如下：
代码语言：javascript复制shell flamingskys$ docker exec -it ck-server /bin/bashroot@300033f6bfc6:/# root@300033f6bfc6:/# clickhouse-client ClickHouse client version 21.3.5.42 (official build).Connecting to localhost:9000 as user default.Connected to ClickHouse server version 21.3.5 revision 54447.2.5 查看所有 database
代码语言：javascript复制300033f6bfc6 :) show databases;
SHOW DATABASES
Query id: 045a3ff5-7309-44d5-9a64-02f163d9e4d4
┌─name────┐│ default ││ system │└─────────┘
2 rows in set. Elapsed: 0.034 sec.三 Prometheus 与 ClickHouse
3.1 Prometheus 架构
Prometheus 的架构如下图所示：
3.2 存储分析
从上面架构图中的 Prometheus Server，可以看到 Prometheus 有自己原生的 tsdb 用于存储各监控数据，属于 server 的本地存储。本地存储的优势就是运维简单，缺点就是无法海量的 metrics 持久化和数据存在丢失的风险。在Prometheus实战--存储篇这篇文章中作者提到，“我们在实际使用过程中，出现过几次 wal 文件损坏，无法再写入的问题。”
Prometheus 2.0 以后压缩数据能力得到了很大的提升。为了解决单节点存储的限制，Prometheus 没有自己实现集群存储，而是提供了远程读写的接口，让用户自己选择合适的时序数据库来实现 Prometheus 的扩展性。
Prometheus 通过下面两种方式来实现与其他的远端存储系统对接：
1）Prometheus 按照标准的格式将 metrics 写到远端存储
2）prometheus 按照标准格式从远端的 url 来读取 metrics
3.3 prometheus 的远程存储到 clickhouse
可参考：prometheus的远程存储到clickhouse这篇文章。暂时没有找到直接在 docker 内快速配置的方法，后续尝试成功后会再做更新。
四 K8S 架构
4.1 K8S 集群构成
根据官方文档的描述，k8s 集群由：1）控制平面组件（Control Plane Components）；和 2）Node 组件构成（有些文章也会描述为由 master 节点和 node 节点构成，基本上是一个含义）。
官方的 Kubernetes 集群的架构图如下所示：
4.2 控制平面组件（Control Plane Components）
控制平面组件（理解为 master 节点）对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。
控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。
包含主要组件如下：
4.2.1 kube-apiserver
apiserver 公开了 Kubernetes API。API 服务器是 Kubernetes 控制面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。kube-apiserver 设计上考虑了水平伸缩，也就是可通过部署多个实例进行伸缩。你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
4.2.2 etcd
etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
Kubernetes 集群的 etcd 数据库通常需要有个备份计划。
4.2.3 kube-scheduler
负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
4.2.4 kube-controller-manager
在主节点上运行 控制器 的组件。从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
这些控制器包括:
- 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
- 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
- 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
- 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
4.2.5 cloud-controller-manager
云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。
cloud-controller-manager 仅运行特定于云平台的控制回路。如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要云控制器管理器。
与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。
下面的控制器都包含对云平台驱动的依赖：
- 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
- 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
- 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器
4.3 Node 组件
节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。
4.3.1 kubelet
一个在集群中每个节点（node）上运行的代理。它保证容器（containers）都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
4.3.2 kube-proxy
kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。
4.3.3 容器运行时（Container Runtime）
容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境: Docker、 containerd、CRI-O 以及任何实现 Kubernetes CRI (容器运行环境接口)。
4.4 插件
插件使用 Kubernetes 资源（DaemonSet、 Deployment等）实现集群功能。因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。
常用插件包括：
4.4.1 DNS
尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该 有 集群 DNS， 因为很多示例都需要 DNS 服务。
集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
4.4.2 Web 界面（仪表盘）
Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
4.4.3 容器资源监控
容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
4.4.4 集群层面日志
集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
参考文献
Prometheus实战--存储篇
Kubernetes 组件
