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
# ...

1
CR 이름은 instance여야 합니다.
2
CR은 openshift-logging 네임스페이스에 설치해야 합니다.
3
Red Hat OpenShift Logging Operator 관리 상태입니다. 상태가 Unmanaged 로 설정된 경우 Operator는 지원되지 않는 상태에 있으며 업데이트가 제공되지 않습니다.

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 를 참조하십시오.

절차

  1. ClusterLogging CR logStore 사양을 수정합니다.

    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: {}
    # ...

    1
    로그 저장소 유형을 지정합니다. lokistack 또는 elasticsearch 일 수 있습니다.
    2
    Elasticsearch 로그 저장소에 대한 선택적 구성 옵션입니다.
    3
    중복 유형을 지정합니다. 이 값은 ZeroRedundancy,SingleRedundancy,MultipleRedundancy 또는 FullRedundancy 일 수 있습니다.
    4
    LokiStack에 대한 선택적 구성 옵션입니다.

    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
    # ...

  2. 다음 명령을 실행하여 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을 생성했습니다.

절차

  1. ClusterLogging CR 컬렉션 사양을 수정합니다.

    ClusterLogging CR 예

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      collection:
        type: <log_collector_type> 1
        resources: {}
        tolerations: {}
    # ...

    1
    로깅에 사용할 로그 수집기 유형입니다. 벡터 또는 fluentd 일 수 있습니다.
  2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

    $ oc apply -f <filename>.yaml

5.5.4. 로그 시각화 프로그램 구성

ClusterLogging 사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 시각화 프로그램 유형을 구성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • ClusterLogging CR을 생성했습니다.
중요

시각화에 OpenShift Container Platform 웹 콘솔을 사용하려면 로깅 콘솔 플러그인을 활성화해야 합니다. "웹 콘솔을 사용한 로그 시각화"에 대한 설명서를 참조하십시오.

절차

  1. 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: {}
    # ...

    1
    로깅에 사용할 시각화 프로그램 유형입니다. kibana 또는 ocp-console 일 수 있습니다. Kibana 콘솔은 Elasticsearch 로그 스토리지를 사용하는 배포와만 호환되며 OpenShift Container Platform 콘솔은 LokiStack 배포와만 호환됩니다.
    2
    Kibana 콘솔의 선택적 구성입니다.
    3
    OpenShift Container Platform 웹 콘솔의 선택적 구성입니다.
  2. 다음 명령을 실행하여 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 를 설치합니다. 따라서 이 두 프로젝트 간 트래픽을 허용해야 합니다.

OpenShift Container Platform은 네트워크 플러그인인 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의 경우 다음 작업을 수행합니다.

    1. openshift-operators-redhat 네임스페이스에서 레이블을 설정합니다. 예를 들면 다음과 같습니다.

      $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
    2. openshift-operators-redhat,openshift-monitoringopenshift-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
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.