容器深入解析中的多租用戶受控記錄 (預覽)

2025-04-23

容器深入解析中的多租用戶記錄對於使用 AKS 操作共用叢集平台的客戶很有用。您可能需要具備設定容器控制台記錄收集的能力，以便將記錄按不同小組隔離，使每個小組都能存取其擁有的 K8s 命名空間中運行的容器記錄，並有能力存取與 Azure Log Analytics 工作區相關聯的計費和管理。例如，來自 kube-system 等基礎結構命名空間的容器記錄可以導向至基礎結構小組的特定 Log Analytics 工作區，而每個應用程式小組的容器記錄都可以傳送至其各自的工作區。

本文說明多租戶日誌記錄在容器深入解析中的運作方式、可支援的情境，以及如何將叢集上線以使用此功能。

案例

Container Insights 中的多租戶記錄功能支援以下情境：

多租用戶。 將容器記錄（stdout 和 stderr）從一或多個 K8s 命名空間傳送至對應的 Log Analytics 工作區。
多路連接： 將同一組容器記錄（stdout 和 stderr）從一或多個 K8s 命名空間傳送至多個 Log Analytics 工作區。

運作方式

容器深入解析會使用資料收集規則（DCR）來定義 AKS 叢集的數據收集設定。當您啟用容器深入解析時，會自動建立預設 ContainerInsights 延伸模組 DCR。此 DCR 是單一的，這表示每個 Kubernetes 叢集都有一個 DCR。

針對多租戶記錄，Container Insights 新增對 ContainerLogV2Extension 資料收集規則 (DCR) 的支援，用來定義 K8s 命名空間的容器記錄集合。您可以使用不同命名空間的不同設定建立多個 ContainerLogV2Extension DCR，並與相同的 AKS 叢集相關聯。

當您透過 ConfigMap 啟用多租使用者功能時，Container Insights 代理程式會定期擷取預設 ContainerInsights 擴充功能 DCR 和與 AKS 叢集相關聯的 ContainerLogV2Extension DCR。此擷取會在容器啟動時每隔 5 分鐘執行一次。如果新增了任何其他 ContainerLogV2Extension DCR，則下次執行提取時，將會辨識它們。除了容器記錄之外，預設 DCR 中所有已設定的數據流仍會如往常一樣傳送至預設 ContainerInsights DCR 中的 Log Analytics 工作區。

用以下邏輯流程來判斷如何處理每個日誌項目：

如果記錄專案的命名空間有 ContainerLogV2Extension DCR，則會使用該 DCR 來處理專案。這包括 Log Analytics 工作區目的地和任何擷取時間轉換。
如果記錄專案的命名空間沒有 ContainerLogV2Extension DCR，則會使用預設 ContainerInsights DCR 來處理專案。

局限性

請參閱 Container Insights 中高規模記錄收集的限制。
每個叢集最多支援 30 個 ContainerLogV2Extension DCR 關聯。

先決條件

您必須使用容器深入解析中的大規模記錄收集 (預覽) 的指引，為叢集設定大規模記錄模式。
資料收集端點 (DCE) 會為每個應用程式或基礎結構小組建立 DCR。每個 DCE 的記錄擷取端點必須在防火牆中設定，如 Container Insights 中大規模記錄收集的網路防火牆需求中所述。

為叢集啟用多租用戶

請遵循設定及部署 ConfigMap 中的指導，下載並更新叢集的 ConfigMap。
變更 enabled 底下的 agent_settings.high_log_scale 設定，以啟用大規模模式，如下所示。
```
agent-settings: |-
    [agent_settings.high_log_scale]
        enabled = true
```

變更 enabled 下的 log_collection_settings.multi_tenancy 設定以啟用多租用戶，如下所示。

log-data-collection-settings: |-
    [log_collection_settings]
       [log_collection_settings.multi_tenancy]
        enabled = true

使用下列命令將 ConfigMap 套用至叢集。

kubectl config set-context <cluster-name>
kubectl apply -f <configmap_yaml_file.yaml>

為每個應用程式或基礎結構小組建立 DCR

重複下列步驟，為每個應用程式或基礎結構小組建立個別的 DCR。每個命名空間都會包含一組 K8s 命名空間和 Log Analytics 工作區目的地。

小提示

針對多路連接，請為每個 Log Analytics 工作區部署個別的 DCR 範本和參數檔案，並包含相同的一組 K8s 命名空間。這可讓相同的記錄傳送至多個工作區。例如，如果您想要將 app-team-1、app-team-2 的記錄傳送至 LAW1 和 LAW2，

建立 DCR1，在 app-team-1 和 app-team-2 命名空間中包含 LAW1
建立 DCR2，並將 LAW2 包含在 app-team-1 和 app-team-2 命名空間中

擷取下列ARM樣本和參數檔案。

範本：https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-file
參數：https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-parameter-file

使用下列值編輯參數檔案。

參數名稱	說明
`aksResourceId`	AKS 叢集的 Azure 資源識別碼
`aksResourceLocation`	AKS 叢集的 Azure 區域
`workspaceResourceId`	Log Analytics 工作區的 Azure 資源識別碼
`workspaceRegion`	Log Analytics 工作區的 Azure 區域
`K8sNamespaces`	要傳送至此參數檔案中定義的 Log Analytics 工作區記錄的 K8s 命名空間的清單。
`resourceTagValues`	在 AKS、資料收集規則（DCR）和資料收集端點（DCE）上使用的 Azure 資源標記。
`transformKql`	使用擷取時間轉換進行進階篩選的 KQL 篩選。例如，若要排除特定 Pod 的記錄，請使用 `source \\| where PodName != '<podName>'`。如需詳細資訊，請參閱 Azure 監視器中的轉換。
`useAzureMonitorPrivateLinkScope`	指出是否要設定 Azure 監視器 Private Link 範圍。
`azureMonitorPrivateLinkScopeResourceId`	Azure 監視器 Private Link 範圍的 Azure 資源識別碼。

使用參數檔案搭配下列命令來部署範本。

az deployment group create --name AzureMonitorDeployment --resource-group <aksClusterResourceGroup> --template-file existingClusterOnboarding.json --parameters existingClusterParam.json

停用多租用戶記錄

備註

如果您想要完全停用叢集的容器深入解析，請參閱停用 Kubernetes 叢集的監視。

使用下列步驟來停用叢集上的多租用戶記錄。

使用下列命令來列出叢集的所有 DCR 關聯。

az monitor data-collection rule association list-by-resource --resource /subscriptions/<subId>/resourcegroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>

使用下列命令刪除 ContainerLogV2 擴充功能的所有 DCR 關聯。

az monitor data-collection rule association delete --association-name <ContainerLogV2ExtensionDCRA> --resource /subscriptions/<subId>/resourcegroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>

刪除 ContainerLogV2Extension DCR。

az monitor data-collection rule delete --name <ContainerLogV2Extension DCR> --resource-group <rgName>

編輯 container-azm-ms-agentconfig ，並將底下的 enabled 值[log_collection_settings.multi_tenancy]從 true 變更為 false。
```
kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml
```

故障排除

執行下列步驟，以針對容器深入解析中的多租用戶記錄問題進行疑難排解。

確認叢集已啟用高規模記錄。

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # get the logs one of the ama-logs daemonset pod and check for log message indicating high scale enabled
  kubectl logs ama-logs-xxxxx -n kube-system -c ama-logs | grep high
  # output should be something like
   "Using config map value: enabled = true for high log scale config"

確認已針對叢集啟用 ContainerLogV2 架構。

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check if the containerlog v2 schema enabled or not
  env | grep AZMON_CONTAINER_LOG_SCHEMA_VERSION
  # output should be v2. If not v2, then check whether this is being enabled through DCR
  AZMON_CONTAINER_LOG_SCHEMA_VERSION=v2
  # check if its enabled through DCR
  grep -r "enableContainerLogV2" /etc/mdsd.d/config-cache/configchunks/
  # validate the enableContainerLogV2 configured with true or not from JSON output

驗證已為叢集啟用多租用戶。

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # get the logs one of the ama-logs daemonset pod and check for log message indicating high scale enabled
  kubectl logs ama-logs-xxxxx -n kube-system -c ama-logs | grep multi_tenancy
  # output should be something like
  "config::INFO: Using config map setting multi_tenancy enabled: true, advanced_mode_enabled: false and namespaces: [] for Multitenancy log collection"

確認已建立與 ContainerInsightsExtension 和 ContainerLogV2Extension 相關的 DCR 和 DCE。

    az account set -s <clustersubscriptionId>
    az monitor data-collection rule association list-by-resource --resource "<clusterResourceId>"
    # output should list both ContainerInsightsExtension and ContainerLogV2Extension DCRs associated to the cluster
    # From the output, for each dataCollectionRuleId and check dataCollectionEndpoint associated or not
    az monitor data-collection rule show --ids <dataCollectionRuleId>
    # you can also check the extension settings for the K8s namespace configuration

確認代理程式正在下載所有相關聯的 DCR。

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check if its enabled through DCR
  grep -r "ContainerLogV2Extension" /etc/mdsd.d/config-cache/configchunks
  # output should list all the associated DCRs and configuration
  # if there are no DCRs downloaded then likely Agent has issues to pull associate DCRs and this could be missing network or firewall issue and check for errors in mdsd.err log file
  cat /var/opt/microsoft/linuxmonagent/log/mdsd.err

檢查 fluent-bit-out-oms-runtime.log 檔案中是否有任何錯誤

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check for errors
  cat /var/opt/microsoft/docker-cimprov/log/fluent-bit-out-oms-runtime.log

後續步驟

深入了解容器深入解析。

共用方式為