개요

이 점검은 Kubernetes와 Universal 모드(VM 및 독립 실행형 컨테이너)를 모두 지원하는 서비스 메시용 범용 오픈 소스 컨트롤 플레인 Kuma를 모니터링합니다. Kuma는 Kong에서 개발한 Kong Mesh의 오픈 소스 커뮤니티 버전입니다.

Datadog Kuma 통합을 통해 다음 작업을 할 수 있습니다.

• Kuma 컨트롤 플레인 상태와 성능을 모니터링합니다.
• 컨트롤 플레인과 데이터 플레인 프록시 모두에서 로그를 수집합니다.
• 서비스 메시 내부 트래픽 흐름에 관한 자세한 정보를 토대로 성능을 모니터링하고 안정성을 확보합니다.

Kuma 메시 내의 Envoy 데이터 플레인(사이드카)을 모니터링하려면 다음 단계를 따르세요.

• Envoy 통합을 사용하여 메트릭을 수집합니다.
• Kuma 통합 기능을 사용하여 로그를 수집하세요.

설정

Kuma 점검은 Datadog Agent 패키지에 포함되어 있어 서버에 추가로 설치할 필요가 없습니다.

설정

메트릭 수집

메트릭은 Kuma 컨트롤 플레인과 Envoy 데이터 플레인에서 수집됩니다.

컨트롤 플레인

Autodiscovery (Kubernetes)

Autodiscovery를 사용하여 Kuma 컨트롤 플레인에서 메트릭을 수집하도록 Agent를 구성하려면 kuma-control-plane 배포에 다음 포드 어노테이션을 적용하세요. 이 예에서는 Helm을 사용하여 Kuma를 설치했다고 가정합니다. Autodiscovery에 대한 자세한 내용은 Autodiscovery 통합 템플릿을 참고하세요.

# values.yaml
controlPlane:
  podAnnotations:
    ad.datadoghq.com/control-plane.checks: |
      {
        "kuma": {
          "init_config": {},
          "instances": [
            {
              "openmetrics_endpoint": "http://%%host%%:5680/metrics",
              "service": "kuma-control-plane"
            }
          ]
        }
      }

참고: Kuma용 Autodiscovery 어노테이션 형식은 ad.datadoghq.com/<CONTAINER_NAME>.checks:입니다. 컨트롤 플레인의 이름이 다른 경우 해당 줄을 적절히 변경하세요. 자세한 내용은 [Datadog 문서]https://docs.datadoghq.com/containers/kubernetes/integrations/?tab=annotations)를 참고하세요.

구성 파일

또는 Agent 구성 디렉터리의 루트 conf.d/ 폴더에 있는 kuma.d/conf.yaml 파일을 편집하여 통합을 구성할 수도 있습니다.

instances:
  - openmetrics_endpoint: http://<KUMA_CONTROL_PLANE_HOST>:5680/metrics
    service: kuma-control-plane

사용 가능한 모든 옵션은 샘플 kuma.d/conf.yaml을 참고하세요.

데이터 플레인(Envoy 프록시)

데이터 플레인의 메트릭은 Envoy 통합을 사용하여 수집됩니다.

1. 먼저 MeshMetric 정책을 생성하여 데이터 플레인에서 Prometheus 메트릭 노출을 활성화하세요. 자세한 내용은 Kuma 문서를 참고하세요.

   apiVersion: kuma.io/v1alpha1
   kind: MeshMetric
   metadata:
     name: my-metrics-policy
     namespace: kuma-system
     labels:
       kuma.io/mesh: default
   spec:
     default:
       backends:
       - type: Prometheus
         prometheus:
           port: 5670
           path: "/metrics"
   

2. 다음으로, 애플리케이션 포드에 다음 어노테이션을 적용하여 Datadog Agent가 이러한 메트릭을 수집하도록 구성합니다. 어노테이션 적용에 대한 자세한 내용은 Autodiscovery 통합 템플릿을 참고하세요.

   ad.datadoghq.com/kuma-sidecar.checks: |
     {
       "envoy": {
         "instances": [
           {
             "openmetrics_endpoint": "http://%%host%%:5670/metrics",
             "collect_server_info": false
           }
         ]
       }
     }
   

   참고: Kuma용 Autodiscovery 어노테이션 형식은 ad.datadoghq.com/<CONTAINER_NAME>.checks:입니다. 사이드카의 이름이 다른 경우 해당 줄을 적절히 수정하세요. 자세한 내용은 Datadog 문서를 참고하세요.

로그 수집

datadog.yaml 파일에서 로그 수집을 활성화합니다.

logs_enabled: true

컨트롤 플레인 로그

Kuma 컨트롤 플레인에서 로그를 수집하려면 kuma-control-plane 배포에 다음 어노테이션을 적용하세요.

# values.yaml
controlPlane:
  podAnnotations:
    ad.datadoghq.com/control-plane.logs: |
      [
        {
          "source": "kuma",
          "service": "kuma-control-plane"
        }
      ]

참고: Kuma용 Autodiscovery 어노테이션 형식은 ad.datadoghq.com/<CONTAINER_NAME>.logs:입니다. 컨트롤 플레인의 이름이 다른 경우 해당 줄을 적절히 변경하세요. 자세한 내용은 Datadog 문서를 참고하세요.

데이터 플레인 로그

Datadog Agent가 Envoy 사이드카 컨테이너에서 로그를 수집하도록 구성하려면 애플리케이션 포드에 다음 어노테이션을 적용하세요.

ad.datadoghq.com/kuma-sidecar.logs: |
  [
    {
      "source": "kuma",
      "service": "<MY_SERVICE>",
      "auto_multi_line_detection": true
    }
  ]

참고: Kuma용 Autodiscovery 어노테이션 형식은 ad.datadoghq.com/<CONTAINER_NAME>.logs:입니다. 컨트롤 플레인의 이름이 다른 경우 해당 줄을 적절히 변경하세요. 자세한 내용은 Datadog 문서를 참고하세요.

<MY_SERVICE>를 서비스 이름으로 변경합니다.

선택 사항: 메시 액세스 로그를 활성화합니다

메시 내 서비스 간 트래픽을 보여주는 액세스 로그를 수집하려면 MeshAccessLog 정책을 생성하여 활성화할 수 있습니다. 자세한 내용은 Kuma 문서를 참고하세요.

Datadog Agent 포드에 사이드카 주입 활성화

메시에 엄격한 mTLS가 활성화된 경우, Datadog Agent는 다른 서비스와 통신하기 위해 Kuma 사이드카를 포드에 주입해야 합니다.

Datadog Agent에 사이드카 주입을 활성화하려면 Agent가 배포된 네임스페이스(일반적으로 datadog)에 kuma.io/sidecar-injection: enabled 레이블을 추가하세요.

apiVersion: v1
kind: Namespace
metadata:
  name: datadog
  labels:
    kuma.io/sidecar-injection: enabled

Agent와 서비스 간의 트래픽을 허용하는 MeshTrafficPermission 정책을 적용해야 합니다. 자세한 내용은 Kuma 문서를 참고하세요.

검증

Agent status 하위 명령을 실행하고 Checks 섹션에서 kuma를 찾습니다.

수집한 데이터

Metrics

이벤트

Kuma 통합은 이벤트를 포함하지 않습니다.

트러블슈팅

mTLS 연결 이슈

mTLS를 엄격하게 설정하고 패스스루를 사용하지 않으면 Agent가 컨트롤 플레인이나 다른 서비스에 연결하지 못할 수 있습니다. 모든 트래픽이 암호화되어 Kuma의 데이터 플레인 프록시를 통해 라우팅되기 때문입니다. 이 문제를 해결하려면 Datadog Agent 포드에 사이드카 주입을 활성화해야 합니다(#enable-sidecar-injection-for-datadog-agent-pods).

사이드카가 주입되면 Autodiscovery 어노테이션에서 %%host%%을 Kubernetes 서비스 이름으로 교체해야 합니다. 그렇지 않으면 트래픽이 메쉬를 통해 라우팅될 때 %%host%% 매크로가 올바르게 작동하지 않을 수 있습니다. Kuma 컨트롤 플레인이나 사이드카의 경우에는 이 작업이 필요하지 않습니다.

예를 들어, 다음 대신에

yaml"openmetrics_endpoint": "http://%%host%%:5670/metrics"

서비스 이름을 사용하세요.

yaml"openmetrics_endpoint": "http://my-service.my-namespace.svc.cluster.local:5670/metrics"

mTLS를 활성화한 경우 %%host%% 매크로를 사용하므로 자동 검색 자동 구성을 비활성화하는 것이 좋습니다. 자동 구성을 비활성화하는 방법에 관한 자세한 내용은 Datadog 문서를 참고하세요.

도움이 필요하세요? Datadog 지원 팀에 문의하세요.

참고 자료

• Kuma 공식 문서
• Kuma 정책 문서