原生Kubernetes监控功能详解-Part1

Kubernetes是一个开源的容器编排框架，它为咱们提供了一种简单的部署、扩展和监控的方法。本文将讨论Kubernetes的内置监控功能，如Kubernetes dashboard、cAdvisor等。为便于更好地理解，文内还提供了演示。

---

介 绍

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有一份很是直观的入门指南可供参考：https://rancher.com/quick-start/

使用Rancher部署GKE集群

按照操做指南，使用Rancher设置和配置Kubernetes集群：

https://rancher.com/docs/ranc...

注意：请确保已启用Kubernetes Dashboard，咱们这里使用的Kubernetes 版本为v.1.10。

图1 使用Rancher建立Kubernetes集群

Kubernetes Dashboard

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

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

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

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

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

如今，要查看dashboard，请经过浏览器访问如下地址：

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

而后，咱们须要在登陆页面输入相应的凭据：

图2 Dashboard登陆

下面咱们未来了解如何使用服务账户机制，建立具备管理员权限的用户。咱们将使用两个YAML文件。

一个YAML文件用于建立服务账户：

另外一个YAML文件将为咱们的用户建立ClusterRoleBinding：

应用两个YAML文件，来建立其定义的对象：

建立用户并设置了正确的权限后，咱们须要找到令牌才能登陆：

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

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

Kubernetes Dashboard包含几个主要视图：

• 管理视图：列出了node、命名空间和持久卷以及其余详细信息。咱们能够得到node的集成页面（CPU和内存使用状况）以及每一个node的单独详细信息页面，显示其指标、规范、状态、分配的资源和pod。
• 工做负载视图：显示了在选定的命名空间中运行的全部应用程序。总结了关于工做负载的重要信息，例如StatefulSet或部署中准备好的pod数量或pod的当前内存使用状况。
• 服务发现和负载均衡视图：显示了向外部公开服务的Kubernetes资源，并在集群内启用服务发现。
• 配置和存储视图：显示了应用程序使用的持久卷声明资源。配置视图显示了用于在集群中运行的应用程序实时配置的全部Kubernetes资源。

在没有任何工做负载运行的状况下，dashboard页面将为空，由于此时在Kubernetes上不会部署任何内容。若是要浏览 dashboard提供的全部视图，最佳选择是部署使用不一样工做负载类型的应用程序（StatefulSet、部署、副本集等）。这篇如何在Kubernetes上部署Redis的文章就是一个很好的示例，它展现了部署一个Redis集群（具备卷声明和configMaps的有状态集）和一个测试应用程序（一个Kubernetes部署）时，dashboard会如何显示相关信息。

配置完工做负载后，咱们能够关闭一个node，而后检查不一样的选项卡，以查看一些更新：

图3 Stateful Set的dashboard页面

图4 Pod的dashboard页面

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名称替换为你在命令行中找到的标识符：

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

图5 初始cAdvisor UI

图6 cAdvisor UI概述和流程

为了确认kubelet正在监听端口4194，你能够登陆到node查看更多信息：

咱们能够确认，在咱们的Kubernetes版本中，kubelet进程经过该端口提供cAdvisor Web UI：

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

kubelet二进制文件使用Prometheus展现格式公开了全部runtime和cAdvisor指标：

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

图7 cAdvisor指标端点

在一大堆输出中，你能够重点查找和关注的指标有：

CPU:

• ocontainer_cpu_user_seconds_total：以秒为单位，“用户”累计消耗CPU的时间
• ocontainer_cpu_system_seconds_total：以秒为单位，“系统”累计消耗CPU的时间
• ocontainer_cpu_usage_seconds_total：以秒为单位，累计消耗CPU的时间（上述总和）

内存:

• ocontainer_memory_cache：页面缓存内存的字节数
• ocontainer_memory_swap：容器交换使用状况，以字节为单位
• ocontainer_memory_usage_bytes：当前内存使用状况，以字节为单位，包括全部内存
• ocontainer_memory_max_usage_bytes：以字节为单位，最大内存使用量

磁盘:

• ocontainer_fs_io_time_seconds_total：执行I/O所花费的时间，以秒为单位
• ocontainer_fs_io_time_weighted_seconds_total：累计加权I/O时间，以秒为单位
• ocontainer_fs_writes_bytes_total：写入的累计字节数
• ocontainer_fs_reads_bytes_total：读取的累计字节数

网络:

• ocontainer_network_receive_bytes_total：接收的累计字节数
• ocontainer_network_receive_errors_total：接收时遇到的累计错误数
• ocontainer_network_transmit_bytes_total：传输的累计字节数
• ocontainer_network_transmit_errors_total：传输时遇到的累计错误数

一些其余有用的指标：

• / healthz：用于肯定cAdvisor是否健康的端点
• / healthz / ping：检查与etcd的链接情况
• / spec：返回cAdvisor MachineInfo()的端点

例如，要查看cAdvisor MachineInfo()，咱们能够访问：

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

图8 cAdvisor规范端点

pod端点为node上运行的pod提供与kubectl get pods -o json相同的输出：

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

图9 cAdvisor pod端点

一样，也能够经过访问如下连接来获取日志：

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

结 语

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

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