Azure Monitor 및 클라우드 네이티브 도구를 사용하여 Kubernetes 클러스터 모니터링

Azure Monitor의 Kubernetes 모니터링은 Kubernetes 환경 및 해당 환경에서 실행되는 워크로드의 전체 모니터링을 제공하는 데 사용되는 Azure Monitor 서비스에 대해 설명합니다. 이 문서에서는 이러한 서비스를 활용하여 관리하는 일반적인 역할에 따라 Kubernetes 환경의 다양한 계층을 모니터링하는 방법에 대한 모범 사례를 제공합니다.

다음은 인프라 계층에서 애플리케이션을 통해 시작되는 일반적인 Kubernetes 환경의 공통 모델을 보여주는 그림입니다. 각 계층에는 서로 다른 서비스에서 처리되고 일반적으로 조직에서 서로 다른 역할로 관리되는 고유한 모니터링 요구 사항이 있습니다.

Kubernetes 환경의 여러 계층과 이에 의존하는 애플리케이션에 대한 책임은 일반적으로 여러 역할에 의해 처리됩니다. 조직의 크기에 따라 이러한 역할은 다른 사람이나 다른 팀에서 수행할 수 있습니다. 다음 표에서는 다양한 역할에 대해 설명하고 아래 섹션에서는 각 역할이 일반적으로 발생하는 모니터링 시나리오를 제공합니다.

역할	설명
개발자	클러스터에서 실행되는 애플리케이션을 개발하고 유지 관리합니다. 애플리케이션 성능 및 실패를 포함한 애플리케이션별 트래픽을 담당합니다. SLA에 따라 애플리케이션의 안정성을 유지 관리합니다.
플랫폼 엔지니어	Kubernetes 클러스터를 담당합니다. 개발자가 사용하는 플랫폼을 프로비전하고 유지 관리합니다.
네트워크 엔지니어	워크로드와 클러스터를 사용한 수신/송신 간의 트래픽을 담당합니다. 네트워크 트래픽을 분석하고 위협 분석을 수행합니다.

네트워크 엔지니어

네트워크 엔지니어는 워크로드와 클러스터를 사용한 수신/송신 간의 트래픽을 담당합니다. 네트워크 트래픽을 분석하고 위협 분석을 수행합니다.

모니터 수준 1 - 네트워크

다음은 네트워크를 모니터링하기 위한 일반적인 시나리오입니다.

• Network Watcher를 사용하여 흐름 로그를 만들어 클러스터에서 사용하는 네트워크 보안 그룹을 통해 흐르는 IP 트래픽에 대한 정보를 기록한 다음 트래픽 분석을 사용하여 이 데이터를 분석하고 인사이트를 제공합니다. 컨테이너 로그 및 컨트롤 플레인 로그에 사용하는 트래픽 분석에 동일한 Log Analytics 작업 영역을 사용합니다.
• 트래픽 분석을 사용하여 클러스터에서 사용하는 예기치 않은 포트 간 트래픽이 흐르는지 여부와 노출해서는 안 되는 공용 IP를 통해 트래픽이 흐르는지 확인합니다. 이 정보를 사용하여 네트워크 규칙을 수정해야 하는지 여부를 확인합니다.
• AKS 클러스터의 경우 AKS용 네트워크 가시성 추가 기능(미리 보기)을 사용하여 클러스터의 서비스 간 액세스를 모니터링하고 관찰합니다(동-서 트래픽).

플랫폼 엔지니어

클러스터 관리자라고도 하는 플랫폼 엔지니어는 Kubernetes 클러스터 자체를 담당합니다. 개발자가 사용하는 플랫폼을 프로비전하고 유지 관리합니다. 클러스터 및 해당 구성 요소의 상태를 이해하고 검색된 문제를 해결할 수 있어야 합니다. 또한 클러스터를 운영하는 데 드는 비용을 이해하고 잠재적으로 다른 팀에 비용을 할당할 수 있어야 합니다.

대규모 조직에는 플랫폼 엔지니어와 비슷하지만 여러 클러스터를 담당하는 플릿 설계자가 있을 수도 있습니다. 전체 환경에 대한 가시성이 필요하며 대규모로 관리 작업을 수행해야 합니다. 대규모 권장 사항은 아래 지침에 포함되어 있습니다. 다중 클러스터 및 대규모 시나리오에 대한 Fleet 리소스를 만드는 방법에 대한 자세한 내용은 Azure Kubernetes Fleet Manager란?을 참조하세요.

플랫폼 엔지니어에 대한 모니터링 구성

아래 섹션에서는 컨테이너 수준의 Azure 서비스를 사용하여 Kubernetes 환경을 모니터링하는 단계를 식별합니다. 특정 요구 사항에 맞게 이 구성을 수정해야 할 위치를 결정하는 데 도움이 되는 기능 및 통합 옵션이 각각 제공됩니다. 관리형 Prometheus 및 컨테이너 로깅의 온보딩은 Kubernetes 클러스터에 대한 모니터링 사용에서 설명한 동일한 경험의 일부가 될 수 있습니다. 다음 섹션에서는 각각에 대한 모든 온보딩 및 구성 옵션을 고려할 수 있도록 개별적으로 설명했습니다.

Prometheus 메트릭의 스크래핑 사용

중요합니다

Prometheus용 Azure Monitor 관리 서비스를 사용하려면 Azure Monitor 작업 영역이 있어야 합니다. 작업 영역 구성의 디자인 고려 사항에 대한 자세한 내용은 Azure Monitor 작업 영역 아키텍처를 참조하세요.

클러스터를 만들 때 또는 기존 클러스터에 이 기능을 추가할 때 클러스터에서 Prometheus용 Azure Monitor 관리 서비스에서 Prometheus 메트릭을 스크래핑하도록 설정합니다. 자세한 내용은 Prometheus 메트릭 사용을 참조하세요 .

AKS 클러스터에 사용할 Prometheus 환경이 이미 있는 경우 Prometheus용 Azure Monitor 관리 서비스를 사용하도록 설정한 다음, 원격 쓰기를 사용하여 기존 Prometheus 환경으로 데이터를 보냅니다. 원격 쓰기를 사용하여 기존 자체 관리형 Prometheus 환경에서 Prometheus용 Azure Monitor 관리 서비스로 데이터를 보낼 수도 있습니다.

기본적으로 수집되는 메트릭과 수집 빈도에 대한 자세한 내용은 Azure Monitor의 기본 Prometheus 메트릭 구성을 참조하세요. 구성을 사용자 지정하려면 Prometheus용 Azure Monitor 관리 서비스에서 Prometheus 메트릭 스크래핑 사용자 지정을 참조하세요.

Prometheus 데이터 분석에 Grafana 사용

참고

Grafana가 있는 Azure Monitor 대시보드 는 현재 공개 미리 보기로 제공되며 Managed Grafana를 대체할 수 있습니다. 이 버전의 Grafana는 비용이 없고, 구성이 필요하지 않으며, Azure Portal에 대시보드를 제공합니다. 여러 데이터 원본의 데이터를 결합하는 대시보드를 만들거나 기존 Grafana 환경과 통합하려는 경우 Managed Grafana를 사용합니다.

Managed Grafana의 인스턴스를 생성하고 Prometheus 데이터를 데이터 원본으로 사용할 수 있도록 Azure Monitor 작업 영역에 연결합니다. Prometheus용 Azure Monitor 관리 서비스를 데이터 원본으로 추가하여 이 구성을 수동으로 수행할 수도 있습니다. 컨테이너 인사이트 뷰와 유사한 정보를 제공하는 몇 가지 정보를 포함하여 Kubernetes 클러스터를 모니터링하기 위해 미리 빌드된 다양한 대시보드를 사용할 수 있습니다.

기존 Grafana 환경이 있는 경우 계속 사용하고 Prometheus용 Azure Monitor 관리 서비스를 데이터 원본으로 추가할 수 있습니다. Azure Monitor 데이터 원본을 Grafana에 추가하여 사용자 지정 Grafana 대시보드에서 컨테이너 인사이트로 수집한 데이터를 사용할 수도 있습니다. 컨테이너 인사이트 보기 및 보고서를 사용하는 대신 Grafana 대시보드에 집중하려면 이 구성을 수행합니다.

컨테이너 로그 수집 활성화

중요합니다

Prometheus에 Azure Monitor 관리 서비스를 사용하려면 Log Analytics 작업 영역이 있어야 합니다. 작업 영역 구성의 디자인 고려 사항에 대한 자세한 내용은 Azure Monitor 작업 영역 아키텍처를 참조하세요.

Kubernetes 클러스터에 컨테이너 로그 수집을 사용하도록 설정하면 Azure Monitor는 KQL(Kusto Query Language)을 사용하여 분석할 수 있는 Azure Monitor의 Log Analytics 작업 영역에 stdout/stderr 및 인프라 로그를 보내는 컨테이너화된 버전의 Azure Monitor 에이전트를 배포합니다.

Kubernetes 클러스터를 온보딩하기 위한 필수 구성 요소 및 구성 옵션은 AKS 클러스터에 대한 모니터링 사용을 참조하세요. Azure Policy를 사용하여 온보딩하여 모든 클러스터가 일관된 구성을 유지하도록 합니다.

클러스터에 컨테이너 로깅을 사용하도록 설정하면 다음 작업을 수행하여 설치를 최적화합니다.

• 가끔 문제 해결을 위해서만 로그를 사용하는 경우 이 테이블을 기본 로그로 구성하는 것이 좋습니다.
• Container Insights에서 비용 최적화 설정 사용에 설명된 비용 사전 설정을 사용하여 수집되는 데이터의 양을 줄여 Container Insights 데이터 수집 비용을 절감할 수 있습니다. Prometheus와 동일한 메트릭 값이 많기 때문에 로그 및 이벤트만 수집하도록 Container Insights를 구성하여 메트릭 컬렉션을 사용하지 않도록 설정합니다.

로그 수집을 위한 기존 솔루션이 있는 경우 해당 도구에 대한 지침을 따르거나 Azure Monitor를 사용하여 로그 수집을 사용하도록 설정하고 Log Analytics 작업 영역의 데이터 내보내기 기능을 사용하여 대체 시스템으로 전달하기 위해 Azure Event Hubs 로 데이터를 보냅니다.

AKS 클러스터에 대한 컨트롤 플레인 로그 수집

AKS 컨트롤 플레인 구성 요소에 대한 로그는 Azure에서 리소스 로그로 구현됩니다. Log Analytics 작업 영역으로 리소스 로그를 보내도록 각 AKS 클러스에 대한 진단 설정을 만듭니다. Azure Policy를 사용하여 여러 클러스터에서 일관된 구성을 보장합니다.

리소스 로그를 작업 영역으로 보내는 데는 비용이 있으므로 사용하려는 로그 범주만 수집해야 합니다. AKS에 사용할 수 있는 범주에 대한 설명은 리소스 로그를 참조하세요. 최소한의 범주를 수집하여 시작한 다음, 요구 사항이 증가하고 관련 비용을 이해하게 되면 추가 범주를 수집하도록 진단 설정을 수정합니다. 규정 준수를 위해 정보를 유지해야 하는 경우 비용을 줄이기 위해 Azure Storage 계정에 로그를 보낼 수 있습니다. 로그 데이터 수집 및 보존 비용에 대한 자세한 내용은 Azure Monitor 로그 가격 책정 세부 정보를 참조하세요.

어떤 리소스 로그를 처음에 사용하도록 설정할지 확실하지 않으면 가장 일반적인 고객 요구 사항을 기반으로 하는 다음 권장 사항을 사용합니다. 필요한 경우 나중에 다른 범주를 사용하도록 설정할 수 있습니다.

범주	사용 여부	대상
kube-apiserver	사용	Log Analytics 작업 영역
kube-audit	사용	Azure Storage의 Blob을 나타냅니다. 이렇게 하면 비용을 최소화하면서도 감사자가 요구하는 경우 감사 로그가 유지됩니다.
kube-audit-admin	사용	Log Analytics 작업 영역
kube-controller-manager (큐브 컨트롤러 매니저)	사용	Log Analytics 작업 영역
kube-scheduler	사용 안 함
cluster-autoscaler	자동 크기 조정을 사용하는 경우 사용하도록 설정	Log Analytics 작업 영역
가드	Microsoft Entra ID를 사용하는 경우 사용	Log Analytics 작업 영역
AllMetrics	메트릭이 Managed Prometheus에서 수집되므로 사용하지 않도록 설정합니다.	Log Analytics 작업 영역

로그 수집을 위한 기존 솔루션이 있는 경우 해당 도구에 대한 지침을 따르거나 Azure Monitor를 사용하여 로그 수집을 사용하도록 설정하고 Log Analytics 작업 영역의 데이터 내보내기 기능을 사용하여 대체 시스템으로 전달하기 위해 Azure 이벤트 허브로 데이터를 보냅니다.

AKS 클러스터에 대한 활동 로그 수집

AKS 클러스터에 대한 구성 변경 내용은 활동 로그에 저장됩니다. 이 데이터를 Log Analytics 작업 영역으로 보내 진단 설정을 생성하여 다른 모니터링 데이터로 분석합니다. 이 데이터 수집에 대한 비용은 없으며 Log Analytics를 사용하여 데이터를 분석하거나 경고할 수 있습니다.

모니터 수준 2 - 클러스터 수준 구성 요소

클러스터 수준에는 다음 구성 요소가 포함됩니다.

구성 요소	모니터링 요구 사항
노드	각 노드에 대한 CPU, 메모리, 디스크 및 IP 사용량의 준비 상태와 성능을 이해하고 워크로드를 배포하기 전에 사용 추세를 적극적으로 모니터링합니다.

다음은 클러스터 수준 구성 요소를 모니터링하기 위한 일반적인 시나리오입니다.

Azure Portal

• Azure Portal의 통합 모니터링 대시보드를 사용하여 CPU 및 메모리 사용률을 포함하여 클러스터의 노드 성능을 확인합니다.
• 노드 보기를 사용하여 각 노드의 상태와 노드에서 실행 중인 Pod의 상태 및 성능을 확인합니다. 노드 상태 및 성능 분석에 대한 자세한 내용은 Azure Portal에서 Kubernetes 클러스터 성능 분석을 참조하세요.
• 보고서에서 노드 모니터링 통합 문서를 사용하여 디스크 용량, 디스크 IO 및 GPU 사용량을 분석합니다. 이러한 통합 문서에 대한 자세한 내용은 노드 모니터링 통합 문서를 참조하세요.
• 모니터링에서 통합 문서를 선택한 다음, 서브넷 IP 사용량을 선택하여 선택한 시간 범위에 대한 각 노드의 IP 할당 및 할당을 확인합니다.

Grafana 대시보드

• Kubelet용 Managed Grafana에서 미리 빌드된 대시보드를 사용하여 각 항목의 상태 및 성능을 확인합니다.
• 및 node_disk_io_time_seconds_total와 같은 디스크와 관련된 windows_logical_disk_free_bytes과 함께 Grafana 대시보드를 사용하여 연결된 스토리지를 모니터링합니다.
• Prometheus에 저장된 데이터를 기반으로 노드의 성능과 상태를 시각화하는 여러 Kubernetes 대시보드를 사용할 수 있습니다.

Log Analytics

• Log Analytics 작업 영역의 쿼리 대화 상자에서 컨테이너 범주를 선택하면 컨테이너 인사이트로 채워진 ContainerImageInventory 테이블에서 데이터를 검색하는 이미지 인벤토리 로그 쿼리를 포함하여 클러스터에 대해 미리 빌드된 로그 쿼리에 액세스할 수 있습니다.

문제 해결

• 문제 해결 시나리오의 경우 유지 관리 또는 즉각적인 로그 수집을 위해 노드에 직접 액세스해야 할 수 있습니다. 보안을 위해 AKS 노드는 인터넷에 노출되지 않지만 kubectl debug 명령을 사용하여 AKS 노드에 SSH로 연결할 수 있습니다. 이 프로세스에 대한 자세한 내용은 유지 관리 또는 문제 해결을 위해 SSH를 통해 AKS(Azure Kubernetes Service) 클러스터 노드에 연결을 참조하세요.

비용 분석

• Kubernetes 비용을 이해하기 위한 오픈 소스, 공급업체 중립적 CNCF 샌드박스 프로젝트인 OpenCost를 구성하여 클러스터 비용 분석을 지원합니다. 자세한 비용 데이터를 Azure Storage로 내보냅니다.
• OpenCost의 데이터를 사용하여 조직의 여러 팀에서 클러스터의 상대적 사용량을 분석하여 각 팀 간에 비용을 할당할 수 있습니다.
• OpenCost의 데이터를 사용하여 많은 작은 노드가 아닌 더 적은 수의 큰 노드를 사용하여 워크로드를 조밀하게 압축하여 클러스터가 노드의 전체 용량을 사용하고 있는지 확인합니다.

모니터 수준 3 - 관리되는 Kubernetes 구성 요소

관리되는 Kubernetes 수준에는 다음 구성 요소가 포함됩니다.

구성 요소	모니터링
API 서버	API 서버의 상태를 모니터링하고 서비스가 중단된 경우 요청 로드 및 병목 현상의 증가를 식별합니다.
kubelet	Kubelet을 모니터링하여 Pod 관리 문제, 시작되지 않는 Pod, 준비되지 않은 노드 또는 Pod가 종료되는 문제를 해결하는 데 도움을 줍니다.

다음은 관리되는 Kubernetes 구성 요소를 모니터링하기 위한 일반적인 시나리오입니다.

Azure Portal

• 메트릭 탐색기를 사용하여 클러스터에 대한 Inflight Requests 카운터를 봅니다.
• Kubelet 통합 문서를 사용하여 각 kubelet의 상태 및 성능을 확인합니다.

그라파나 주

• Kubelet용 Managed Grafana에서 미리 빌드된 대시보드를 사용하여 각 kubelet의 상태 및 성능을 확인합니다.
• API 서버 성능을 전체적으로 보려면 Kubernetes apiserver와 같은 대시보드를 사용합니다. 여기에는 요청 대기 시간 및 작업 큐 처리 시간과 같은 값이 포함됩니다.

Log Analytics

• 리소스 로그와 함께 로그 쿼리를 사용하여 AKS 구성 요소에서 생성된 컨트롤 플레인 로그를 분석합니다.

• AKS에 대한 모든 구성 작업은 활동 로그에 기록됩니다. 활동 로그를 Log Analytics 작업 영역으로 보낼 때 Log Analytics를 사용하여 분석할 수 있습니다. 예를 들어 다음 샘플 쿼리를 사용하여 모든 AKS 클러스터에서 성공적인 업그레이드를 식별하는 레코드를 반환할 수 있습니다.

  AzureActivity
  | where CategoryValue == "Administrative"
  | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
  | extend properties=parse_json(Properties_d) 
  | where properties.message == "Upgrade Succeeded"
  | order by TimeGenerated desc
  

문제 해결

• 문제 해결 시나리오의 경우 AKS(Azure Kubernetes Service) 클러스터 노드에서 kubelet 로그 가져오기에 설명된 프로세스를 사용하여 kubelet 로그에 액세스할 수 있습니다.

모니터 수준 4 - Kubernetes 개체 및 워크로드

Kubernetes 개체 및 워크로드 수준에는 다음 구성 요소가 포함됩니다.

구성 요소	모니터링 요구 사항
배포	배포의 실제 상태와 필요한 상태 및 여기에서 실행되는 Pod의 상태 및 리소스 사용률을 모니터링합니다.
Pod	AKS 클러스터에서 실행되는 Pod의 상태 및 리소스 사용률(CPU 및 메모리 포함)을 모니터링합니다.
컨테이너	AKS 클러스터에서 실행되는 컨테이너의 리소스 사용률(CPU 및 메모리 포함)을 모니터링합니다.

다음은 Kubernetes 개체 및 워크로드를 모니터링하기 위한 일반적인 시나리오입니다.

Azure Portal

• 노드 및 컨트롤러 보기를 사용하여 여기에서 실행되는 Pod의 상태 및 성능을 확인하고 컨테이너의 상태 및 성능으로 드릴다운합니다.
• 컨테이너의 상태와 성능을 보려면 컨테이너 보기를 사용합니다. 컨테이너 상태 및 성능 분석에 대한 자세한 내용은 Container Insights를 사용하여 Kubernetes 클러스터 데이터 분석을 참조하세요.
• 배포 통합 문서를 사용하여 배포 메트릭을 확인합니다. 자세한 내용은 Container Insights를 사용한 배포 및 HPA 메트릭을 참조하세요.

Grafana 대시보드

• 노드 및 Pod용 Managed Grafana에서 미리 빌드된 대시보드를 사용하여 상태 및 성능을 확인합니다.
• Prometheus에 저장된 데이터를 기반으로 노드의 성능과 상태를 시각화하는 여러 Kubernetes 대시보드를 사용할 수 있습니다.

라이브 데이터

• 문제 해결 시나리오에서 컨테이너 인사이트는 라이브 AKS 컨테이너 로그(stdout/stderror), 이벤트 및 Pod 메트릭에 대한 액세스를 제공합니다. 이 기능에 대한 자세한 내용은 Kubernetes 로그, 이벤트 및 Pod 메트릭을 실시간으로 보는 방법을 참조하세요.

플랫폼 엔지니어에 대한 경고

Azure Monitor 경고는 모니터링 데이터의 흥미로운 데이터와 패턴을 사전에 알립니다. 이를 통해 사용자에게 알리기 전에 시스템 문제를 식별하고 해결할 수 있습니다. 경고를 위한 기존 ITSM 솔루션이 있는 경우 Azure Monitor와 통합할 수 있습니다. 작업 영역 데이터를 내보내 Log Analytics 작업 영역에서 현재 경고 솔루션을 지원하는 다른 위치로 데이터를 보낼 수도 있습니다.

경고 유형

다음 표에서는 위에서 설명한 서비스에서 수집한 데이터를 기반으로 만들 수 있는 다양한 유형의 사용자 지정 경고 규칙에 대해 설명합니다.

경고 유형	설명
Prometheus 경고	Prometheus 경고는 Prom QL(Prometheus 쿼리 언어)로 작성되고 Prometheus용 Azure Monitor 관리형 서비스에 저장된 Prometheus 메트릭에 적용됩니다. 권장되는 경고에는 이미 가장 일반적인 Prometheus 경고가 포함되어 있으며 필요에 따라 추가 경고 규칙을 만들 수 있습니다.
메트릭 경고 규칙	메트릭 경고 규칙은 메트릭 탐색기와 동일한 메트릭 값을 사용합니다. 실제로 현재 분석 중인 데이터를 사용하여 메트릭 탐색기에서 직접 경고 규칙을 만들 수 있습니다. 메트릭 경고 규칙은 AKS 데이터 참조 메트릭의 값을 사용하여 AKS 성능에 대해 경고하는 데 유용할 수 있습니다.
로그 검색 경고 규칙	로그 검색 경고 규칙을 사용하여 로그 쿼리 결과에서 경고를 생성합니다. 자세한 내용은 컨테이너 인사이트에서 로그 검색 경고를 만드는 방법 및 컨테이너 인사이트에서 로그를 쿼리하는 방법을 참조하세요.

권장 경고

Kubernetes 클러스터에 대한 가장 일반적인 경고 조건을 포함하는 컨테이너 인사이트의 메트릭 경고 규칙(미리 보기)에서 권장되는 Prometheus 경고 세트로 시작합니다. 나중에 추가 경고 조건을 식별할 때 더 많은 경고 규칙을 추가할 수 있습니다.

Developer

개발자는 애플리케이션 개발 외에도 클러스터에서 실행되는 애플리케이션을 유지 관리합니다. 애플리케이션 성능 및 오류를 비롯한 애플리케이션별 트래픽을 담당하며 회사가 정의한 SLA에 따라 애플리케이션의 안정성을 유지 관리합니다.

모니터 수준 5 - 애플리케이션

Azure Monitor OpenTelemetry Distro를 구현하여 Application Insights 환경을 사용하도록 설정하고 비용을 제어하도록 샘플링을 구성합니다.

Application Insights 환경

• 개요 대시보드에서 애플리케이션 상태 및 성능에 대한 한눈에 확인할 수 있습니다.
• 애플리케이션 활동 및 성능에 대한 실시간 인사이트를 위한 라이브 메트릭 을 봅니다.
• 오류, 성능 및 트랜잭션을 조사 하여 애플리케이션 상태 및 효율성을 진단합니다.
• 애플리케이션 아키텍처 및 구성 요소 상호 작용의 시각적 개요에 애플리케이션 맵 을 사용합니다.
• 애플리케이션 가용성을 모니터링하는 표준 테스트를 만듭니다.

애플리케이션 로그

• 컨테이너 인사이트는 Stdout/stderr 로그를 Log Analytics 작업 영역으로 보냅니다. 다양한 로그에 대한 설명은 리소스 로그를 참조하고 각각 전송되는 테이블 목록은 Kubernetes Services를 참조하세요.

서비스 메시

• AKS 클러스터의 경우 마이크로 서비스 아키텍처에 가시성을 제공하는 Istio 기반 서비스 메시 추가 기능을 배포합니다. Istio는 기존 분산 애플리케이션에 투명하게 계층화되는 오픈 소스 서비스 메시입니다. 추가 기능은 AKS용 Istio의 배포 및 관리를 지원합니다.

참고 항목

• 클러스터에서 Managed Prometheus 및 로그 수집을 사용하도록 설정하려면 Kubernetes 클러스터에 대한 모니터링 사용을 참조하세요.