使用 Azure 服务和云原生工具监视 Kubernetes 群集

本文介绍如何使用 Azure Monitor 以及相关的 Azure 和云原生服务监视 Kubernetes 群集及其上运行的工作负载的运行状况和性能。 其中包括在 Azure Kubernetes 服务 (AKS) 或其他云（如 AWS 和 GCP）中运行的群集。 对于通常管理组成 Kubernetes 环境的唯一组件的不同角色，提供了不同的指导集。

Kubernetes 环境的层和角色

以下是典型 Kubernetes 环境的通用模型（从基础结构层到应用程序）的图示。 每层都有不同的监视要求，这些要求由不同的服务解决，通常由组织中的不同角色管理。

Kubernetes 环境的不同层和依赖此环境的应用程序的责任通常由多个角色承担。 根据组织的规模，这些角色可能由不同的人员甚至不同的团队执行。 下表描述了不同的角色，以下部分提供了每个角色通常会遇到的监视场景。

角色	说明
Developer	开发和维护群集上运行的应用程序。 负责特定于应用程序的流量，包括应用程序性能和故障。 根据 SLA 维护应用程序的可靠性。
平台工程师	负责 Kubernetes 群集。 预配和维护开发人员使用的平台。
网络工程师	负责工作负载与群集的任何入口/出口之间的流量。 分析网络流量并执行威胁分析。

选择监视工具

Azure 提供基于 Azure Monitor 的完整服务集，用于监视 Kubernetes 基础结构的不同层以及依赖此基础结构的应用程序的运行状况和性能。 这些服务相互配合，提供完整的监视解决方案，推荐用于 AKS 和其他云中运行的 Kubernetes 群集。 你可能已经对云原生计算基础认证的云原生技术进行了投资，在这种情况下，你可以选择将 Azure 工具集成到现有环境中。

选择部署哪些工具及其配置将取决于特定环境的需求。 例如，可以将 Azure 中托管的产品/服务用于 Prometheus 和 Grafana，也可以选择将这些工具的现有安装与 Azure 中的 Kubernetes 群集配合使用。 组织还可以使用容器见解的替代工具来收集和分析 Kubernetes 日志，例如 Splunk 或 Datadog。

网络工程师

网络工程师负责工作负载与群集的任何入口/出口之间的流量。 他们分析网络流量并执行威胁分析。

面向网络管理员的 Azure 服务

下表列出了网络工程师在监视支持 Kubernetes 群集的网络的运行状况和性能时通常使用的服务。

服务	说明
网络观察程序	Azure 中的一套工具，用于监视 Kubernetes 群集使用的虚拟网络并诊断检测到的问题。
流量分析	网络观察程序的功能，用于分析流日志以提供对流量流的见解。
网络见解	Azure Monitor 的功能，包括不同网络组件的性能和运行状况的直观表示形式，并提供对网络观察程序中的网络监视工具的访问权限。

网络见解默认处于启用状态，无需配置。 通常，每个 Azure 区域中还默认启用网络观察程序。

监视级别 1 - 网络

以下是监视网络的常见方案。

• 创建流日志以记录有关流经群集使用的网络安全组的 IP 流量的信息，然后使用流量分析对此数据进行分析并提供见解。 你很可能会使用与用于容器见解和控制平面日志的相同的 Log Analytics 工作区来进行流量分析。
• 使用流量分析，可以确定是否有流量流向或流出群集所使用的任何非预期端口，以及是否有流量流经不应公开的公共 IP。 使用此信息确定是否需要修改网络规则。
• 对于 AKS 群集，请使用适用于 AKS 的网络可观测性加载项（预览版）监视和观察群集中服务之间的访问（东-西流量）。

平台工程师

平台工程师（也称为群集管理员）负责 Kubernetes 群集本身。 他们预配和维护开发人员使用的平台。 他们需要了解群集及其组件的运行状况，并能够排查检测到的任何问题。 他们还需要了解运行群集的成本，并有可能将成本分配给不同的团队。

大型组织可能还有群队架构师，类似于平台工程师，但负责多个群集。 他们需要查看整个环境，并且必须大规模执行管理任务。 以下指导中提供了大规模建议。 有关为多群集和大规模方案创建舰队资源的详细信息，请参阅什么是 Azure Kubernetes 舰队管理器？。

面向平台工程师的 Azure 服务

下表列出了平台工程师使用的监视 Kubernetes 群集及其组件的运行状况和性能的 Azure 服务。

服务	说明
容器见解	用于 AKS 和已启用 Azure arc 的 Kubernetes 群集的 Azure 服务，此服务使用容器化版本的 Azure Monitor 代理从群集的每个节点收集 stdout/stderr 日志、性能指标和 Kubernetes 事件。 你可以在 Azure 门户中查看数据，也可以使用 Log Analytics 查询数据。 配置 Prometheus 体验，以将容器见解视图与 Prometheus 数据配合使用。
适用于 Prometheus 的 Azure Monitor 托管服务	Prometheus 是由 Cloud Native Compute Foundation 推出的一款云原生指标解决方案，是从 Kubernetes 群集收集和分析指标数据时最常用的工具。 适用于 Prometheus 的 Azure Monitor 托管服务是一种完全托管的解决方案，它与 Prometheus 查询语言 (PromQL) 和 Prometheus 警报兼容，并与 Azure 托管 Grafana 集成，实现可视化。 此服务支持对开放源代码工具的投资，免除了管理自己的 Prometheus 环境的复杂性。
Microsoft 托管 Grafana	完全托管实现 Grafana 是一个开源数据可视化平台，通常用于呈现 Prometheus 和其他数据。 可选择多种预定义的 Grafana 仪表板来监视 Kubernetes 并进行全堆栈故障排除。

为平台工程师配置监视

以下部分介绍使用上表中的 Azure 服务对 Kubernetes 环境进行完整监视的步骤。 其中为每个配置提供了功能和集成选项，以帮助你确定可能需要在哪个位置修改此配置以满足你的特定需求。

加入容器见解和托管 Prometheus 可以是启用对 Kubernetes 群集的监视中描述的相同体验的一部分。 以下各节分别对每一项进行了描述，使你可以考虑每一项的所有加入和配置选项。

启用 Prometheus 指标的抓取

使用以下方法之一，允许适用于 Prometheus 的 Azure Monitor 托管服务从群集中抓取 Prometheus 指标：

• 创建 AKS 群集时，选择“启用 Prometheus 指标”选项。
• 在现有 AKS 群集上启用容器见解时，请选择“启用 Prometheus 指标”选项。
• 为现有的 AKS 群集或已启用 Arc 的 Kubernetes 群集启用。

如果已有要用于 AKS 群集的 Prometheus 环境，请启用适用于 Prometheus 的 Azure Monitor 托管服务，然后使用远程写入将数据发送到现有 Prometheus 环境。 还可以使用远程写入将数据从现有的自托管 Prometheus 环境发送到适用于 Prometheus 的 Azure Monitor 托管服务。

有关默认收集的指标及其收集频率的详细信息，请参阅 Azure Monitor 中的默认 Prometheus 指标配置。 若要自定义配置，请参阅在适用于 Prometheus 的 Azure Monitor 托管服务中自定义 Prometheus 指标的抓取。

启用 Grafana 以分析 Prometheus 数据

创建托管 Grafana 实例并将其链接到 Azure Monitor 工作区，以便可以将 Prometheus 数据用作数据源。 还可以使用将适用于 Prometheus 的 Azure Monitor 托管服务添加为数据源手动执行此配置。 各种预生成的仪表板可用于监视 Kubernetes 群集，其中包括一些提供与容器见解视图类似信息的仪表板。

如果已有 Grafana 环境，则可以继续使用它，并将适用于 Prometheus 的 Azure Monitor 托管服务添加为数据源。 还可以将 Azure Monitor 数据源添加到 Grafana，以便在自定义 Grafana 仪表板中使用容器见解收集的数据。 如果需要重点关注 Grafana 仪表板，而不使用容器见解视图和报表，请执行此配置。

启用容器见解以收集日志

为 Kubernetes 群集启用容器见解时，它会部署 Azure Monitor 代理的一个容器化版本，用于将数据发送到 Azure Monitor 中的 Log Analytics 工作区。 容器见解将收集容器 stdout/stderr、基础结构日志和性能数据。 所有日志数据存储在 Log Analytics 工作区中，可以在此使用 Kusto 查询语言 (KQL) 对日志数据进行分析。

有关加入 Kubernetes 群集的先决条件和配置选项，请参阅启用容器见解。 使用 Azure Policy 加入以确保所有群集保持一致的配置。

为群集启用容器见解后，请执行以下操作以优化安装。

• 启用容器见解中的 Prometheus 体验，使你可以将容器见解视图与 Prometheus 数据配合使用。
• 若要使用容器见解收集的数据改善查询体验并降低收集成本，请为每个群集启用 ContainerLogV2 架构。 如果只偶尔使用日志进行故障排除，请考虑将此表配置为基本日志。

如果已有用于收集日志的现有解决方案，请按照此工具的指导进行操作，或启用容器见解，并使用 Log Analytics 工作区的数据导出功能将数据发送到 Azure 事件中心以转发到备用系统。

收集 AKS 群集的控制平面日志

AKS 控制平面组件的日志在 Azure 中是以资源日志的形式实现的。 容器见解不会使用这些日志，因此你需要创建自己的日志查询来查看和分析它们。 有关日志结构和查询的详细信息，请参阅如何从容器见解查询日志。

为每个 AKS 群集创建诊断设置，以便将资源日志发送到 Log Analytics 工作区。 使用 Azure Policy 来确保跨多个群集的一致配置。

向工作区发送资源日志会产生成本，因此只应收集打算使用的日志类别。 有关可用于 AKS 的类别的说明，请参阅资源日志。 首先收集最少数量的类别，然后随着需求的增加和对相关成本的了解，修改诊断设置以收集其他类别。 如果出于符合性原因需要保留信息，可以将日志发送到 Azure 存储帐户以降低成本。 有关引入和保留日志数据的成本的详细信息，请参阅 Azure Monitor 日志定价详细信息。

如果不确定最初启用哪些资源日志，请采用以下根据最常见客户要求提出的建议。 如果需要，稍后可以启用其他类别。

类别	是否启用？	目标
kube-apiserver	启用	Log Analytics 工作区
kube-audit	启用	Azure 存储。 这样可以将成本保持在最低水平，但仍然保留审核日志供审核者使用。
kube-audit-admin	启用	Log Analytics 工作区
kube-controller-manager	启用	Log Analytics 工作区
kube-scheduler	禁用
cluster-autoscaler	启用自动缩放后启用	Log Analytics 工作区
防护	请在启用 Microsoft Entra ID 时启用	Log Analytics 工作区
AllMetrics	禁用，因为指标是在托管 Prometheus 中收集的	Log Analytics 工作区

如果已有用于收集日志的现有解决方案，请按照此工具的指导进行操作，或启用容器见解，并使用 Log Analytics 工作区的数据导出功能将数据发送到 Azure 事件中心以转发到备用系统。

收集 AKS 群集的活动日志

对 AKS 群集的配置更改存储在活动日志中。 创建诊断设置以将此数据发送到 Log Analytics 工作区，以便与其他监视数据同时分析。 此数据收集不收取任何费用，可以使用 Log Analytics 对数据进行分析或发出警报。

监视级别 2 - 群集级别组件

群集级别包括以下组件：

组件	监视要求
节点	了解每个节点的 CPU、内存、磁盘和 IP 使用情况的就绪状态和性能，并在部署任何工作负载之前主动监视其使用趋势。

以下是监视群集级别组件的常见方案。

容器见解

• 使用“群集”视图可查看群集中节点的性能，包括 CPU 和内存利用率。
• 使用“节点”视图可查看每个节点的运行状况，以及在每个节点上运行的 Pod 的运行状况和性能。 若要详细了解如何分析节点的运行状况和性能，请参阅使用容器见解监视 Kubernetes 群集性能。
• 在“报告”下，使用“节点监视”工作簿分析磁盘容量、磁盘 IO 和 GPU 使用情况。 有关这些工作簿的详细信息，请参阅节点监视工作簿。
• 在“监视”下，可以选择“工作簿”，然后选择“子网 IP 使用情况”，查看所选时间范围内每个节点上的 IP 分配和赋值。

Grafana 仪表板

• 使用适用于 Kubelet 的托管 Grafana 中的预生成仪表板查看每个设备的运行状况和性能。
• 使用 Grafana 仪表板中与磁盘相关的Prometheus 指标值（例如 node_disk_io_time_seconds_total 和 windows_logical_disk_free_bytes）监视附加存储。
• 可以使用多个 Kubernetes 仪表板，根据 Prometheus 中存储的数据可视化节点的性能和运行状况。

Log Analytics

• 在 Log Analytics 工作区的查询对话框中选择“容器”类别，以访问群集的预生成日志查询，其中包括从容器见解填充的 ContainerImageInventory 表中检索数据的“映像清单”日志查询。

故障排除

• 对于故障排除方案，你可能需要直接访问节点来实现维护或即时日志收集。 出于安全目的，AKS 节点不会向 Internet 公开，但你可使用 kubectl debug 命令通过 SSH 连接到 AKS 节点。 有关此过程的详细信息，请参阅使用 SSH 连接到 Azure Kubernetes 服务 (AKS) 群集节点以进行维护或故障排除。

成本分析

• 配置 OpenCost，这是一个开源的、供应商无关的 CNCF 沙盒项目，用于了解 Kubernetes 成本，为群集成本分析提供支持。 它将详细的成本数据导出到 Azure 存储。
• 使用 OpenCost 中的数据细分组织中不同团队对群集的相对使用情况，以便可以在每个团队之间分配成本。
• 使用 OpenCost 中的数据，确保群集通过密集打包工作负载（使用较少的大型节点而不是许多较小的节点）来使用其节点的全部容量。

监视级别 3 - 托管 Kubernetes 组件

托管 Kubernetes 级别包括以下组件：

组件	监视
API 服务器	监视 API 服务器的状态，确定服务关闭时请求负载的任何增加以及瓶颈。
Kubelet	监视 Kubelet 有助于排查 Pod 管理问题，或者 Pod 无法启动、节点未就绪或 Pod 被终止的问题。

以下是监视托管 Kubernetes 组件的常见方案。

容器见解

• 在“监视”下，选择“指标”以查看“进行中的请求数”计数器。
• 在“报告”下，使用 Kubelet 工作簿可查看每个 kubelet 的运行状况和性能。 有关这些工作簿的详细信息，请参阅资源监视工作簿。

Grafana

• 使用适用于 Kubelet 的托管 Grafana 中的预生成仪表板查看每个 kubelet 的运行状况和性能。
• 使用 Kubernetes apiserver 等仪表板获取 API 服务器性能的完整视图。 这包括诸如请求延迟和工作队列处理时间之类的值。

Log Analytics

• 通过使用资源日志进行日志查询来分析由 AKS 组件生成的控制平面日志。

• AKS 的任何配置活动都记录在活动日志中。 将活动日志发送到 Log Analytics 工作区时，可以使用 Log Analytics 对其进行分析。 例如，以下示例查询可用于返回所有 AKS 群集中标识成功升级的记录。

  AzureActivity
  | where CategoryValue == "Administrative"
  | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
  | extend properties=parse_json(Properties_d) 
  | where properties.message == "Upgrade Succeeded"
  | order by TimeGenerated desc
  

故障排除

• 对于故障排除方案，可按照从 Azure Kubernete 服务 (AKS) 群集节点获取 kubelet 日志中描述的过程中访问 kubelet 日志。

监视级别 4 - Kubernetes 对象和工作负载

Kubernetes 对象和工作负载级别包括以下组件：

组件	监视要求
部署	监视部署的实际状态与预期状态，以及在其上运行的 Pod 的状态和资源利用率。
Pod	监视 AKS 群集上运行的 Pod 的状态和资源利用率，包括 CPU 和内存。
容器	监视 AKS 群集上运行的容器的资源利用率，包括 CPU 和内存。

以下是监视 Kubernetes 对象和工作负载的常见方案。

容器见解

• 使用“节点”视图和“控制器”视图可查看在其上运行的 Pod 的运行状况和性能，并向下钻取到其容器的运行状况和性能。
• 使用“容器”视图可查看容器的运行状况和性能。 若要详细了解如何分析容器的运行状况和性能，请参阅使用容器见解监视 Kubernetes 群集性能。
• 在“报告”下，使用“部署”工作簿可查看部署指标。 有关详细信息，请参阅使用容器见解收集的部署和 HPA 指标。

Grafana 仪表板

• 使用适用于节点和 Pod 的托管 Grafana 中的预生成仪表板查看其运行状况和性能。
• 可以使用多个 Kubernetes 仪表板，根据 Prometheus 中存储的数据可视化节点的性能和运行状况。

实时数据

• 在故障排除方案中，容器见解提供对实时 AKS 容器日志 (stdout/stderror)、事件和 Pod 指标的访问。 有关此功能的详细信息，请参阅如何实时查看 Kubernetes 日志、事件和 Pod 指标。

面向平台工程师的警报

Azure Monitor 中的警报会主动通知你在监视数据中发现的值得关注的数据和模式。 有了警报，你就可以在客户注意到你的系统中的问题之前确定和解决它们。 还可以导出工作区数据，将数据从 Log Analytics 工作区发送到支持当前警报解决方案的其他位置。

警报类型

下表描述了可以根据上述服务收集的数据创建的不同类型的自定义警报规则。

警报类型	说明
指标警报规则	指标警报规则使用与“指标”资源管理器相同的指标值。 事实上，你可以使用当前分析的数据从“指标”资源管理器直接创建警报规则。 指标预警规则可用于使用 AKS 数据参考指标中的任何值对 AKS 性能发出警报。
日志搜索预警规则	使用日志搜索警报规则根据日志查询结果生成警报。 有关详细信息，请参阅如何从容器见解创建日志搜索警报和如何从容器见解查询日志。

建议的警报

Developer

除了开发应用程序外，开发人员还负责维护群集上运行的应用程序。 他们负责应用程序特定的流量，包括应用程序性能和故障，并根据公司定义的 SLA 维护应用程序的可靠性。

面向开发人员的 Azure 服务

下表列出了开发人员在监视群集上运行的应用程序的运行状况和性能时通常使用的服务。

服务	说明
Application insights	Azure Monitor 的功能，提供应用程序性能监视 (APM)，以监视 Kubernetes 群集上运行的应用程序，从开发、测试到生产环境。 使用分布式跟踪快速识别和缓解延迟和可靠性问题。 支持 OpenTelemetry 进行与供应商无关的检测。

有关从群集上运行的应用程序配置数据收集的选项，以及针对特定需求的最佳方法的决策标准，请参阅 Azure Monitor Application Insights 的数据收集基本信息。

监视级别 5 - 应用程序

以下是监视应用程序的常见方案。

应用程序性能

• 使用 Application Insights 中的“性能”视图查看应用程序中不同操作的性能。
• 使用探查器捕获和查看应用程序的性能跟踪。
• 使用应用程序映射查看应用程序组件之间的依赖关系并识别任何瓶颈。
• 启用分布式跟踪，它提供一个性能分析器，其工作方式类似于云和微服务体系结构的调用堆栈，以便更好地观察服务之间的交互。

应用程序失败

• 使用 Application Insights 的“失败”选项卡查看失败的请求数和最常见的异常。
• 确保正确配置智能检测识别的失败异常警报。

运行状况监视

• 在 Application Insights 中创建可用性测试，以便创建定期测试来监视应用程序的可用性和响应能力。
• 使用 SLA 报表计算和报告 Web 测试的 SLA。
• 使用批注确定何时部署了新版本，以便可以在更新后直观地检查性能的任何变更。

应用程序日志

• 容器见解将 stdout/stderr 日志发送到 Log Analytics 工作区。 有关不同日志的说明，请参阅资源日志；有关每个日志发送到的表的列表，请参阅 Kubernetes 服务。

服务网格

• 对于 AKS 群集，请部署基于 Istio 的服务网格加载项，以便为微服务体系结构提供可观测性。 Istio 是一个开放源代码服务网格，它以透明方式分层到现有的分布式应用程序上。 加载项有助于部署和管理 AKS 的 Istio。

另请参阅

• 有关监视 Azure Kubernetes 服务 (AKS) 的指导，请参阅监视 AKS。