文档章节

原生Kubernetes监控功能详解-Part1

RancherLabs
 RancherLabs
发布于 05/08 21:47
字数 3332
阅读 1261
收藏 54

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

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

© 著作权归作者所有

RancherLabs
粉丝 53
博文 206
码字总数 437250
作品 0
深圳
程序员
私信 提问
加载中

评论(1)

RancherLabs
RancherLabs
有任何疑问或者想法,欢迎添加微信助手(rancher2),进官方技术群,和大家一起交流~
原生Kubernetes监控功能详解-Part2

由于我们停止了生成负载的命令,所以如果我们等待几分钟,HPA应该注意到负载减少并缩小副本的数量。没有高负载,就不需要创建额外的两个pod。

RancherLabs
05/13
0
0
Cloud Native 世界顶级开源项目

CNCF 是什么? CNCF 是一个开源软件基金会,致力于使云原生计算具有普遍性和可持续性。 云原生计算使用开源软件技术栈将应用程序部署为微服务,将每个部分打包到自己的容器中,并动态编排这些...

Docker
2018/04/22
0
0
超越Kubernetes:值得关注的5大云原生技术

Kubernetes是一个开源容器管理平台,它现在已经成为了云原生的中流砥柱。自从把它移交给Cloud Native Compute Foundation(云原生计算基金)后,该项目在业界上取得了史无前例的关注,目前没...

Docker
2018/09/12
0
0
三种主流的Kubernetes部署方式

摘要:当您转向云原生开发和部署时,让我们来看看Kubernetes所扮演的角色,以及如何从编排中获得更丰富的功能。容器提供了将应用程序及其依赖关系与操作系统分离的功能。通过一种有别于虚拟机...

Docker
2017/12/23
0
0
部署 Prometheus Operator - 每天5分钟玩转 Docker 容器技术(179)

本节在实践时使用的是 Prometheus Operator 版本 v0.14.0。由于项目开发迭代速度很快,部署方法可能会更新,必要时请参考官方文档。 下载最新源码 git clone https://github.com/coreos/prom...

cloudman6
2018/06/10
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Kubernetes云供应商架构的未来

首先,我想分享SIG的使命,因为我们用它来指导我们现在和将来的工作。从我们的章程中直接来看,SIG的使命是简化,开发和维护云供应商集成,作为Kubernetes集群的扩展或附加组件。这背后的动机...

Linux就该这么学
14分钟前
0
0
线程池没你想的那么简单

前言 原以为线程池还挺简单的(平时常用,也分析过原理),这次是想自己动手写一个线程池来更加深入的了解它;但在动手写的过程中落地到细节时发现并没想的那么容易。结合源码对比后确实不得...

crossoverJie
21分钟前
13
0
Scientific Linux开发停止 相关设备将迁移至CentOS上

在经历了将近14年的版本更迭之后,这个专注于科学领域的GNU/Linux发行版本不会发布下个重大版本更新--Scientific Linux 8了。 目前维护该发行版本的成员最终决定是时候休息了,今后将不再发布...

linuxCool
26分钟前
0
0
Redux

Redux概念 Redux = Reducer + Flux,数据层框架,将所有数据都存储到store中 Redux的工作流程 Antd的使用 安装npm install antd --save import 'antd/dist/antd.css'import { Input, Butto......

星闪海洋
今天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部