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.27에서 1.31까지 |
중요
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) | |
랜처 쿠버네티스 엔진(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
파일에서 조정할 수 있습니다. 이러한 리소스 요구 사항을 충족함으로써 쿠버네티스 클러스터에 대한 효율적이고 효과적인 모니터링을 뉴렐릭으로 유지할 수 있습니다.