介绍
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/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/
注意:请确保已启用 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 文件,来创建其定义的对象:
创建用户并设置了正确的权限后,我们需要找到令牌才能登录:
在 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)有充分的了解。
在本文中,我们重点关注了专为用户提供监控和指标的工具。在本系列文章的下一篇中,我们将继续分享那些关注工作负载扩缩容和生命周期管理的监控工具,敬请期待。
评论