• EnglishEspañol日本語한국어Português
  • 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하시기 바랍니다.

문제 신고

개요

Kubernetes 통합 버전 2에는 버전 3과 몇 가지 다른 설정 및 요구 사항이 있습니다. 이 문서에서는 버전 3과 다른 설정과 버전 2에 필요한 설정에 대해 설명합니다. 다르게 지정하지 않으면 버전 3의 설정을 사용할 수 있습니다.

주의

우리는 버전 2를 대체했으며 이를 사용해서는 안 된다는 점을 명심하세요. 우리는 여전히 버전 2를 사용하고 있는 사용자를 위해 이 문서를 유지 관리합니다.

현재 버전의 Kubernetes를 시작하려면 Kubernetes 통합 소개를 참조하세요.

버전 3 변경 사항을 이해하려면 Kubernetes 통합 버전 3 문서에 도입된 변경 사항을 참조하세요.

통합 버전 2로 제어 영역 모니터링

이 섹션에서는 통합 버전 2 이하에서 컨트롤 플레인 모니터링을 구성하는 방법을 다룹니다.

이러한 버전에는 유연성이 떨어지는 자동 검색 옵션이 있으며 외부 엔드포인트를 지원하지 않습니다. 최대한 빨리 버전 3 으로 업데이트하는 것이 좋습니다.

자동 검색 및 기본 설정: hostNetworkprivileged

v3 미만 버전에서 통합이 privileged: false 을 사용하여 배포되면 제어 영역 구성요소에 대한 hostNetwork 설정도 false 로 설정됩니다.

마스터 노드 및 제어 평면 구성 요소 검색

Kubernetes 통합은 kubeadm 라벨 지정 규칙을 사용하여 마스터 노드와 제어 영역 구성요소를 검색합니다. 이는 마스터 노드에 node-role.kubernetes.io/master="" 또는 kubernetes.io/role="master" 라벨이 지정되어야 함을 의미합니다.

제어 영역 구성요소에는 k8s-app 또는 tiercomponent 라벨이 있어야 합니다. 허용되는 라벨 조합 및 값은 다음 표를 참조하세요.

요소

상표

끝점

API 서버

Kubeadm / Kops / ClusterAPI

k8s-app=kube-apiserver

tier=control-plane component=kube-apiserver

OpenShift

app=openshift-kube-apiserver apiserver=true

localhost:443/metrics 기본적으로(구성 가능) 요청이 실패하면 localhost:8080/metrics

Kubeadm / Kops / ClusterAPI

k8s-app=etcd-manager-main

tier=control-plane component=etcd

OpenShift

k8s-app=etcd

localhost:4001/metrics

스케줄러

Kubeadm / Kops / ClusterAPI

k8s-app=kube-scheduler

tier=control-plane component=kube-scheduler

OpenShift

app=openshift-kube-scheduler scheduler=true

localhost:10251/metrics

컨트롤러 관리자

Kubeadm / Kops / ClusterAPI

k8s-app=kube-controller-manager

tier=control-plane component=kube-controller-manager​

OpenShift

app=kube-controller-manager kube-controller-manager=true

localhost:10252/metrics

통합이 마스터 노드 내에서 실행 중임을 감지하면 위 표에 나열된 레이블과 일치하는 패드를 찾아서 노드에서 실행 중인 구성 요소를 찾으려고 합니다. 실행 중인 모든 구성 요소에 대해 통합은 해당 메트릭 엔드포인트에 요청을 보냅니다.

구성

제어 평면 모니터링은 마스터 노드 내부에서 실행되는 에이전트에 대해 자동입니다. 클라이언트 요청에 대해 상호 TLS 인증(mTLS)을 사용하기 때문에 실행하기 위해 추가 단계가 필요한 유일한 구성 요소는 etcd입니다. API 서버는 보안 포트 를 사용하여 쿼리하도록 구성할 수도 있습니다.

중요

OpenShift 4.x에 대한 제어 평면 모니터링에는 추가 구성이 필요합니다. 자세한 내용은 OpenShift 4.x 구성 섹션을 참조하십시오.

etcd 쿼리를 위해 mTLS를 설정하려면 다음 두 가지 구성 옵션을 설정해야 합니다.

옵션

ETCD_TLS_SECRET_NAME

mTLS 구성을 포함하는 Kubernetes 시크릿의 이름입니다.

비밀에는 다음 키가 포함되어야 합니다.

  • cert: 요청하는 클라이언트를 식별하는 인증서입니다. etcd의 신뢰할 수 있는 CA에서 서명해야 합니다.

  • key: 클라이언트 인증서를 생성하는 데 사용되는 개인 키입니다.

  • cacert: etcd 서버 인증서를 식별하는 데 사용되는 루트 CA입니다.

    ETCD_TLS_SECRET_NAME 옵션이 설정되어 있지 않으면 etcd 측정항목을 가져오지 않습니다.

ETCD_TLS_SECRET_NAMESPACE

ETCD_TLS_SECRET_NAME 에 지정된 보안 비밀이 생성된 네임스페이스입니다. 설정하지 않으면 default 네임스페이스가 사용됩니다.

API 서버

기본적으로 API 서버 측정항목은 보안되지 않은 localhost:8080 엔드포인트를 사용하여 쿼리됩니다. 이 포트가 비활성화된 경우 보안 포트를 통해 이러한 메트릭을 쿼리할 수도 있습니다. 이를 활성화하려면 Kubernetes 통합 매니페스트 파일에서 다음 구성 옵션을 설정하십시오.

옵션

API_SERVER_ENDPOINT_URL

메트릭을 쿼리하기 위한 (보안) URL입니다. API 서버는 기본적으로 localhost:443 을 사용합니다.

ClusterRole 이 매니페스트에서 찾은 최신 버전으로 업데이트되었는지 확인합니다.

버전 1.15.0에 추가됨

중요

API 서버에서 사용하는 보안 포트에 따라 포트가 다를 수 있습니다.

예를 들어 Minikube에서 API 서버 보안 포트는 8443이므로 API_SERVER_ENDPOINT_URL 를 다음으로 설정해야 합니다. https://localhost:8443

오픈시프트 구성

OpenShift 4.x의 제어 플레인 구성 요소는 SSL 및 서비스 계정 기반 인증이 필요한 엔드포인트 URL을 사용합니다. 따라서 기본 Leavepoint URL을 사용할 수 없습니다.

중요

Helm을 통해 openshift 을 설치할 때 이러한 엔드포인트를 자동으로 포함하도록 구성을 지정합니다. openshift.enabled=trueopenshift.version="4.x" 를 설정하면 보안 엔드포인트가 포함되고 /var/run/crio.sock 런타임이 활성화됩니다.

OpenShift에서 제어 플레인 모니터링을 구성하려면 사용자 정의된 매니페스트 에서 다음 환경 변수의 주석 처리를 제거하세요. URL 값은 OpenShift 4.x의 제어 플레인 모니터링 메트릭 엔드포인트에 대한 기본 기본 URL로 사전 구성되어 있습니다.

- name: "SCHEDULER_ENDPOINT_URL"
value: "https://localhost:10259
- name: "ETCD_ENDPOINT_URL"
value: "https://localhost:9979"
- name: "CONTROLLER_MANAGER_ENDPOINT_URL"
value: "https://localhost:10257"
- name: "API_SERVER_ENDPOINT_URL"
value: "https://localhost:6443"

중요

사용자 정의 ETCD_ENDPOINT_URL 이 정의되었더라도 etcd를 구성하려면 HTTPS 및 mTLS 인증이 필요합니다. OpenShift에서 etcd에 대한 mTLS를 구성하는 방법에 대한 자세한 내용은 OpenShift에서 etcd에 대한 mTLS 설정을 참조하세요.

쿠버네티스 로그

자세한 로그를 생성하고 버전 및 설정 정보를 얻으려면 아래 정보를 확인하세요.

Kubernetes에서 실행되는 서비스 모니터링

Kubernetes의 모니터링 서비스는 인프라 에이전트와 호스트 내 통합 및 자동 검색 메커니즘을 활용하여 지정된 선택기가 있는 포드를 가리키는 방식으로 작동합니다.

수행 방법을 알아보려면 Helm 차트 문서를 사용하여 서비스 모니터링 활성화를 확인하세요. nri-bundle 차트의 values.yml 파일에 추가된 Redis 통합을 위한 yaml 구성을 보여주는 버전 2의 예시를 확인하세요.

newrelic-infrastructure:
integrations_config:
- name: nri-redis.yaml
data:
discovery:
command:
# Run NRI Discovery for Kubernetes
# https://github.com/newrelic/nri-discovery-kubernetes
exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
match:
label.app: redis
integrations:
- name: nri-redis
env:
# using the discovered IP as the hostname address
HOSTNAME: ${discovery.ip}
PORT: 6379
labels:
env: test

Kubernetes 통합 구성에 서비스 YAML 추가

Kubernetes 통합 버전 2를 사용하는 경우 DaemonSet의 specvolumesvolumeMounts 섹션에 이 ConfigMap에 대한 항목을 추가하여 ConfigMap의 모든 파일이 /etc/newrelic-infra/integrations.d/ 에 마운트되도록 해야 합니다. .

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.