共计 4780 个字符，预计需要花费 12 分钟才能阅读完成。
作者：Carlos Arilla
翻译：Bach（才云）
校对：bot（才云）、星空下的文仔（才云）
如果想要监控 Kubernetes，包含基础架构平台和正在运行的工作负载，传统的监控工具和流程可能还不够用。就目前而言，监控 Kubernetes 并不是件容易的事。
K8sMeetup
为什么监控 Kubernetes 很难？
Kubernetes 曾经席卷了整个容器生态系统，它充当着容器分布式部署的大脑，旨在应用跨主机集群散布的容器来治理面向服务的应用程序。Kubernetes 提供了用于应用程序部署、调度、更新、服务发现和扩大的机制，然而监控 Kubernetes 呢？
尽管 Kubernetes 能够极大地简化将应用程序在容器以及跨云的部署过程，但它会为日常工作、应用程序性能治理、服务可见性以及典型的“监控 -> 警报 -> 故障排除”工作流程减少了复杂性。
旧版监控工具从动态指标中收集指标，用于监控服务器和服务，这些工具过来工作良好，但当初无奈失常工作。上面就是这些工具当初无奈监控 Kubernetes 的起因：
Kubernetes 减少了基础架构的复杂性
为了简化应用程序部署，基础架构减少了新的复杂性层：动静配置的 IaaS、主动配置的配置管理工具以及编排平台（如 Kubernetes），它们都位于裸机或虚构基础架构与反对应用程序的服务之间，因而在管制立体上监控 Kubernetes 平安也是工作的一部分。
微服务架构
除了减少基础架构的复杂性之外，微服务还被设计了新的应用程序，其中互相通信的组件数量也会按数量级减少。每个服务散布在多个实例中，并且容器能够依据须要在根底构造中挪动。这就是监控 Kubernetes 编排状态对于理解 Kubernetes 执行工作至关重要的起因。咱们要验证服务的所有实例都已启动并运行。
原生云爆炸的规模要求
咱们须要监控零碎，这样能为高水平的服务指标收回警报，另外咱们也要保留粒度以依据须要查看各个组件。当采纳云原生架构时，它们带来了变动也带走了越来越多的小组件。这就影响了 Kubernetes 监控办法和工具。
随着指标数量的激增，传统的监控零碎已无奈跟上。 尽管过来咱们能晓得每个服务组件有多少个实例以及它们位于何处，但当初状况已不再如此。当初指标通常具备肯定的基数，Kubernetes 会有一些多维级别，例如集群、节点、命名空间、Service 等。许多标签的代表属性来自于微服务的逻辑、应用程序版本、API 端点、特定资源或操作等。
另外， 容器不会永远运行上来 。据一份容器应用状况报告显示，22% 的容器寿命不超过 10 秒，54% 的容器寿命不到 5 分钟。这会造成很大的变动，容器 ID、Pod 名称之类的标签始终在变动，这也是咱们在解决新标签时却再也看不到它们的起因。
当初，咱们如果将度量规范的名称、标签与理论值、工夫戳一起应用，在短时间内，就将领有成千上万个数据点，即便是在小型 Kubernetes 集群中，也将生成数十万个工夫序列，如果是中型基础架构，可能就是数百万个。这就是为什么 Kubernetes 监控工具须要筹备好扩大成千上万个指标。
容器可见性有余
容器的生命周期是短暂的，它一旦死亡，外部的所有货色都将隐没，咱们无奈应用 SSH 或查看日志。容器非常适合操作，咱们能够打包、隔离应用程序，在任何中央以统一的形式部署它们，然而同时，它们同样会成为难以排除故障的黑盒。监控工具能够通过零碎调用跟踪从而提供详尽的可见性，这样咱们能够查看容器内产生的每个过程、文件或网络连接，从而更快地对问题进行故障排除。
思考到这些因素，咱们能够更好地了解为什么监控 Kubernetes 与监控服务器、VM 甚至是云实例有很大不同。
K8sMeetup
Kubernetes 监控的用例
Kubernetes 集群具备多个组件和层，在每个组件和层中，咱们须要监控不同的故障点。以下是 Kubernetes 监控的一些典型用例：
监控 Kubernetes 集群和节点
通过监控集群，您能够全面理解整个平台的运行状况和容量。具体的用例如下：
- 集群资源应用状况： 集群基础架构充分利用了吗？还是产能过剩？
- 我的项目和团队摊派资源： 每个我的项目或团队的资源使用量是多少？
- 节点可用性和运行状况： 是否有足够的节点可用于复制咱们的应用程序？咱们会耗尽资源吗？
监控 Kubernetes deployment 和 Pod
查看诸如命名空间、deployment、正本集或 DaemonSet 之类的 Kubernetes constructs，咱们能够理解应用程序是否已正确部署。例如：
- Pod 失落（Missing）和失败 ：Pod 是否在咱们的应用程序中运行？多少 Pod 快死亡了？
- 正在运行的实例与所需的实例 ：每个 Service 理论筹备了多少个实例？咱们须要多少个？
- 申请和限度的 Pod 资源应用状况 ：是否设置了 CPU 和内存的申请和限度？它们的理论作用是什么？
监控 Kubernetes 利用
归根结底，利用的监控才是最重要的。上面是利用监控的一部分：
- 应用程序可用性 ：应用程序是否响应？
- 应用程序运行状况和性能 ：咱们有多少个申请？多少响应能力或延迟时间？咱们有没有出错？
K8sMeetup
Kubernetes 监控工具
与大多数平台一样，Kubernetes 具备一组根本工具，能够监控平台，包含基于物理基础架构之上的 Kubernetes 结构。因为 Kubernetes 具备可扩展性，它会增加其余组件以取得 Kubernetes 可见性。让咱们来看一下 Kubernetes 监控设置的局部：
- cadvisor 和 heapster
- Kubernetes metric server
- Kubernetes 仪表板 (Dashboard)
- Kubernetes kube-state-metrics
- Kubernetes liveness 和 readiness 探针
- 用于 Kubernetes 监控的 Prometheus
cAdvisor 和 heapster
cAdvisor 是一个开源容器资源应用收集器。 它专为容器而构建，反对本地 Docker 容器。cAdisor 会主动发现给定节点中的所有容器，并收集 CPU、内存、文件系统和网络应用状况统计信息，不过它仅会收集根本资源利用率。仅当容器具备 X%CPU 利用率时，cAdvisor 能力通知咱们应用程序的理论性能。cAdvisor 自身并不提供任何长期存储或剖析性能。
在 Kubernetes 上，节点的 kubelet 能够装置 cAdvisor 来监控 Pod 容器资源。
为了进一步解决这些数据，咱们须要一些货色来整合整个集群中的数据。最受欢迎的抉择是 Heapster。就像任何应用程序一样，Heapster 在集群中作为 Pod 运行。Heapster Pod 从 kubelet 获取有用数据，而 kubelet 自身的数据则是从 cAdvisor 失去，而后 Heapster 按窗格将信息分组，其中也包含相干标签。
在 Kubernetes 中应用 Heapster 和 cAdvisor 进行监控。材料起源：blog.kubernetes.io
Heapster 是一个收集者，而不是采集者 ，它只是让咱们收集整个集群中的 cAdvisor 数据。咱们须要将这些数据推送到可配置的后端进行存储和可视化。咱们能够增加可视化层（例如 Grafana）查看数据。
尽管 cAdvisor 依然是通过 kubelet 的默认 Pod 监控组件，但 Heapster 已被弃用，当初 Kubernetes 通过 metric-server 应用指标。
Kubernetes metric server
从 Kubernetes v1.8 开始，来自 Kubernetes 和 cAdvisor 的资源应用状况指标能够通过 Kubernetes metric server API 取得，这与公开 Kubernetes API 的形式雷同。
不过此服务也不容许咱们随工夫存储值，并且不足可视化或剖析性能。Kubernetes metric server 可用于 Kubernetes 的高级编排，例如 Horizontal Pod Autoscaler 主动伸缩。
Kubernetes 仪表板（Dashboard）
Kubernetes 仪表板提供了一种简略的形式，让咱们通过 Kubernetes 命名空间和工作量查看环境。它提供了一种统一的形式来可视化根本数据，包含根本的 CPU、内存数据。另外，咱们还能够从仪表板进行治理并采取措施，不过这就波及到了多租户集群上的平安问题，须要设置适当的 RBAC 特权。
Kubernetes kube-state-metrics
还有一个组件是 kube-state-metrics，这是一项附加服务，它与 Kubernetes metrics-server 一起运行，可轮询 Kubernetes API 并将 Kubernetes 结构的特色转换为指标。kube-state-metrics 能够解决以下问题：
- 当初打算了多少个正本？目前有多少可用？
- 有多少个 Pod 正在运行、已进行、已终止？
- 此 Pod 已重启多少次？
咱们当初对在 Kubernetes 环境中构建正当的监控有了肯定理解，尽管依然没有具体的应用程序监控（例如：我的数据库服务的响应工夫是多少？），但至多能够看到根底主机、Kubernetes 节点以及 Kubernetes 状态的一些监控。
Kubernetes liveness 和 readiness 探针
Kubernetes 探针施展了定期监控 Pod 的运行状况和可用性的重要作用。它能够让咱们通过针对端点的申请和运行命令来任意定义“活动性”。以下是基于运行 cat 命令的 liveness 探针的简略示例：
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
image: gcr.io/google_containers/busybox
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
#source https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/用于 Kubernetes 监控的 Prometheus
Prometheus 是一个是开源的工夫序列数据库 ，它和 Kubernetes 一样是 CNCF 我的项目。Prometheus 监控是围绕 Prometheus 服务器的整个监控堆栈，该服务器会收集并存储度量，另外还有用于仪表板的 Grafana。
Prometheus 入门非常容易，只有简略设置 Prometheus、Grafana 和很少的元素即可。Prometheus 是监控 Kubernetes 的一种不错办法，咱们能够对本人的 Kubernetes 施行 DIY Prometheus 监控。
只管一开始应用 Prometheus 监控 Kubernetes 真的很简略，然而当前 DevOps 团队会很快意识到 Prometheus 也有一些应用阻碍，例如规模、RBAC 以及一些团队合规性问题。
K8sMeetup
总结
Kubernetes 监控的事实标准是由许多开源工具构建的，例如 cAdvisor、Kubernetes metric server、kube-state-metrics 和 Prometheus。总而言之，咱们要思考以适宜的形式来监控咱们的 Kubernetes。
原文地址：https://mp.weixin.qq.com/s/NimzBHGHCxjTamWyoOyC1A
