本文介绍如何使用以下 Azure Monitor 功能启用 Kubernetes 群集的完整监视：
- 用于指标收集的托管 Prometheus
- 用于日志收集的容器见解
- 用于可视化的托管 Grafana。
使用 Azure 门户，可以同时启用所有这些功能。 还可以使用 Azure CLI、Azure 资源管理器模板、Terraform 或 Azure Policy 单独启用它们。 本文介绍了上述每种方法。
重要
Kubernetes 群集会生成大量日志数据，如果你对收集的日志没有选择性，可能会导致高昂的成本。 在启用群集监视之前，请参阅以下文章，以确保环境针对成本进行了优化，并将日志收集限制为仅收集所需的数据：
-
使用数据收集规则在容器见解中配置数据收集和成本优化
有关启用监视后如何自定义日志收集的详细信息，包括使用预设的成本优化配置方案。 -
使用 Azure Monitor 监视 Kubernetes 的最佳做法
根据 Azure 架构良好的框架的五大支柱（包括成本优化）整理的 Kubernetes 群集监视最佳实践。 -
Azure Monitor 中的成本优化
有关配置 Azure Monitor 所有功能以优化成本并限制收集的数据量的最佳做法。
本文就以下类型的群集提供加入指南。 相关部分中介绍了每种类型过程中的任何差异。
权限
托管 Prometheus 的先决条件
- 群集必须使用托管标识身份验证。
- 必须在群集和 Azure Monitor 工作区的订阅中注册以下资源提供程序：
- Microsoft.ContainerService (微软容器服务)
- Microsoft.Insights
- Microsoft.AlertsManagement
- Microsoft.Monitor
- 以下资源提供程序必须在 Grafana 工作区订阅中注册：
- Microsoft.Dashboard
已启用 Arc 的 Kubernetes 群集先决条件
- 请验证防火墙要求和已启用 Azure Arc 的 Kubernetes 网络要求。
- 如果以前为 AKS 安装了监视，请务必禁用监视后再继续，以免在扩展安装过程中出现问题。
- 如果以前在没有群集扩展的情况下使用脚本在群集上安装监视，请按照禁用 Kubernetes 群集监视的说明来删除此 Helm 图表。
备注
托管 Prometheus 已启用 Arc 的 Kubernetes 扩展不支持以下配置：
- Red Hat Openshift 分发版，包括 Azure Red Hat OpenShift (ARO)
- Windows 节点*
*对于包含 Windows 节点的已启用 ARC 的群集，可以在群集中的 Linux 节点上设置 Azure 托管 Prometheus，并配置为从 Windows 节点上运行的指标终结点抓取指标。
下表介绍了支持托管 Prometheus 和容器见解所需的工作区。 可在加入过程中创建每个工作区，或者使用现有工作区。 请参阅设计 Log Analytics 工作区体系结构，获取有关要创建多少个工作区以及应在何处放置工作区的指导。
| 功能 | 工作区 | 说明 |
|---|---|---|
| 托管 Prometheus | Azure Monitor 工作区 |
Contributor 权限足以允许加载项将数据发送到 Azure Monitor 工作区。 若要链接 Azure Monitor 工作区以查看 Azure 托管 Grafana 中的指标，则需要 Owner 级别权限。 这是必需项，因为执行入门步骤的用户需要能够在 Azure Monitor 工作区上为 Azure 托管 Grafana 系统标识授予 Monitoring Reader 角色，以便查询指标。 |
| 容器见解 | Log Analytics 工作区 | 可以将群集附加到同一Microsoft Entra 租户中不同 Azure 订阅中的 Log Analytics 工作区，但必须使用 Azure CLI 或 Azure 资源管理器模板。 目前不能使用 Azure 门户执行此配置。 如果要将现有群集连接到另一订阅中的 Log Analytics 工作区，则必须在订阅中向 Log Analytics 工作区注册 Microsoft.ContainerService 资源提供程序。 有关详细信息，请参阅注册资源供应商。 |
| 托管 Grafana | Azure 托管 Grafana 工作区 | 将 Grafana 工作区链接到 Azure Monitor 工作区，以使从群集收集的 Prometheus 指标可供 Grafana 仪表板使用。 |
使用以下方法之一可以从群集中抓取 Prometheus 指标，并启用 Managed Grafana 来可视化指标。 有关连接 Azure Monitor 工作区和 Azure 托管 Grafana 工作区的选项，请参阅链接 Grafana 工作区。
备注
如果使用 ARM、Bicep 或 Terraform 模板或 Azure Policy 完成部署，并且未使用提供的示例，请确保命名数据收集终结点、数据收集规则和数据收集规则关联 MSProm-<Location of Azure Monitor Workspace>-<Name of cluster resource>。 否则将导致载入过程未成功完成。
备注
如果您有一个私有链接的 Azure Monitor 资源，那么如果 AKS 群集和 Azure Monitor 工作区位于不同区域，Prometheus 启用将无法正常工作。 由于专用链接约束，Prometheus 加载项所需的配置无法跨区域使用。 若要解决此问题，请在群集位置创建新的 DCE，并在同一群集区域中创建新的 DCRA（关联）。 将新的 DCE 与群集关联，并将新的关联（DCRA）命名为 configurationAccessEndpoint。 有关如何配置与 Azure Monitor 工作区关联的 DCE 以使用专用链接进行数据引入的完整说明，请参阅在 Azure Monitor 中启用 Kubernetes 监视的专用链接。
- 必须已创建 Azure Monitor 工作区和 Azure 托管 Grafana 工作区。
- 模板需要部署在 Azure 托管 Grafana 工作区所在的资源组中。
- AKS 群集订阅中具有“用户访问管理员”角色的用户可以通过部署模板直接启用“监视读者”角色。
- 如果 Azure 托管 Grafana 实例所在的订阅不是 Azure Monitor 工作区订阅，请按照
Microsoft.Dashboard中的步骤向 资源提供程序注册 Azure Monitor 工作区订阅。
在 Azure 门户中 Azure 托管 Grafana 实例的“概述”页面，选择“JSON 视图”。
如果使用已链接到 Azure Monitor 工作区的现有 Azure 托管 Grafana 实例，则需要 Grafana 集成列表。 复制azureMonitorWorkspaceIntegrations字段的值。 如果该值不存在，则实例尚未链接到任何 Azure Monitor 工作区。 使用 Grafana 集成列表更新 azure_monitor_workspace_integrations 中的 main.tf 块。
azure_monitor_workspace_integrations {
resource_id = var.monitor_workspace_id[var.monitor_workspace_id1, var.monitor_workspace_id2]
}
如果要使用启用了托管 Prometheus 加载项的 Terraform 部署新的 AKS 群集，请按照以下步骤操作：
- 下载AddonTerraformTemplate下的所有文件。
- 使用正确的参数值编辑 variables.tf 文件中的变量。
- 运行
terraform init -upgrade，将 Terraform 部署进行初始化。 - 运行
terraform plan -out main.tfplan，将 Terraform 部署进行初始化。 - 运行
terraform apply main.tfplan，将执行计划应用到云基础结构。
注意：仅当 annotations_allowed 和 labels_allowed 关键值的变量存在时，才会在 main.tf 中传递这些变量。 这些模块是可选的。
备注
在运行 terraform 模板之前，相应地编辑 main.tf 文件。 在运行模板之前，将任何现有的 azure_monitor_workspace_integrations 值添加到 Grafana 资源。 否则，旧值将被删除，并替换为部署期间模板中的内容。 AKS 群集订阅中具有“用户访问管理员”角色的用户可以部署模板以直接启用“监视读者”角色。 如果正在使用非标准 SKU，请编辑 GrafanaSku 参数，最后在 Grafana 资源的资源组中运行此模板。
按照下述方法之一在群集中启用容器见解。 完成此操作后，请参阅配置容器见解代理的数据收集，以根据需要自定义配置，确保收集的数据不会超出您的需求。
备注
如果你有一个专用链接的 Azure Monitor 资源，则无法通过 Azure 门户启用容器见解。 有关如何使用专用链接配置容器见解的完整说明，请参阅在 Azure Monitor 中启用 Kubernetes 监视的专用链接。
下载 Terraform 模板文件，具体取决于是否要启用 Syslog 集合。
Syslog
没有 Syslog
根据您的群集设置，调整
azurerm_kubernetes_cluster资源在 main.tf 中的位置。更新 variables.tf 中的参数以替换“”中的值<>
参数 说明 aks_resource_group_name使用资源组的“AKS 概述”页中的值。 resource_group_location使用资源组的“AKS 概述”页中的值。 cluster_name定义要创建的群集名称。 workspace_resource_id使用你的 Log Analytics 工作区的资源 ID。 workspace_region使用你的 Log Analytics 工作区的位置。 resource_tag_values将为群集的现有容器见解扩展数据收集规则 (DCR) 指定的现有标记值与 DCR 的名称进行匹配。 名称将匹配 MSCI-<clusterName>-<clusterRegion>，并且此资源在 AKS 群集所在的同一资源组中创建。 首次载入时，可设置任意标记值。enabledContainerLogV2要使用推荐的默认 ContainerLogV2，请将此参数值设置为 true。 成本优化参数 请参考数据收集参数 运行
terraform init -upgrade，将 Terraform 部署进行初始化。运行
terraform plan -out main.tfplan，将 Terraform 部署进行初始化。运行
terraform apply main.tfplan，将执行计划应用到云基础结构。
- 首先使用以下命令导入现有群集资源：
terraform import azurerm_kubernetes_cluster.k8s <aksResourceId> - 将 oms_agent 附加配置文件添加到现有 azurerm_kubernetes_cluster 资源。
oms_agent { log_analytics_workspace_id = var.workspace_resource_id msi_auth_for_monitoring_enabled = true } - 从 Terraform 模板复制 DCR 和 DCRA 资源
- 运行
terraform plan -out main.tfplan并确保更改是添加 oms_agent 属性。 注意：如果在 terraform 计划期间定义的azurerm_kubernetes_cluster资源不同，则会销毁现有群集并重新进行创建。 - 运行
terraform apply main.tfplan，将执行计划应用到云基础结构。
提示
- 在运行 terraform 模板之前，相应地编辑
main.tf文件 - 数据将在 10 分钟后开始流动，因为群集需要先准备好
- WorkspaceID 需要与格式
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/example-resource-group/providers/Microsoft.OperationalInsights/workspaces/workspaceValue匹配 - 如果资源组已存在，请先运行
terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name>，然后执行 terraform 计划
在 Azure 门户中创建新的 AKS 群集时，会在“监视”选项卡中选中“启用容器日志”、“启用 Prometheus 指标”、“启用 Grafana”和“启用建议的警报”复选框。
- 请在 Azure 门户中进入您的集群。
- 在服务菜单中，选择“ 监视>监视器设置”。
- 已为你选择 Prometheus 指标、Grafana 和容器日志及事件。 如果你现在有 Azure Monitor 工作区、Grafana 工作区和 Log Analytics 工作区，系统会为你选择它们。
- 如果你希望选择备用工作区或创建新工作区，请选择“高级设置”。 使用“日志记录配置文件和经典配置文件”设置，你可以修改默认集合详细信息来降低监视成本。 有关详细信息，请参阅在容器见解中启用成本优化设置。
- 选择“配置” 。
备注
windows-exporter-daemonset.yaml 中不存在 CPU/内存限制，因此可能会过度预配 Windows 节点
有关更多详细信息，请参阅资源预留
在部署工作负载时，请对容器设置资源内存和 CPU 限制。 这也会从 NodeAllocatable 中扣减，并且可以帮助群集范围的计划程序确定将哪些 pod 放置在哪些节点上。 在没有限制的情况下调度 Pod 可能会导致 Windows 节点过度配置，并且在极端情况下可能会导致节点不健康。
自托管 Prometheus 加载项容器 (prometheus_collector) 的 6.4.0-main-02-22-2023-3ee44b9e 版本起，AKS 群集已启用 Windows 指标收集。 加入 Azure Monitor 指标附加组件可使 Windows 守护进程集 pod 在节点池上开始运行。 支持 Windows Server 2019 和 Windows Server 2022。 按照以下步骤使 Pod 能够从 Windows 节点池收集指标。
通过部署 windows-exporter-daemonset YAML 文件，在 AKS 节点上手动安装 windows 导出程序以访问 Windows 指标。 启用以下收集器：
[defaults]containermemoryprocesscpu_info
有关更多收集器，请参阅适用于 Windows 指标的 Prometheus 导出器。
部署 windows-exporter-daemonset YAML 文件。 请注意，如果在节点上应用了任何排斥，你将需要应用相应的容忍度。
kubectl apply -f windows-exporter-daemonset.yaml将 ama-metrics-settings-configmap 应用到群集。 将
windowsexporter和windowskubeproxy布尔值设置为true。 有关详细信息，请参阅指标加载项设置 configmap。启用开箱即用仪表板所需的录制规则：
[仅适用于已启用 ARC 的群集中的 Windows 节点]如果要为已启用 ARC 的群集启用托管 Prometheus，则可以配置群集中 Linux 节点上运行的 Managed Prometheus，以从 Windows 节点上运行的终结点中抓取指标。 将以下抓取任务添加到 ama-metrics-prometheus-config-configmap.yaml，并将 configmap 应用到集群。
scrape_configs:
- job_name: windows-exporter
scheme: http
scrape_interval: 30s
label_limit: 63
label_name_length_limit: 511
label_value_length_limit: 1023
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]
target_label: instance
- action: keep
source_labels: [__meta_kubernetes_node_label_kubernetes_io_os]
regex: windows
- source_labels:
- __address__
action: replace
target_label: __address__
regex: (.+?)(\:\d+)?
replacement: $$1:9182
kubectl apply -f ama-metrics-prometheus-config-configmap.yaml
使用 kubectl 命令行工具验证是否已正确部署代理。
验证是否已在 Linux 节点池上正确部署 DaemonSet
kubectl get ds ama-metrics-node --namespace=kube-system
Pod 数应等于群集上的 Linux 节点数。 输出应与下面的示例类似：
User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-metrics-node 1 1 1 1 1 <none> 10h
验证是否已正确部署 Windows 节点
kubectl get ds ama-metrics-win-node --namespace=kube-system
Pod 数应等于群集上的 Windows 节点数。 输出应与下面的示例类似：
User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-metrics-win-node 3 3 3 3 3 <none> 10h
验证是否为 Prometheus 部署了两个 ReplicaSet
kubectl get rs --namespace=kube-system
输出应与下面的示例类似：
User@aksuser:~$kubectl get rs --namespace=kube-system
NAME DESIRED CURRENT READY AGE
ama-metrics-5c974985b8 1 1 1 11h
ama-metrics-ksm-5fcf8dffcd 1 1 1 11h
验证是否已在 Linux 节点池上正确部署 DaemonSet
kubectl get ds ama-logs --namespace=kube-system
Pod 数应等于群集上的 Linux 节点数。 输出应与下面的示例类似：
User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-logs 2 2 2 2 2 <none> 1d
验证是否已正确部署 Windows 节点
kubectl get ds ama-logs-windows --namespace=kube-system
Pod 数应等于群集上的 Windows 节点数。 输出应与下面的示例类似：
User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-logs-windows 2 2 2 2 2 <none> 1d
验证容器见解解决方案的部署
kubectl get deployment ama-logs-rs --namespace=kube-system
输出应与下面的示例类似：
User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
ama-logs-rs 1/1 1 1 24d
使用 CLI 查看配置
使用 aks show 命令查看是否已启用解决方案，并查看 Log Analytics 工作区资源 ID 以及有关群集的摘要信息。
az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>
该命令将会返回有关解决方案的 JSON 格式信息。
addonProfiles 部分应包括有关 omsagent 的信息，如下例所示：
"addonProfiles": {
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"useAADAuth": "true"
},
"enabled": true,
"identity": null
},
}
启用监视时，会在你的订阅中创建以下资源：
| 资源名称 | 资源类型 | 资源组 | 区域/位置 | 说明 |
|---|---|---|---|---|
MSCI-<aksclusterregion>-<clustername> |
数据收集规则 | 与群集相同 | 与 Log Analytics 工作区相同 | 此数据收集规则适用于 Azure Monitor 代理的日志收集，该代理使用 Log Analytics 工作区作为目标，并关联到 AKS 群集资源。 |
MSPROM-<aksclusterregion>-<clustername> |
数据收集规则 | 与群集相同 | 与 Azure Monitor 工作区相同 | 此数据收集规则适用于指标加载项执行的 prometheus 指标收集，其目标位置为选定的 Azure Monitor 工作区，且与 AKS 群集资源相关联 |
MSPROM-<aksclusterregion>-<clustername> |
数据收集终结点 | 与群集相同 | 与 Azure Monitor 工作区相同 | 上述数据收集规则利用这个数据收集终端来从指标插件中引入 Prometheus 指标。 |
新建 Azure Monitor 工作区时，会创建以下附加资源作为工作区的一部分
| 资源名称 | 资源类型 | 资源组 | 区域/位置 | 说明 |
|---|---|---|---|---|
<azuremonitor-workspace-name> |
数据收集规则 | <MA_azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed | 与 Azure Monitor 工作区相同 | 使用 OSS Prometheus 服务器远程写入 Azure Monitor 工作区时创建的 DCR。 |
<azuremonitor-workspace-name> |
数据收集终结点 | <MA_azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed | 与 Azure Monitor 工作区相同 | 使用 OSS Prometheus 服务器远程写入 Azure Monitor 工作区时创建的 DCE。 |
监视 Windows Server 群集与监视 Linux 群集相比，主要差异包括：
- Windows 没有内存 RSS 指标。 因此它不适用于 Windows 节点和容器。 工作集指标已可用。
- 磁盘存储容量信息不适用于 Windows 节点。
- 仅监视 Pod 环境，不监视 Docker 环境。
- 使用预览版时，最多支持 30 个 Windows Server 容器。 此限制不适用于 Linux 容器。
备注
适用于 Windows Server 2022 操作系统的容器见解功能目前为预览版。
容器化 Linux 代理 (replicaset pod) 向群集内 Kubelet 安全端口 (10250) 上的所有 Windows 节点进行 API 调用，以收集与节点和容器性能相关的指标。 应在群集的虚拟网络中针对入站和出站打开 Kubelet 安全端口 (:10250)，以便正常收集 Windows 节点和容器性能相关指标。
如果你有一个包含 Windows 节点的 Kubernetes 群集，请查看并配置网络安全组和网络策略，确保在群集的虚拟网络中针对入站和出站打开 Kubelet 安全端口 (:10250)。