Azure

Azure - 다중 네임스페이스 로그 관리 with LAW

rygus 2025. 12. 29. 15:30
728x90

안녕하세요.

오늘은 AKS 네임스페이스별 로그를 각 Log Analytics Workspace에 저장해 보겠습니다. 

 

 

Azure Monitor Private Scope(AMPLS) : Azure Monitor 리소스에 프라이빗 엔드포인트를 사용하여 Azure PaaS(Platform as a Service) 리소스를 가상 네트워크에 안전하게 연결할 수 있는 서비스로 공용 네트워크를 거치지 않고 Azure 백본망을 통해 통신됩니다.

 

Data Collection Endpoint(DCE) : DCE는 관문 또는 진입점과 같습니다. 리소스가 DCR에서 처리되기 전에 데이터를 전송하는 보안 주소입니다.

 

데이터 수집 규칙(DCR) : DCR은 Azure에 어떤 종류의 데이터를 수집할지, 어디에서 수집할지, 필요한 경우 어떻게 변환할지, 그리고 어디로 보낼지를 알려주는 일련의 지침입니다.

 

Log Analytics Workspace(LAW) : LAW는 모든 Azure 및 비 Azure 리소스와 애플리케이션에서 모든 형식의 로그 데이터를 수집할 수 있는 데이터 저장소입니다.

 

즉, 이 아키텍처는 DCR에서 네임스페이스별 로그 수집 및 대상(Log Analytics Workspace)을 정의하고, AMPLS를 통해 프라이빗하게 DCE로 데이터를 전달하여 최종적으로 Log Analytics Workspace에 로그를 저장하는 구조입니다.

 

배포

이제 직접 배포해보겠습니다. 

먼저 VNET은 각자 상황에 맞게 배포해 주세요. 

 

AKS

먼저 Azure CLI를 통해 AKS를 배포하겠습니다.

프라이빗 클러스터 생성합니다. 

# AKS 변수
SUBCRIPTION_ID='<SUB-ID>'
LOCATION='koreacentral'
AKS_RGNAME='<resourcegroup>'
AKS_CLUSTERNAME='<AKS-Name>'
VMSET_TYPE='VirtualMachineScaleSets'
SYSTEMPOOLNAME='systempool'
SYSTEMNODECOUNT='1'
SYSTEMNODE_SIZE='Standard_D2ds_v5'
OSDISK_SIZE='150'
OSDISK_TYPE='Managed'
NETWORK_PLUGIN='azure'
NETWORK_PLUGINMODE='overlay'
NETWORK_POLICY='azure'
NETWORK_DATAPLANE='azure'
SUBNET_ID='<subnet_id>'
OUTBOUND_TYPE='loadBalancer'
LOADBALANCER_SKU='Standard'
KUBENETESVERSION='1.33.5'
SERVICE_CIDR='172.29.0.0/16'
DNS_SERVICE_IP='172.29.0.10'
DNS_NAME_PREFIX='aks-test'
MC_RESOURCEGROUP='MC-aks-test'

# AKS 생성
az aks create \
  --subscription ${SUBCRIPTION_ID} \
  --location ${LOCATION} \
  --resource-group ${AKS_RGNAME} \
  --name ${AKS_CLUSTERNAME} \
  --vm-set-type ${VMSET_TYPE} \
  --nodepool-name ${SYSTEMPOOLNAME} \
  --node-count ${SYSTEMNODECOUNT} \
  --node-osdisk-size ${OSDISK_SIZE} \
  --node-osdisk-type ${OSDISK_TYPE} \
  --network-plugin ${NETWORK_PLUGIN} \
  --network-plugin-mode ${NETWORK_PLUGINMODE} \
  --network-policy ${NETWORK_POLICY} \
  --network-dataplane ${NETWORK_DATAPLANE} \
  --vnet-subnet-id ${SUBNET_ID} \
  --outbound-type ${OUTBOUND_TYPE} \
  --load-balancer-sku ${LOADBALANCER_SKU} \
  --node-vm-size ${SYSTEMNODE_SIZE} \
  --zones {1,2,3} \
  --kubernetes-version ${KUBENETESVERSION} \
  --service-cidr ${SERVICE_CIDR} \
  --dns-service-ip ${DNS_SERVICE_IP} \
  --dns-name-prefix ${DNS_NAME_PREFIX} \
  --node-resource-group ${MC_RESOURCEGROUP} \
  --enable-private-cluster \
  --generate-ssh-keys

 

 

Log Analytics Workspace

다음은 Log Analytics Workspace(LAW) 를 생성하는 방법입니다.
Azure CLI를 사용하여 LAW를 생성합니다.

LAW는 네임스페이스의 로그 수집을 위한 용도로 사용됩니다.

 

LOCATION='koreacentral'
LAW_RGNAME='<resourcegroup>'
LAW_NAME='<LAW_NAME>'

az monitor log-analytics workspace create \
  --resource-group $LAW_RGNAME \
  --workspace-name $LAW_NAME \
  --location $LOCATION \
  --sku PerGB2018 \
  --retention-time 30

 

AMPLS

AMPLS는 포탈에서 생성해주겠습니다. 

Azure 포탈에서 'Azure Monitor Pirvate Link Scopes' 를 검색 후 만들기를 클릭합니다.

 

저희는 프라이빗 전용으로 사용할 것이기 때문에 각 모드를 '프라이빗 전용'으로 한 뒤 생성합니다. 

 

프라이빗 통신을 위해서 생성된 AMPLS에 프라이빗 엔드포인트를 연결하겠습니다. 

 

기본적인 리소스 그룹 및 이름을 설정하고 다음으로 넘아갑니다.

 

다음은 리소스를 지정하겠습니다. 

리소스 종류에서 'Microsoft.Insights/privateLinkScopes' 를 선택합니다.

 

사전에 생성한 Vnet 및 Subnet을 선택합니다.

 

DNS도 처음 나오는 설정에서 건드리지 말고 바로 생성합니다.

 

이제 다음 다음으로 넘어가 바로 생성합니다.

 

DCE, DCR

이제 DCR과 DCE를 생성합니다.

네임스페이스별 로그 수집을 구성하려면 ContainerLogV2Extension을 사용하는 DCR이 필요하므로, 이를 포함한 템플릿을 기반으로 리소스를 생성합니다.

k8sNamespaces에 배포할 네임스페이스도 지정해야합니다. 

저는 "ns-a"로 생성하겠습니다. 

즉, ns-a에 배포된 파드들의 로그만 쌓게 됩니다.

만약 다른 네임스페이스도 필요하면 dcr이 하나 더 필요하게 됩니다.

# json 파일
wget -O template.json https://raw.githubusercontent.com/microsoft/Docker-Provider/ci_prod/scripts/onboarding/aks/multi-tenancy/existingClusterOnboarding.json

# 변수 설정
RESOURCE_GROUP='<resourcegroup>'
AKS_ID='<AKS-ID>'
WORKSPACE_ID='<Workspace-ID>'
LOCATION='koreacentral'
AMPLS_ID='<AMPLS-ID>'

# 배포 실행
az deployment group create \
  --resource-group $RESOURCE_GROUP \
  --template-file template.json \
  --parameters \
    aksResourceId="$AKS_ID" \
    aksResourceLocation="$LOCATION" \
    workspaceRegion="$LOCATION" \
    workspaceResourceId="$WORKSPACE_ID" \
    k8sNamespaces='["ns-a"]' \
    transformKql="" \
    useAzureMonitorPrivateLinkScope=false \
    azureMonitorPrivateLinkScopeResourceId="$AMPLS_ID" \
    resourceTagValues='{"Environment":"Prod", "Team":"DevOps"}'

 

이제 포탈에서 DCR을 확인하면 MSCI-multi-tenancy 명으로 생성되어 있는 것을 확인 가능합니다.

여기서 AKS에 DCE를 할당해주어야하는데요. 

아래 사진과 같이 DCE를 할당해줍니다.

 

이제 프라이빗한 통신을 위해서 다시 AMPLS로 돌아와 리소스로 아까 생성한 DCE를 연결해줍니다. 

 

Configmap

이제 AKS(Container Insights / Azure Monitor Agent) 환경에서 “다중 테넌트 로그 수집(Multi-tenancy Logging)”을 활성화하기 위한 ConfigMap을 배포하겠습니다. 

ConfigMap을 배포해야 AMA에서 정상적으로 고성능 로그 처리 모드(High Log Scale) 로 동작되고 다중 DCR을 허용하는 multi-tenancy 모드가 활성화되기 때문입니다.

 

아래 명령어를 통해서 configmap yaml 파일을 받아온 뒤 vim으로 수정해 주겠습니다. 

wget -O config.yml https://raw.githubusercontent.com/microsoft/Docker-Provider/ci_prod/kubernetes/container-azm-ms-agentconfig.yaml

 

 

agent_settings.high_log_scale 부분을 찾아 "true" 로 변경합니다. 

 

log_collection_settings.multi_tenancy 부분을 찾아 "true"로 변경합니다.

 

이제 저장 후 배포하겠습니다. 

 

Azure Monitor Agent

이제 거의 다 왔습니다. 

이제 AKS 내부에서 로그를 수집할 녀석을 배포해주어야 하는데요.

바로 Azure Monitor Agent 줄여서 AMA입니다. 

AKS_RGNAME='<resourcegroup>'
AKS_CLUSTERNAME='<AKS-Name>'
AMPLS_ID='<AMPLS_ID>'

az aks enable-addons -a monitoring \
-g "$AKS_RGNAME" \
-n "$AKS_CLUSTERNAME" \
--enable-high-log-scale-mode \
--ampls-resource-id $AMPLS_ID

 

Pod 및 리소스 배포

이제 정상적으로 테스트가 되는지 확인하기 위해 네임스페이스와 테스트용 파드를 생성하겠습니다. 

 

# 네임스페이스 생성
kubectl create ns ns-a
kubectl create ns ns-b

# 로그용 파드 생성
kubectl run pod-a -n ns-a --image=busybox -- sh -c "while true; do echo 'AAAA' ; sleep 5 ; done ;"
kubectl run pod-a -n ns-b --image=busybox -- sh -c "while true; do echo 'BBBB' ; sleep 5 ; done ;"

 

저희는 네임스페이스 ns-a 에 대한 DCR만 생성해 주었기 때문에 LAW에 ns-a에 대한 로그만 있으면 정상적으로 배포가 된 것입니다. 

확인해 보겠습니다. 

 

 

정상적으로 a 파드 내용만 로그가 쌓여 있는 것을 확인 가능합니다. 

 

*참고

https://learn.microsoft.com/ko-kr/azure/azure-monitor/containers/container-insights-multitenant?utm_source=chatgpt.com&tabs=arm

 

컨테이너 인사이트에서 다중 테넌트 관리 로깅 - Azure Monitor

컨테이너 인사이트에서 다중 테넌트 로깅에 대한 개념 및 온보딩 단계입니다.

learn.microsoft.com

https://www.linkedin.com/posts/cjcheema_azure-azuremonitor-cloudcomputing-activity-7375633527817666560-BnfC

 

Azure DCR vs DCE: Understanding the Basics | Charanjit Singh Cheema님이 토픽에 대해 올림 | LinkedIn

🤔 Understanding the Difference Between Azure DCR and DCE: When working with Azure Monitor and Log Analytics, you may often hear about DCR (Data Collection Rules) and DCE (Data Collection Endpoints). Both are part of Microsoft’s new data collection pip

www.linkedin.com

 

감사합니다.