Datadog의 Kubernetes Explorer를 사용하면 포드, 배포, 기타 Kubernetes 리소스의 상태를 모니터링할 수 있습니다. 배포 내 실패한 포드의 리소스 사양을 확인하고, 노드 활동을 관련 로그와 연결하고, 리소스 사용률을 추적하고, 워크로드를 자동으로 확장하며, 오류를 해결할 수 있습니다.

구성

Kubernetes Explorer 활성화

Kubernetes Explorer는 대부분의 Datadog Agent 설치에서 기본적으로 활성화되어 있습니다.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    orchestratorExplorer:
      enabled: true

datadog:
  clusterName: <CLUSTER_NAME>
  # (...)
  processAgent:
    enabled: true
  orchestratorExplorer:
    enabled: true

export DD_API_KEY="<YOUR_DATADOG_API_KEY>"
kubectl create secret generic datadog-secret --from-literal api-key=$DD_API_KEY

mode: deployment
replicaCount: 1

image:
  repository: otel/opentelemetry-collector-contrib
  tag: 0.154.0
  pullPolicy: IfNotPresent

extraEnvs:
  - name: DD_API_KEY
    valueFrom:
      secretKeyRef:
        name: datadog-secret
        key: api-key

presets:
  kubernetesObjects:
    enabled: true
    watch: true

config:
  receivers:
    k8sobjects:
      interval: 3m

config:
  exporters:
    datadog:
      api:
        site: <YOUR_DATADOG_SITE>
        key: ${env:DD_API_KEY}
      orchestrator_explorer:
        enabled: true

  processors:
    resourcedetection:
      detectors: [k8s_api, eks]
      override: false
      eks:
        resource_attributes:
          k8s.cluster.name:
            enabled: true

  service:
    pipelines:
      logs:
        receivers: [k8sobjects]
        processors: [resourcedetection]
        exporters: [datadog]

  processors:
    resourcedetection:
      detectors: [k8s_api]
      override: false
    resource/add-cluster-name:
      attributes:
        - key: k8s.cluster.name
          value: <YOUR_CLUSTER_NAME>
          action: upsert

  service:
    pipelines:
      logs:
        receivers: [k8sobjects]
        processors: [resourcedetection, resource/add-cluster-name]
        exporters: [datadog]

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm install deployment-collector open-telemetry/opentelemetry-collector \
  --values ./deployment-collector.yaml

processors:
  k8sattributes:
    auth_type: "serviceAccount"
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.replicaset.name
        - k8s.statefulset.name
        - k8s.daemonset.name
        - k8s.cronjob.name
        - k8s.job.name
        - k8s.container.name
    pod_association:
      - sources:
          - from: resource_attribute
            name: k8s.pod.uid
      - sources:
          - from: resource_attribute
            name: k8s.pod.ip
      - sources:
          - from: resource_attribute
            name: k8s.pod.name
          - from: resource_attribute
            name: k8s.namespace.name
      - sources:
          - from: connection

service:
  pipelines:
    logs:
      processors: [k8sattributes, resourcedetection, ...]
    metrics:
      processors: [k8sattributes, resourcedetection, ...]
    traces:
      processors: [k8sattributes, resourcedetection, ...]

./install

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

export DD_API_KEY="<YOUR_DATADOG_API_KEY>"
export DD_SITE="datadoghq.com"  # for example us3.datadoghq.com, datadoghq.eu

kubectl create namespace opentelemetry-operator-system \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl create secret generic datadog-secret \
  --namespace opentelemetry-operator-system \
  --from-literal="api-key=$DD_API_KEY" \
  --from-literal="dd-site=$DD_SITE" \
  --dry-run=client -o yaml | kubectl apply -f -

mkdir -p deployment

# EKS, GKE, or AKS (resource detector auto-populates k8s.cluster.name):
cp examples/eks-deployment/values.yaml deployment/values.yaml
cp examples/gcp-deployment/values.yaml deployment/values.yaml
cp examples/aks-deployment/values.yaml deployment/values.yaml

# Other platforms (set the cluster name manually):
cp examples/manually-set-k8s-cluster-name/values.yaml deployment/values.yaml

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm upgrade --install opentelemetry-kube-stack \
  open-telemetry/opentelemetry-kube-stack \
  --namespace opentelemetry-operator-system \
  --values ./values.yaml \
  --values ./deployment/values.yaml

리소스에 사용자 지정 태그 추가

필터링을 쉽게 하려면 DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS 환경 변수를 통해 Kubernetes 리소스에 사용자 지정 태그를 추가할 수 있습니다. 이 태그는 Kubernetes Explorer에만 나타납니다.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    liveContainerCollection:
      enabled: true
    orchestratorExplorer:
      enabled: true
  override:
    agents:
      containers:
        processAgent:
          env:
            - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
              value: "tag1:value1 tag2:value2"
    clusterAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

agents:
  containers:
    processAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"
clusterAgent:
  env:
    - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
      value: "tag1:value1 tag2:value2"

- name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS
  value: "tag1:value1 tag2:value2"

사용 방법

보기

페이지 왼쪽 상단에 있는 Select Resources 드롭다운 메뉴에서 Pods, Clusters, Namespaces 및 기타 Kubernetes 리소스 간에 전환합니다.

이러한 각 보기에는 상태, 이름, Kubernetes 레이블과 같은 필드별로 데이터를 더 잘 구성할 수 있도록 돕는 데이터 표와 포드 및 Kubernetes 클러스터의 전체적인 모습을 보여주는 상세 클러스터 맵이 포함되어 있습니다.

이러한 보기를 필터링하는 방법에 대한 자세한 내용은 쿼리 필터 세부 정보를 참조하세요.

기능 및 패싯별로 그룹화

태그, Kubernetes 레이블 또는 Kubernetes 주석별로 포드를 그룹화하여 정보를 더 빠르게 찾을 수 있는 집계된 조회를 확인합니다. 페이지 오른쪽 상단에 있는 ‘그룹화(Group by)’ 막대를 사용하거나 특정 태그 또는 레이블을 클릭하고 아래와 같이 컨텍스트 메뉴에서 그룹화 기능을 찾아 그룹화를 수행할 수 있습니다.

페이지 왼쪽에 있는 패싯을 사용하여 리소스를 그룹화하거나 CrashLoopBackOff 포드 상태의 포드와 같이 가장 중요한 리소스를 필터링할 수도 있습니다.

클러스터 맵

클러스터 맵은 포드와 Kubernetes 클러스터의 전체적인 모습을 보여줍니다. 사용자 지정 그룹 및 필터를 사용하여 한 화면에서 모든 리소스를 함께 볼 수 있으며, 노드의 색상을 채울 메트릭을 선택할 수 있습니다.

상세 패널을 채우려면 클러스터 맵에서 원이나 그룹을 클릭하여 리소스를 살펴봅니다.

정보 패널

표의 행이나 클러스터 맵의 개체를 클릭하면 사이드 패널에서 특정 리소스에 대한 정보를 볼 수 있습니다.

사이드 패널의 YAML 탭에는 전체 리소스 정의가 표시됩니다. Agent 버전 7.44.0부터는 7일간의 정의 기록도 포함됩니다. 시간 경과에 따른 변경 사항 및 서로 다른 버전 간에 무엇이 변경되었는지 비교할 수 있습니다. 표시된 시간은 변경 사항이 리소스에 적용된 대략적인 시간입니다.

관련 없는 변경 사항이 너무 많이 표시되는 것을 방지하기 위해 다음 필드에만 영향을 주는 업데이트는 무시됩니다.

• metadata.resourceVersion
• metadata.managedFields
• metadata.generation
• metadata.annotations[“kubernetes.io/config.seen”]
• status

다른 탭에는 선택한 리소스의 문제를 해결하기 위한 추가 정보가 표시됩니다.

• 로그: 컨테이너 또는 리소스에서 로그를 확인합니다. 로그를 클릭하여 로그 탐색기에서 관련 로그를 확인합니다.
• APM: 트레이스의 날짜, 서비스, 기간, 방법, 상태 코드를 포함하여 컨테이너 또는 리소스에서 트레이스를 확인합니다.
• 메트릭: 컨테이너 또는 리소스에 대한 실시간 메트릭을 조회합니다. 이 탭에서 그래프를 전체 화면으로 보거나, 스냅샷을 공유하거나, 내보낼 수 있습니다.
• Processes: 이 리소스의 컨테이너에서 실행 중인 모든 프로세스를 조회합니다.
• Network: 소스, 대상, 전송 및 수신 볼륨, 처리량 필드를 포함하여 컨테이너 또는 리소스의 네트워크 성능을 조회합니다. Destination 필드를 사용하여 DNS 또는 ip_type과 같은 태그로 검색하거나, 이 조회에서 Group by 필터를 사용하여 pod_name 또는 service와 같은 태그별로 네트워크 데이터를 그룹화할 수 있습니다.
• 이벤트: 리소스에 대한 모든 Kubernetes 이벤트를 조회합니다.
• Monitors: 이 리소스에 대해 태그가 지정되거나, 범위가 지정되거나, 그룹화된 모니터를 조회합니다.

이 리소스에 대한 자세한 대시보드를 보려면 이 패널의 오른쪽 상단에 있는 대시보드 보기를 클릭합니다.

리소스 사용률

리소스 사용률 페이지는 리소스 사용률을 참조하세요.

Kubernetes Explorer 탭 내에서 리소스 사용률 메트릭을 선택하여 탐색할 수 있습니다.

이 모든 열은 정렬을 지원하므로 리소스 사용률을 기준으로 개별 워크로드를 정확하게 파악할 수 있습니다.

쿼리 필터 세부 정보

페이지 왼쪽 상단에 있는 ‘필터링(Filter by)’ 검색창에 쿼리를 입력하여 표시되는 리소스를 좁힐 수 있습니다.

구문

쿼리 필터는 용어와 연산자로 구성됩니다. 예:

용어

사용 가능한 여러 유형의 용어가 있습니다.

참고: 동일한 키-값 쌍이 태그와 레이블(또는 주석)로 모두 존재할 수 있습니다. 이는 클러스터의 구성 방식에 따라 다릅니다.

다음 리소스 속성은 임의의 문자열 일치에서 지원됩니다.

• metadata.name
• metadata.uid
• 다음에서 발견된 IP 주소:
  • 포드
  • 노드(내부 및 외부)
  • 서비스(클러스터, 외부 및 로드 밸런서 IP)

이름이나 IP로 리소스를 검색하기 위해 키를 지정할 필요는 없습니다. 문자열 검색에 특정 특수 문자가 포함되지 않는 한 따옴표는 필요하지 않습니다.

비교 연산자

모든 용어는 : 등가 연산자를 지원합니다. 메트릭 값 용어는 숫자 비교도 지원합니다.

• :> 초과(예: metric#cpu_usage_avg15:>0.9)
• :>= 이상
• :< 미만
• :<= 이하

연산자

여러 용어를 복잡한 쿼리로 결합하려면, 대소문자를 구분하는 다음 불리언 연산자를 사용할 수 있습니다.

OR 값 약어

동일한 키를 공유하는 여러 용어는 모두 OR 연산자를 사용하는 경우 단일 용어로 결합할 수 있습니다. 예를 들어, 이 쿼리의 경우:

app_name:web-server OR app_name:database OR app_name:event-consumer

다음과 같이 줄일 수 있습니다.

app_name:(web-server OR database OR event-consumer)

와일드카드

* 와일드카드를 용어의 일부로 사용하여 값과 키 모두에 대해 부분 일치로 필터링할 수 있습니다. 몇 가지 예:

• kube_job:stats-*: stats- 항목으로 시작하는 kube_deployment 태그 값을 가진 모든 리소스를 찾습니다.
• pod_name:*canary: canary 항목으로 끝나는 pod_name 값을 가진 모든 리소스를 찾습니다.
• label#release:*: 값에 상관없이 release 레이블이 있는 모든 리소스를 찾습니다.
• -label#*.datadoghq.com/*: Datadog 범위 레이블이 없는 리소스를 찾습니다.
• kube_*:*stats*canary: 값 중간에 stats 항목이 포함되고 canary 항목으로 끝나는 관련 리소스 태그(kube_*)가 있는 리소스를 찾습니다.

추출된 태그

Datadog Agent 내에서 구성한 태그 외에도, Datadog은 검색 및 그룹화 요구 사항에 도움이 될 수 있는 리소스 속성을 기반으로 생성된 태그를 삽입합니다. 이러한 태그는 관련이 있을 때 조건부로 리소스에 추가됩니다.

모든 리소스

모든 리소스에는 kube_cluster_name 태그가 있고 모든 네임스페이스 리소스에는 kube_namespace 태그가 추가됩니다.

또한 리소스에는 kube_<api_kind>:<metadata.name> 태그가 포함됩니다. 예를 들어, web-server-2라는 이름의 배포에는 kube_deployment:web-server-2 태그가 자동으로 추가됩니다.

참고: 이 패턴에는 몇 가지 예외가 있습니다.

• 포드는 대신 pod_name 항목을 사용합니다.
• VPA: verticalpodautoscaler.
• HPA: horizontalpodautoscaler.
• Persistent Volume Claims: persistentvolumeclaim.

리소스에 첨부된 레이블을 기반으로 다음 태그도 추출됩니다.

연관성

관련 리소스는 서로 태그가 지정됩니다. 몇 가지 예:

• ‘XYZ’ 배포의 일부인 포드에는 kube_deployment:xyz 태그가 지정됩니다.
• 서비스 ‘A’를 가리키는 인그레스에는 kube_service:a 태그가 지정됩니다.

‘상위’ 리소스에서 생성된 리소스에는 kube_ownerref_kind 및 kube_ownerref_name 태그(예: 포드 및 작업)가 지정됩니다.

팁: 필터 쿼리 자동 완성 기능을 활용하여 사용 가능한 관련 리소스 태그를 확인하세요. kube_ 항목을 입력하고 어떤 결과가 제안되는지 확인하세요.

포드

포드에는 다음 태그가 지정됩니다.

• pod_name
• pod_phase(매니페스트에서 추출됨)
• pod_status(kubectl과 유사하게 계산됨)

워크로드

워크로드 리소스(포드, 배포, 스테이트풀셋 등)에는 리소스 사용률 페이지 내에서의 지원 여부를 나타내는 다음 태그가 지정됩니다.

• resource_utilization(supported 또는 unsupported)
• missing_cpu_requests
• missing_cpu_limits
• missing_memory_requests
• missing_memory_limits

조건

일부 리소스의 특정 조건은 태그로 추출됩니다. 예를 들어, 배포에서 kube_condition_available 태그를 찾을 수 있습니다. 태그는 항상 kube_condition_<name> 형식이며 true 또는 false 값을 가집니다.

팁: 자동 완성 기능을 사용하여 특정 리소스 유형에서 사용 가능한 조건이 무엇인지 확인하려면 kube_condition 항목을 입력하고 결과를 검토하세요.

리소스별 태그

일부 리소스에는 클러스터의 환경에 따라 추출되는 특정 태그가 있습니다. 위의 공유 태그 외에도 다음 태그를 사용할 수 있습니다.

리소스 사용률 필터

다음 워크로드 리소스는 리소스 사용률 메트릭으로 보강됩니다.

• 클러스터
• 노드
• 포드

이 메트릭은 수집 시점에 지난 15분 동안의 평균값을 기준으로 계산됩니다. 다음과 같이 메트릭 값으로 필터링할 수 있습니다. metric#<metric_name><comparator><numeric_value>.

• metric_name 항목은 사용 가능한 메트릭입니다(아래 참조).
• comparator 항목은 지원되는 비교 연산자입니다.
• 및 numeric_value 항목은 부동 소수점 값입니다.

포드의 경우 다음 메트릭 이름을 사용할 수 있습니다.

또한 클러스터와 노드에서 다음 메트릭을 사용할 수 있습니다.

• cpu_usage_pct_alloc_avg15
• cpu_requests_pct_alloc_avg15
• mem_usage_pct_alloc_avg15
• mem_requests_pct_alloc_avg15

메트릭 단위

CPU 메트릭은 코어 수로 저장됩니다.

메모리 메트릭은 바이트 단위로 저장됩니다.

백분율(*_pct_*)은 부동 소수점으로 저장되며, 0.0은 0%, 1.0은 100%입니다. 값은 표시된 두 메트릭의 비율입니다. 예를 들어 cpu_usage_pct_limits_avg15는 usage / limits의 값입니다. 요청의 CPU 사용률과 같은 메트릭 값은 100%를 초과할 수 있습니다.

참고 사항 및 이슈

• 데이터는 일정한 간격으로 자동 업데이트됩니다.
• 1000개 이상의 배포 또는 레플리카셋이 있는 클러스터에서는 Cluster Agent의 CPU 사용량이 증가할 수 있습니다. Helm 차트에서 컨테이너 스크러빙을 비활성화하는 옵션이 있습니다. 자세한 내용은 Helm 차트 저장소를 참조하세요.

추가 자료

추가적인 유용한 설명서, 링크 및 기사:

Kubernetes 오퍼레이터를 모니터링하여 애플리케이션을 원활하게 운영하기블로그 Kubernetes Observability 시작하기학습 센터