Kubernetes集群的监控报警策略最佳实践

版权声明：本文为博主原创文章，未经博主赞成不得转载。 https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/79652064

本文为Kubernetes监控系列的第二篇文章。系列文件夹例如如下：

1. Kubernetes监控开源工具基本介绍以及怎样使用Sysdig进行监控

2. Kubernetes集群的监控报警策略最佳实践（本篇）

3. Kubernetes中的服务发现与故障排除（敬请期待）

4. Docker与Kubernetes在WayBlazer的使用案例（敬请期待）

本文将介绍关于怎样在Kubernetes集群中配置基础设施层的警报。本文是关于在生产中使用Kubernetes系列的一部分。 第一部分介绍了Kubernetes和监控工具的基础知识；这部分涵盖了Kubernetes报警的最佳实践，第三部分将介绍Kubernetes服务发现与故障排除，最后一部分是监控Kubernetes的实际使用案例。
监控是每个优质基础设施的基础，是达到可靠性层次的基础。

监控有助于下降对突发事件的响应时间，实现对系统问题的检測、故障排除和调试。

在基础设施高度动态的云时代。监控也是容量规划的基础。

有效的警报是监控策略的基石。当你转向容器和Kubernetes编排环境，你的警报策略也需要演进。正是因为下面几个核心缘由。当中不少咱们在"怎样监视Kubernetes"中进行了讲述：

• 可见性：容器是一个黑盒。

  传统工具仅仅能针对公共监控端点进行检查。假设想深刻监控相关服务，则需要採取不同的方法。

  
  

• 新的基础架构层：现在服务和主机之间有一个新的层：容器和容器编排服务。

  这些是你需要监控的新内部服务，你的监控系统需要了解这些服务。

  
  

• 动态重调度：容器没有像以前那样的服务节点。因此传统的监控不能有效地工做。没有获取服务度量标准的静态端点，没有执行服务实例的静态数量（设想一个金丝雀公布或本身主动伸缩设置）。在某节点中一个进程被kill是正常的。因为它有很是大的机会被又一次调度到基础设施的其它节点。

  
  

• 元数据和标签：随着服务跨多个容器，为所有这些服务加入系统级别的监控以及服务特定的度量标准，再加上Kubernetes带来的所有新服务。怎样让所有这些信息对咱们有所帮助？有时你但愿看到分布在不一样节点容器中的服务的网络请求度量，有时你但愿看到特定节点中所有容器的一样度量。而不关心它们属于哪一个服务。这就需要一个多维度量系统，需要从不一样的角度来看待这些指标。假设经过Kubernetes中存在的不一样标签本身主动标记度量标准，并且监控系统可以了解Kubernetes元数据，那么仅仅需要在每种状况下依照需要聚合和切割度量标准就可以实现多维度度量。

考虑到这些问题。让咱们建立一组对Kubernetes环境相当重要的报警策略。

咱们的Kubernetes报警策略教程将涵盖：

• 应用程序层度量标准的报警

• Kubernetes上执行的服务的报警

• Kubernetes基础设施的报警

• 在主机/节点层上的报警

最后咱们还将经过检測系统调用问题来了解怎样经过报警加速故障排除。

应用程序层度量标准的报警

工做指标（working metrics）可以确认应用程序是否按预期执行。这些度量标准一般来自用户或消费者对服务的指望操做。或者是由应用程序经过statsd或JMX在内部生成。假设监控系统自己提供网络数据，就可以使用它来建立基于响应时间的报警策略。

下面演示样例是一个公共REST API端点监控警报，监控prod命令空间中的名为javaapp的deployment，在10分钟内假设延迟超过1秒则报警。

所有这些报警高度依赖于应用程序、工做负载模式等等，但真正的问题是怎样在所有服务中一致性地获取数据。

在理想环境中，除了核心监控工具以外。无需再购买综合监控服务就能够得到这一套关键指标。
这个类别中经常出现的一些指标和报警是：

• 服务对应时间

• 服务可用性

• SLA合规性

• 每秒请求的成功/失败数

Kubernetes上执行的服务的报警

对于服务级别，和使用Kubernetes以前对于服务集群需要作的事情应该没什么不一样。试想下。当在MySQL/MariaDB或者MongoDB等数据库服务中查看副本状态与延迟时。需要考虑些什么？
没错。假设想知道服务的全局执行和执行状况，就需要利用监视工具功能依据容器元数据将度量标准进行聚合和分段。
如 第一篇文章所述。Kubernetes将容器标记为一个deployment或者经过一个service进行暴露，在定义报警时就需要考虑这些因素。好比针对生产环境的报警（可能经过命名空间进行定义）。
下面是Cassandra集群的演示样例：

假设咱们在Kubernetes、AWS EC2或OpenStack中执行Cassandra。则衡量指标cassandra.compactions.pending存在每个实例上，但是现在咱们要查看在prod命名空间内的cassandra复制控制器中聚合的指标。这两个标签都来自Kubernetes，但咱们也可以更改范围，包含来自AWS或其它云提供商的标签，好比可用区域。

这个类别中经常出现的一些指标和警报是：

• HTTP请求数

• 数据库链接数、副本数

• 线程数、文件描写叙述符数、链接数

• 中间件特定指标：Python uwsgi worker数量。JVM堆大小等

另外，假设正在使用外部托管服务。则很是可能需要从这些提供程序导入度量标准。因为它们可能还有需要作出反应的事件。

 

Kubernetes基础设施的报警

在容器编排层面的监控和报警有两个层面。一方面，咱们需要监控Kubernetes所处理的服务是否符合所定义的要求。还有一方面。咱们需要确保Kubernetes的所有组件都正常执行。
由Kubernetes处理的服务
1.1 是否有足够的Pod/Container给每个应用程序执行？
Kubernetes可以经过Deployments、Replica Sets和Replication Controllers来处理具备多个Pod的应用程序。它们之间差异比較小。可以使用它们来维护执行一样应用程序的多个实例。执行实例的数量可以动态地进行伸缩，甚至可以经过本身主动缩放来实现本身主动化。
执行容器数量可能发生变化的缘由有多种：因为节点失败或资源不足将容器又一次调度到不一样主机或者进行新版本号的滚动部署等。假设在延长的时间段内执行的副本数或实例的数量低于咱们所需的副本数，则表示某些组件工做不正常（缺乏足够的节点或资源、Kubernetes或Docker Engine故障、Docker镜像损坏等等）。
在Kubernetes部署服务中。跨多个服务进行例如如下报警策略对照是很是有必要的：

timeAvg(kubernetes.replicaSet.replicas.running) < timeAvg(kubernetes.replicaSet.replicas.desired)

正如以前所说，在又一次调度与迁移过程执行中的实例副本数少于预期是可接受的。因此对每个容器需要关注配置项 .spec.minReadySeconds （表示容器从启动到可用状态的时间）。你可能也需要检查 .spec.strategy.rollingUpdate.maxUnavailable 配置项，它定义了在滚动部署期间有多少容器可以处于不可用状态。
下面是上述报警策略的一个演示样例，在 wordpress 命名空间中集群 kubernetes-dev 的一个deployment wordpress-wordpress。

1.2 是否有给定应用程序的不论什么Pod/Container？
与以前的警报类似。但具备更高的优先级（好比，这个应用程序是半夜获取页面的备选对象）。将提醒是否没有为给定应用程序执行容器。
下面演示样例，在一样的deployment中添加警报，但不一样的是1分钟内执行Pod <1时触发：

1.3 从新启动循环中是否有不论什么Pod/Container？
在部署新版本号时。假设没有足够的可用资源，或者仅仅是某些需求或依赖关系不存在，容器或Pod终于可能会在循环中持续又一次启动。这样的状况称为“CrashLoopBackOff”。发生这样的状况时，Pod永远不会进入就绪状态，从而被视为不可用，并且不会处于执行状态，所以，这样的场景已被报警覆盖。虽然如此。笔者仍但愿设置一个警报，以便在整个基础架构中捕捉到这样的行为。立刻了解详细问题。这不是那种中断睡眠的报警，但会有很多实用的信息。
这是在整个基础架构中应用的一个演示样例，在过去的2分钟内检測到4次以上的又一次启动：

监控Kubernetes系统服务
除了确保Kubernetes能正常完毕其工做以外。咱们还但愿监測Kubernetes的内部健康情况。这将取决于Kubernetes集群安装的不一样组件。因为这些可能会依据不一样部署选择而改变，但有一些基本组件是一样的。
2.1 etcd是否正常执行？
etcd是Kubernetes的分布式服务发现、通讯、命令通道。监控etcd可以像监控不论什么分布式键值数据库同样深刻，但会使事情变得简单。

咱们可以进一步去监控设置命令失败或者节点数，但是咱们将会把它留给将来的etcd监控文章来描写叙述。
2.2 集群中有足够的节点吗？
节点故障在Kubernetes中不是问题。调度程序将在其它可用节点中生成容器。

但是，假设咱们耗尽节点呢？或者已部署的应用程序的资源需求超过了现有节点？或者咱们达到配额限制？
在这样的状况下发出警报并不easy，因为这取决于你想要在待机状态下有多少个节点，或者你想要在现有节点上推送多少超额配置。可以使用监控度量值kube_node_status_ready和kube_node_spec_unschedulable进行节点状态警报。
假设要进行容量级别报警，则必须将每个已调度Pod请求的CPU和memory进行累加。而后检查是否会覆盖每个节点，使用监控度量值kube_node_status_capacity_cpu_cores和kube_node_status_capacity_memory_bytes。

在主机/节点层上的报警

主机层的警报与监视虚拟机或物理机差异不大。主要是关于主机是启动仍是关闭或不可訪问状态。以及资源可用性（CPU、内存、磁盘等）。
主要差异是现在警报的严重程度。

在此以前。系统服务宕机可能意味着你的应用程序中止执行并且要紧急处理事故（禁止有效的高可用性）。而对于Kubernetes来讲当服务发生异常，服务可以在主机之间移动。主机警报不该该不受重视。
让咱们看看咱们应该考虑的几个方面：

1. 主机宕机
假设主机停机或没法訪问，咱们但愿收到通知。

咱们将在整个基础架构中应用此单一警报。咱们打算给它一个5分钟的等待时间。因为咱们不想看到网络链接问题上的嘈杂警报。

你可能但愿将其下降到1或2分钟，详细取决于你但愿接收通知的速度。

2. 磁盘利用率
这是略微复杂一些的警报。咱们在整个基础架构的所有文件系统中应用此警报。咱们将范围设置为 everywhere，并针对每个 fs.mountDir 设置单独的评估/警报。
下面是超过80％使用率的通用警报。但你可能需要不一样的策略。如具备更高阈值（95％）或不一样阈值的更高优先级警报（详细取决于文件系统）。

假设要为不一样的服务或主机建立不一样的阈值。仅仅需更改要应用特定阈值的范围。
3. 一些其它资源
此类别中的常见资源是有关负载、CPU使用率、内存和交换空间使用状况的警报。假设在必定的时间内这些数据中的不论什么一个显著提高，可能就需要警报提醒您。

咱们需要在阈值、等待时间以及怎样断定噪声警报之间进行折中。

假设您想为这些资源设置指标。请參考下面指标：

• 负载：load.average.1m, load.average.5m 和 load.average.15m

• CPU：cpu.used.percent

• memory：memory.used.percent 或 memory.bytes.used

• swap：memory.swap.used.percent 或 memory.swap.bytes.used

一些人一样使用这个类别监控他们部分基础架构所在云服务提供商的资源。

Sysdig额外监控：监控系统调用

从警报触发并收到通知的那一刻起，真正的工做就開始为DevOps值班成员开展工做。有时执行手冊就像检查工做负载中的轻微异常同样简单。

这多是云提供商的一个事件，但但愿Kubernetes正在处理这个问题，并且仅仅需要花费一些时间来应对负载。
但是假设一些更棘手的问题出现在咱们面前。咱们可以看到咱们拥有的所有武器：提供者状态页面、日志（但愿来自中心位置）、不论什么形式的APM或分布式追踪（假设开发者安装了代码或者外部综合监測）。而后，咱们祈祷这一事件在这些地方留下了一些线索。以便咱们可以追溯到问题出现的多种来源缘由。
咱们怎么可以在警报被解除时本身主动dump所有系统调用？系统调用是所发生事情的真实来源，并将包含咱们可以得到的所有信息。经过系统调用有可能发现触发警报的根本问题所在。Sysdig Monitor赞成在警报触发时本身主动開始捕获所有系统调用。

好比，可以配置CrashLoopBackOff场景：

仅仅有当你安装代码后。Sysdig Monitor代理才干从系统调用拦截中计算出来对应的指标。

考虑HTTP响应时间或SQL响应时间。Sysdig Monitor代理程序在套接字上捕获read()和write()系统调用。解码应用程序协议并计算转发到咱们时间序列数据库中的指标。这样作的优势是可以在不触及开发者代码的状况下得到仪表盘数据和警报：

结论

咱们已经看到怎样使用容器编排平台来添加系统中移动部分的数量。拥有容器本地监控是创建可靠基础架构的关键要素。监控不能仅仅关注基础架构。而是需要从底层的主机到应用程序指标所在的顶端来了解整个技术栈。

可以利用Kubernetes和云服务提供商的元数据信息来汇总和细分监控指标和警报将成为多层次有效监控的必要条件。咱们已经看到怎样使用标签来更新咱们已有的警报或建立Kubernetes上所需的新警报。
接下来，让咱们看看在Kubernetes编排环境中的典型服务发现故障排除的挑战。


原文连接：https://sysdig.com/blog/alerting-kubernetes/

深刻浅出Kubernetes及企业AI平台落地实践培训

本次培训内容包含：容器原理、Docker架构、工做原理、网络方案、存储方案、Harbor、Kubernetes架构、组件、核心机制、插件、核心模块、监控、日志、二次开发、TensorFlow架构、工做原理、注意事项以及实践经验等，点击识别下方二维码加微信好友了解 详细培训内容。
4月20日正式上课，点击阅读原文连接就能够报名。