在使用Kubernetes进行监视时需要注意的事项
这篇文章是AP Communications网站上的2018年12月23日的文章。
首先
在我们公司最近的内部培训中,我们在学习Kubernetes,期间我对于如何监控Kubernetes的问题产生了兴趣。在查询了一些资料后,我发现有很多与Prometheus、Datadog等应用程序相关的名称和用法,但基础的问题,例如监控的对象是什么,与以往的监控方式有何不同,似乎没有太多的解答。
因此,我决定研究一下在监控容器和Kubernetes时需要考虑的方法和注意事项,并将其整理为这篇文章。文章的内容仅仅是在Datadog官方页面的翻译上加入了一些额外的信息,但我希望读者们通过阅读本文能够了解在监控Kubernetes时应注意的要点。
如果有任何不同的解释或观点,请务必告诉我,我将不胜感激。
Kubernetes与系统监控
要稳定地运行使用Kubernetes构建的系统,除了部署在集群上的应用程序和容器,还必须监视Kubernetes本身。
在监视时需要考虑的方面除了需要监视容器的方面外,还需要监视Kubernetes,这将增加额外的考虑。在本页面中介绍了容器监视的要点,大致如下:
-
- ホストやメトリクスの数が爆発的に増加し、またそれらの変化も急速に起こる。これによりシステムの複雑さが増し、運用の負荷も増加する。
- これまでのホスト中心の監視では複雑なシステムで何が起こっているかを明らかにするのが困難になるため、監視対象をレイヤーごとに分けるのでなく、すべてのレイヤーを一括に監視することでシステムを包括的に監視することができる。またその際はタグ付けをすることでより効率的に監視できる。
Kubernetes通过基本对象如Pod和控制器如ReplicaSet来促进系统的抽象化,也有助于系统的全面监控。
传统系统监控和现代系统监控的区别
在监控Kubernetes时,与以前基于本地服务器或虚拟机构建的系统相比,有几个重要的区别。文章中列举了4个主要的区别。
标签和标签是必需的。
即使在容器出现之前的监控系统中,为了有效地进行监控,我们也会对指标和监控对象进行标记和标签化。通过添加这样的标识,可以对监控对象和指标进行分组,从而更容易监视基础设施的总体性能趋势和发现问题。
在引入了容器和Kubernetes的系统中,标签和标签的含义会发生很大的变化,成为区分容器和Pod的”唯一手段”。Kubernetes的优势在于根据集群的资源等来部署容器,并将其部署到适当的位置,但有时很难确定已部署的容器的位置。尤其是用户通过自定义标签可以从各个方面对基础设施进行容器监控。
ラベルの例
* フロントエンド/バックエンド
* アプリケーションごと
* 環境ごと(開発環境、本番環境など)
* チームごと
* バージョンごと
通过用户自定义的标签,可以对跨越不同层级的事件和指标进行细致监控。
作为标记过程的关键点,提到了定义逻辑合理且易于理解的模式,并创建简洁的标签。这里所说的逻辑是与物理相对的,指的是基础设施的物理部分(如CPU和内存)相对于逻辑部分(例如命名空间和复制控制器)。此外,简洁的标签意味着避免使用复杂的名称,以免造成难以理解。
监视对象的组件数量增加了。
正如在介绍中提到的,引入容器后还存在监控问题。主机和指标可能会急剧增加,从而导致监控目标相比传统系统大幅增加。
需要追踪不断运行的应用程序.
正如我之前所写的,Kubernetes具有自动调度容器的能力,这是它的优点之一。然而,用户的操作范围有限,追踪正在运行的应用程序变得困难。
使用服务发现工具作为解决方法,可以监控容器和Pod的配置更改,并通过自动优化收集到的指标来持续监视,即使基础架构扩展、出现异常或主机移动。可以说,Datadog和Prometheus是代表这种类型工具。
将集群优化为各种环境的群集,从本地到多云。
从Kubernetes 1.3开始,可以创建并部署应用程序的集群跨越多个环境。这使得可以选择最适合的环境来部署应用程序,并避免单个提供商造成的单点故障。
然而,在监视方面,尽管从多个基础设施环境中收集指标变得更加简便,但也指出可能会出现一些问题。因此,在多云环境或混合云与本地环境并存的基础设施配置中需要谨慎。
在介绍多云环境下Kubernetes最佳实践的这篇文章中,提到了由于应用可能在不同的环境中运行,所以需要一种方法来隔离噪音并聚焦于应用实例。因此,度量、状态和事件需要与应用相关联。
在此之前,我们已经总结了传统系统监控和基于容器和Kubernetes构建的系统监控之间的区别。接下来的章节将详细介绍应该收集哪些指标。
重要的监控指标
在本章中,首先对Heapster进行了介绍,但由于从Kubernetes 1.13开始,Heapster被视为已淘汰,所以在这里不再详述。在这里,我们将分成几个类别进行解释。
Pod 部署
为了判断Kubernetes是否正常运行,首先要查看的是Pod deployment。在开始Deployment时,Kubernetes首先确定需要运行的Pod数量,并部署必要数量的Pod以运行应用程序。此时,新的Pod将启动并被计算为当前运行的Pod。但是当前的Pod不一定立即可用(available)状态。
当用户部署Pod时,有时候会希望将部分Pod保持在等待状态。在文章中以Jenkins为例,说明了Jenkins的slave位于Pod中,希望在启动之前将Pod保持在不可用的状态。
通过使用PodSpec等,用户可以控制Pod的数量和启动时机,可以启动所需数量的Pod(desired pod)。因此,用户应该监视可用状态的Pod和desired Pod的数量始终相等。
此外,文章还提到,如果确切地了解Pod的状态,最好使用readiness check作为更好的方法。
运行中的Pod
监控当前Pod并与其相配合。实时监控运行中的Pod数量并监控整个基础设施的运行情况。为了理解Pod数量与资源利用之间的关系,应将运行中的Pod和资源利用之间的指标进行关联。
资源使用量
通过资源监视,可以确认集群和应用程序的健康状况。在这里,我们介绍了与资源相关的各种指标(如CPU、内存、磁盘I/O、网络等)的监视。
例如,我们推荐使用kube-state-metrics来监控节点的CPU和内存容量。kube-state-metrics会监听Kubernetes API并生成与对象状态相关的指标(如部署、节点、Pod等)。目前可以用于20种对象,并且可以监视每个对象的数量和状态等指标。
同样关于资源监控的注意事项,指出应该监控节点上每个容器的最小资源需求总量,而不是实际资源使用率。其原因是说明了节点的上限和容器的请求之间的关系。如果某节点上存在的容器请求总量不超过节点的上限,那么容器自然会正常运行。但是,即使容器正在使用节点上可用的资源的100%,Kubernetes也可以为节点部署另一个Pod。Kubernetes简单地减少现有Pod的可用资源量,以便可以部署新的Pod。只要满足所有容器的最低资源需求,这个过程将持续下去。因此,与仅监视CPU和内存使用量相比,确保节点的请求总量没有超过该节点的限制是更重要的事情。
容器的健康检查
在Kubernetes中,可以使用标准的指标来检查应用程序的健康状况。健康检查有两种类型,分别是活跃探针(liveness probe)和就绪探针(readiness probe)。
活跃探针用于检查应用程序是否处于可用状态,以及是否发生死锁等情况。如果活跃探针失败,kubelet将终止相应的容器并重新启动。
就绪探针用于检查是否能够接收流量。如果就绪探针失败,终端节点控制器将除去Pod的IP地址,并阻止流量进入相应的容器。
用于以容器的原生指标进行监控
在这一章中,我们讨论了关于Kubernetes指标的主要内容,但在这一章中,我们解释了监视容器指标的必要性。原因是,尽管Kubernetes和容器在监视项目上是一样的,但其值可能不同。在向用户传递指标时,Kubernetes不使用cAdvisor而是使用heapster等工具。而heapster与cAdvisor在收集Kubernetes指标的频率上有所不同,这可能导致与实际值不一致。因此,Kubernetes指标值和容器指标值之间可能会有差异。
应用程序特定的指标
为了准确监控由Kubernetes创建的系统,建议将Kubernetes和容器等资源指标与应用程序行为相关联。虽然要监控的指标可能因应用程序而异,但吞吐量、延迟和错误相关的指标通常应包含在应共监控的指标中。这里提供了MySQL和Nginx的示例,并附上相关文章的链接,请点击查看。
将事件与相应的活动关联
通过将Kubernetes的事件与应用程序的行为相关联,可以快速定位故障和低性能的问题所在。
正确地发出警报
Pod要在Node上移动,因此警报也必须跟随其移动。因此,Pod提到了必须附加一个标志(例如用户自定义标签、服务名称、复制控制器或副本集的名称等)作为Pod移动时的一个稳定点。
总结
我認為在這篇文章中提到了各種不同的觀點,但可以總結出兩個共同點:
-
- Kubernetesシステムを監視する際はラベル付けが必須である。またデフォルトで用意されたラベルだけでなく利用者が独自のラベルをつけることで監視をしやすくすることができる。
- 個々のリソース等のメトリクスだけでなく、それらとアプリケーションやKubernetesのオブジェクトの挙動とを紐付けて監視することができる。それにより障害や低パフォーマンスの要因に早く気づくことができる。
由于文章中关于网络和警报等部分的解释不够详细,因此我打算在今后重点研究这些方面。