컨테이너 인사이트의 다중 테넌트 관리 로깅(미리 보기)

컨테이너 인사이트의 다중 테넌트 로깅은 AKS를 사용하여 공유 클러스터 플랫폼을 운영하는 고객에게 유용합니다. 각각이 소유한 K8s 네임스페이스에서 실행되는 컨테이너의 컨테이너 로그에 액세스하고 Azure Log Analytics 작업 영역과 연결된 청구 및 관리에 액세스할 수 있도록 서로 다른 팀별로 로그를 분리하는 방식으로 컨테이너 콘솔 로그 수집을 구성하는 기능이 필요할 수 있습니다. 예를 들어 kube-system과 같은 인프라 네임스페이스의 컨테이너 로그는 인프라 팀의 특정 Log Analytics 작업 영역으로 전달될 수 있지만 각 애플리케이션 팀의 컨테이너 로그는 해당 작업 영역으로 보낼 수 있습니다.

이 문서에서는 컨테이너 인사이트에서 다중 테넌트 로깅이 작동하는 방식, 지원하는 시나리오 및 이 기능을 사용하기 위해 클러스터를 온보딩하는 방법을 설명합니다.

시나리오

Container Insights의 다중 테넌트 로깅 기능은 다음 시나리오를 지원합니다.

• 다중 테넌시. 하나 이상의 K8s 네임스페이스에서 해당 Log Analytics 작업 영역으로 컨테이너 로그(stdout 및 stderr)를 보냅니다.

  

• 멀티호밍: 하나 이상의 K8s 네임스페이스에서 여러 Log Analytics 작업 영역으로 동일한 컨테이너 로그 집합(stdout 및 stderr)을 보냅니다.

  

작동 방식

컨테이너 인사이트는 DCR(데이터 수집 규칙) 을 사용하여 AKS 클러스터에 대한 데이터 수집 설정을 정의합니다. 컨테이너 인사이트를 사용하도록 설정하면 기본 ContainerInsights 확장 DCR이 자동으로 만들어집니다. 이 DCR은 Kubernetes 클러스터당 하나의 DCR이 있음을 의미하는 싱글톤입니다.

다중 테넌트 로깅의 경우 Container Insights는 K8s 네임스페이스에 대한 컨테이너 로그 컬렉션을 정의하는 데 사용되는 ContainerLogV2Extension DCR에 대한 지원을 추가합니다. 여러 ContainerLogV2Extension DCR은 서로 다른 네임스페이스에 대한 다른 설정과 동일한 AKS 클러스터와 연결된 모든 설정을 사용하여 만들 수 있습니다.

ConfigMap을 통해 다중 테넌트 기능을 사용하도록 설정하면 Container Insights 에이전트는 AKS 클러스터와 연결된 기본 ContainerInsights 확장 DCR 및 ContainerLogV2Extension DCR을 주기적으로 가져옵니다. 이 인출은 컨테이너가 시작될 때 5분마다 수행됩니다. 추가 ContainerLogV2Extension DCR이 추가되면 다음에 인출이 수행될 때 인식됩니다. 컨테이너 로그를 제외한 기본 DCR의 구성된 모든 스트림은 평소와 같이 기본 ContainerInsights DCR의 Log Analytics 작업 영역으로 계속 전송됩니다.

다음 논리는 각 로그 항목을 처리하는 방법을 결정하는 데 사용됩니다.

• 로그 항목의 네임스페이스에 대한 ContainerLogV2Extension DCR이 있는 경우 해당 DCR은 항목을 처리하는 데 사용됩니다. 여기에는 Log Analytics 작업 영역 대상과 모든 수집 시간 변환이 포함됩니다.
• 로그 항목의 네임스페이스에 대한 ContainerLogV2Extension DCR이 없는 경우 기본 ContainerInsights DCR을 사용하여 항목을 처리합니다. 아래의 ConfigMap 항목을 disable_fallback_ingestion = false 사용하여 기본 DCR 수집을 사용하지 않도록 설정할 수 있습니다 [log_collection_settings.multi_tenancy].

제한점

• Container Insights에서 대규모 로그 컬렉션에 대한 제한 사항을 참조하세요.
• 클러스터당 최대 30개의 ContainerLogV2Extension DCR 연결이 지원됩니다.

필수 조건

• Container Insights의 대규모 로그 컬렉션에 대한 지침을 사용하여 클러스터에 대해 높은 로그 확장 모드를 구성해야 합니다.
• 각 애플리케이션 또는 인프라 팀에 대한 DCR을 사용하여 DCE(데이터 수집 엔드포인트)를 만듭니다. 각 DCE의 로그 수집 엔드포인트는 Container Insights의 대규모 로그 수집에 대한 네트워크 방화벽 요구 사항에 설명된 대로 방화벽에서 구성해야 합니다.

클러스터에 대한 다중 테넌트 사용

1. ConfigMap 구성 및 배포의 지침에 따라 클러스터에 대한 ConfigMap을 다운로드하고 업데이트합니다.

2. enabled에서 agent_settings.high_log_scale 설정을 다음과 같이 변경하여 대규모 모드를 활성화하십시오.

   agent-settings: |-
       [agent_settings.high_log_scale]
           enabled = true
   

3. 다음과 같이 enabled에서 log_collection_settings.multi_tenancy 설정을 변경하여 다중 테넌시를 활성화합니다.

   log-data-collection-settings: |-
       [log_collection_settings]
          [log_collection_settings.multi_tenancy]
           enabled = true 
           disable_fallback_ingestion = false # If enabled, logs of the k8s namespaces for which ContainerLogV2Extension DCR is not configured will not be ingested to the default DCR.
   
   

4. 다음 명령을 사용하여 ConfigMap을 클러스터에 적용합니다.

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

각 애플리케이션 또는 인프라 팀에 대한 DCR 만들기

다음 섹션에서는 각 애플리케이션 또는 인프라 팀에 대해 별도의 DCR을 만드는 다양한 방법에 대해 자세히 설명합니다. 각각에는 K8s 네임스페이스 집합과 Log Analytics 작업 영역 대상이 포함됩니다.

아래 각 메서드는 다음 표에서 동일한 매개 변수를 사용합니다.

다중 테넌트 로깅 사용 안 함

다음 단계를 사용하여 클러스터에서 다중 테넌트 로깅을 사용하지 않도록 설정합니다.

1. 다음 명령을 사용하여 클러스터에 대한 모든 DCR 연결을 나열합니다.

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

2. 다음 명령을 사용하여 ContainerLogV2 확장에 대한 모든 DCR 연결을 삭제합니다.

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

3. ContainerLogV2Extension DCR을 삭제합니다.

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

4. container-azm-ms-agentconfig를 편집하고 enabled 아래의 [log_collection_settings.multi_tenancy] 값을 true에서 false로 변경합니다.

   kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml
   

문제 해결

컨테이너 인사이트에서 다중 테넌트 로깅 문제를 해결하려면 다음 단계를 수행합니다.

1. 클러스터에 대해 대규모 로깅 이 사용하도록 설정되어 있는지 확인합니다.

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

2. 클러스터에 대해 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
   

3. 클러스터에 대해 다중 테넌시가 사용하도록 설정되어 있는지 확인합니다.

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

4. 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
   

5. 에이전트가 연결된 모든 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
   

6. 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
   

다음 단계

• 컨테이너 인사이트에 대해 자세히 알아보세요.