Registrazione gestita multi-tenant in Informazioni dettagliate sui contenitori (anteprima)

2025-04-14

La registrazione multi-tenant in Informazioni dettagliate sui contenitori è utile per i clienti che gestiscono piattaforme cluster condivise utilizzando il servizio Azure Container. Potrebbe essere necessaria la possibilità di configurare la raccolta di log della console del contenitore in modo da separare i log da team diversi in modo che ognuno abbia accesso ai log dei contenitori in esecuzione negli spazi dei nomi K8s di cui sono proprietari e la possibilità di accedere alla fatturazione e alla gestione associata all'area di lavoro Log Analytics di Azure. Ad esempio, i log dei contenitori dagli spazi dei nomi dell'infrastruttura, ad esempio kube-system, possono essere indirizzati a un'area di lavoro Log Analytics specifica per il team dell'infrastruttura, mentre i log dei contenitori di ogni team di applicazioni possono essere inviati alle rispettive aree di lavoro.

Questo articolo descrive il funzionamento della registrazione multi-tenant in Informazioni dettagliate sui contenitori, gli scenari supportati e come eseguire l'onboarding del cluster per usare questa funzionalità.

Scenari

La funzionalità di registrazione multi-tenant in Informazioni dettagliate sui contenitori supporta gli scenari seguenti:

Multi-tenancy. Invia i log dei contenitori (stdout e stderr) da uno o più spazi dei nomi K8s all'area di lavoro Log Analytics corrispondente.
Multihoming: Invia lo stesso set di log dei contenitori (stdout e stderr) da uno o più namespace K8s a più aree di lavoro di Log Analytics.

Come funziona

Informazioni dettagliate contenitore usa una regola di raccolta dati (DCR) per definire le impostazioni di raccolta dati per il cluster del servizio Azure Kubernetes. Quando si abilitano i Container insights, viene creato automaticamente un ContainerInsights Extension DCR predefinito. Questo DCR è un singleton, il che significa che c'è un solo DCR per cluster di Kubernetes.

Per la registrazione multi-tenant, Informazioni dettagliate sui contenitori aggiunge il supporto per le richieste di modifica progettazione ContainerLogV2Extension, usate per definire la raccolta di log dei contenitori per gli spazi dei nomi K8s. È possibile creare più DCR ContainerLogV2Extension con impostazioni diverse per spazi dei nomi diversi e tutti associati allo stesso cluster del servizio Azure Kubernetes.

Quando si abilita la funzionalità multi-tenancy tramite un oggetto ConfigMap, l'agente di Container Insights recupera periodicamente sia il DCR dell'estensione predefinito ContainerInsights che i DCR dell'estensione ContainerLogV2Extension associati al cluster AKS. Questo recupero dei dati viene eseguito ogni 5 minuti a partire dall'avvio del contenitore. Se vengono aggiunti ulteriori richieste di modifica progettazione ContainerLogV2Extension, verranno riconosciute al successivo recupero dei dati. Tutti i flussi configurati nel registro di dominio predefinito a parte i log dei contenitori continuano a essere inviati all'area di lavoro Log Analytics nel record di dominio ContainerInsights predefinito come di consueto.

La seguente logica viene usata per determinare come elaborare ogni voce di log:

Se è presente un DCR ContainerLogV2Extension per lo spazio dei nomi della voce di log, tale DCR viene usato per elaborare la voce. Sono incluse la destinazione dell'area di lavoro Log Analytics e qualsiasi trasformazione durante l'ingestione.
Se non è presente un DCR ContainerLogV2Extension per lo spazio dei nomi della voce di log, per elaborare la voce viene utilizzato il DCR predefinito ContainerInsights.

Limitazioni

Consulta Limitazioni per la raccolta di log su larga scala in Container Insights.
Per ogni cluster sono supportate al massimo 30 associazioni ContainerLogV2Extension DCR.

Prerequisiti

La modalità a scalabilità elevata dei log deve essere configurata per il cluster usando le indicazioni riportate nella raccolta dei log su larga scala in Container Insights (anteprima).
Un endpoint di raccolta dati (DCE) viene creato con il DCR per ogni team dell'applicazione o dell'infrastruttura. L'endpoint di inserimento dei log di ogni controller di dominio deve essere configurato nel firewall, come descritto in Requisiti del firewall di rete per la raccolta di log su larga scala in Container Insights.

Abilitare il multi-tenancy per il cluster

Seguire le indicazioni in Configurare e distribuire ConfigMap per scaricare e aggiornare ConfigMap per il cluster.
Abilitare la modalità a scalabilità elevata modificando l'impostazione enabled in agent_settings.high_log_scale come indicato di seguito.
```
agent-settings: |-
    [agent_settings.high_log_scale]
        enabled = true
```

Abilitare la multi-tenancy modificando l'impostazione enabled in log_collection_settings.multi_tenancy come indicato di seguito.

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

Applicare ConfigMap al cluster con i comandi seguenti.

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

Creare una richiesta di modifica progettazione per ogni team dell'applicazione o dell'infrastruttura

Ripetere i passaggi seguenti per creare un controller di dominio separato per ogni team dell'applicazione o dell'infrastruttura. Ognuna includerà un set di spazi dei nomi K8s e una destinazione dell’area di lavoro Log Analytics.

Suggerimento

Per il multihoming, distribuire, per ogni area di lavoro Log Analytics, un modello DCR separato e un file di parametri e includere lo stesso set di namespace K8s. In questo modo gli stessi log verranno inviati a più aree di lavoro. Ad esempio, se si vogliono inviare log per app-team-1, app-team-2 a LAW1 e LAW2,

Creare DCR1 e includere LAW1 per i namespace app-team-1 e app-team-2
Creare DCR2 e includere LAW2 per i namespace app-team-1 e app-team-2

Recupera il seguente modello ARM e il file di parametri.

Modello: https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-file
Parametro: https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-parameter-file

Modificare il file di parametri con i valori seguenti.

Nome del parametro	Descrizione
`aksResourceId`	ID risorsa di Azure del cluster AKS
`aksResourceLocation`	Area di Azure del cluster AKS
`workspaceResourceId`	ID risorsa di Azure dell'area di lavoro Log Analytics
`workspaceRegion`	Area di Azure dell'area di lavoro Log Analytics
`K8sNamespaces`	Elenco dei namespace K8s per i log da inviare all'area di lavoro Log Analytics definita in questo file dei parametri.
`resourceTagValues`	Tag risorse di Azure da usare su AKS, regola di raccolta dati (DCR) ed endpoint di raccolta dati (DCE).
`transformKql`	Filtro KQL per il filtraggio avanzato tramite trasformazione al momento dell'inserimento. Ad esempio, per escludere i log per un pod specifico, usare `source \\| where PodName != '<podName>'`. Per informazioni dettagliate, vedere Trasformazioni in Monitoraggio di Azure .
`useAzureMonitorPrivateLinkScope`	Indica se configurare l’ambito collegamento privato di Monitoraggio di Azure.
`azureMonitorPrivateLinkScopeResourceId`	ID risorsa di Azure dell'ambito del collegamento privato di Monitoraggio di Azure.

Distribuire il modello usando il file di parametri con il comando seguente.

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

Disabilitazione della registrazione multi-tenant

Annotazioni

Consultare Disabilitare il monitoraggio del cluster Kubernetes se si desidera disabilitare completamente Informazioni dettagliate sui contenitori per il cluster.

Segui i passaggi seguenti per disabilitare il log multitenant in un cluster.

Usare il comando seguente per elencare tutte le associazioni DCR per il cluster.

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

Usare il comando seguente per eliminare tutte le associazioni DCR per l'estensione ContainerLogV2.

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

Eliminare la richiesta di modifica progettazione ContainerLogV2Extension.

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

Modificare container-azm-ms-agentconfig e modificare il valore per enabled under [log_collection_settings.multi_tenancy] da true a false.
```
kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml
```

Risoluzione dei problemi

Eseguire questa procedura per risolvere i problemi relativi alla registrazione multi-tenant in Informazioni dettagliate sui contenitori.

Verificare che la registrazione su larga scala sia abilitata per il cluster.

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

Verificare che lo schema ContainerLogV2 sia abilitato per il cluster.

  # 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

Verificare che il multi-tenancy sia abilitato per il cluster.

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

Verificare che i DCR e i DCE correlati a ContainerInsightsExtension e ContainerLogV2Extension siano stati creati.

    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

Verificare che l'agente stia scaricando tutti i DCR associati.

  # 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

Controllare se sono presenti errori nel file 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

Passaggi successivi

Altre informazioni su Informazioni dettagliate sui contenitori.