중요
Agent Control 및 뉴렐릭 Control은 일반적으로 Kubernetes 에서 사용할 수 있습니다. Linux 및 Windows 호스트 지원은 공개 미리 보기 프로그램에 포함되어 있습니다, 사전 출시 정책에 따라.
에이전트 제어는 쿠버네티스 클러스터 및 호스트에서 실행되어 뉴렐릭 및 오픈 소스 측정, 로그 에이전트의 수명주기를 관리하는 경량 에이전트 감독자입니다. 플릿 컨트롤과 통신하여 플릿 전체에 걸쳐 에이전트를 원격으로 구성, 업데이트 및 모니터링합니다.
개요
규모에 따른 측정, 로그 관리는 노동 집약적이고 오류가 발생하기 쉽습니다. 여러 대리인, 버전 확장 및 설정 드리프트로 인해 텔렙리의 맹점, 규정 준수 위험 및 작은 변경 사항에도 몇 주가 소요되는 조정이 발생할 수 있습니다.
Agent Control은 호스트 또는 클러스터당 한 번 설치하는 확장 가능한 단일 감독자를 제공합니다. 모든 뉴렐릭 및 오픈 소스 에이전트를 최신 상태로 유지하고, 원격 설정을 적용하며, 각 에이전트를 개별적으로 건드리지 않고도 일관된 설정을 적용합니다.
비용 및 데이터 수집 관련 참고 사항
Control은 지원되는 모든 환경에 설치할 수 있으며 유료 권한이 필요하지 않습니다. 감독자 자체는 새로운 텔레메트리를 뉴렐릭에 푸시하지 않습니다. 수집 비용은 관리형 에이전트(인프라, APM, 로그)에서 활성화된 측정, 리소스에 따라 달라집니다.
아키텍처
에이전트 제어는 에이전트 관리에 대해 GitOps와 유사한 선언적 접근 방식을 사용합니다. 플릿 컨트롤에서 받은 원격 설정을 측정의 원하는 상태로 처리하여 플릿에 구현하고 배포하는 것이 클러스터에서 실행되고 있는지 확인합니다.
선언적 엔진: Kubernetes의 Flux
Kubernetes 에서 에이전트 제어는 CNCF 등급 연속 배포 도구인 Flux를 선언적 엔진으로 활용합니다. Flux 컨트롤러는 에이전트 Control에서 제공하는 설정을 기반으로 에이전트를 자동으로 구현, 배포 및 업데이트합니다.
아래 다이어그램은 에이전트 Control을 뉴렐릭 Control(백앤드 및 UI) 및 Flux(클러스터 엔진)에 연결하여 에이전트를 관리하는 방법을 보여줍니다.

에이전트 제어는 로컬 또는 원격 설정을 사용할 수 있습니다. 로컬 설정은 초기 설치 파일에 정의되어 있지만, 원격 설정은 뉴렐릭 Control에서 수신되어 에이전트로 직접 렌더링됩니다. 이를 통해 다음을 포함한 모든 것을 중앙에서 관리할 수 있습니다.
- 자격 증명: 에이전트 제어는 Vault와 같은 외부 비밀 제공자로부터 민감한 자격 증명을 가져와 런타임에 에이전트 설정에 주입할 수 있습니다. 이렇게 하면 자격 증명을 설정 자체에서 제외함으로써 보안이 강화됩니다.
- 에이전트 설정: 에이전트 제어는 원격 설정을 기본 에이전트와 호환되는 형식으로 자동 변환합니다. 이는 뉴렐릭 인프라 에이전트, OpenTelemetry 수집기 등 다양한 유형의 에이전트를 단일 통합 프로세스로 관리할 수 있음을 의미합니다.
각 클러스터와 호스트에 에이전트 제어를 설치하면 옵저버빌리티 실습을 확장할 수 있습니다.
- 전체 함대에 걸친 작업: 전체 함대에 걸쳐 수신 설정 및 수명 주기 작업을 수행합니다.
- 양방향 통신: 에이전트 for 동양 문제 해결, 문제 해결 및 진단을 통한 인증 및 암호화 통신.
- 보안 태세: 자격 증명을 비밀 제공업체로부터 받는 방식을 표준화하여 처리를 중앙 집중화하고, 자격 증명 교체를 자동화하며, 노출 위험을 줄입니다.
중요
이러한 수준의 제어 및 통신을 가능하게 하려면 Control에 특정 권한이 필요합니다. 에이전트 수명 주기를 관리하기 위해 설정을 가져오고 로컬 시스템과 상호 작용할 수 있는 필요한 액세스 권한이 구성되어야 합니다. 구현하다, 배포하다 에이전트 제어인 경우 안전하고 기능적인 환경을 유지하는 데 필요한 권한을 이해하고 부여하는지 확인하세요. 에이전트 제어 권한에 대한 다음 섹션을 참조하세요.
컨트롤은 측정, 계측 등을 관리하는 감독자 역할을 하도록 설계되었으며, 이를 위해서는 사용자 환경 내에서 강력한 작업을 수행할 수 있는 능력이 필요합니다. 필요한 권한을 이해하고 부여하는 것이 매우 중요합니다.
주요 행동
- 에이전트 없이 시작: 에이전트 제어는 기본적으로 관리되는 에이전트가 실행되지 않는 경량 감독자로 설치됩니다. 설치 후 플릿 컨트롤을 통해 구현하다, 배포하다를 정의합니다.
- Linux에서의 원격 설치 및 업그레이드: Linux 호스트에서는 원격 제어를 통해 도구를 원격으로 설치, 구성 및 업그레이드할 수 있습니다. 각 호스트에서 수동으로 개입할 필요가 없습니다.
- 자동 에이전트 마이그레이션 없음: Agent Control은 기존 에이전트 설치를 자동으로 마이그레이션하거나 교체하지 않습니다. Agent Control을 설치하기 전에 기존 에이전트를 제거한 후 플릿위험을 통해 관리하세요. 기존 측정 관리, 로그를 참조하세요.
에이전트 제어 권한
쿠버네티스 클러스터에서 구현하다, 배포하다 및 에이전트를 관리하려면 필요한 권한에 대한 명확한 이해가 필요합니다. 여기에서는 에이전트형 Control과 Flux의 역할을 설명하고, 각 에이전트가 필요한 권한만 갖도록 하면서 에이전트를 안전하게 설치, 업데이트, 제거하기 위해 두 에이전트가 어떻게 상호 작용하는지 알아보겠습니다.
Kubernetes
Kubernetes 환경에서 에이전트 제어는 Flux를 연속 배포 엔진으로 사용하여 에이전트를 설치, 업데이트 및 제거합니다. Control에는 Flux 리소스를 생성하고 관리할 권한이 필요하고, Flux에는 실행 중인 Kubernetes 리소스를 생성하고 업데이트할 수 있는 권한이 필요합니다.
- 에이전트 제어 권한: 에이전트 제어에는
HelmRelease및HelmRepository과 같은 Flux 관련 사용자 지정 리소스를 생성, 읽기, 업데이트 및 삭제할 수 있는 권한이 필요합니다. 이를 통해 Agent Control은 Agent Control 전체 관리자 권한 자체를 부여하지 않고도 Flux에게 무엇을 해야 할지 지시할 수 있습니다. - Flux에 대한 권한: Flux는 Helm 차트의 수명 주기를 관리하기 위해 일반적으로
cluster-admin역할과 같은 높은 권한이 필요합니다. 여기에는 사용자를 대신하여Deployments,DaemonSets,Services,ConfigMaps,Secrets및 기타 Kubernetes 리소스를 생성하는 것이 포함됩니다. 보안을 위해 신뢰할 수 있고 검증된 설정만 Agent Control과 함께 사용하도록 보장하는 것이 모범 사례입니다.
리눅스 호스트
호스트 기반 시스템(현재 공개 미리 보기 중)의 경우 에이전트 제어에는 관리자 권한이 필요합니다. 감독자는 에이전트 수명 주기 작업을 수행하기 위해 루트, 관리자 또는 그와 동등한 권한으로 실행되어야 합니다.
- 새 에이전트 설치: 에이전트 바이너리 및 설정 파일을 시스템 디렉터리에 복사합니다.
- 에이전트 프로세스 관리: 예를 들어 systemd를 사용하여 서비스를 시작, 중지 및 재시작합니다.
- 시스템 데이터 읽기: 로그 및 성능 범위와 같은 시스템 상태, 재고 및 진단에 필요한 시스템 정보에 액세스합니다.
Kubernetes 와 유사하게, Control은 호스트에서 선언적 모델을 따릅니다. 설정에서 원하는 상태를 읽고 해당 상태에 도달하는 데 필요한 작업만 수행합니다. 이는 관리자가 취할 수 있는 조치를 제한하기 위해 고안되었습니다. 관리자 권한은 에이전트를 구성, 설치, 업데이트 및 제거하는 데 사용되며, 임의적이고 승인되지 않은 작업을 수행하는 데 사용해서는 안 됩니다.
에이전트별 권한
에이전트 유형과 해당 설정에 따라 다른 권한이 필요합니다. 예를 들어, Kubernetes API에서 메트릭을 수집하는 에이전트는 파일에서 로그만 읽는 에이전트보다 더 많은 권한이 필요합니다.
에이전트 제어는 이러한 권한을 유연하게 관리하도록 설계되었습니다. Flux는 기능을 수행하기 위해 높은 수준의 접근 권한이 필요하지만, 우리의 목표는 Control이 특정 조합에 필요한 최소한의 권한 만 requests 것입니다. 관리 중인
각 에이전트에 필요한 특정 권한에 대한 자세한 내용은 지원되는 에이전트 유형을 참조하세요.
요구 사항 및 호환성
Kubernetes
쿠버네티스 클러스터에 배포하다 에이전트 제어를 시작하기 전에 다음 전제 조건을 충족하는지 확인하세요.
- Helm 3: Helm 버전 3이 컴퓨터에 설치되어 있어야 합니다. 설치 지침은 Helm 설치를 참조하세요.
- 뉴렐릭 클러스터 키: 귀하의 뉴렐릭 계정에 텔넷리를 보고하려면 클러스터 키가 필요합니다.
- 쿠버네티스 클러스터 이름: 쿠버네티스 클러스터의 이름을 준비하세요. 설치 과정에서 참조하게 될 겁니다.
- 인증 관리자: 에이전트 제어를 설정하고 플릿 위험에 연결하려면 인증 관리자 역할이 있어야 합니다. 자세한 내용은 사용자 관리 개념을 참조하세요.
중요: 기존 측정, 로그
쿠버네티스 클러스터가 이미 뉴렐릭으로 구성된 경우 에이전트 Control을 설치하기 전에 기존 측정, 리소스를 제거해야 합니다. 에이전트 Control을 설치한 후 뉴렐릭 Control을 사용하여 클러스터에 모든 에이전트 에이전트를 설치하고 관리할 수 있습니다. 이 프로세스에 대한 지침은 에이전트 제어를 사용하여 기존 측정 관리를 참조하세요.
경고
동일한 클러스터에 여러 개의 Agent Control을 설치하는 것은 지원되지 않습니다.
Agent Control은 다음과 호환됩니다:
- 마지막 3개의 Kubernetes 마이너 릴리스
- Minikube, Kind, Amazon EKS, Azure AKS 및 Google GKE
뉴렐릭 Kubernetes 에이전트 에이전트 및 뉴렐릭 OpenTelemetry (NRDOT) 수집기와 관련된 시스템 요구 사항은 다음을 참조하세요.
리눅스 호스트
Control을 설치하기 전에 뉴럴릭 계정이 있는지, 그리고 시스템이 아래 요구 사항을 충족하는지 확인하십시오. 우리는 제조업체의 수명이 다할 때까지 이러한 운영 시스템을 지원합니다.
프로세서 아키텍처 | Agent Control은 다음 프로세서를 지원합니다.
|
운영체제 | Agent Control은 제조업체의 수명이 다할 때까지 이러한 운영 시스템을 지원합니다.
|
운영 시스템 세부 정보를 확인하려면 다음 명령을 실행하세요.
$cat /etc/os-releaseWindows 호스트
Windows 에 Control을 설치하기 전에 뉴럴릭 계정이 있고 시스템이 아래 요구 사항을 충족하는지 확인하십시오.
프로세서 아키텍처 | Agent Control은 다음 프로세서를 지원합니다.
|
운영체제 | Agent Control은 다음과 같은 Windows 운영 시스템을 지원합니다.
|
전제 조건 |
|
네트워크 요구 사항 | 에이전트 제어에는 다음과 같은 외부 HTTPS 연결이 필요합니다.
|
Windows 버전을 확인하려면 PowerShell에서 다음 명령을 실행하세요.
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayerWindows 지원 제한 사항
지원되는 에이전트: Windows 호스트에서 에이전트 제어는 현재 뉴렐릭 인프라 에이전트 및 뉴렐릭 OpenTelemetry Collector (NRDOT) 만 지원합니다. 다른 에이전트 유형(APM 에이전트, Fluent Bit, Prometheus, eBPF 등)은 아직 지원되지 않습니다.
최소 버전 요구 사항: Windows 의 에이전트 제어는 다음 최소 버전을 충족하는 에이전트만 관리할 수 있습니다.
인프라 에이전트: 버전 1.71.0 이상
NRDOT(OpenTelemetry Collector): 버전 1.5.0 이상
구현하다, 배포하다 이전 버전을 시도하면 실패합니다.
설정 호환성: Linux 또는 Kubernetes 환경의 설정, 템플릿 및 에이전트 버전은 Windows 와 호환되지 않을 수 있습니다. Windows 지원은 위에 나열된 최소 버전부터 시작하며 해당 버전에서 사용 가능한 기능만 포함합니다. 이전 버전을 적용하거나 다른 환경에서 설정하면 구현, 배포 실패가 발생할 수 있습니다.
자동 마이그레이션 없음: Windows 의 에이전트 제어는 기존 임시 에이전트의 자동 마이그레이션을 지원하지 않습니다. Windows 호스트에 에이전트가 이미 설치되어 있는 경우 먼저 에이전트를 제거한 다음 Agent Control 및 플릿위험을 통해 관리해야 합니다.
플릿 유형 요구 사항: Windows에서 에이전트 제어를 설정할 때는 "Host - Windows" 유형의 플릿을 생성하거나 사용해야 합니다. 이는 Windows 환경에서 정상적인 작동을 위해 필수적입니다.
로그 수집: Windows에서의 로그 수집은 인프라 에이전트에 통합된 Fluent Bit를 통해 지원됩니다. 안드로이드 에이전트 패키지에는 Windows 용 Fluent Bit 바이너리가 포함되어 있어
config_logging설정을 통해 로그 포워딩 기능을 활성화할 수 있습니다.
다음 단계
호환성을 확인하고 모든 필수 조건을 충족했으면 이제 Control을 설치할 준비가 되었습니다.