Kubernetes 통합: 호환성 및 요구 사항

Kubernetes 통합 은 GKE, EKS, AKS, OpenShift 등을 비롯한 다양한 플랫폼과 호환됩니다. 각각은 우리의 통합과 다른 호환성을 가지고 있습니다. 이 페이지에서 더 많은 정보를 찾을 수 있습니다.

요구 사항

New Relic Kubernetes 통합에는 New Relic 계정이 필요합니다. 아직 하지 않았다면 아래에서 무료 New Relic 계정을 만들어 오늘 데이터 모니터링을 시작하십시오.

뉴렐릭 인프라 에이전트와 호환되는 Linux 배포판도 필요합니다.

중요

kube-state-metrics v2 이상은 통합 버전 3.6.0부터 지원됩니다. 또는 더 높게.
버전 3.5.0까지 Kubernetes 통합 설치 kube-state-metrics 1.9.8 이하를 사용하는 경우.
일부 변수가 변경되었을 수 있으므로 kube-state-metrics v1.9.8에서 v2 이상으로 업데이트하는 경우 values.yaml 파일을 확인하세요.

Helm의 호환성 및 요구 사항

Helm이 설치되어 있고 지원되는 최소 버전이 v3인지 확인하세요. Kubernetes 통합 버전 3에는 Helm 버전 3이 필요합니다.
클러스터의 표시 이름을 선택합니다. 예를 들어 다음 출력을 사용할 수 있습니다.
bash
```
$kubectl config current-context
```

매니페스트의 호환성 및 요구 사항

Helm 대신 사용자 지정 매니페스트를 사용한 경우 먼저 kubectl delete -f previous-manifest-file.yml 을 사용하여 이전 설치를 제거한 다음 안내 설치 프로그램을 다시 진행해야 합니다. 그러면 kubectl apply -f manifest-file.yml 을 사용하여 배포할 수 있는 업데이트된 매니페스트 세트가 생성됩니다.

컨테이너 런타임

우리의 Kubernetes 통합은 CRI에 구애받지 않습니다. Containerd와 호환되도록 특별히 테스트되었습니다. Dockershim은 릴리스 1.24부터 Kubernetes 프로젝트에서 제거되었습니다. 자세한 내용은 Dockershim 제거 FAQ를 읽어보세요.

호환성

중요

Openshift를 사용하는 경우 대부분의 경우 kubectl 을 사용할 수도 있지만 kubectl 에는 oc login 또는 oc adm 같은 명령이 없습니다. kubectl oc 를 사용해야 할 수도 있습니다.

당사의 통합은 호환 가능하며 다음 Kubernetes 버전에서 지속적으로 테스트됩니다.

	버전
쿠버네티스 클러스터	1.28에서 1.32까지

중요

Kubernetes 버전 1.26부터 @autoscaling/v2 가 @autoscaling/v2beta2 API를 대체했습니다. 지속적인 HorizontalPodAutoscaling 지표 보고를 위해서는 Kubernetes 버전 1.26+ 클러스터에 kube-state-metrics 버전 2.7+을 설치해야 합니다. 왜냐하면 kube-state-metrics v2.7+만 @autoscaling/v2 API 지원할 수 있기 때문입니다.

쿠버네티스 풍미

Kubernetes 통합은 다양한 특징과 호환됩니다. 다음 항목과의 통합을 테스트했습니다.

맛	Notes
미니쿠베
친절한
K3
Kubeadm
Amazon Elastic Kubernetes Service(EKS)
Amazon Elastic Kubernetes Service Anywhere(EKS-Anywhere)
Fargate의 Amazon Elastic Kubernetes Service(EKS-Fargate)	Fargate 설치 문서
랜처 쿠버네티스 엔진(RKE1)	컨트롤 플레인 구성요소를 계측하려면 추가 구성 이 필요합니다.
Azure Kubernetes 서비스(AKS)
구글 쿠버네티스 엔진(GKE)	표준 및 자동 조종 모드 와 호환됩니다.
오픈시프트	버전 4.14로 테스트됨
VMware 탄주	VMware Tanzu(Pivotal Platform) 버전 2.5-2.11 및 Ops Manager 버전 2.5-2.10과 호환됩니다.

설치 방법에 따라컨트롤 플레인 모니터링 을 사용할 수 없거나 추가 구성이 필요할 수 있습니다.

예를 들어:

etcd, 스케줄러 및 컨트롤러 관리자에 필요한 측정항목을 노출하는 엔드포인트가 없기 때문에 관리형 클러스터(GKE, EKS, AKS) 제어 플레인 계측에 API 서버 측정항목만 스크랩 가능하고 사용할 수 있습니다.
Rancher 제어 평면을 계측하려면 구성요소 /metrics 이(가) 기본적으로 항상 도달할 수 있는 것은 아니고 자동 검색할 수 없기 때문에 몇 가지 추가 구성 이 필요합니다.

리소스 요구 사항

뉴렐릭 Kubernetes 통합을 구현하거나 배포할 때, 모니터링 구성 요소가 효율적으로 작동하도록 적절한 리소스를 할당하는 것이 중요합니다.

다음은 인텔 차트에서 권장하는 각 구성 요소에 대한 최소 리소스 요청 및 한도입니다.

Kubelet 구성 요소

각 노드의 Kubelet 컴포넌트 파드 구현하다, 배포하다에는 다음 컨테이너가 포함되어 있습니다.

Kubelet 컨테이너

CPU:
- 요구: 100m
메모리:
- 요구: 150M
- 한계: 300M

에이전트 컨테이너

CPU:
- 요구: 100m
메모리:
- 요구: 150M
- 한계: 300M

Kube 상태 지표 구성요소

KSM 컨테이너

CPU:
- 요구: 100m
메모리:
- 요구: 150M
- 한계: 850M

포워더 컨테이너

CPU:
- 요구: 100m
메모리:
- 요구: 150M
- 한계: 850M

제어 평면 구성 요소

CPU:
- 요구: 100m
메모리:
- 요구: 150M
- 한계: 300M

에이전트 컨테이너

CPU:
- 요구: 100m
메모리:
- 요구: 150M
- 한계: 300M

다음은 nri-bundle의 일부로 다른 구성 요소에 필요한 권장 리소스 요청 및 제한 사항입니다.

메타데이터 주입

CPU:
- 요구: 100m
메모리:
- 요구: 30M
- 한계: 80M

벌채 반출

다음 컨테이너는 각 노드의 뉴렐릭 로깅 파드 구현하다, 배포하다에 포함되어 있습니다.

CPU:
- 요구: 250m
- 한계: 500m
메모리:
- 요구: 64M
- 한계: 128M

고려 사항

클러스터 크기: 이러한 리소스 권장 사항은 일반적인 클러스터 크기에 대한 것입니다. 더 많은 노드와 파드를 갖춘 대형 유닛의 경우 추가 데이터 볼륨을 처리하기 위해 더 많은 리소스 할당이 필요할 수 있습니다.
사용자 정의 설정: 추가 기능이나 사용자 정의 설정을 활성화하는 경우 리소스를 이에 따라 조정하는 것을 고려하세요.
모니터링 및 조정: 구현, 배포 후 이러한 파드의 자원 사용량을 모니터링하고 실제 사용량에 따라 요청 및 제한을 조정하여 성능 및 비용을 최적화합니다.

이러한 리소스 사양은 뉴렐릭 Kubernetes 통합을 구현하고 배포하는 데 사용되는 Helm 차트의 values.yaml 파일에서 조정할 수 있습니다. 이러한 리소스 요구 사항을 충족함으로써 쿠버네티스 클러스터에 대한 효율적이고 효과적인 모니터링을 뉴렐릭으로 유지할 수 있습니다.

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