3장. OpenShift Logging 설치
OpenShift Elasticsearch 및 Red Hat OpenShift Logging Operator를 배포하여 OpenShift Logging을 설치할 수 있습니다. OpenShift Elasticsearch Operator는 OpenShift Logging에 사용되는 Elasticsearch 클러스터를 생성하고 관리합니다. Red Hat OpenShift Logging Operator는 로깅 스택의 구성 요소를 생성하고 관리합니다.
OpenShift Container Platform에 OpenShift Logging을 배포하는 프로세스에는 다음이 포함됩니다.
- OpenShift Logging 스토리지 고려 사항 검토.
- OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator 설치
3.1. 웹 콘솔을 사용하여 OpenShift Logging 설치
OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치할 수 있습니다.
즉, 기본 Elasticsearch 로그 저장소를 사용하지 않는 경우 ClusterLogging
사용자 정의 리소스(CR)에서 내부 Elasticsearch logStore
, Kibana visualization
구성 요소를 제거할 수 있습니다. 이러한 구성 요소를 제거하는 것은 선택 사항이지만 리소스를 절약할 수 있습니다. 자세한 내용은 기본 Elasticsearch 로그 저장소를 사용하지 않는 경우 사용되지 않는 구성 요소 제거를 참조하십시오.
사전 요구 사항
Elasticsearch에 필요한 영구 스토리지가 있는지 확인합니다. 각 Elasticsearch 노드에는 자체 스토리지 볼륨이 필요합니다.
참고영구 스토리지에 로컬 볼륨을 사용하는 경우
LocalVolume
개체에서volumeMode: block
에 설명된 원시 블록 볼륨을 사용하지 마십시오. Elasticsearch는 원시 블록 볼륨을 사용할 수 없습니다.Elasticsearch는 메모리를 많이 사용하는 애플리케이션입니다. 기본적으로 OpenShift Container Platform은 메모리 요청 및 제한이 16GB인 3 개의 Elasticsearch 노드를 설치합니다. 이 초기 3개의 OpenShift Container Platform 노드 세트에는 클러스터 내에서 Elasticsearch를 실행하기에 충분한 메모리가 없을 수 있습니다. Elasticsearch와 관련된 메모리 문제가 발생하는 경우 기존 노드의 메모리를 늘리는 대신 클러스터에 Elasticsearch 노드를 더 추가합니다.
프로세스
OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치하려면 다음을 수행합니다.
OpenShift Elasticsearch Operator를 설치합니다.
-
OpenShift Container Platform 웹 콘솔에서 Operator
OperatorHub를 클릭합니다. - 사용 가능한 Operator 목록에서 OpenShift Elasticsearch Operator를 선택한 다음 설치를 클릭합니다.
- 설치 모드에서 클러스터의 모든 네임스페이스가 선택되어 있는지 확인합니다.
설치된 네임스페이스에서 openshift-operators-redhat이 선택되어 있는지 확인합니다.
openshift-operators-redhat
네임스페이스를 지정해야 합니다.openshift-operators
네임스페이스에 신뢰할 수 없는 Community Operator가 포함될 수 있고, 여기에서 OpenShift Container Platform 지표와 동일한 이름의 지표를 게시하면 충돌이 발생합니다.이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.
이 옵션은 네임스페이스 오브젝트에서
openshift.io/cluster-monitoring: "true"
레이블을 설정합니다. 클러스터 모니터링이openshift-operators-redhat
네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.- stable-5.x을 업데이트 채널로 선택합니다.
승인 전략을 선택합니다.
- 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
- 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
- 설치를 클릭합니다.
-
Operator
설치된 Operator 페이지로 전환하여 OpenShift Elasticsearch Operator가 설치되었는지 확인합니다. - 상태가 성공인 모든 프로젝트에 OpenShift Elasticsearch Operator가 나열되어 있는지 확인합니다.
-
OpenShift Container Platform 웹 콘솔에서 Operator
Red Hat OpenShift Logging Operator를 설치합니다.
-
OpenShift Container Platform 웹 콘솔에서 Operator
OperatorHub를 클릭합니다. - 사용 가능한 Operator 목록에서 Red Hat OpenShift Logging을 선택한 다음 설치를 클릭합니다.
- 설치 모드에서 클러스터의 특정 네임스페이스가 선택되어 있는지 확인합니다.
- 설치된 네임스페이스에서 Operator 권장 네임스페이스가 openshift-logging인지 확인하십시오.
이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.
이 옵션은 네임스페이스 오브젝트에서
openshift.io/cluster-monitoring: "true"
레이블을 설정합니다. 클러스터 모니터링이openshift-logging
네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.- stable-5.x을 업데이트 채널로 선택합니다.
승인 전략을 선택합니다.
- 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
- 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
- 설치를 클릭합니다.
-
Operator
설치된 Operator 페이지로 전환하여 Red Hat OpenShift Logging Operator가 설치되었는지 확인합니다. Red Hat OpenShift Logging이 openshift-logging 프로젝트에 성공 상태로 나열되어 있는지 확인합니다.
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
-
Operator
설치된 Operator 페이지로 전환하여 상태 열에 오류 또는 실패가 있는지 점검합니다. -
워크로드
Pod 페이지로 전환하고 openshift-logging
프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.
-
Operator
-
OpenShift Container Platform 웹 콘솔에서 Operator
OpenShift Logging 인스턴스를 생성합니다.
-
관리
사용자 정의 리소스 정의 페이지로 전환합니다. - 사용자 정의 리소스 정의 페이지에서 ClusterLogging을 클릭합니다.
- 사용자 정의 리소스 정의 상세 정보 페이지의 작업 메뉴에서 인스턴스 보기를 선택합니다.
ClusterLoggings 페이지에서 ClusterLogging 생성을 클릭합니다.
데이터를 로드하기 위해 페이지를 새로 고쳐야 할 수도 있습니다.
YAML 필드에서 코드를 다음으로 교체합니다.
참고이 기본 OpenShift Logging 구성은 다양한 환경을 지원해야 합니다. OpenShift Logging 클러스터에 수행할 수 있는 수정 사항에 대한 정보는 OpenShift Logging 구성 요소 튜닝 및 구성 주제를 검토하십시오.
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" 1 namespace: "openshift-logging" spec: managementState: "Managed" 2 logStore: type: "elasticsearch" 3 retentionPolicy: 4 application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 5 storage: storageClassName: "<storage_class_name>" 6 size: 200G resources: 7 limits: memory: "16Gi" requests: memory: "16Gi" proxy: 8 resources: limits: memory: 256Mi requests: memory: 256Mi redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" 9 kibana: replicas: 1 collection: logs: type: "fluentd" 10 fluentd: {}
- 1
- 이름은
instance
이어야 합니다. - 2
- OpenShift Logging 관리 상태입니다. 경우에 따라 OpenShift Logging 기본값을 변경하는 경우 이를
Unmanaged
로 설정해야 합니다. 그러나 관리되지 않는 배포는 OpenShift Logging이 다시 Managed 상태로 될 때까지 업데이트를 받지 않습니다. - 3
- Elasticsearch 구성을 위한 설정입니다. CR을 사용하여 shard 복제 정책 및 영구 스토리지를 구성할 수 있습니다.
- 4
- Elasticsearch가 각 로그 소스를 유지해야 하는 시간을 지정합니다. 정수 및 시간 지정을 입력합니다(주(w), 시간(h/H), 분(m) 및 초(s)). 예를 들어 7일은
7d
입니다.maxAge
보다 오래된 로그는 삭제됩니다. 각 로그 소스에 대한 보존 정책을 지정해야 합니다. 그렇지 않으면 해당 소스에 대해 Elasticsearch 인덱스가 생성되지 않습니다. - 5
- Elasticsearch 노드 수를 지정합니다. 이 목록 뒤에 나오는 참고 사항을 참조하십시오.
- 6
- Elasticsearch 스토리지의 기존 스토리지 클래스 이름을 입력합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. 스토리지 클래스를 지정하지 않으면 OpenShift Logging은 임시 스토리지를 사용합니다.
- 7
- 필요에 따라 Elasticsearch에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시
16Gi
이고 CPU 요청 시1
입니다. - 8
- 필요에 따라 Elasticsearch 프록시에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시
256Mi
이고 CPU 요청 시100m
입니다. - 9
- Kibana 구성을 위한 설정입니다. CR을 사용하여 중복성을 위해 Kibana를 확장하고 Kibana 노드의 CPU 및 메모리를 구성할 수 있습니다. 자세한 내용은 로그 시각화 프로그램 구성을 참조하십시오.
- 10
- Fluentd 구성을 위한 설정입니다. CR을 사용하여 Fluentd CPU 및 메모리 제한을 구성할 수 있습니다. 자세한 내용은 Fluentd 구성을 참조하십시오.
참고Elasticsearch 컨트롤 플레인 노드(마스터 노드라고도 함)의 최대 수는 3입니다.
3
보다 큰nodeCount
를 지정하면 OpenShift Container Platform은 마스터, 클라이언트 및 데이터 역할을 가진 마스터 적격 노드인 Elasticsearch 노드 3개를 생성합니다. 추가 Elasticsearch 노드는 클라이언트 및 데이터 역할을 사용하여 데이터 전용 노드로 생성됩니다. 컨트롤 플레인 노드는 인덱스 작성 또는 삭제, shard 할당 및 추적 노드와 같은 클러스터 전체 작업을 수행합니다. 데이터 노드는 shard를 보유하고 CRUD, 검색 및 집계와 같은 데이터 관련 작업을 수행합니다. 데이터 관련 작업은 I/O, 메모리 및 CPU 집약적입니다. 현재 노드에 과부하가 걸리면 이러한 리소스를 모니터링하고 더 많은 데이터 노드를 추가하는 것이 중요합니다.예를 들어
nodeCount = 4
인 경우 다음 노드가 생성됩니다.$ oc get deployment
출력 예
cluster-logging-operator 1/1 1 1 18h elasticsearch-cd-x6kdekli-1 0/1 1 0 6m54s elasticsearch-cdm-x6kdekli-1 1/1 1 1 18h elasticsearch-cdm-x6kdekli-2 0/1 1 0 6m49s elasticsearch-cdm-x6kdekli-3 0/1 1 0 6m44s
인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.
-
생성을 클릭합니다. 이렇게 하면 OpenShift Logging 구성 요소,
Elasticsearch
사용자 정의 리소스 및 구성 요소, Kibana 인터페이스가 생성됩니다.
-
관리
설치를 확인합니다.
-
워크로드
Pod 페이지로 전환합니다. openshift-logging 프로젝트를 선택합니다.
다음 목록과 유사한 OpenShift Logging, Elasticsearch, Fluentd 및 Kibana에 대한 여러 Pod가 표시됩니다.
- cluster-logging-operator-cb795f8dc-xkckc
- elasticsearch-cdm-b3nqzchd-1-5c6797-67kfz
- elasticsearch-cdm-b3nqzchd-2-6657f4-wtprv
- elasticsearch-cdm-b3nqzchd-3-588c65-clg7g
- fluentd-2c7dg
- fluentd-9z7kk
- fluentd-br7r2
- fluentd-fn2sb
- fluentd-pb2f8
- fluentd-zqgqx
- kibana-7fb4fd4cc9-bvt4p
-
워크로드
추가 리소스