Azure Monitor 中的 Kubernetes 监视 描述了用于提供对 Kubernetes 环境及其上运行的工作负荷的完整监视的 Azure Monitor 服务。 本文提供了有关如何利用这些服务的最佳做法,根据管理这些服务的典型角色监视 Kubernetes 环境的不同层。
以下是典型 Kubernetes 环境的通用模型(从基础结构层到应用程序)的图示。 每层都有不同的监视要求,这些要求由不同的服务解决,通常由组织中的不同角色管理。
Kubernetes 环境的不同层和依赖此环境的应用程序的责任通常由多个角色承担。 根据组织的规模,这些角色可能由不同的人员甚至不同的团队执行。 下表描述了不同的角色,以下部分提供了每个角色通常会遇到的监视场景。
角色 | 说明 |
---|---|
开发人员 | 开发和维护群集上运行的应用程序。 负责特定于应用程序的流量,包括应用程序性能和故障。 根据 SLA 维护应用程序的可靠性。 |
平台工程师 | 负责 Kubernetes 群集。 预配和维护开发人员使用的平台。 |
网络工程师 | 负责工作负载与群集的任何入口/出口之间的流量。 分析网络流量并执行威胁分析。 |
网络工程师
网络工程师负责工作负载与群集的任何入口/出口之间的流量。 他们分析网络流量并执行威胁分析。
监视级别 1 - 网络
以下是监视网络的常见方案。
- 使用网络观察程序创建流日志,以记录有关流经群集使用的网络安全组的 IP 流量的信息,然后使用流量分析来分析和提供有关此数据的见解。 请使用与容器日志和控制平面日志相同的 Log Analytics 工作区来进行网络流量分析。
- 使用 流量分析,确定群集使用的任何流量是否流向或流出任何意外端口,以及是否有流量流经不应公开的公共 IP。 使用此信息确定是否需要修改网络规则。
- 对于 AKS 群集,请使用适用于 AKS 的网络可观测性加载项(预览版)监视和观察群集中服务之间的访问(东-西流量)。
平台工程师
平台工程师(也称为群集管理员)负责 Kubernetes 群集本身。 他们预配和维护开发人员使用的平台。 他们需要了解群集及其组件的运行状况,并能够排查检测到的任何问题。 他们还需要了解运行群集的成本,并有可能将成本分配给不同的团队。
大型组织可能还有群队架构师,类似于平台工程师,但负责多个群集。 他们需要查看整个环境,并且必须大规模执行管理任务。 以下指导中提供了大规模建议。 有关为多群集和大规模方案创建舰队资源的详细信息,请参阅什么是 Azure Kubernetes 舰队管理器?。
为平台工程师配置监视
以下部分确定了使用 容器级别中的 Azure 服务监视 Kubernetes 环境的步骤。 其中为每个配置提供了功能和集成选项,以帮助你确定可能需要在哪个位置修改此配置以满足你的特定需求。 加入托管 Prometheus 和容器日志记录可以属于与为 Kubernetes 群集启用监视中所述的相同体验的一部分。 以下各节分别对每一项进行了描述,使你可以考虑每一项的所有加入和配置选项。
启用 Prometheus 指标的抓取
重要
要使用适用于 Prometheus 的 Azure Monitor 托管服务,需要具有 Azure Monitor 工作区。 有关工作区配置的设计注意事项的信息,请参阅 Azure Monitor 工作区体系结构。
在创建 Prometheus 或将此功能添加到现有群集时,启用 Azure Monitor 适用于 Prometheus 的托管服务从你的群集中抓取 Prometheus 指标的功能。 有关详细信息,请参阅 “启用 Prometheus 指标 ”。
如果已有要用于 AKS 群集的 Prometheus 环境,请启用适用于 Prometheus 的 Azure Monitor 托管服务,然后使用远程写入将数据发送到现有 Prometheus 环境。 还可以使用远程写入将数据从现有的自托管 Prometheus 环境发送到适用于 Prometheus 的 Azure Monitor 托管服务。
有关默认收集的指标及其收集频率的详细信息,请参阅 Azure Monitor 中的默认 Prometheus 指标配置。 若要自定义配置,请参阅在适用于 Prometheus 的 Azure Monitor 托管服务中自定义 Prometheus 指标的抓取。
启用 Grafana 以分析 Prometheus 数据
注意
使用 Grafana 的 Azure Monitor 仪表板目前以公共预览版提供,可以替换托管 Grafana。 此版本的 Grafana 不收费,无需配置,并在 Azure 门户中提供仪表板。 如果要创建合并来自多个数据源的数据的仪表板,或者想要与现有 Grafana 环境集成,请使用 Managed Grafana。
创建托管 Grafana 实例并将其链接到 Azure Monitor 工作区,以便可以将 Prometheus 数据用作数据源。 还可以使用将适用于 Prometheus 的 Azure Monitor 托管服务添加为数据源手动执行此配置。 各种预生成的仪表板可用于监视 Kubernetes 群集,其中包括一些提供与容器见解视图类似信息的仪表板。
如果已有 Grafana 环境,则可以继续使用它,并将适用于 Prometheus 的 Azure Monitor 托管服务添加为数据源。 还可以将 Azure Monitor 数据源添加到 Grafana,以便在自定义 Grafana 仪表板中使用容器见解收集的数据。 如果需要重点关注 Grafana 仪表板,而不使用容器见解视图和报表,请执行此配置。
启用容器日志收集
重要
若要使用 Prometheus 的 Azure Monitor 托管服务,需要具有 Log Analytics 工作区。 有关工作区配置的设计注意事项的信息,请参阅 Azure Monitor 工作区体系结构。
为 Kubernetes 群集启用容器日志收集时,Azure Monitor 会部署 Azure Monitor 代理 的容器化版本,该代理将 stdout/stderr 和基础结构日志发送到 Azure Monitor 中的 Log Analytics 工作区 ,可在其中使用 Kusto 查询语言(KQL)对其进行分析。
有关载入 Kubernetes 群集的先决条件和配置选项,请参阅 “为 AKS 群集启用监视 ”。 使用 Azure Policy 加入以确保所有群集都保留一致的配置。
为群集启用容器日志记录后,执行以下作来优化安装。
- 如果只偶尔使用日志进行故障排除,请考虑将此表配置为基本日志。
- 使用在容器见解中启用成本优化设置中所述的成本预设,通过减少收集的数据量来降低容器见解数据引入的成本。 通过将容器见解配置为仅收集“日志和事件”来禁用指标收集,因为许多指标值与 Prometheus 相同。
如果有用于收集日志的现有解决方案,请按照该工具的指导进行作,或者使用 Azure Monitor 启用日志收集,并使用 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调度器 | 禁用 | |
集群自动扩展器 | 启用自动缩放后启用 | Log Analytics 工作区 |
临界 | 请在启用 Microsoft Entra ID 时启用 | Log Analytics 工作区 |
AllMetrics | 禁用,因为指标是在托管 Prometheus 中收集的 | Log Analytics 工作区 |
如果有用于收集日志的现有解决方案,请遵循该工具的指导,或者使用 Azure Monitor 启用日志收集,并使用 Log Analytics 工作区的数据导出功能 将数据发送到 Azure 事件中心以转发到备用系统。
收集 AKS 群集的活动日志
对 AKS 群集的配置更改存储在活动日志中。 创建诊断设置以将此数据发送到 Log Analytics 工作区,以便与其他监视数据同时分析。 此数据收集不收取任何费用,可以使用 Log Analytics 对数据进行分析或发出警报。
监视级别 2 - 群集级别组件
群集级别包括以下组件:
组件 | 监视要求 |
---|---|
Node | 了解每个节点的 CPU、内存、磁盘和 IP 使用情况的就绪状态和性能,并在部署任何工作负载之前主动监视其使用趋势。 |
以下是监视群集级别组件的常见方案。
Azure 门户
- 使用 Azure 门户中的统一监视仪表板查看群集中节点的性能,包括 CPU 和内存利用率。
- 使用“节点”视图可查看每个节点的运行状况,以及在每个节点上运行的 Pod 的运行状况和性能。 有关分析节点运行状况和性能的详细信息,请参阅 Azure 门户中的分析 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 组件的常见方案。
Azure 门户
- 使用 指标资源管理器 查看群集 的“登录请求” 计数器。
- 使用 Kubelet 工作簿 查看每个 kubelet 的运行状况和性能。
格拉法纳
- 使用适用于 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 对象和工作负载的常见方案。
Azure 门户
- 使用“节点”视图和“控制器”视图可查看在其上运行的 Pod 的运行状况和性能,并向下钻取到其容器的运行状况和性能。
- 使用“容器”视图可查看容器的运行状况和性能。 有关分析容器运行状况和性能的详细信息,请参阅 使用容器见解分析 Kubernetes 群集数据。
- 使用 部署工作簿 查看部署指标。 有关详细信息,请参阅使用容器见解收集的部署和 HPA 指标。
Grafana 仪表板
- 使用适用于节点和 Pod 的托管 Grafana 中的预生成仪表板查看其运行状况和性能。
- 可以使用多个 Kubernetes 仪表板,根据 Prometheus 中存储的数据可视化节点的性能和运行状况。
实时数据
- 在故障排除方案中,容器见解提供对实时 AKS 容器日志 (stdout/stderror)、事件和 Pod 指标的访问。 有关此功能的详细信息,请参阅如何实时查看 Kubernetes 日志、事件和 Pod 指标。
面向平台工程师的警报
Azure Monitor 中的警报会主动通知你在监视数据中发现的值得关注的数据和模式。 有了警报,你就可以在客户注意到你的系统中的问题之前确定和解决它们。 还可以导出工作区数据,将数据从 Log Analytics 工作区发送到支持当前警报解决方案的其他位置。
警报类型
下表描述了可以根据上述服务收集的数据创建的不同类型的自定义警报规则。
警报类型 | 说明 |
---|---|
指标警报规则 | 指标警报规则使用与“指标”资源管理器相同的指标值。 事实上,你可以使用当前分析的数据从“指标”资源管理器直接创建警报规则。 指标预警规则可用于使用 AKS 数据参考指标中的任何值对 AKS 性能发出警报。 |
日志搜索预警规则 | 使用日志搜索警报规则根据日志查询结果生成警报。 有关详细信息,请参阅如何从容器见解创建日志搜索警报和如何从容器见解查询日志。 |
建议的警报
开发人员
除了开发应用程序外,开发人员还负责维护群集上运行的应用程序。 他们负责应用程序特定的流量,包括应用程序性能和故障,并根据公司定义的 SLA 维护应用程序的可靠性。
面向开发人员的 Azure 服务
下表列出了开发人员在监视群集上运行的应用程序的运行状况和性能时通常使用的服务。
有关从群集上运行的应用程序配置数据收集的选项,以及针对特定需求的最佳方法的决策标准,请参阅 Azure Monitor Application Insights 的数据收集基本信息。
监视级别 5 - 应用程序
以下是监视应用程序的常见方案。
应用程序性能
- 使用 Application Insights 中的“性能”视图查看应用程序中不同操作的性能。
- 使用应用程序映射查看应用程序组件之间的依赖关系并识别任何瓶颈。
- 启用分布式跟踪,它提供一个性能分析器,其工作方式类似于云和微服务体系结构的调用堆栈,以便更好地观察服务之间的交互。
应用程序失败
运行状况监视
- 在 Application Insights 中创建可用性测试,以便创建定期测试来监视应用程序的可用性和响应能力。
- 使用 SLA 报表计算和报告 Web 测试的 SLA。
- 使用批注确定何时部署了新版本,以便可以在更新后直观地检查性能的任何变更。
应用程序日志
- 容器见解将 stdout/stderr 日志发送到 Log Analytics 工作区。 有关不同日志的说明,请参阅资源日志;有关每个日志发送到的表的列表,请参阅 Kubernetes 服务。
服务网格
- 对于 AKS 群集,请部署基于 Istio 的服务网格加载项,以便为微服务体系结构提供可观测性。 Istio 是一个开放源代码服务网格,它以透明方式分层到现有的分布式应用程序上。 加载项有助于部署和管理 AKS 的 Istio。
另请参阅
- 请参阅 “启用对 Kubernetes 群集的监视 ”,以便在群集上启用托管 Prometheus 和日志收集。