Kubernetes 监控实践（1）：K8s 的工作原理与监控实践

一、Kubernetes 介绍

Kubernetes（K8s）是一个开源平台，能够有效简化应用管理、应用部署和应用扩展环节的手动操作流程，让用户更加灵活地部署管理云端应用。

作为可扩展的容错平台，K8s 几乎能够部署在所有基础设施中，与 Google Cloud、MS Azure 及 AWS 等公有云、私有云、混合云、服务器集群、数据中心等完美兼容。Kubernetes 最大的亮点在于支持容器自动部署和自动复制。这也是大量云端微服务基础设施部署在 K8s 上的原因。

二、K8s 由来

K8s 最初是由 Google 工程师设计开发的，于 2014 年上线并开源，目前由来自微软、红帽、IBM 及 Docker 等软件巨头的社区贡献者维护升级。

Google 不仅开源了公司整个基础设施在容器中的运行方式，还积极开发 Linux 容器技术，支撑 Google 所有云服务。K8s 是基于云平台 15 年的生产工作负载运行经验设计出来的，用于处理成千上万个容器。Google 每周部署 20 多亿个容器。在 K8s 上线前，Google 主要通过内部开发平台 Borg 进行容器部署。Borg 是大型内部集群管理系统，运行了无数应用和集群任务，多年的开发经验奠定了 K8s 技术的基础。

三、K8s 工作原理

K8s 本质上是分部在不同机器上的容器化应用的协调系统，目的是帮助开发人员通过 K8s 的可预测性、可扩展性和高可用性管理容器化应用和服务的整个生命周期，通过更高水平的抽象，将多个机器统一成一个机器。这对于大型环境的运行来说至关重要。

K8s 不仅能够优化 Docker 的镜像运行能力和容器管理能力，还能兼容 rkt 和 CoreOS 等容器引擎。

1569550381586071835.jpeg

上方架构图展示了 K8s 工作原理。图中包含一组 Master 组件，其中包括很多 pod。Pod 针对特定应用的“逻辑主机”进行建模。每个 Pod 均包含一个或多个应用容器、存储资源、唯一的网络 IP 及容器运行细节。Pod 是容器的最小原子单元。理论上，Pod 中包含一个或多个高度耦合的应用。理想情况下，每个 Pod 中包含一个容器。

每个进程包含一个 API server、一个 scheduler 和多个 controller。

API server 负责暴露 K8s API、处理 REST 操作及后续更新。Scheduler 负责将未部署的 Pod 匹配到合适虚拟机或物理机上。如果没有合适的机器，则 Pod 将处于未分配状态，直至出现合适的节点。Master 运行集群级别的其他功能，通过嵌入式 controller 完成创建端点、发现节点、复制控制等操作。由于 controller 设计灵活且可扩展，Kube 管理员可自行创建 controller。Kube 通过 API server 监控 K8s 集群的共享状态，并对集群状态进行调整，确保当前状态与理想状态一致。

K8s 提供支持容器化应用统一自动化、控制和升级的各项功能，包括企业级容器部署、内置服务发现、自动扩展、持久化存储、高可用、集群互通和资源装箱等。

依赖这些功能，K8s 实现了对单体应用、批处理应用及高度分布式微服务应用等不同应用架构的支持。

四、K8s 监控实践中的挑战

2014 年上线以来，K8s 一直在变革容器技术，已经成为快速批量启动应用的关键工具。与此同时，挑战也随之而来，容器编排极其复杂。

K8s 虽然已经极大地简化了容器实现和管理过程中从调度、配置到状态自动维护等一系列任务的操作难度，但监控方面依然存在挑战：

• 相互通信的应用分布在不同的云服务平台上。K8s 本质上是一个通用平台，用户可在平台上自由部署应用。企业一般会采用多云端解决方案，不仅能够减少对单一云服务平台的依赖，还能缩短故障停机时间，避免数据丢失。但这种部署方式也给实时数据抓取和应用状态监控带来了挑战。

• 在动态基础设施上不断迁移应用。由于应用处于频繁迁移状态，因此很难做到所有平台和协议之间的完全可见，这就会隐藏系统的瓶颈问题。很多公司的基础设施上都运行着多个应用，因此这种问题是不可避免的。如果没有稳健的监控系统，用户便无法发现应用的潜在问题。

• 监控对象数量繁多且极为复杂：K8s 由很多组件构成，非常复杂，因此要监控 K8s，就必须监控下列所有对象：

• 集群容量和资源利用情况：（a）Node：确保 K8s 所有节点的状态，监控 CPU、内存和硬盘的使用情况；（b）Pod：确保所有已实现 Pod 状态正常；（c）Container：根据配置的消耗上限监控 CPU 和内存的消耗情况。 应用：根据请求率、吞吐量、错误率监控集群中应用的性能和可用性。

• 终端用户体验：监控移动应用和浏览器性能，优化加载时间和可用性，提高客户满意度。

• 配套基础设施：前文提到，K8s 的运行平台也非常重要。

• 操作细节：K8s 的所有核心组件（即 kubelet、Kube controller manager 和 Kube scheduler）都有很多标记。这些标记决定了集群的操作和运行方式，其初始默认值一般较小，适用于规模较小的集群。随着集群规模的扩大，用户需要及时对集群进行调整，并监控 K8s 的标签和注释等细节。

但监控工具从 K8s 抓取大量数据时会影响集群性能甚至导致集群故障，因此需要确定监控基线。需要诊断故障时，可适当调高基线值。

调高基线值的同时要部署更多 master 和 node，提高可用性。涉及大规模部署时，可单独部署专门存储 K8s 数据的集群，这样能够保证在创建监控事件、检索监控数据时，主要实例的性能不受影响。

五、从源头上监控 K8s

和很多容器编排平台一样，K8s 具备基本的服务器监控工具。用户可对这些工具进行适当调整，以便更好地监控 K8s 的运行情况。主要工具如下：

• K8s 仪表盘：插件工具，展示每个 K8s 集群上的资源利用情况，也是实现资源和环境管理与交互的主要工具。

• 容器探针：容器健康状态诊断工具。

• Kubelet：每个 Node 上都运行着 Kubelet，监控容器的运行情况。Kubelet 也是 Master 与各个 Node 通信的渠道。Kubelet 能够直接暴露 cAdvisor 中与容器使用相关的个性化指标数据。

• cAdvisor：开源的单节点 agent，负责监控容器资源使用情况与性能，采集机器上所有容器的内存、网络使用情况、文件系统和 CPU 等数据。

• cAdvisor 简单易用，但也存在不足：一是仅能监控基础资源利用情况，无法分析应用的实际性能；二是不具备长期存储和趋势分析能力。

• Kube-state-metrics：轮询 Kubernetes API，并将 Kubernetes 的结构化信息转换为 metrics。

• Metrics server：Metrics server 定时从 Kubelet 的 Summary API 采集指标数据，并以 metric-api 的形式暴露出去。

整体监控流程如下：

• cAdvisor 默认安装在所有集群节点上，采集容器和节点的指标数据。

• Kubelet 通过 kubelet API 将指标数据暴露出去。

• Metrics 判断所有可用节点，请求 kubelet API 上送容器和节点使用情况数据，然后通过 Kubernetes 聚合 API 将指标数据暴露出去。

上述基础性工具虽然不能提供详细的应用监控数据，但能够帮助用户了解底层主机和 K8s 节点的情况。

一般来说，K8s 集群管理员主要关注全局监控，而应用开发人员则主要关注应用层面的监控情况。但两者的共同诉求都是在控制投入成本的前提下尽可能全面地监控系统、采集数据。下周文章中，我们将介绍两个可行的监控方案：Prometheus 和 Sensu。两个方案都能全面提供系统级的监控数据，帮助开发人员跟踪 K8s 关键组件的性能、定位故障、接收预警。

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/304