Azure Kubernetes Service의 자동 계측(미리 보기)

이 가이드에서는 소스 코드를 수정하지 않고 AKS(Azure Kubernetes Service) 워크로드에 대해 Azure Monitor Application Insights를 사용하도록 설정하는 단계를 안내합니다.

aks-preview Azure CLI 확장 설치, AzureMonitorAppMonitoringPreview 기능 플래그 등록, 클러스터 준비, 배포 온보딩 및 배포 다시 시작에 대해 설명합니다. 이러한 단계를 수행하면 자동 계측이 애플리케이션 Pod에 Azure Monitor OpenTelemetry Distro를 삽입하여 원격 분석을 생성합니다. 자동 계측 및 해당 이점에 대한 자세한 내용은 Azure Monitor Application Insights에 대한 자동 계측이란?을 참조하세요.

필수 조건

• Azure 퍼블릭 클라우드에서 Java 또는 Node.js 사용하여 kubernetes 배포를 실행하는 AKS 클러스터
• 작업 영역 기반 Application Insights 리소스입니다.
• Azure CLI 2.60.0 이상. 자세한 내용은 Azure CLI를 설치하는 방법, 설치된 Azure CLI 버전 및 Azure CLI를 업데이트하는 방법을 참조하세요.

aks-preview Azure CLI 확장 설치

확장을 설치합니다.aks-preview

az extension add --name aks-preview

최신 버전의 확장으로 업데이트합니다.

az extension update --name aks-preview

설치된 Azure CLI 버전이 필수 구성 요소 섹션의 요구 사항을 충족하는지 확인합니다.

az version

버전이 요구 사항을 충족하지 않는 경우 앞에서 설명한 단계에 따라 Azure CLI를 설치하고 업데이트합니다.

AzureMonitorAppMonitoringPreview 기능 플래그 등록

# Log into Azure CLI
az login

# Register the feature flag for Azure Monitor App Monitoring in preview
az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorAppMonitoringPreview"

# List the registration state of the Azure Monitor App Monitoring Preview feature
# It could take hours for the registration state to change from Registering to Registered
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AzureMonitorAppMonitoringPreview')].{Name:name,State:properties.state}"

# Once the feature shows as Registered in the prior step, re-register the Microsoft.ContainerService provider to apply the new feature settings
az provider register --namespace "Microsoft.ContainerService"

# Check the registration state of the Microsoft.ContainerService provider
az provider show --namespace "Microsoft.ContainerService" --query "registrationState"

클러스터 준비

클러스터를 준비하려면 다음 Azure CLI 명령을 실행합니다.

az aks update --resource-group={resource_group} --name={cluster_name} --enable-azure-monitor-app-monitoring 

배포 온보딩

배포는 네임스페이스 전체 또는 배포당 두 가지 방법으로 온보딩할 수 있습니다. 네임스페이스 전체 메서드를 사용하여 네임스페이스 내의 모든 배포를 온보딩합니다. 여러 배포에서 선택적 또는 가변적으로 구성된 온보딩의 경우 배포별 접근 방식을 사용합니다.

네임스페이스 전체 온보딩

네임스페이스 내의 모든 배포를 온보딩하려면 각 네임스페이스에 라는 이름의 단일 default 사용자 지정 리소스를 만듭니다. Application Insights 리소스의 연결 문자열을 포함하도록 applicationInsightsConnectionString을 업데이트합니다.

apiVersion: monitor.azure.com/v1
kind: Instrumentation
metadata:
  name: default
  namespace: mynamespace1
spec:
  settings:
    autoInstrumentationPlatforms: []
  destination: # required
    applicationInsightsConnectionString: "InstrumentationKey=11111111-1111-1111-1111-111111111111;IngestionEndpoint=https://eastus2-3.in.applicationinsights.azure.com/;LiveEndpoint=https://eastus2.livediagnostics.monitor.azure.com/"

최소한 다음 구성이 필요합니다.

• spec.settings.autoInstrumentationPlatforms: 포드가 실행 중인 언어에 기반한 하나 이상의 값입니다.
• spec.destination.applicationInsightsConnectionString: Application Insights 리소스의 연결 문자열입니다.

배포별 온보딩

배포별 온보딩을 사용하여 배포가 특정 언어로 계측되도록 하거나 원격 분석을 별도의 Application Insights 리소스로 보냅니다.

1. 각 시나리오에 대한 고유한 계측 사용자 지정 리소스를 만듭니다. 네임스페이스 전체 온보딩에 사용되는 이름을 default사용하지 않습니다.

   각 네임스페이스에서 Application Insights를 구성하는 계측 사용자 지정 리소스를 만듭니다. Application Insights 리소스의 연결 문자열을 포함하도록 applicationInsightsConnectionString을 업데이트합니다.

   팁 (조언)

   Application Insights 리소스의 개요 페이지에서 연결 문자열을 검색할 수 있습니다.

   apiVersion: monitor.azure.com/v1
   kind: Instrumentation
   metadata:
     name: cr1
     namespace: mynamespace1
   spec:
     settings:
       autoInstrumentationPlatforms: []
     destination: # required
       applicationInsightsConnectionString: "InstrumentationKey=11111111-1111-1111-1111-111111111111;IngestionEndpoint=https://eastus2-3.in.applicationinsights.azure.com/;LiveEndpoint=https://eastus2.livediagnostics.monitor.azure.com/"
   

   최소한 다음 구성이 필요합니다.

   • spec.destination.applicationInsightsConnectionString: Application Insights 리소스의 연결 문자열입니다.

2. 주석을 사용하여 각 배포를 적절한 사용자 지정 리소스 와 연결합니다. 주석은 사용자 지정 리소스에 설정된 언어를 재정의합니다.

   중요

   실수로 배포 주석에 주석을 추가하지 않도록 하려면 배포의 spec.template.metadata.annotations 수준에서 주석을 추가합니다.

   예제:

   • 자바: instrumentation.opentelemetry.io/inject-java: "cr1"
   • Node.js: instrumentation.opentelemetry.io/inject-nodejs: "cr1"

   주석 배치는 다음과 같이 표시되어야 합니다.

   apiVersion: apps/v1
   kind: Deployment
   ...
   spec:
     template:
       metadata:
         annotations:
           instrumentation.opentelemetry.io/inject-nodejs: "cr1"
   

혼합 모드 온보딩

대부분의 배포에서 기본 구성을 사용하고 일부 배포에서 다른 구성을 사용해야 하는 경우 혼합 모드를 사용합니다.

1. 네임스페이스 전체 온보딩을 구현하여 기본 구성을 정의합니다.
2. 특정 리소스에 대한 기본 구성을 재정의 하는 배포별 온보딩 구성을 만듭니다.

배포 다시 시작

모든 사용자 지정 리소스를 만들고 배포에 필요에 따라 주석을 추가한 후 다음 명령을 실행합니다.

kubectl rollout restart deployment <deployment-name> -n mynamespace1

이 명령을 사용하면 자동 계측이 적용되어 Application Insights가 활성화됩니다. 트래픽을 생성하고 리소스로 이동하여 Application Insights가 사용하도록 설정되어 있는지 확인할 수 있습니다. 앱은 Application Insights 환경에서 클라우드 역할로 표시됩니다. 라이브 메트릭 및 Application Insights 코드 분석 기능을 제외한 모든 Application Insights 환경을 사용할 수 있습니다. 여기에서 사용 가능한 Application Insights 환경에 대해 자세히 알아봅니다.

AKS의 자동 계측 제거

계측된 배포가 없는지 확인합니다. 계측된 배포의 계측을 해제하려면 연관된 계측 사용자 지정 리소스를 제거하고 배포에서 kubectl rollout restart를 실행합니다. 다음으로 다음 명령을 실행합니다.

az aks update --resource-group={resource_group} --name={cluster_name} --disable-azure-monitor-app-monitoring 

주석

자동 계측 사용 안 함

다음 주석은 지정된 언어에 대한 자동 계측을 비활성화합니다.

• 자바: instrumentation.opentelemetry.io/inject-java

• Node.js: instrumentation.opentelemetry.io/inject-nodejs

  instrumentation.opentelemetry.io/inject-java: "false"
  

비활성화한 후 자동 계측을 다시 켜려면

instrumentation.opentelemetry.io/inject-java: "true"

주석 배치는 다음과 같이 표시되어야 합니다.

apiVersion: apps/v1
kind: Deployment
...
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-java: "false"

Application Insights에서 로그 활성화

Container Insights 로그에 추가 또는 대체로 Application Insights에서 로그를 수집하도록 선택할 수 있습니다.

Application Insights에서 로그를 사용하도록 설정하면 상관 관계가 있는 로그가 제공되므로 사용자는 관련 로그와 함께 분산 추적을 쉽게 볼 수 있습니다. 또한 일부 마이크로 서비스는 콘솔에 로그를 작성하지 않으므로 Container Insights는 로그를 수집할 수 없으며 Application Insights 계측만 이러한 로그를 캡처합니다.

반대로 Application Insights가 모든 마이크로 서비스를 계측하지 못할 수 있습니다. 예를 들어, NGINX 또는 비지원 언어를 사용하는 사람들. 사용자는 이러한 마이크로 서비스에 대해서만 Container Insights 로그를 사용하는 것을 선호할 수 있습니다.

또한 Container Insights를 사용하는 인프라 엔지니어 및 Application Insights를 사용하는 개발자와 같은 여러 관찰 팀이 있는 경우 로그에 두 원본을 모두 사용하도록 선택할 수도 있습니다.

애플리케이션 코드의 콘솔 로깅 구성을 검토하여 Application Insights 로그, Container Insights 로그 또는 둘 다를 사용하도록 설정할지 여부를 결정합니다. Container Insights 로그를 사용하지 않도록 설정하는 경우 Container Insights 설정을 참조하세요.

Application Insights에서 로그를 사용하도록 설정하려면 다음 주석을 사용합니다.

• monitor.azure.com/enable-application-logs

monitor.azure.com/enable-application-logs: "true"

AKS 클러스터 생성 중에 클러스터를 준비하십시오.

AKS 클러스터는 클러스터를 만드는 동안 이 기능에 대해 준비할 수 있습니다. 클러스터를 만드는 동안 미리 준비하려는 경우 다음 Azure CLI 명령을 실행합니다. 클러스터가 미리 준비되었다고 해서 애플리케이션 모니터링이 활성화되지 않습니다. 애플리케이션을 배포하고 이 기능에 애플리케이션을 온보딩해야 합니다.

az aks create --resource-group={resource_group} --name={cluster_name} --enable-azure-monitor-app-monitoring --generate-ssh-keys

다음 단계

• 자주 묻는 질문(FAQ)을 검토하려면 Azure Kubernetes Service FAQ에 대한 자동 도구화를 참조하세요.
• 전용 문제 해결 가이드를 검토하려면 Azure Kubernetes Service를 위한 자동 계측 문제 해결을 참조하세요.
• Azure Monitor 및 Application Insights에 대해 자세히 알아봅니다.
• 애플리케이션 맵이 비즈니스에 대해 수행할 수 있는 작업을 확인합니다.