Registro administrado multiinquilino en Container Insights (versión preliminar)

2025-04-24

El registro multicliente en Container Insights es útil para los clientes que gestionan plataformas compartidas de clústeres con AKS. Es posible que necesite la capacidad de configurar la recopilación de registros de la consola de contenedor de manera que separe los registros de los diferentes equipos para que cada uno tenga acceso a los registros de los contenedores que se ejecutan en los espacios de nombres K8s que poseen y la capacidad de acceder a la facturación y la administración asociados al área de trabajo de Azure Log Analytics. Por ejemplo, los registros de contenedor de los espacios de nombres de la infraestructura, como kube-system, se pueden dirigir a un área de trabajo de Log Analytics específica del equipo de infraestructura, mientras que los registros de contenedor de cada equipo de la aplicación se pueden enviar a sus respectivas áreas de trabajo.

En este artículo se describe cómo funciona el registro multiinquilino en Container Insights, los escenarios que admite y cómo incorporar el clúster para usar esta característica.

Escenarios

La función de registro en un entorno multiinquilino de Container Insights admite los siguientes escenarios:

Multiinquilinato. Envía registros de contenedor (stdout & stderr) desde uno o varios espacios de nombres K8s al área de trabajo de Log Analytics correspondiente.
Hospedaje múltiple: Envía el mismo conjunto de registros de contenedor (stdout & stderr) desde uno o varios espacios de nombres K8s a varias áreas de trabajo de Log Analytics.

Cómo funciona

Container Insights usa una regla de recopilación de datos (DCR) para definir la configuración de recopilación de datos para el clúster de AKS. Al habilitar Container insights, se crea automáticamente un DCR de extensión ContainerInsights predeterminado. Este DCR es un singleton, lo que significa que hay un DCR por clúster de Kubernetes.

Para el registro multiinquilino, Container Insights agrega compatibilidad con las DCR ContainerLogV2Extension, las cuales se usan para definir la recopilación de registros de contenedor de los espacios de nombre K8s. Se pueden crear múltiples ContainerLogV2Extension DCR con diferentes configuraciones para distintos espacios de nombres y todos asociados al mismo clúster de AKS.

Cuando habilitas la funcionalidad de multitenencia a través de un ConfigMap, el agente de Container Insights obtiene periódicamente tanto las DCR de la extensión ContainerInsights predeterminada como las DCR ContainerLogV2Extension asociadas al clúster AKS. Esta recuperación se realiza cada 5 minutos a partir del momento en que se inicia el contenedor. Si se agregan DCR ContainerLogV2Extension adicionales, se reconocerán la próxima vez que se realice la recuperación de cambios. Todos los flujos configurados en el DCR predeterminado, aparte de los registros de contenedor, se siguen enviando al área de trabajo de Log Analytics en el DCR de ContainerInsights predeterminado como de costumbre.

La siguiente lógica se usa para determinar cómo procesar cada entrada de registro:

Si hay una DCR ContainerLogV2Extension para el espacio de nombres de la entrada de registro, se usará esa DCR para procesar la entrada. Esto incluye el destino del espacio de trabajo de Log Analytics y cualquier transformación en el momento de la ingesta.
Si no hay una DCR ContainerLogV2Extension para el espacio de nombres de la entrada de registro, la DCR ContainerInsights predeterminada se usa para procesar la entrada.

Limitaciones

Consulte Limitaciones para la recopilación de registros a gran escala en Container Insights.
Se admite un máximo de 30 asociaciones de DCR ContainerLogV2Extension por clúster.

Prerrequisitos

El modo de registros de gran escala debe configurarse para el clúster mediante las directrices de la Recopilación de registros a gran escala en Container Insights (Versión preliminar).
Se crea un punto de conexión de recopilación de datos (DCE) con el DCR para cada aplicación o equipo de infraestructura. El punto de conexión de ingesta de registros de cada DCE debe configurarse en el firewall, tal como se describe en Requisitos de firewall de red para la recopilación de registros a gran escala en Container Insights.

Habilitar el multiinquilinato para el clúster

Siga las instrucciones de Configuración e implementación de ConfigMap para descargar y actualizar ConfigMap para el clúster.
Habilite el modo de escalado alto cambiando la configuración de enabled bajo agent_settings.high_log_scale de la siguiente manera.
```
agent-settings: |-
    [agent_settings.high_log_scale]
        enabled = true
```

Para habilitar el multiinquilinato, cambie la opción enabled de log_collection_settings.multi_tenancy de la siguiente manera.

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

Aplique ConfigMap al clúster con los siguientes comandos.

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

Creación de DCR para cada aplicación o equipo de infraestructura

Repita los pasos siguientes para crear un DCR independiente para cada aplicación o equipo de infraestructura. Cada uno incluirá un conjunto de espacios de nombres K8s y un destino de área de trabajo de Log Analytics.

Sugerencia

Para el hospedaje múltiple, implemente una plantilla de DCR independiente y un archivo de parámetros para cada área de trabajo de Log Analytics e incluya el mismo conjunto de espacios de nombres K8s. Esto permitirá enviar los mismos registros a varias áreas de trabajo. Por ejemplo, si desea enviar registros para app-team-1, app-team-2 a LAW1 y LAW2,

Cree DCR1 e incluya LAW1 para los espacios de nombres app-team-1 y app-team-2
Cree DCR2 e incluya LAW2 para los espacios de nombres app-team-1 y app-team-2

Recupere la siguiente plantilla de ARM y el archivo de parámetros.

Plantilla: https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-file
Parámetro: https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-parameter-file

Edite el archivo de parámetros con valores para los valores siguientes.

Nombre de parámetro	Descripción
`aksResourceId`	Identificador de recurso de Azure del clúster de AKS
`aksResourceLocation`	Región de Azure del clúster de AKS
`workspaceResourceId`	Identificador de recurso de Azure del área de trabajo de Log Analytics
`workspaceRegion`	Región de Azure del área de trabajo de Log Analytics
`K8sNamespaces`	Lista de espacios de nombres K8s para enviar los registros al área de trabajo de Log Analytics definida en este archivo de parámetros.
`resourceTagValues`	Etiquetas de recursos de Azure para usar en AKS, reglas de recopilación de datos (DCR) y puntos de conexión de recopilación de datos (DCE).
`transformKql`	Filtro KQL para el filtrado avanzado mediante la transformación en tiempo de ingesta. Por ejemplo, para excluir los registros de un pod específico, use `source \\| where PodName != '<podName>'`. Consulte Transformaciones en Azure Monitor para más información.
`useAzureMonitorPrivateLinkScope`	Indica si se va a configurar el ámbito de Private Link de Azure Monitor.
`azureMonitorPrivateLinkScopeResourceId`	Identificador de recurso del ámbito de Private Link de Azure Monitor.

Implemente la plantilla mediante el archivo de parámetros con el comando siguiente.

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

Deshabilitación del registro multiinquilino

Nota:

Consulte Deshabilitación de la supervisión del clúster de Kubernetes si desea deshabilitar completamente Container Insights para el clúster.

Siga estos pasos para deshabilitar el registro de múltiples inquilinos en un clúster.

Use el siguiente comando para enumerar todas las asociaciones dcR del clúster.

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

Use el siguiente comando para eliminar todas las asociaciones dcR de la extensión ContainerLogV2.

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

Elimine ContainerLogV2Extension DCR.

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

Edite container-azm-ms-agentconfig y cambie el valor de enabled en [log_collection_settings.multi_tenancy] de true a false.
```
kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml
```

Solución de problemas

Realice los pasos siguientes para solucionar problemas con el registro multiinquilino en Container Insights.

Compruebe que el registro de gran escala está habilitado para el clúster.

  # 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"

Compruebe que el esquema ContainerLogV2 está habilitado para el clúster.

  # 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

Compruebe que el multiinquilinato esté habilitado para el clúster.

  # 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"

Compruebe que se crean las DCR y los DCE relacionados con ContainerInsightsExtension y ContainerLogV2Extension.

    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

Compruebe que el agente está descargando todos los DCR asociados.

  # 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

Compruebe si hay algún error en fluent-bit-out-oms-runtime.log archivo

  # 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

Pasos siguientes

Obtenga más información sobre Container Insights.