今晚20:30，Kubernetes Master Class在线培训第五期《Kubernetes中的日志、监控与告警》即将开播，点击http://live.vhall.com/317569561 即可免费预约注册！
介 绍
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所需的必要组件：
从逻辑角度看，一个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/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/
注意：请确保已启用Kubernetes Dashboard，我们这里使用的Kubernetes 版本为v.1.10。
Kubernetes Dashboard
Kubernetes dashboard是基于Web的Kubernetes用户界面，我们可以使用它来对应用程序进行故障排除并管理集群资源。
而Rancher，能帮助用户一键安装dashboard。dashboard的主要用途包括：
要访问dashboard，我们需要在我们的计算机和Kubernetes API服务器之间代理请求。输入以下代码即可使用kubectl启动代理服务器：
代理服务器将在后台启动，输出类似于下文的内容：
现在，要查看dashboard，请通过浏览器访问以下地址：
http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
然后，我们需要在登录页面输入相应的凭据：
下面我们将来了解如何使用服务帐户机制，创建具有管理员权限的用户。我们将使用两个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，然后检查不同的选项卡，以查看一些更新：
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/
为了确认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
在一大堆输出中，你可以重点查找和关注的指标有：
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/
pod端点为node上运行的pod提供与kubectl 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）有充分的了解。
在本文中，我们重点关注了专为用户提供监控和指标的工具。在本系列文章的下一篇中，我们将继续分享那些关注工作负载扩缩容和生命周期管理的监控工具，敬请期待。