原生Kubernetes监控功能详解-Part1

原生Kubernetes监控功能详解-Part1

介 绍

Kubernetes是一个开源的容器编排框架，它为我们提供了一种简单的部署、扩展和监控的方法。在本文中，我们将讨论Kubernetes的内置监控功能。为了便于读者更好地理解，本文包含了一些演示。

Kubernetes架构概述

在基础架构级别，Kubernetes集群是一组各自发挥特定功能的物理机或虚拟机。充当主要角色的物理机或虚拟机负责整个操作，并协调在所有node上运行的容器管理。

Master组件管理pod的生命周期：

apiserver：为所有其他master组件公开API的主组件scheduler：负责依照pod规范中的信息来决定pod应该运行在哪个node上controller-manager：负责node管理（检测node是否出现故障）、pod复制和endpoint创建etcd：用于存储所有内部集群数据的键/值存储

Node组件是Kubernetes中由master管理的worker机器。每个node都包含运行pod所需的必要组件：

kubelet：处理master及其上运行的node之间的所有通信。它与容器运行时配合，负责部署和监控容器kube-proxy：负责维护node的网络规则，还负责处理pod、node和外部之间的通信。容器运行时：在node上运行容器。

从逻辑角度看，一个Kubernetes部署，是由在集群中各自发挥作用的各个组件组成：

Pod：Kubernetes内部的基本部署单位。一个pod由一个或多个容器组成，这些容器共享网络命名空间和IP地址。Service：充当负载均衡器。它们在池（一组pod）之前提供IP地址，且还提供控制访问IP地址的策略。ReplicaSet：由deployment控制，负责确保deployment所需数量的pod都正常运行。Namespace(命名空间)：为pod或service等不同类型的资源定义逻辑隔离。Metadata：根据容器的部署特征对容器进行标记。

监控Kubernetes

若我们想要预测问题并发现开发或部署中潜在的瓶颈，那么对应用程序进行监控是必不可少的。

为了帮助监控集群和构成部署的许多活动组件，Kubernetes提供了一些内置的监控功能：

Kubernetes dashboard：为集群上运行的资源提供一个概览。它还提供了一种非常基本的部署以及与这些资源进行交互的方法。cAdvisor：一种用于监控资源使用情况并分析容器性能的开源代理。Liveness和Readiness Probe：主动监控容器的健康情况。Horizontal Pod Autoscaler：基于通过分析不同指标所收集的信息，根据需要增加pod的数量。

在本文中，我们将重点介绍前两个内置工具。在本系列文章的下一篇中，我们将介绍其他的监控工具。

Kubernetes中有许多指标需要监控。正如我们会以两种不同的方式（基础架构和逻辑）描述架构那样，我们也可以将监控分为两个主要组件：监控集群本身以及集群上运行的工作负载监控。

集群监控

所有集群都应监控底层服务器组件，因为服务器层的问题往往都会出现在工作负载中。监控node资源时要注意的一些指标包括CPU、磁盘和网络带宽。了解这些指标可以让我们知道是否需要对集群进行扩容或缩容（如果企业使用的是云提供商，对运行成本很看重，那么这一点更尤其重要）。

工作负载监控

我们还需要考虑与部署及其pod相关的指标。其中重要的一点，是将deployment中当下运行的pod数量与期望的数量进行对比。此外，我们还应当注意健康检查、容器指标以及最终的应用指标。

前期准备

在以下部分中，我们将以demo的形式逐一介绍列出的内置监控功能，为此我们需要做的前期准备有：

谷歌云平台帐户：使用免费试用版的即可，若你使用的是其他的主流云平台，操作方法也是类似的。用于运行Rancher的主机：可以是个人PC / Mac或公有云中的VM。谷歌云SDK：应与运行Rancher的主机上的kubectl一起安装。通过使用你的凭据进行身份验证（gcloud init和gcloud auth login），确保gcloud可以访问你的谷歌云帐户。

启动Rancher实例

第一步，启动Rancher实例。Rancher有一份非常直观的入门指南可供参考：Dashboard，我们这里使用的Kubernetes 版本为v.1.10。

Kubernetes Dashboard

Kubernetes dashboard是基于Web的Kubernetes用户界面，我们可以使用它来对应用程序进行故障排除并管理集群资源。

而Rancher，能帮助用户一键安装dashboard。dashboard的主要用途包括：

对集群资源进行概述（包括整体情况和每个node的情况），显示所有命名空间，列出定义的所有存储类显示集群上运行的所有应用程序提供关于集群中Kubernetes资源状态以及可能出现的任何错误的信息

要访问dashboard，我们需要在我们的计算机和Kubernetes API服务器之间代理请求。输入以下代码即可使用kubectl启动代理服务器：

代理服务器将在后台启动，输出类似于下文的内容：

现在，要查看dashboard，请通过浏览器访问以下地址：

-n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

在Kubernetes dashboard凭据提示中选择“Token（令牌）”，然后在字段中输入你在上面检索的值以进行身份验证。

Kubernetes Dashboard包含几个主要视图：

配置完工作负载后，我们可以关闭一个node，然后检查不同的选项卡，以查看一些更新：

cAdvisor

cAdvisor是一个集成到kubelet二进制文件中的开源代理，主要用于监控资源使用情况并分析容器的性能。cAdvisor会收集关于在给定node上运行的所有容器的CPU、内存、文件和网络使用情况的统计信息（cAdvisor不在pod层运行）。除核心指标外，cAdvisor还会监控事件。用户可以使用诸如kubectl top之类的命令直接访问指标，也可以使用调度程序执行调度层的指标（例如使用autoscaling）。

需要注意的是，cAdvisor不会长期存储某些指标，因此如果需要使用该功能，则应寻找专用的监控工具。

从Kubernetes版本1.10起，cAdvisor的UI已经差不多被弃用了，Kubernetes 1.12版本之后cAdvisor的UI会被彻底删除。Rancher可以让你选择用于集群的Kubernetes版本。在为此演示设置基础架构时，我们将集群配置为使用版本1.10，因此我们仍然可以访问cAdvisor UI。

要访问cAdvisor UI，我们需要在我们的计算机和Kubernetes API服务器之间进行代理。输入以下命令启动代理服务器的本地实例：

接下来，找到node的名称：

你可以通过以下地址在浏览器中查看UI，将node名称替换为你在命令行中找到的标识符：

Web UI：

如果你运行的Kubernetes版本为1.12或更高，因为cAdvisorUI已被删除，因此kubelet不会再监听4194端口了。你可以使用上面的命令进行确认。不过，由于cAdvisor是kubelet二进制文件的一部分，因此相关指标仍然存在。

kubelet二进制文件使用Prometheus展示格式公开了所有runtime和cAdvisor指标：

healthz：用于确定cAdvisor是否健康的端点/ healthz / ping：检查与etcd的连接状况/ spec：返回cAdvisor MachineInfo()的端点

例如，要查看cAdvisor MachineInfo()，我们可以访问：

get pods -o json相同的输出：

http://localhost:8001/api/v1/nodes/gke-c-plnf4-default-pool-5eb56043-23p5:10255/proxy/pods/

同样，也可以通过访问以下链接来获取日志：

http://localhost:8001/logs/kube-apiserver.log

结 语

监控的重要性不言而喻，它让我们能充分了解到应用程序的状况。Kubernetes有很多内置工具可供用户们选择，让大家更好地对基础架构层（node）和逻辑层（pod）有充分的了解。

在本文中，我们重点关注了专为用户提供监控和指标的工具。在本系列文章的下一篇中，我们将继续分享那些关注工作负载扩缩容和生命周期管理的监控工具，敬请期待。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。