写点什么

原生 Kubernetes 监控功能详解 -Part1

  • 2020-05-14
  • 本文字数:4687 字

    阅读完需:约 15 分钟

原生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 有一份非常直观的入门指南可供参考: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 文件,来创建其定义的对象:



创建用户并设置了正确的权限后,我们需要找到令牌才能登录:


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)有充分的了解。


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


2020-05-14 22:261014

评论

发布
暂无评论
发现更多内容

不要用+""代替强转

BerryMew

HBase 底层原理详解(深度好文,建议收藏)

五分钟学大数据

大数据 HBase

【计算机内功修炼】五:从小白到高手,你需要理解同步与异步

码农的荒岛求生

异步 同步 回调函数

读《快手要上市了》,一起了解快手

李忠良

开源 技术 28天写作

28天瞎写的第二百一七天:你们 CentOS 服务器还有图形界面啊?

树上

28天写作

关于焦虑的思考

.

28天写作

玩一玩Linux常见命令第二篇

程序员的时光

程序员 28天写作

【TF2系列笔记】Day01:在VSCode中创建开发环境

IT蜗壳-Tango

七日更 TF2

Spring 源码学习 14:initApplicationEventMulticaster、onRefresh 和 registerListeners

程序员小航

spring 源码 源码阅读

读书笔记:《中产阶级如何保护自己的财富》

lidaobing

28天写作 中产阶级如何保护财富

醒醒!Python已经支持中文变量名啦!

Python猫

Python

城市生态的机器人革命

脑极体

Swift 算法-栈

Byte_Panda

算法

欢迎来到机器人的打工时代「幻想短篇 6/28」

道伟

28天写作

大流量场景下如何云淡风轻地进行线上发布?

阿里巴巴中间件

项目管理系列(2)-如何写好一份报告

Ian哥

项目管理 28天写作

RocketMQ中的事务消息

废材姑娘

RocketMQ

28 天带你玩转 Kubernetes-- 第六天(玩转 Docker命令)

Java全栈封神

Docker k8s 28天写作 docker命令

《适用于初学者的Python》

计算机与AI

数据结构与算法-时间和空间复杂度

Byte_Panda

算法

测试一年多,上线就崩溃!微服务到底应该怎么测试?

阿里巴巴中间件

中间件

简单三招,每个管理者都可以成为有温度的共情高手

一笑

沟通与管理 28天写作

油车和电车比到底哪个整体能源利用效率高?(28天写作 Day6/28)

mtfelix

自动驾驶 28天写作 电动汽车

生产环境全链路压测建设历程 28:FAQ 之 混沌工程

数列科技杨德华

28天写作

创业失败启示录|校园微生活(故事篇3)

阿萌

28天写作 创业失败启示录 青城

pub哥的2020文章清单

JavaPub

Java javapub

Docker真的被Kubernetes放弃了吗?

蔡超

Docker Kubernetes 云原生

精选算法面试-数组(二分查找)

李孟聊AI

面试 算法 数组 28天写作

LeetCode题解:105. 从前序与中序遍历序列构造二叉树,递归+数组切割,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

[4/28]保障产品高质量交付业务价值

L3C老司机

为什么我们需要自动化回归?

阿里巴巴中间件

中间件

原生Kubernetes监控功能详解-Part1_文化 & 方法_Rancher_InfoQ精选文章