Red Hat OpenShift Cluster Observability Operator 정보
Cluster Observability Operator 소개.
초록
1장. Cluster Observability Operator 개요 링크 복사링크가 클립보드에 복사되었습니다!
COO(Cluster Observability Operator)는 고도의 사용자 지정 모니터링 스택을 생성하고 관리하기 위해 설계된 OpenShift Container Platform의 선택적 구성 요소입니다. 이를 통해 클러스터 관리자는 기본 OpenShift Container Platform 모니터링 시스템에 비해 각 네임스페이스에 대한 보다 맞춤화되고 자세한 보기를 제공하여 모니터링 요구 사항을 광범위하게 자동화할 수 있습니다.
COO는 다음 모니터링 구성 요소를 배포합니다.
- Prometheus - 원격 쓰기를 사용하여 외부 엔드포인트에 지표를 보낼 수 있는 고가용성 Prometheus 인스턴스입니다.
- Thanos Querier (선택 사항) - 중앙 위치에서 Prometheus 인스턴스 쿼리를 활성화합니다.
- Alertmanager (선택 사항) - 다양한 서비스에 대한 경고 구성 기능을 제공합니다.
- UI 플러그인 (선택 사항) - 모니터링, 로깅, 분산 추적 및 문제 해결을 위한 플러그인으로 관찰 기능 강화
- Korrel8r (선택 사항) - 오픈 소스 Korrel8r 프로젝트에 의해 구동되는 관찰 가능성 신호 상관 관계를 제공합니다.
- 사고 탐지 (선택 사항) - 경고 버스트의 근본 원인을 식별하는 데 도움이 되는 관련 경고를 사고로 그룹화합니다.
1.1. COO 기본 모니터링 스택 비교 링크 복사링크가 클립보드에 복사되었습니다!
COO 구성 요소는 기본 클러스터 내부 모니터링 스택과 독립적으로 작동합니다. 이 스택은 CCMO(Cluster Monitoring Operator)에서 배포 및 관리합니다. 두 Operator에서 배포한 스택 모니터링은 충돌하지 않습니다. CMO에서 배포한 기본 플랫폼 모니터링 구성 요소 외에도 COO 모니터링 스택을 사용할 수 있습니다.
COO와 기본 클러스터 내 모니터링 스택의 주요 차이점은 다음 표에 표시되어 있습니다.
기능 | COO | 기본 모니터링 스택 |
---|---|---|
범위 및 통합 | 클러스터 및 워크로드 성능을 다루는 엔터프라이즈급 요구 사항에 대한 포괄적인 모니터링 및 분석을 제공합니다. 그러나 OpenShift Container Platform과 직접 통합되지 않으며 일반적으로 대시보드를 위해 외부 Grafana 인스턴스가 필요합니다. | 클러스터 내의 핵심 구성 요소(예: API 서버 및 etcd, OpenShift별 네임스페이스)로 제한됩니다. 콘솔에 콘솔 대시보드 및 경고 관리를 포함하여 OpenShift Container Platform과 긴밀하게 통합됩니다. |
구성 및 사용자 정의 | 데이터 보존 기간, 스토리지 방법 및 수집된 데이터 유형을 포함한 광범위한 구성 옵션. COO는 SSA(Server-Side Apply)를 사용하여 사용자 지정 리소스에 있는 단일 구성 가능한 필드의 소유권을 사용자에게 위임할 수 있습니다. | 제한된 사용자 지정 옵션이 포함된 기본 제공 구성입니다. |
데이터 보존 및 스토리지 | 장기 데이터 보존, 기록 분석 및 용량 계획 지원 | 데이터 보존 시간이 단축되어 단기 모니터링 및 실시간 탐지에 중점을 둡니다. |
1.2. COO 사용의 주요 이점 링크 복사링크가 클립보드에 복사되었습니다!
COO를 배포하면 기본 모니터링 스택을 사용하기 어려운 모니터링 요구 사항을 해결할 수 있습니다.
1.2.1. 확장성 링크 복사링크가 클립보드에 복사되었습니다!
- COO 배포 모니터링 스택에 메트릭을 추가할 수 있습니다. 이는 지원을 손실하지 않고 핵심 플랫폼 모니터링에서는 불가능합니다.
- 페더레이션을 통해 코어 플랫폼 모니터링에서 클러스터별 메트릭을 수신할 수 있습니다.
- COO는 추세 예측 및 변칙 탐지와 같은 고급 모니터링 시나리오를 지원합니다.
1.2.2. 멀티 테넌시 지원 링크 복사링크가 클립보드에 복사되었습니다!
- 사용자 네임스페이스당 모니터링 스택을 생성할 수 있습니다.
- 네임스페이스당 여러 스택을 배포하거나 여러 네임스페이스에 대해 단일 스택을 배포할 수 있습니다.
- COO를 사용하면 다른 팀에 대한 경고 및 수신자를 독립적으로 구성할 수 있습니다.
1.2.3. 확장성 링크 복사링크가 클립보드에 복사되었습니다!
- 단일 클러스터에서 여러 모니터링 스택을 지원합니다.
- 수동 샤딩을 통해 대규모 클러스터의 모니터링을 활성화합니다.
- 메트릭이 단일 Prometheus 인스턴스의 기능을 초과하는 경우를 해결합니다.
1.2.4. 유연성 링크 복사링크가 클립보드에 복사되었습니다!
- OpenShift Container Platform 릴리스 사이클과 분리되었습니다.
- 릴리스 반복 속도가 빨라지고 변화하는 요구 사항에 신속하게 대응합니다.
- 경고 규칙에 대한 독립적인 관리
1.3. COO 대상 사용자 링크 복사링크가 클립보드에 복사되었습니다!
COO는 특히 복잡한 멀티 테넌트 엔터프라이즈 환경에서 사용자 정의 기능, 확장성 및 장기 데이터 보존이 필요한 사용자에게 이상적입니다.
1.3.1. 엔터프라이즈급 사용자 및 관리자 링크 복사링크가 클립보드에 복사되었습니다!
엔터프라이즈 사용자에게는 고급 성능 분석, 장기 데이터 보존, 추세 예측 및 기록 분석을 포함하여 OpenShift Container Platform 클러스터에 대한 심층적인 모니터링 기능이 필요합니다. 이러한 기능을 통해 기업은 리소스 사용량을 더 잘 이해하고 성능 문제를 방지하며 리소스 할당을 최적화할 수 있습니다.
1.3.2. 멀티 테넌트 환경의 운영 팀 링크 복사링크가 클립보드에 복사되었습니다!
COO를 사용하면 멀티 테넌시 지원을 통해 다른 팀이 프로젝트 및 애플리케이션에 대한 모니터링 보기를 구성할 수 있으므로 유연한 모니터링 요구 사항이 있는 팀에 적합합니다.
1.3.3. 개발 및 운영 팀 링크 복사링크가 클립보드에 복사되었습니다!
COO는 개발 및 작업 중에 심층적인 문제 해결, 변칙 감지 및 성능 튜닝을 위해 세분화된 모니터링 및 사용자 지정 관찰 기능을 제공합니다.
1.4. Server-Side Apply를 사용하여 Prometheus 리소스 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
server-Side Apply는 Kubernetes 리소스를 공동으로 관리할 수 있는 기능입니다. 컨트롤 플레인은 다양한 사용자와 컨트롤러가 Kubernetes 오브젝트 내에서 필드를 관리하는 방법을 추적합니다. 필드 관리자의 개념을 소개하고 필드의 소유권을 추적합니다. 이 중앙 집중식 제어는 충돌 감지 및 해결을 제공하며 의도하지 않은 덮어쓰기의 위험을 줄입니다.
Client-Side Apply와 비교하면 더 선언적이며 마지막으로 적용된 상태가 아니라 필드 관리를 추적합니다.
- server-Side 적용
- 삭제하고 다시 생성할 필요 없이 리소스의 상태를 업데이트하여 선언적 구성 관리.
- 필드 관리
- 사용자는 다른 필드에 영향을 주지 않고 업데이트할 리소스의 필드를 지정할 수 있습니다.
- 관리형 필드
-
Kubernetes는 메타데이터 내의
managedFields
필드에 있는 각 오브젝트 필드를 관리하는 사용자에 대한 메타데이터를 저장합니다. - 충돌
- 여러 관리자가 동일한 필드를 수정하려고 하면 충돌이 발생합니다. applier는 관리를 덮어쓰거나, 리클립싱(relinquish)하거나, 관리하도록 선택할 수 있습니다.
- 병합 전략
- server-Side Apply는 작업자를 관리하는 작업자에 따라 병합 필드를 적용합니다.
프로세스
다음 구성을 사용하여
MonitoringStack
리소스를 추가합니다.MonitoringStack
오브젝트의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow sample-monitoring-stack
이라는 Prometheus 리소스는coo-demo
네임스페이스에 생성됩니다. 다음 명령을 실행하여 생성된 Prometheus 리소스의 관리형 필드를 검색합니다.oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields
$ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
metadata.managedFields
값을 확인하고,메타데이터
및사양
의 일부 필드가MonitoringStack
리소스에서 관리되는지 확인합니다. MonitoringStack
리소스에서 제어하지 않는 필드를 수정합니다.MonitoringStack
리소스에서 설정하지 않은 필드인spec.enforcedSampleLimit
를 변경합니다.prom-spec-edited.yaml
파일을 생성합니다.prom-spec-edited.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 YAML을 적용합니다.
oc apply -f ./prom-spec-edited.yaml --server-side
$ oc apply -f ./prom-spec-edited.yaml --server-side
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고--server-side
플래그를 사용해야 합니다.변경된 Prometheus 오브젝트를 가져오고
managedFields
에spec.enforcedSampleLimit
이 있는 섹션이 하나 더 있음을 확인합니다.oc get prometheus -n coo-demo
$ oc get prometheus -n coo-demo
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
MonitoringStack
리소스에서 관리하는 필드를 수정합니다.다음 YAML 구성을 사용하여
MonitoringStack
리소스에서 관리하는 필드인spec.LogLevel
을 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
spec.logLevel
추가
다음 명령을 실행하여 YAML을 적용합니다.
oc apply -f ./prom-spec-edited.yaml --server-side
$ oc apply -f ./prom-spec-edited.yaml --server-side
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
spec.logLevel
필드는observability-operator
에서 이미 관리하므로 Server-Side Apply를 사용하여 변경할 수 없습니다. --force-conflicts
플래그를 사용하여 변경 사항을 강제 적용합니다.oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts
$ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied
prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow --force-conflicts
플래그를 사용하면 필드를 강제로 변경할 수 있지만 동일한 필드가MonitoringStack
리소스에서도 관리되므로 Observability Operator는 변경 사항을 감지하고MonitoringStack
리소스에서 설정한 값으로 되돌립니다.참고MonitoringStack
리소스에서 생성한 일부 Prometheus 필드는MonitoringStack
사양
스탠자의 필드(예:logLevel
)의 영향을 받습니다. 이는MonitoringStack
사양
을 변경하여 변경할 수 있습니다.Prometheus 오브젝트에서
logLevel
을 변경하려면 다음 YAML을 적용하여MonitoringStack
리소스를 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 변경 사항이 수행되었는지 확인하려면 다음 명령을 실행하여 로그 수준을 쿼리합니다.
oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'
$ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
info
info
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
새 버전의 Operator가 이전에 액터에 의해 생성 및 제어되는 필드를 생성하면 액터에 의해 설정된 값이 재정의됩니다.
예를 들어
MonitoringStack
리소스에서 생성하지 않는enforcedSampleLimit
필드를 관리하고 있습니다. Observability Operator가 업그레이드되고 새 버전의 Operator가enforcedSampleLimit
에 대한 값을 생성하는 경우 이전에 설정한 값을 덮어씁니다.-
MonitoringStack
리소스에서 생성한Prometheus
오브젝트에는 모니터링 스택에서 명시적으로 설정하지 않은 일부 필드가 포함될 수 있습니다. 이러한 필드는 기본값이 있기 때문에 나타납니다.