3장. 클러스터 로깅
3.1. OpenShift Serverless에서 OpenShift Logging 사용
3.1.1. Red Hat OpenShift용 로깅 하위 시스템 배포 정보
OpenShift Container Platform 클러스터 관리자는 OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 로깅 하위 시스템을 배포하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치할 수 있습니다. Operator가 설치되면 ClusterLogging
사용자 정의 리소스(CR)를 생성하여 로깅 하위 시스템 Pod 및 로깅 하위 시스템을 지원하는 데 필요한 기타 리소스를 예약합니다. Operator는 로깅 하위 시스템의 배포, 업그레이드 및 유지 관리를 담당합니다.
ClusterLogging
CR은 로그를 수집, 저장 및 시각화하기 위해 로깅 스택의 모든 구성 요소를 포함하는 전체 로깅 하위 시스템 환경을 정의합니다. Red Hat OpenShift Logging Operator는 로깅 하위 시스템 CR을 감시하고 그에 따라 로깅 배포를 조정합니다.
관리자와 애플리케이션 개발자는 보기 권한이 있는 프로젝트의 로그를 볼 수 있습니다.
3.1.2. Red Hat OpenShift에 대한 로깅 하위 시스템 배포 및 구성 정보
로깅 하위 시스템은 중소 규모의 OpenShift Container Platform 클러스터에 맞게 튜닝된 기본 구성에서 사용하도록 설계되었습니다.
다음 설치 지침에는 로깅 하위 시스템 인스턴스를 생성하고 로깅 하위 시스템 환경을 구성하는 데 사용할 수 있는 샘플 ClusterLogging
CR(사용자 정의 리소스)이 포함되어 있습니다.
기본 로깅 하위 시스템 설치를 사용하려면 샘플 CR을 직접 사용할 수 있습니다.
배포를 사용자 정의하려면 필요에 따라 샘플 CR을 변경합니다. 이어지는 내용에서는 OpenShift Logging 인스턴스를 설치할 때 수행하거나 설치 후 수정할 수 있는 구성에 대해 설명합니다. ClusterLogging
사용자 정의 리소스 외부에서 수행할 수 있는 수정을 포함하여 각 구성 요소의 작업에 대한 자세한 내용은 구성 섹션을 참조하십시오.
3.1.2.1. 로깅 하위 시스템 구성 및 조정
openshift-logging
프로젝트에 배포된 ClusterLogging
사용자 정의 리소스를 수정하여 로깅 하위 시스템을 구성할 수 있습니다.
설치 시 또는 설치 후 다음 구성 요소를 수정할 수 있습니다.
- 메모리 및 CPU
-
유효한 메모리 및 CPU 값으로
resources
블록을 수정하여 각 구성 요소의 CPU 및 메모리 제한을 모두 조정할 수 있습니다.
spec: logStore: elasticsearch: resources: limits: cpu: memory: 16Gi requests: cpu: 500m memory: 16Gi type: "elasticsearch" collection: logs: fluentd: resources: limits: cpu: memory: requests: cpu: memory: type: "fluentd" visualization: kibana: resources: limits: cpu: memory: requests: cpu: memory: type: kibana
- Elasticsearch 스토리지
-
storageClass
name
및size
매개변수를 사용하여 Elasticsearch 클러스터의 영구 스토리지 클래스 및 크기를 구성할 수 있습니다. Red Hat OpenShift Logging Operator는 이러한 매개변수를 기반으로 Elasticsearch 클러스터의 각 데이터 노드에 대한 PVC(영구 볼륨 클레임)를 생성합니다.
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
이 예제에서는 클러스터의 각 데이터 노드가 "gp2" 스토리지의 "200G"를 요청하는 PVC에 바인딩되도록 지정합니다. 각 기본 분할은 단일 복제본에서 지원합니다.
storage
블록을 생략하면 임시 스토리지만 포함하는 배포가 생성됩니다.
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
- Elasticsearch 복제 정책
Elasticsearch 분할이 클러스터의 여러 데이터 노드에 복제되는 방법을 정의하는 정책을 설정할 수 있습니다.
-
FullRedundancy
. 각 인덱스의 분할이 모든 데이터 노드에 완전히 복제됩니다. -
MultipleRedundancy
. 각 인덱스의 분할이 데이터 노드의 1/2에 걸쳐 있습니다. -
SingleRedundancy
. 각 분할의 단일 사본입니다. 두 개 이상의 데이터 노드가 존재하는 한 항상 로그를 사용할 수 있고 복구할 수 있습니다. -
ZeroRedundancy
. 분할 복사본이 없습니다. 노드가 다운되거나 실패하는 경우 로그를 사용할 수 없거나 로그가 손실될 수 있습니다.
-
3.1.2.2. 수정된 ClusterLogging 사용자 정의 리소스 샘플
다음은 이전에 설명한 옵션을 사용하여 수정한 ClusterLogging
사용자 정의 리소스의 예입니다.
수정된 ClusterLogging
사용자 정의 리소스 샘플
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" retentionPolicy: application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 resources: limits: cpu: 200m memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: limits: memory: 1Gi requests: cpu: 500m memory: 1Gi replicas: 1 collection: logs: type: "fluentd" fluentd: resources: limits: memory: 1Gi requests: cpu: 200m memory: 1Gi