컨트롤 플레인 모니터링 구성

New Relic 은 Kubernetes 통합을 위한 제어 평면 지원을 제공하므로 클러스터의 제어 평면 구성 요소에서 메트릭을 모니터링하고 수집할 수 있습니다. 그 데이터는 New Relic에서 찾을 수 있고 쿼리와 차트를 만드는 데 사용할 수 있습니다.

팁

이 페이지에서는 Kubernetes 통합 v3을 참조합니다. v2를 실행 중인 경우 v2에 대한 제어 플레인 모니터링을 구성하는 방법을 참조하세요.

특징

우리는 다음 컨트롤 플레인 구성 요소에서 지표를 모니터링하고 수집합니다.

etcd: 리더 정보, 상주 메모리 크기, OS 스레드 수, 합의 제안 데이터 등 지원되는 지표 목록은 etcd data 를 참조하세요.
API server: apiserver 요청 비율, HTTP 메소드 및 응답 코드별 apiserver 요청 분석 등 지원되는 지표의 전체 목록은 API 서버 데이터를 참조하세요.
Scheduler: 요청된 CPU/메모리와 노드에서 사용 가능한지, 오염에 대한 허용, 설정된 선호도 또는 반선호도 등 지원되는 지수의 전체 목록은 스케줄러 데이터를 참조하세요.
Controller manager: 상주 메모리 크기, 생성된 OS 스레드 수, 현재 존재하는 고루틴 등 지원되는 지표의 전체 목록은 컨트롤러 관리자 데이터를 참조하세요.

호환성 및 요구 사항

AKS, EKS, GKE를 포함한 대부분의 관리형 클러스터는 제어 영역 구성 요소에 대한 외부 액세스를 허용하지 않습니다.그렇기 때문에 관리되는 클러스터에서 New Relic은 API 서버에 대한 컨트롤 플레인 메트릭만 얻을 수 있고 etcd, 스케줄러 또는 컨트롤러 관리자에 대해서는 얻을 수 없습니다.
비권한 모드 에서 솔루션을 배포할 때 제어 평면 설정에는 추가 단계 가 필요하며 몇 가지 주의 사항이 적용될 수 있습니다.
OpenShift 4.x는 기본값과 다른 제어 평면 구성 요소 메트릭 끝점을 사용합니다.

제어 평면 구성 요소

Kubernetes 제어 영역을 모니터링하는 작업은 기본적으로 DaemonSet으로 구현, 배포되는 nrk8s-controlplane 구성 요소의 책임입니다. 이 구성 요소는 nodeSelectorTerms 의 기본 목록을 사용하여 자동으로 제어 평면 노드에 구현, 배포됩니다. 이 목록에는 node-role.kubernetes.io/control-plane 와 같이 제어 평면 노드를 식별하는 데 일반적으로 사용되는 레이블이 포함됩니다. 그럼에도 불구하고, 이 선택기는 values.yml 파일에 노출되어 있으므로 다른 환경에 맞게 재구성이 가능합니다.

이러한 선택기와 일치하는 노드가 없는 클러스터는 포드가 예약되지 않으므로 리소스를 낭비하지 않으며 기능적으로 Helm 차트에서 controlPlane.enabled 을 false 로 설정하여 제어 평면 모니터링을 비활성화하는 것과 동일합니다.

제어 평면의 각 구성 요소에는 개별적으로 다음을 수행할 수 있는 전용 섹션이 있습니다.

해당 구성 요소의 모니터링 활성화 또는 비활성화
해당 구성 요소를 검색하기 위한 특정 선택기 및 네임스페이스 정의
해당 구성 요소에 대한 메트릭을 가져오는 데 사용할 끝점 및 경로를 정의합니다.
해당 구성 요소에 대한 메트릭을 가져오는 데 사용해야 하는 인증 메커니즘을 정의합니다.
자동 검색을 완전히 건너뛰는 끝점을 수동으로 지정

Diagram showing a possible configuration scraping etcd with mTLS and API server with bearer Token. The monitoring is a DaemonSet deployed on control plane nodes only.

controlPlane 키 아래 nri-kubernetes 차트의 values.yaml 에서 사용 가능한 모든 구성 옵션을 확인할 수 있습니다.

nri-bundle 차트를 통해 통합을 설치하는 경우 해당 하위 차트에 값을 전달해야 합니다. 예를 들어 controlPlane 구성요소에서 etcd 모니터링을 비활성화하려면 다음을 수행할 수 있습니다.

newrelic-infrastructure:
  controlPlane:
    config:
      etcd:
        enabled: false

자동 검색 및 기본 구성

기본적으로 Helm 차트 는 Kubeadm 또는 minikube 과 같이 클러스터 내부에서 제어 영역을 실행하는 온프레미스 배포의 일부 제어 영역 구성 요소에 대해 즉시 작동해야 하는 구성을 제공합니다.

자동 검색은 검색 메커니즘으로 포드 레이블에 의존하기 때문에 클라우드 환경에서 또는 제어 평면 구성 요소가 클러스터 내에서 실행되고 있지 않을 때마다 작동하지 않습니다.그러나 제어 평면 구성 요소에 연결할 수 있는 경우 이러한 시나리오에서 정적 끝점 을 활용할 수 있습니다.

`hostNetwork` 그리고 `privileged`

3보다 높은 버전에서 privileged 플래그는 securityContext 객체, 즉 컨테이너가 호스트 지표에 액세스할 수 있는 루트로 실행되는지 여부에만 영향을 미칩니다. 이제 모든 통합 구성요소의 기본값은 hostNetwork: false 입니다. 단, 대부분의 배포판에서 제어 평면 끝점에 도달하는 데 필요하므로 hostNetwork: true 이 있는 제어 평면에서 지표를 가져오는 패드를 제외합니다. 모든 구성요소의 hostNetwork 값은 values.yaml의 hostNetwork 토글을 사용하여 개별적으로 또는 전체적으로 변경할 수 있습니다.

팁

버전 2와 관련된 특정 설정은 자동 검색 및 기본 구성: hostNetwork 및 privileged 참조하세요.

클러스터 또는 기타 정책으로 인해 hostNetwork 으로 실행 중인 포드가 허용되지 않는 경우 제어 평면 모니터링이 불가능하며 controlPlane.enabled 을 false 로 설정하여 비활성화해야 합니다.

hostNetwork 없이 제어 영역을 모니터링하는 데 사용할 수 있는 사용자 지정 자동 검색 또는 정적 엔드포인트 가 포함된 고급 구성이 있는 경우 프로젝트의 README 를 확인하고 values.yaml 에서 controlPlane.hostNetwork 도구를 찾으세요.

사용자 지정 자동 검색

자동 검색에 사용되는 선택기는 values.yaml 파일의 구성 항목으로 완전히 노출됩니다. 즉, 제어 영역이 클러스터의 일부로 실행되는 거의 모든 환경에 맞게 조정하거나 교체할 수 있습니다.

자동 검색 섹션은 다음과 같습니다.

autodiscover:
  - selector: "tier=control-plane,component=etcd"
    namespace: kube-system
    # Set to true to consider only pods sharing the node with the scraper pod.
    # This should be set to `true` if Kind is Daemonset, `false` otherwise.
    matchNode: true
    # Try to reach etcd using the following endpoints.
    endpoints:
      - url: https://localhost:4001
        insecureSkipVerify: true
        auth:
          type: bearer
      - url: http://localhost:2381
  - selector: "k8s-app=etcd-manager-main"
    namespace: kube-system
    matchNode: true
    endpoints:
      - url: https://localhost:4001
        insecureSkipVerify: true
        auth:
          type: bearer

autodiscover 섹션에는 자동 검색 항목 목록이 있습니다. 각 항목에는 다음이 포함됩니다.

selector: 포드를 찾는 데 사용할 문자열로 인코딩된 레이블 선택기입니다.
matchNode: true로 설정하면 검색을 수행하는 DaemonSet의 특정 인스턴스와 동일한 노드에서 실행되는 포드로 검색을 추가로 제한합니다.
endpoints: 지정된 선택기에 대해 팟(Pod)이 발견되면 시도할 엔드포인트 목록입니다.

또한 각 endpoint 에는 다음이 포함됩니다.

url: 스키마를 포함하여 대상에 대한 URL입니다. http 또는 https 수 있습니다.
insecureSkipVerify: true로 설정하면 인증서에서 https URL을 확인하지 않습니다.
auth.type: 요청을 인증하는 데 사용할 메커니즘입니다. 현재 다음 방법이 지원됩니다.
없음: auth 을 지정하지 않으면 요청에 인증이 포함되지 않습니다.
bearer: Kubernetes API에 대해 인증하는 데 사용된 동일한 전달자 토큰이 이 요청으로 전송됩니다.
mtls: mTLS를 사용하여 요청을 수행합니다.

mTLS

mtls 유형의 경우 다음을 지정해야 합니다.

endpoints:
  - url: https://localhost:4001
    auth:
      type: mtls
      mtls:
        secretName: secret-name
        secretNamespace: secret-namespace

여기서 secret-name 은 secret-namespace 에 있는 Kubernetes TLS 보안 비밀의 이름이며 해당 특정 엔드포인트에 연결하는 데 필요한 인증서, 키 및 CA를 포함합니다.

통합은 이 비밀을 탑재하는 대신 런타임에 가져오므로 액세스 권한을 부여하는 RBAC 역할이 필요합니다. Helm 차트는 렌더링 시 자동으로 auth.mtls 항목을 감지하고 rbac.create 이 false로 설정되지 않는 한 이러한 특정 비밀 및 네임스페이스에 대한 항목을 자동으로 생성합니다.

통합은 다음 키로 비밀을 수락합니다.

cacert: 서명하는 데 사용되는 PEM 인코딩된 CA 인증서 cert
cert: etcd에 제시될 PEM 인코딩 인증서
key: 위의 인증서에 해당하는 PEM으로 인코딩된 개인 키

이러한 인증서는 etcd가 작동하는 데 사용하는 것과 동일한 CA에서 서명해야 합니다.

이러한 인증서를 생성하는 방법은 Kubernetes 배포판마다 크게 다르므로 이 문서의 범위를 벗어납니다. 필요한 etcd 피어 인증서를 가져오는 방법은 배포판의 설명서를 참조하세요. 예를 들어 Kubeadm에서는 제어 평면 노드의 /etc/kubernetes/pki/etcd/peer.{crt,key} 에서 찾을 수 있습니다.

etcd 피어 인증서를 찾거나 생성한 후에는 암호에 있을 것으로 예상되는 키와 일치하도록 파일 이름을 변경하고 클러스터에 암호를 생성해야 합니다.

bash

$mv peer.crt cert
$mv peer.key key
$mv ca.crt cacert
$
$kubectl -n newrelic create secret tls newrelic-etcd-tls-secret --cert=./cert --key=./key --certificate-authority=./cacert

마지막으로 이 섹션의 시작 부분에 표시된 구성 스니펫에 비밀 이름( newrelic-etcd-tls-secret )과 네임스페이스( newrelic )를 입력할 수 있습니다. Helm 차트는 이 구성을 자동으로 구문 분석하고 RBAC 역할을 생성하여 nrk8s-controlplane 구성 요소에 대한 이 특정 비밀 및 네임스페이스에 대한 액세스 권한을 부여하므로 이와 관련하여 수동 작업이 필요하지 않습니다.

정적 엔드포인트

자동 검색은 제어 평면이 Kubernetes 클러스터 내부에 있는 경우를 포함해야 하지만 일부 배포 또는 정교한 Kubernetes 환경은 가용성 또는 리소스 격리를 포함한 다양한 이유로 제어 평면을 다른 곳에서 실행합니다.

이러한 경우 노드에서 컨트롤 플레인 레이블이 있는 포드가 있는지 여부에 관계없이 임의의 고정 URL을 스크랩하도록 통합을 구성할 수 있습니다. 이것은 staticEndpoint 항목을 지정하여 수행됩니다. 예를 들어 외부 etcd 인스턴스에 대한 인스턴스는 다음과 같습니다.

controlPlane:
  etcd:
    staticEndpoint:
      url: https://url:port
      insecureSkipVerify: true
      auth: {}

Diagram showing a possible configuration scraping an external API server with bearer Token. The monitoring is a Deployment with a single replica.

staticEndpoint 위에 설명된 필드의 autodiscover 항목에 있는 endpoints 과 동일한 유형의 항목입니다. 여기에서 인증 메커니즘과 스키마가 지원됩니다.

staticEndpoint 이 설정되면 autodiscover 섹션이 완전히 무시됩니다.

제한 사항

중요

노드 외부(예: localhost 아님) 엔드포인트를 가리키는 staticEndpoint 사용하는 경우 controlPlane.kind DaemonSet 에서 Deployment 로 변경해야 합니다.

staticEndpoint사용할 때 모든 nrk8s-controlplane 포드는 해당 엔드포인트에 도달하고 스크레이핑을 시도합니다. 즉, nrk8s-controlplane 가 DaemonSet(기본값)인 경우 DaemonSet의 모든 인스턴스가 이 끝점을 스크랩합니다. localhost을 가리키는 경우에는 괜찮지만 엔드포인트가 노드에 로컬이 아닌 경우 잠재적으로 메트릭을 복제하고 청구 가능한 사용량을 증가시킬 수 있습니다. staticEndpoint 사용 중이고 로컬이 아닌 URL을 가리키는 경우 controlPlane.kind 배포로 변경해야 합니다.

위와 같은 이유로 현재 일부 제어 평면 구성 요소에는 자동 검색을 사용하고 다른 구성 요소에는 정적 끝점을 사용할 수 없습니다. 이는 향후 통합 버전에서 해결하기 위해 작업 중인 알려진 제한 사항입니다.

마지막으로 staticEndpoint 에서는 구성요소당 단일 엔드포인트만 정의할 수 있습니다. 즉, 서로 다른 호스트에 여러 제어 평면 샤드가 있는 경우 현재 이를 별도로 가리킬 수 없습니다. 이는 향후 버전에서 해결하기 위해 작업 중인 알려진 제한 사항이기도 합니다. 당분간 해결 방법은 다른 곳에서 다른 샤드에 대한 측정항목을 집계하고 staticEndpoint URL이 집계된 출력을 가리키도록 하는 것입니다.

관리 및 클라우드 환경을 위한 제어 평면 모니터링

EKS 또는 GKE와 같은 일부 클라우드 환경에서는 Kubernetes API 서버에서 측정항목을 검색할 수 있습니다. 이것은 정적 엔드포인트로 쉽게 구성할 수 있습니다.

controlPlane:
  affinity: false  # https://github.com/helm/helm/issues/9136
  kind: Deployment
  # `hostNetwork` is not required for monitoring API Server on AKS, EKS
  hostNetwork: false
  config:
    etcd:
      enabled: false
    scheduler:
      enabled: false
    controllerManager:
      enabled: false
    apiServer:
     staticEndpoint:
       url: "https://kubernetes.default:443"
       insecureSkipVerify: true
       auth:
         type: bearer

이는 API 서버에만 적용되며 etcd, 스케줄러 및 컨트롤러 관리자는 클라우드 환경에서 계속 액세스할 수 없습니다.

또한 특정 관리 또는 클라우드 환경에 따라 Kubernetes 서비스가 API 서버의 여러 인스턴스 간에 트래픽을 로드 밸런싱할 수 있습니다.이 경우 로드 밸런서가 선택하는 특정 인스턴스에 의존하는 메트릭은 신뢰할 수 없습니다.

Rancher RKE1에 대한 제어 평면 모니터링

Rancher Kubernetes Engine(RKE1)을 활용하여 배포된 클러스터는 제어 평면 구성 요소를 Kubelet에서 관리하는 Pod가 아닌 Docker 컨테이너로 실행합니다. 그렇기 때문에 통합에서 해당 컨테이너를 자동 검색할 수 없으며 모든 엔드포인트를 통합 구성의 staticEndpoint 섹션에서 수동으로 지정해야 합니다.

통합은 사용 가능한 인증 방법(서비스 계정 토큰, 사용자 지정 mTLS 인증서 또는 없음)을 사용하여 직접 연결하거나 프록시를 통해 다른 끝점에 연결할 수 있어야 합니다.

예를 들어 스케줄러 및 컨트롤러 관리자 측정항목에 연결할 수 있도록 하려면 --authorization-always-allow-paths 플래그 를 추가하여 /metrics 또는 --authentication-kubeconfig 및 --authorization-kubeconfig 에서 토큰 인증을 활성화해야 할 수 있습니다.

지정된 포트에서 모든 구성 요소에 연결할 수 있다고 가정하면 다음 구성은 API 서버, 스케줄러 및 컨트롤러 관리자를 모니터링합니다.

controlPlane:
  kind: DaemonSet
  config:
    scheduler:
      enabled: true
      staticEndpoint:
        url: https://localhost:10259
        insecureSkipVerify: true
        auth:
          type: bearer
    controllerManager:
      enabled: true
      staticEndpoint:
        url: https://localhost:10257
        insecureSkipVerify: true
        auth:
          type: bearer
    apiServer:
      enabled: true
      staticEndpoint:
        url: https://localhost:6443
        insecureSkipVerify: true
        auth:
          type: bearer

이 예에서 통합은 각 staticEndpoint 에 로컬로 연결되기 때문에 hostNetwork 옵션이 true로 설정된 각 제어 영역 구성요소의 동일한 노드에서 실행되어야 합니다. 따라서 controlPlane.kind 는 DaemonSet 으로 유지되어야 합니다. 또한 DaemonSet에는 모니터링하려는 모든 제어 평면 노드에서 모든 인스턴스가 실행되도록 구성된 선호도 규칙, nodeSelector 및 허용 오차가 필요합니다.

node-role.kubernetes.io/controlplane 레이블을 확인하여 제어 영역 노드를 인식할 수 있습니다. 이 레이블은 통합 기본 선호도 규칙에서 이미 고려하고 있습니다.

통합 버전 2를 사용하는 경우 통합 버전 2를 사용한 모니터링 제어 영역을 참조하세요.

오픈시프트 구성

Kubernetes 통합 버전 3에는 OpenShift 클러스터의 제어 평면 구성 요소를 자동 검색하는 기본 설정이 포함되어 있으므로 etcd를 제외한 모든 구성 요소에 대해 즉시 작동해야 합니다.

메트릭 엔드포인트가 OpenShift 환경에서 mTLS 인증을 요구하도록 구성되어 있으므로 Etcd는 기본적으로 지원되지 않습니다. 우리의 통합은 이 구성에서 etcd 메트릭을 가져오기 위해 mTLS 인증을 지원하지만 필요한 mTLS 인증서를 수동으로 생성해야 합니다. 이는 사용자의 명시적인 승인 없이 통합에 대한 광범위한 권한을 부여하는 것을 방지하기 위해 필요합니다.

mTLS 암호를 생성하려면 아래 이 섹션 의 단계를 수행한 다음 mtls 섹션 에 설명된 대로 새로 생성된 암호를 사용하도록 통합을 구성하십시오.

통합 버전 2를 사용하는 경우 통합 버전 2에서 OpenShift를 설정하세요.

OpenShift에서 etcd용 mTLS 설정

OpenShift 4.x에서 etcd에 대한 상호 TLS 인증을 설정하려면 다음 지침을 따르십시오.

클러스터에서 불투명한 비밀로 etcd 클라이언트 인증서를 내보냅니다. 기본 관리형 OpenShift 클러스터에서 비밀 이름은 kube-etcd-client-certs 이며 openshift-monitoring 네임스페이스에 저장됩니다.

bash

$kubectl get secret etcd-client -n openshift-etcd -o yaml > etcd-secret.yaml

etcd-secret.yaml의 내용은 다음과 같습니다.

apiVersion: v1
 data:
   tls.crt: <CERT VALUE>
   tls.key: <KEY VALUE>
 kind: Secret
 metadata:
   creationTimestamp: "2023-03-23T23:19:17Z"
   name: etcd-client
   namespace: openshift-etcd
   resourceVersion: 
   uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 type: kubernetes.io/tls

선택적으로 비밀 이름과 네임스페이스를 의미 있는 이름으로 변경합니다. 다음 단계에서는 비밀 이름과 네임스페이스가 각각 mysecret 및 newrelic 로 변경되었다고 가정합니다.
메타데이터 섹션에서 다음과 같은 불필요한 키를 제거합니다.
- creationTimestamp
- resourceVersion
- uid
새 이름과 네임스페이스로 매니페스트를 설치합니다.
bash
```
$kubectl apply -n newrelic -f etcd-secret.yaml
```

mtls 섹션에 설명된 대로 새로 생성된 암호를 사용하도록 통합을 구성합니다. nri-bundle 차트를 통해 통합을 설치하는 경우 values.yaml 에 다음 구성을 추가하면 됩니다.

newrelic-infrastructure:
 controlPlane:
   enabled: true
   config:
     etcd:
       enabled: true
       autodiscover:
         - selector: "app=etcd,etcd=true,k8s-app=etcd"
           namespace: openshift-etcd
           matchNode: true
           endpoints:
             - url: https://<ETCD_ENDPOINT>:<PORT>
               insecureSkipVerify: true
               auth:
                 type: mTLS
                 mtls:
                   secretName: mysecret
                   secretNamespace: newrelic

데이터 보기

통합이 올바르게 설정된 경우 아래에 표시된 것처럼 모든 제어 평면 구성 요소와 해당 상태가 전용 섹션에 표시된 보기가 표시됩니다.

New Relic - Kubernetes cluster explorer - Control Plane section

one.newrelic.com > All capabilities > Kubernetes 으로 이동하여 왼쪽 탐색 창에서 Control plane 클릭합니다.

이 NRQL 쿼리를 사용하여 제어 평면 데이터를 확인할 수도 있습니다.

SELECT latest(timestamp) 
FROM K8sApiServerSample, K8sEtcdSample, K8sSchedulerSample, K8sControllerManagerSample FACET entityName 
WHERE clusterName = '_MY_CLUSTER_NAME_'

팁

여전히 제어 평면 데이터를 볼 수 없는 경우 이 문제 해결 페이지를 확인하세요.

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