作者|段超
起源|尔达 Erda 公众号

背景

咱们是一家做商业软件的公司，从一开始咱们就把软件交付流程做的十分规范且简略，所有的软件都是基于咱们的企业数字化平台 Erda（现已开源）来交付，底层基于 Kubernetes，为企业提供 DevOps、微服务治理、多云治理以及快数据管理等云厂商无绑定的 IT 服务。
​

随着咱们服务的客户数量越来越多，现在咱们治理着相当规模数量的 Kubernetes 集群，集群的稳定性决定了服务质量以及对外口碑，很长一段时间内咱们在这件事件上都显得很被动，常常会呈现 Erda 反对同学或者客户将问题反馈到咱们说：有业务呈现了问题，须要咱们帮助查问一下是不是平台导致的，而后咱们下来一顿操作最初解决问题，回答客户。看似业余且厉害，急用户之所急，实则无章无奈，一地鸡毛。

通常咱们依赖监控零碎来提前发现问题，然而监控数据作为一个正向链路，很难笼罩到所有场景，常常会有因为集群配置的不一致性或者一些更底层资源的异样，导致即便监控数据齐全失常，然而整个零碎仍然会有一些性能不可用。对此，咱们做了一套巡检零碎，针对零碎中一些薄弱点以及一致性做诊断，美中不足的是，这套零碎的扩展性不是很好，对集群跟巡检项的治理也绝对粗犷了一点。
​

最初，咱们决定做一个更加云原生的诊断工具，应用 operator 来实现集群跟诊断项的治理，形象出集群跟诊断项的资源概念，来解决大规模 Kubernetes 集群的诊断问题，通过在核心下发诊断项到其余集群，并对立收集其余集群的诊断后果，来实现任何时刻都能够从核心获取到其余所有集群的运行状态，做到对大规模 Kubernetes 集群的无效治理以及诊断。
​

Kubeprober

我的项目介绍

我的项目地址：https://github.com/erda-project/kubeprober
​

KubeProber 是一个针对大规模 Kubernetes 集群设计的诊断工具，用于在 Kubernetes 集群中执行诊断项以证实集群的各项性能是否失常，KubeProber 有如下特点:
​

• 反对大规模集群：反对多集群治理，反对在治理端配置集群跟诊断项的关系以及对立查看所有集群的诊断结。
• 云原生：外围逻辑采纳 operator 来实现，提供残缺的 Kubernetes API 兼容性。
• 可扩大：反对用户自定义巡检项。

​

其外围架构如下：
​

​

区别于监控零碎，kubeProber 从巡检的角度来证实集群的各项性能是否失常，监控作为正向链路，无奈笼罩零碎中的所有场景，零碎中各个环境的监控数据都失常，也不能保证系统是 100% 能够用的，因而须要一个工具从反向来证实零碎的可用性、从根本上做到先于用户发现集群中不可用的点，比方：
​

• 集中的所有节点是否均能够被调度，有没有非凡的污点存在等。
• pod 是否能够失常的创立、销毁，验证从 Kubernetes，Kubelet 到 Docker 的整条链路。
• 创立一个 Service，并测试连通性，验证 kube-proxy 的链路是否失常。
• 解析一个外部或者内部的域名，验证 CoreDNS 是否失常工作。
• 拜访一个 ingress 域名，验证集群中的 ingress 组件是否失常工作。
• 创立并删除一个 namespace，验证相干的 webhook 是否失常工作。
• 对 Etcd 执行 put/get/delete 等操作，用于验证 Etcd 是否失常运行。
• 通过 mysql-client 的操作来验证 MySQL 是否失常运行。
• 模仿用户对业务零碎进行登录、操作，验证业务的主流程是否经常。
• 查看各个环境的证书是否过期。
• 云资源的到期查看。
• 更多 …

​

组件介绍

Kubeprober 整体采纳 Operator 来实现外围逻辑，集群之间的治理应用 remotedialer 来维持被纳管集群跟治理集群之间的心跳链接，被纳管集群通过 RBAC 赋予 probe-agent 最小所需权限，并且通过心跳链接实时上报被纳管集群元信息，以及拜访 apiserver 的 token，实现在治理集群能够对被治理集群的相干资源进行操作的性能。
​

probe-master

运行在治理集群上的 operator，这个 operator 保护两个 CRD，一个是 Cluster，用于治理被纳管的集群；另一个是 Probe，用于治理内置的以及用户本人编写的诊断项，probe-master 通过 watch 这两个 CRD，将最新的诊断配置推送到被纳管的集群，同时 probe-master 提供接口用于查看被纳管集群的诊断后果。
​

probe-agent

运行在被纳管集群上的 operator，这个 operator 保护两个 CRD，一个是跟 probe-master 完全一致的 Probe，probe-agent 依照 probe 的定义去执行该集群的诊断项，另一个是 ProbeStatus，用于记录每个 Probe 的诊断后果，用户能够在被纳管的集群中通过 kubectl get probestatus 来查看本集群的诊断后果。
​

什么是 Probe

kubeprobe 中运行的诊断打算咱们称之为 Probe，一个 Probe 为一个诊断项的汇合，咱们倡议将对立场景下的诊断项作为一个 Probe 来运行，probe-agent 组件会 watch probe 资源，执行 Probe 中定义的诊断项，并且将后果写在 ProbeStatus 的资源中。

咱们冀望有一个输入能够清晰的看到以后集群的运行状态，因而，咱们倡议所有的 Probe 都尽可能属于利用、中间件、Kubernets、根底设置这四大场景，这样咱们能够在展现状态的时候，自上而下分明地查看到底是零碎中哪个层面引起的问题。
​

目前的 Probe 还比拟少，咱们还在持续欠缺，也心愿跟大家一起共建。
​

自定义 Probe
​

比照其余诊断工具

目前社区曾经有 Kuberhealthy 以及 kubeeye 来做 Kubernetes 集群诊断这件事件。
​

kuberheathy 提供一套比拟清晰的框架能够让你轻松编写本人的诊断项，将诊断项 CRD 化，能够轻松地应用 Kubernetes 的形式来对单个 Kubernetes 进行体检。
​

kubeeye 同样是针对单个集群，次要通过调用 Kubernetes 的 event api 以及 Node-Problem-Detector 来检测集群管制立体以及各种节点问题，同时也反对自定义诊断项。
​

kubeprober 做的也是诊断 Kubernetes 集群这件事件，提供框架来编写本人的诊断项。除此之外，kubeprober 次要解决了大规模 Kubernetes 集群的诊断问题，通过中心化的思路，将集群跟诊断项形象成 CRD，能够实现在核心 Kubernetes 集群治理其余 Kubernetes 诊断项配置、诊断后果收集，将来也会解决大规模 Kubernetes 集群的运维问题。
​

如何应用

kubeprober 次要解决大规模 Kubernetes 集群的诊断问题，通常咱们抉择其中一个集群作为 master 集群，部署 probe-master，其余集群作为被纳管集群，部署 probe-agent。
​

装置 probe-master

probe-master 应用了 webhook，webhook 的运行须要校验证书，须要先部署一下 cert-manager 的服务:
​

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml

​

而后装置 probe-master：
​

APP=probe-master make deploy

装置 probe-agent

在逻辑上，一个 cluster 资源对应一个 probe-agent，在部署 probe-agent 之前，须要先创立一个 cluster 资源，probe-master 会给每一个 cluster 生成一个 secreykey，用于跟 probe-master 交互的惟一凭证。
​

kubectl apply -f config/samples/kubeprobe_v1_cluster.yaml
kubectl get cluster -o wide  #能够获取到集群的 secretkey

​

部署 probe-agent 前，须要先批改 probe-agent 的 configmap：
​

vim config/manager-probe-agent/manager.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: probeagent
  namespace: system
data:
  probe-conf.yaml: |
    probe_master_addr: http://kubeprober-probe-master.kubeprober.svc.cluster.local:8088
    cluster_name: moon
    secret_key: 2f5079a5-425c-4fb7-8518-562e1685c9b4

​

最初装置 probe-agent：
​

APP=probe-agent make deploy

​

装置好 probeagent 后咱们就能够在 master 集群中看到 cluster 信息。

配置 probe

有了 cluster，咱们还须要在 master 集群中创立 probe 资源，比方：
​

kubectl apply -f config/samples/kubeprobe_v1_cron_probe.yaml

​

应用 kubectl get probe 来查看 probe 列表，应用 kubectl label 来将一个 probe 跟 cluster 关联起来，则对用的 probe-agent 会在本集群内执行相干的诊断项。
​

kubectl label cluster moon probe/probe-link-test1=true
kubectl label cluster moon probe/probe-cron-sample=true

​

最初，咱们能够在被诊断的集群中应用 kubectl get probestatus 来查看诊断本集群的诊断后果。
​

欢送参加开源

​

欢送参加开源

以后 kubeprobe 曾经公布了第一个版本 0.0.1，还有许多性能不太欠缺，probe-master 的治理能力还能够进一步的被放大开掘，probe 的编写也须要更加的简略易用。咱们心愿跟社区一起共建，独特打造一个大规模 Kubernetes 集群的治理神器。欢送大家关注、奉献代码和 Star！
​

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官网：https://www.erda.cloud/
• Contributing to KubeProber：https://github.com/erda-project/kubeprober/blob/master/CONTRIBUTING.md