5.5. 설치 후 작업
Red Hat OpenShift Logging Operator를 설치한 후 ClusterLogging
사용자 정의 리소스(CR)를 생성하고 수정하여 배포를 구성할 수 있습니다.
Elasticsearch 로그 저장소를 사용하지 않는 경우 ClusterLogging
사용자 정의 리소스(CR)에서 내부 Elasticsearch logStore
및 Kibana visualization
구성 요소를 제거할 수 있습니다. 이러한 구성 요소를 제거하는 것은 선택 사항이지만 리소스를 절약할 수 있습니다. Elasticsearch 로그 저장소를 사용하지 않는 경우 사용되지 않는 구성 요소 제거를 참조하십시오.
5.5.1. 클러스터 로깅 사용자 정의 리소스 정보
로깅 환경을 변경하려면 ClusterLogging
사용자 정의 리소스(CR)를 생성하고 수정합니다.
ClusterLogging
사용자 정의 리소스 (CR) 샘플
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance 1 namespace: openshift-logging 2 spec: managementState: Managed 3 # ...
5.5.2. 로그 스토리지 구성
ClusterLogging
사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 스토리지 유형을 구성할 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat OpenShift Logging Operator와 LokiStack 또는 Elasticsearch인 내부 로그 저장소를 설치했습니다.
-
ClusterLogging
CR을 생성했습니다.
로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.
프로세스
ClusterLogging
CRlogStore
사양을 수정합니다.ClusterLogging
CR 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... logStore: type: <log_store_type> 1 elasticsearch: 2 nodeCount: <integer> resources: {} storage: {} redundancyPolicy: <redundancy_type> 3 lokistack: 4 name: {} # ...
LokiStack을 로그 저장소로 지정하는
ClusterLogging
CR의 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: managementState: Managed logStore: type: lokistack lokistack: name: logging-loki # ...
다음 명령을 실행하여
ClusterLogging
CR을 적용합니다.$ oc apply -f <filename>.yaml
5.5.3. 로그 수집기 구성
ClusterLogging
사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 수집기 유형을 구성할 수 있습니다.
Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat OpenShift Logging Operator가 설치되어 있습니다.
-
ClusterLogging
CR을 생성했습니다.
프로세스
ClusterLogging
CR컬렉션
사양을 수정합니다.ClusterLogging
CR 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... collection: type: <log_collector_type> 1 resources: {} tolerations: {} # ...
- 1
- 로깅에 사용할 로그 수집기 유형입니다.
벡터
또는fluentd
일 수 있습니다.
다음 명령을 실행하여
ClusterLogging
CR을 적용합니다.$ oc apply -f <filename>.yaml
5.5.4. 로그 시각화 프로그램 구성
ClusterLogging
사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 시각화 프로그램 유형을 구성할 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat OpenShift Logging Operator가 설치되어 있습니다.
-
ClusterLogging
CR을 생성했습니다.
시각화를 위해 AWS 웹 콘솔에서 Red Hat OpenShift Service를 사용하려면 로깅 콘솔 플러그인을 활성화해야 합니다. "웹 콘솔을 사용한 로그 시각화"에 대한 설명서를 참조하십시오.
프로세스
ClusterLogging
CR시각화
사양을 수정합니다.ClusterLogging
CR 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... visualization: type: <visualizer_type> 1 kibana: 2 resources: {} nodeSelector: {} proxy: {} replicas: {} tolerations: {} ocpConsole: 3 logsLimit: {} timeout: {} # ...
다음 명령을 실행하여
ClusterLogging
CR을 적용합니다.$ oc apply -f <filename>.yaml
5.5.5. 네트워크 분리가 활성화될 때 프로젝트 간 트래픽 허용
클러스터 네트워크 플러그인은 네트워크 분리를 시행할 수 있습니다. 이 경우 OpenShift Logging에서 배포한 operator가 포함된 프로젝트 간 네트워크 트래픽을 허용해야 합니다.
네트워크 분리는 다른 프로젝트에 있는 pod 또는 서비스 간의 네트워크 트래픽을 차단합니다. 로깅은 openshift-operators-redhat
프로젝트에 OpenShift Elasticsearch Operator 를 설치하고 openshift-logging
프로젝트에 Red Hat OpenShift Logging Operator 를 설치합니다. 따라서 이 두 프로젝트 간 트래픽을 허용해야 합니다.
AWS의 Red Hat OpenShift Service는 OpenShift SDN 및 OVN-Kubernetes에 대해 네트워크 플러그인에 대해 지원되는 두 가지 옵션을 제공합니다. 이 두 공급업체는 다양한 네트워크 분리 정책을 구현합니다.
OpenShift SDN에는 다음 세 가지 모드가 있습니다.
- 네트워크 정책
- 이는 기본값 모드입니다. 정책을 정의하지 않은 경우 모든 트래픽을 허용합니다. 그러나 사용자가 정책을 정의하는 경우 일반적으로 모든 트래픽을 거부한 다음 예외를 추가하여 시작합니다. 이 프로세스에서는 다른 프로젝트에서 실행 중인 애플리케이션을 중단할 수 있습니다. 따라서 하나의 로깅 관련 프로젝트에서 다른 프로젝트로 트래픽이 송신될 수 있도록 명시적으로 정책을 구성합니다.
- 서브넷
- 이 모드에서는 모든 트래픽을 허용합니다. 네트워크 분리를 적용하지 않습니다. 아무 작업도 필요하지 않습니다.
OVN-Kubernetes는 항상 네트워크 정책을 사용합니다. 따라서 OpenShift SDN과 마찬가지로 하나의 로깅 관련 프로젝트에서 다른 프로젝트로 트래픽이 송신될 수 있도록 정책을 구성해야 합니다.
프로세스
다중 테넌트 모드에서 OpenShift SDN을 사용하는 경우 두 프로젝트에 참여합니다. 예를 들면 다음과 같습니다.
$ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
또는 네트워크 정책 모드 및 OVN-Kubernetes의 OpenShift SDN의 경우 다음 작업을 수행합니다.
openshift-operators-redhat
네임스페이스에서 레이블을 설정합니다. 예를 들면 다음과 같습니다.$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
openshift-operators-redhat
,openshift-monitoring
및openshift-ingress
프로젝트에서openshift-logging
프로젝트에 수신할 수 있는 openshift-logging 네임스페이스에 네트워크 정책 오브젝트를 생성합니다. 예를 들면 다음과 같습니다.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring-ingress-operators-redhat spec: ingress: - from: - podSelector: {} - from: - namespaceSelector: matchLabels: project: "openshift-operators-redhat" - from: - namespaceSelector: matchLabels: name: "openshift-monitoring" - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress