使用 Azure 服务和云原生工具监视 Kubernetes 群集
本文介绍如何使用 Azure Monitor 以及相关的 Azure 和云原生服务监视 Kubernetes 群集及其上运行的工作负载的运行状况和性能。 其中包括在 Azure Kubernetes 服务 (AKS) 或其他云（如 AWS 和 GCP）中运行的群集。 对于通常管理组成 Kubernetes 环境的唯一组件的不同角色，提供了不同的指导集。
重要
本文提供有关基于 Azure Kubernetes 服务 (AKS) 或其他云中的 Kubernetes 群集监视 Kubernetes 环境不同层的完整指导。 如果你刚开始使用 AKS 或 Azure Monitor，请参阅监视 AKS 以获取监视 AKS 群集入门的基本信息。
Kubernetes 环境的层和角色
以下是典型 Kubernetes 环境的通用模型（从基础结构层到应用程序）的图示。 每层都有不同的监视要求，这些要求由不同的服务解决，通常由组织中的不同角色管理。
Kubernetes 环境的不同层和依赖此环境的应用程序的责任通常由多个角色承担。 根据组织的规模，这些角色可能由不同的人员甚至不同的团队执行。 下表描述了不同的角色，以下部分提供了每个角色通常会遇到的监视场景。
| 角色 | 说明 |
|---|---|
| Developer | 开发和维护群集上运行的应用程序。 负责特定于应用程序的流量，包括应用程序性能和故障。 根据 SLA 维护应用程序的可靠性。 |
| 平台工程师 | 负责 Kubernetes 群集。 预配和维护开发人员使用的平台。 |
| 网络工程师 | 负责工作负载与群集的任何入口/出口之间的流量。 分析网络流量并执行威胁分析。 |
选择监视工具
Azure 提供基于 Azure Monitor 的完整服务集，用于监视 Kubernetes 基础结构的不同层以及依赖此基础结构的应用程序的运行状况和性能。 这些服务相互配合，提供完整的监视解决方案，推荐用于 AKS 和其他云中运行的 Kubernetes 群集。 你可能已经对云原生计算基础认证的云原生技术进行了投资，在这种情况下，你可以选择将 Azure 工具集成到现有环境中。
选择部署哪些工具及其配置将取决于特定环境的需求。 例如，可以将 Azure 中托管的产品/服务用于 Prometheus 和 Grafana，也可以选择将这些工具的现有安装与 Azure 中的 Kubernetes 群集配合使用。 组织还可以使用容器见解的替代工具来收集和分析 Kubernetes 日志，例如 Splunk 或 Datadog。
重要
监视 Kubernetes 等复杂环境涉及收集大量遥测数据，其中大部分会产生费用。 应收集足够的数据来满足你的需求。 其中包括收集的数据量、收集频率和保留期。 如果你非常注重成本，则可以选择实现完整功能的子集，以减少监视支出。
网络工程师
网络工程师负责工作负载与群集的任何入口/出口之间的流量。 他们分析网络流量并执行威胁分析。
面向网络管理员的 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 事件。 此服务还从 Kubernetes 控制平面收集指标，并将其存储在工作区中。 你可以在 Azure 门户中查看数据，也可以使用 Log Analytics 查询数据。 |
为平台工程师配置监视
以下部分介绍使用上表中的 Azure 服务对 Kubernetes 环境进行完整监视的步骤。 其中为每个配置提供了功能和集成选项，以帮助你确定可能需要在哪个位置修改此配置以满足你的特定需求。
启用容器见解以收集日志
为 Kubernetes 群集启用容器见解时，它会部署 Azure Monitor 代理的一个容器化版本，用于将数据发送到 Azure Monitor 中的 Log Analytics 工作区。 容器见解将收集容器 stdout/stderr、基础结构日志和性能数据。 所有日志数据存储在 Log Analytics 工作区中，可以在此使用 Kusto 查询语言 (KQL) 对日志数据进行分析。
有关加入 Kubernetes 群集的先决条件和配置选项，请参阅启用容器见解。 使用 Azure Policy 加入以确保所有群集保持一致的配置。
为群集启用容器见解后，请执行以下操作以优化安装。
- 通过减少收集的数据量，降低容器见解数据引入的成本。
- 若要使用容器见解收集的数据改善查询体验并降低收集成本，请为每个群集启用 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 分配和赋值。
网络可观测性
- 对于 AKS 群集，请使用适用于 AKS 的网络可观测性附加产品（预览版）来监视和观测群集中各服务之间的访问。
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
- 使用 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 仪表板
- 可以使用多个 Kubernetes 仪表板，根据 Prometheus 中存储的数据可视化节点的性能和运行状况。
实时数据
- 在故障排除方案中，容器见解提供对实时 AKS 容器日志 (stdout/stderror)、事件和 Pod 指标的访问。 有关此功能的详细信息，请参阅如何实时查看 Kubernetes 日志、事件和 Pod 指标。
面向平台工程师的警报
Azure Monitor 中的警报会主动通知你在监视数据中发现的值得关注的数据和模式。 有了警报，你就可以在客户注意到你的系统中的问题之前确定和解决它们。
警报类型
下表描述了可以根据上述服务收集的数据创建的不同类型的自定义警报规则。
| 警报类型 | 说明 |
|---|---|
| 指标警报规则 | 指标警报规则使用与“指标”资源管理器相同的指标值。 事实上，你可以使用当前分析的数据从“指标”资源管理器直接创建警报规则。 指标预警规则可用于使用 AKS 数据参考指标中的任何值对 AKS 性能发出警报。 |
| 日志搜索预警规则 | 使用日志搜索警报规则根据日志查询结果生成警报。 有关详细信息，请参阅如何从容器见解创建日志搜索警报和如何从容器见解查询日志。 |
建议的警报
Developer
除了开发应用程序外，开发人员还负责维护群集上运行的应用程序。 他们负责应用程序特定的流量，包括应用程序性能和故障，并根据公司定义的 SLA 维护应用程序的可靠性。
面向开发人员的 Azure 服务
下表列出了开发人员在监视群集上运行的应用程序的运行状况和性能时通常使用的服务。
| 服务 | 说明 |
|---|---|
| Application insights | Azure Monitor 的功能，提供应用程序性能监视 (APM)，以监视 Kubernetes 群集上运行的应用程序，从开发、测试到生产环境。 使用分布式跟踪快速识别和缓解延迟和可靠性问题。 支持 OpenTelemetry 进行与供应商无关的检测。 |
有关从群集上运行的应用程序配置数据收集的选项，以及针对特定需求的最佳方法的决策标准，请参阅 Azure Monitor Application Insights 的数据收集基本信息。
监视级别 5 - 应用程序
以下是监视应用程序的常见方案。
应用程序性能
- 使用 Application Insights 中的“性能”视图查看应用程序中不同操作的性能。
- 使用探查器捕获和查看应用程序的性能跟踪。
- 使用应用程序映射查看应用程序组件之间的依赖关系并识别任何瓶颈。
- 启用分布式跟踪，它提供一个性能分析器，其工作方式类似于云和微服务体系结构的调用堆栈，以便更好地观察服务之间的交互。
应用程序失败
运行状况监视
- 在 Application Insights 中创建可用性测试，以便创建定期测试来监视应用程序的可用性和响应能力。
- 使用 SLA 报表计算和报告 Web 测试的 SLA。
- 使用批注确定何时部署了新版本，以便可以在更新后直观地检查性能的任何变更。
应用程序日志
- 容器见解将 stdout/stderr 日志发送到 Log Analytics 工作区。 有关不同日志的说明，请参阅资源日志；有关每个日志发送到的表的列表，请参阅 Kubernetes 服务。
服务网格
- 对于 AKS 群集，请部署基于 Istio 的服务网格加载项，以便为微服务体系结构提供可观测性。 Istio 是一个开放源代码服务网格，它以透明方式分层到现有的分布式应用程序上。 加载项有助于部署和管理 AKS 的 Istio。
另请参阅
- 有关监视 Azure Kubernetes 服务 (AKS) 的指导，请参阅监视 AKS。