검색

10.2. 로그 스토리지 설치

download PDF

OpenShift CLI(oc) 또는 OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Container Platform 클러스터에 로그 저장소를 배포할 수 있습니다.

참고

로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

10.2.1. Loki 로그 저장소 배포

Loki Operator를 사용하여 OpenShift Container Platform 클러스터에 내부 Loki 로그 저장소를 배포할 수 있습니다. Loki Operator를 설치한 후 보안을 생성하여 Loki 오브젝트 스토리지를 구성하고 LokiStack CR(사용자 정의 리소스)을 생성해야 합니다.

10.2.1.1. Loki 배포 크기 조정

Loki의 크기 조정은 1x.<size> 형식을 따릅니다. 여기서 1x 값은 인스턴스 수이고 < size >는 성능 기능을 지정합니다.

중요

배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

표 10.1. Loki 크기 조정
 1x.demo1x.extra-small1x.small1x.medium

데이터 전송

데모만 사용

100GB/일

500GB/day

2TB/day

초당 쿼리(QPS)

데모만 사용

200ms에서 1-25 QPS

25-50 QPS (200ms)

25-75 QPS (200ms)

복제 요인

없음

2

2

2

총 CPU 요청

없음

14개의 vCPU

34 vCPU

54 vCPU

ruler을 사용하는 경우 총 CPU 요청

없음

16개의 vCPU

42 vCPU

70개의 vCPU

총 메모리 요청

없음

31Gi

67Gi

139Gi

룰러를 사용하는 경우 총 메모리 요청

없음

35Gi

83Gi

171Gi

총 디스크 요청

40Gi

430Gi

430Gi

590Gi

ruler을 사용하는 경우 총 디스크 요청

80Gi

750Gi

750Gi

910Gi

10.2.1.2. OpenShift Container Platform 웹 콘솔을 사용하여 Loki Operator 설치

OpenShift Container Platform 클러스터에 로깅을 설치하고 구성하려면 추가 Operator를 설치해야 합니다. 이 작업은 웹 콘솔 내의 Operator Hub에서 수행할 수 있습니다.

OpenShift Container Platform Operator는 CR(사용자 정의 리소스)을 사용하여 애플리케이션 및 해당 구성 요소를 관리합니다. 높은 수준의 구성 및 설정은 CR 내에서 사용자가 제공합니다. Operator는 고급 지시문을 Operator 논리에 포함된 모범 사례를 기반으로 하위 수준 작업으로 변환합니다. CRD(사용자 정의 리소스 정의)는 CR을 정의하고 Operator 사용자가 사용할 수 있는 모든 구성을 나열합니다. Operator를 설치하면 CRD가 생성되는 CR을 생성하는 데 사용됩니다.

사전 요구 사항

  • 지원되는 오브젝트 저장소(AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation)에 액세스할 수 있습니다.
  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

절차

  1. OpenShift Container Platform 웹 콘솔 관리자 화면에서 Operator OperatorHub 로 이동합니다.
  2. 키워드로 필터링 필드에 Loki Operator를 입력합니다. 사용 가능한 Operator 목록에서 Loki Operator 를 클릭한 다음 설치를 클릭합니다.

    중요

    Community Loki Operator는 Red Hat에서 지원하지 않습니다.

  3. 업데이트 채널로 stable 또는 stable-x.y 를 선택합니다.

    참고

    stable 채널은 최신 로깅 릴리스에 대한 업데이트만 제공합니다. 이전 릴리스에 대한 업데이트를 계속 받으려면 서브스크립션 채널을 stable-x.y 로 변경해야 합니다. 여기서 x.y 는 설치한 로깅 및 마이너 버전을 나타냅니다. 예를 들면 stable-5.7 입니다.

    Loki Operator는 글로벌 Operator 그룹 네임스페이스 openshift-operators-redhat 에 배포되어야 하므로 설치 모드설치된 네임스페이스 가 이미 선택되어 있습니다. 이 네임스페이스가 아직 없는 경우 이를 위해 생성됩니다.

  4. 이 네임스페이스에서 operator-recommended 클러스터 모니터링 사용을 선택합니다.

    이 옵션은 Namespace 오브젝트에서 openshift.io/cluster-monitoring: "true" 라벨을 설정합니다. 클러스터 모니터링이 openshift-operators-redhat 네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.

  5. 업데이트 승인 의 경우 자동 을 선택한 다음 설치를 클릭합니다.

    서브스크립션의 승인 전략이 자동으로 설정된 경우 선택한 채널에서 새 Operator 버전을 사용할 수 있는 즉시 업데이트 프로세스가 시작됩니다. 승인 전략이 Manual 로 설정된 경우 보류 중인 업데이트를 수동으로 승인해야 합니다.

검증

  1. Operator 설치된 Operator 로 이동합니다.
  2. openshift-logging 프로젝트가 선택되어 있는지 확인합니다.
  3. 상태 열에서 InstallSucceeded 가 포함된 녹색 확인 표시와 최대 날짜 텍스트가 표시되는지 확인합니다.
참고

Operator는 설치가 완료되기 전에 실패 상태를 표시할 수 있습니다. Operator 설치가 InstallSucceeded 메시지와 함께 완료되면 페이지를 새로 고칩니다.

10.2.1.3. 웹 콘솔을 사용하여 Loki 오브젝트 스토리지의 보안 생성

Loki 오브젝트 스토리지를 구성하려면 보안을 생성해야 합니다. OpenShift Container Platform 웹 콘솔을 사용하여 시크릿을 생성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • Loki Operator를 설치했습니다.

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 관점에서 워크로드 시크릿 으로 이동합니다.
  2. 생성 드롭다운 목록에서 YAML 에서 선택합니다.
  3. access_key_idaccess_key_secret 필드를 사용하여 인증 정보 및 버킷 이름,끝점, 지역 필드를 지정하여 오브젝트 스토리지 위치를 정의하는 시크릿을 생성합니다. AWS는 다음 예제에서 사용됩니다.

    Secret 오브젝트의 예

    apiVersion: v1
    kind: Secret
    metadata:
      name: logging-loki-s3
      namespace: openshift-logging
    stringData:
      access_key_id: AKIAIOSFODNN7EXAMPLE
      access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
      bucketnames: s3-bucket-name
      endpoint: https://s3.eu-central-1.amazonaws.com
      region: eu-central-1

10.2.1.4. 웹 콘솔을 사용하여 LokiStack 사용자 정의 리소스 생성

OpenShift Container Platform 웹 콘솔을 사용하여 LokiStack CR(사용자 정의 리소스)을 생성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • Loki Operator를 설치했습니다.

절차

  1. Operator 설치된 Operator 페이지로 이동합니다. 모든 인스턴스 탭을 클릭합니다.
  2. Create new 드롭다운 목록에서 LokiStack 을 선택합니다.
  3. YAML 보기를 선택한 다음 다음 템플릿을 사용하여 LokiStack CR을 생성합니다.

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 1
      namespace: openshift-logging
    spec:
      size: 1x.small 2
      storage:
        schemas:
        - version: v12
          effectiveDate: '2022-06-01'
        secret:
          name: logging-loki-s3 3
          type: s3 4
      storageClassName: <storage_class_name> 5
      tenants:
        mode: openshift-logging 6
    1
    logging-loki 라는 이름을 사용합니다.
    2
    배포 크기를 지정합니다. 로깅 5.8 이상 버전에서 Loki의 프로덕션 인스턴스에 지원되는 크기 옵션은 1x.extra- #159 ,1x. windows 또는 1x.medium 입니다.
    중요

    배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

    3
    로그 스토리지에 사용되는 시크릿을 지정합니다.
    4
    해당 스토리지 유형을 지정합니다.
    5
    임시 스토리지의 스토리지 클래스 이름을 입력합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. oc get storageclasses 명령을 사용하여 클러스터에 사용 가능한 스토리지 클래스를 나열할 수 있습니다.
    6
    LokiStack은 기본적으로 다중 테넌트 모드에서 실행되며 수정할 수 없습니다. 각 로그 유형( audit, infrastructure, application logs)에 대해 하나의 테넌트가 제공됩니다. 이를 통해 개별 사용자 및 사용자 그룹에 대한 액세스 제어를 다른 로그 스트림에 사용할 수 있습니다.
  4. 생성을 클릭합니다.

10.2.1.5. CLI를 사용하여 Loki Operator 설치

OpenShift Container Platform 클러스터에 로깅을 설치하고 구성하려면 추가 Operator를 설치해야 합니다. 이 작업은 OpenShift Container Platform CLI에서 수행할 수 있습니다.

OpenShift Container Platform Operator는 CR(사용자 정의 리소스)을 사용하여 애플리케이션 및 해당 구성 요소를 관리합니다. 높은 수준의 구성 및 설정은 CR 내에서 사용자가 제공합니다. Operator는 고급 지시문을 Operator 논리에 포함된 모범 사례를 기반으로 하위 수준 작업으로 변환합니다. CRD(사용자 정의 리소스 정의)는 CR을 정의하고 Operator 사용자가 사용할 수 있는 모든 구성을 나열합니다. Operator를 설치하면 CRD가 생성되는 CR을 생성하는 데 사용됩니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 지원되는 오브젝트 저장소에 액세스할 수 있습니다. 예를 들어 AWS S3, Google Cloud Storage, Azure, Swift, Minio 또는 OpenShift Data Foundation입니다.

절차

  1. Subscription 오브젝트를 생성합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: loki-operator
      namespace: openshift-operators-redhat 1
    spec:
      channel: stable 2
      name: loki-operator
      source: redhat-operators 3
      sourceNamespace: openshift-marketplace
    1
    openshift-operators-redhat 네임스페이스를 지정해야 합니다.
    2
    stable 또는 stable -5.<y&gt;를 채널로 지정합니다.
    3
    redhat-operators를 지정합니다. OpenShift Container Platform 클러스터가 제한된 네트워크(연결이 끊긴 클러스터)에 설치된 경우 OLM(Operator Lifecycle Manager)을 구성할 때 생성된 CatalogSource 오브젝트의 이름을 지정합니다.
  2. Subscription 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml

10.2.1.6. CLI를 사용하여 Loki 오브젝트 스토리지의 보안 생성

Loki 오브젝트 스토리지를 구성하려면 보안을 생성해야 합니다. OpenShift CLI(oc)를 사용하여 이 작업을 수행할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  • 다음 명령을 실행하여 인증서 및 키 파일이 포함된 디렉터리에 보안을 생성합니다.

    $ oc create secret generic -n openshift-logging <your_secret_name> \
     --from-file=tls.key=<your_key_file>
     --from-file=tls.crt=<your_crt_file>
     --from-file=ca-bundle.crt=<your_bundle_file>
     --from-literal=username=<your_username>
     --from-literal=password=<your_password>
참고

최상의 결과를 위해 일반 또는 불투명한 보안을 사용하십시오.

검증

  • 다음 명령을 실행하여 보안이 생성되었는지 확인합니다.

    $ oc get secrets

10.2.1.7. CLI를 사용하여 LokiStack 사용자 정의 리소스 생성

OpenShift CLI(oc)를 사용하여 LokiStack CR(사용자 정의 리소스)을 생성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  1. LokiStack CR을 생성합니다.

    LokiStack CR의 예

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      size: 1x.small 1
      storage:
        schemas:
        - version: v12
          effectiveDate: "2022-06-01"
        secret:
          name: logging-loki-s3 2
          type: s3 3
      storageClassName: <storage_class_name> 4
      tenants:
        mode: openshift-logging 5

    1
    배포 크기를 지정합니다. 로깅 5.8 이상 버전에서 Loki의 프로덕션 인스턴스에 지원되는 크기 옵션은 1x.extra- #159 ,1x. windows 또는 1x.medium 입니다.
    중요

    배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

    2
    로그 저장소 시크릿의 이름을 지정합니다.
    3
    로그 저장소 시크릿 유형을 지정합니다.
    4
    임시 스토리지의 스토리지 클래스 이름을 지정합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. oc get storageclasses 명령을 사용하여 클러스터에 사용 가능한 스토리지 클래스를 나열할 수 있습니다.
    5
    LokiStack은 기본적으로 다중 테넌트 모드에서 실행되며 수정할 수 없습니다. 각 로그 유형( audit, infrastructure, application logs)에 대해 하나의 테넌트가 제공됩니다. 이를 통해 개별 사용자 및 사용자 그룹에 대한 액세스 제어를 다른 로그 스트림에 사용할 수 있습니다.
  2. 다음 명령을 실행하여 LokiStack CR을 적용합니다.

    $ oc apply -f <filename>.yaml

검증

  • 다음 명령을 실행하고 출력을 관찰하여 openshift-logging 프로젝트에 Pod를 나열하여 설치를 확인합니다.

    $ oc get pods -n openshift-logging

    다음 목록과 유사하게 로깅 구성 요소에 대한 여러 Pod가 표시되는지 확인합니다.

    출력 예

    NAME                                           READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-78fddc697-mnl82       1/1     Running   0          14m
    collector-6cglq                                2/2     Running   0          45s
    collector-8r664                                2/2     Running   0          45s
    collector-8z7px                                2/2     Running   0          45s
    collector-pdxl9                                2/2     Running   0          45s
    collector-tc9dx                                2/2     Running   0          45s
    collector-xkd76                                2/2     Running   0          45s
    logging-loki-compactor-0                       1/1     Running   0          8m2s
    logging-loki-distributor-b85b7d9fd-25j9g       1/1     Running   0          8m2s
    logging-loki-distributor-b85b7d9fd-xwjs6       1/1     Running   0          8m2s
    logging-loki-gateway-7bb86fd855-hjhl4          2/2     Running   0          8m2s
    logging-loki-gateway-7bb86fd855-qjtlb          2/2     Running   0          8m2s
    logging-loki-index-gateway-0                   1/1     Running   0          8m2s
    logging-loki-index-gateway-1                   1/1     Running   0          7m29s
    logging-loki-ingester-0                        1/1     Running   0          8m2s
    logging-loki-ingester-1                        1/1     Running   0          6m46s
    logging-loki-querier-f5cf9cb87-9fdjd           1/1     Running   0          8m2s
    logging-loki-querier-f5cf9cb87-fp9v5           1/1     Running   0          8m2s
    logging-loki-query-frontend-58c579fcb7-lfvbc   1/1     Running   0          8m2s
    logging-loki-query-frontend-58c579fcb7-tjf9k   1/1     Running   0          8m2s
    logging-view-plugin-79448d8df6-ckgmx           1/1     Running   0          46s

10.2.2. Loki 오브젝트 스토리지

Loki Operator는 AWS S3MinioOpenShift Data Foundation 과 같은 기타 S3 호환 오브젝트 저장소를 지원합니다. Azure,GCSSwift 도 지원됩니다.

Loki 스토리지에 권장되는 nomenclature는 logging-loki- <your_storage_provider>입니다.

다음 표는 각 스토리지 공급자에 대한 LokiStack CR(사용자 정의 리소스) 내의 유형 값을 보여줍니다. 자세한 내용은 스토리지 공급자의 섹션을 참조하십시오.

표 10.2. 시크릿 유형 빠른 참조
스토리지 공급자보안 유형

AWS

s3

Azure

azure

Google Cloud

gcs

Minio

s3

OpenShift Data Foundation

s3

Swift

swift

10.2.2.1. AWS 스토리지

사전 요구 사항

절차

  • 다음 명령을 실행하여 이름 logging-loki-aws 를 사용하여 오브젝트 스토리지 시크릿을 생성합니다.

    $ oc create secret generic logging-loki-aws \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<aws_bucket_endpoint>" \
      --from-literal=access_key_id="<aws_access_key_id>" \
      --from-literal=access_key_secret="<aws_access_key_secret>" \
      --from-literal=region="<aws_region_of_your_bucket>"

10.2.2.2. Azure 스토리지

사전 요구 사항

  • Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • Azure에 버킷 을 생성했습니다.

절차

  • 다음 명령을 실행하여 name logging-loki-azure 를 사용하여 오브젝트 스토리지 시크릿을 생성합니다.

    $ oc create secret generic logging-loki-azure \
      --from-literal=container="<azure_container_name>" \
      --from-literal=environment="<azure_environment>" \ 1
      --from-literal=account_name="<azure_account_name>" \
      --from-literal=account_key="<azure_account_key>"
    1
    지원되는 환경 값은 AzureGlobal,AzureChinaCloud,AzureGermanCloud 또는 AzureUSGovernment 입니다.

10.2.2.3. Google Cloud Platform 스토리지

사전 요구 사항

  • Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • GCP(Google Cloud Platform)에 프로젝트를 생성했습니다.
  • 동일한 프로젝트에 버킷 을 생성했습니다.
  • GCP 인증을 위해 동일한 프로젝트에 서비스 계정을 생성하셨습니다.

절차

  1. GCP에서 수신한 서비스 계정 인증 정보를 key.json 이라는 파일에 복사합니다.
  2. 다음 명령을 실행하여 이름 logging-loki-gcs 를 사용하여 오브젝트 스토리지 시크릿을 생성합니다.

    $ oc create secret generic logging-loki-gcs \
      --from-literal=bucketname="<bucket_name>" \
      --from-file=key.json="<path/to/key.json>"

10.2.2.4. Minio 스토리지

사전 요구 사항

  • Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • Minio 가 클러스터에 배포되어 있습니다.
  • Minio에 버킷을 생성했습니다.

절차

  • 다음 명령을 실행하여 name logging-loki-minio 를 사용하여 오브젝트 스토리지 시크릿을 생성합니다.

    $ oc create secret generic logging-loki-minio \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<minio_bucket_endpoint>" \
      --from-literal=access_key_id="<minio_access_key_id>" \
      --from-literal=access_key_secret="<minio_access_key_secret>"

10.2.2.5. OpenShift Data Foundation 스토리지

사전 요구 사항

절차

  1. openshift-logging 네임스페이스에 ObjectBucketClaim 사용자 정의 리소스를 생성합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: loki-bucket-odf
      namespace: openshift-logging
    spec:
      generateBucketName: loki-bucket-odf
      storageClassName: openshift-storage.noobaa.io
  2. 다음 명령을 실행하여 관련 ConfigMap 오브젝트에서 버킷 속성을 가져옵니다.

    BUCKET_HOST=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_HOST}')
    BUCKET_NAME=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_NAME}')
    BUCKET_PORT=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_PORT}')
  3. 다음 명령을 실행하여 관련 시크릿에서 버킷 액세스 키를 가져옵니다.

    ACCESS_KEY_ID=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
    SECRET_ACCESS_KEY=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)
  4. 다음 명령을 실행하여 logging-loki-odf 라는 이름으로 오브젝트 스토리지 시크릿을 생성합니다.

    $ oc create -n openshift-logging secret generic logging-loki-odf \
    --from-literal=access_key_id="<access_key_id>" \
    --from-literal=access_key_secret="<secret_access_key>" \
    --from-literal=bucketnames="<bucket_name>" \
    --from-literal=endpoint="https://<bucket_host>:<bucket_port>"

10.2.2.6. Swift 스토리지

사전 요구 사항

  • Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • Swift에 버킷 을 생성했습니다.

절차

  • 다음 명령을 실행하여 이름 logging-loki-swift 를 사용하여 오브젝트 스토리지 시크릿을 생성합니다.

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>"
  • 선택적으로 다음 명령을 실행하여 프로젝트별 데이터, 지역 또는 둘 다를 제공할 수 있습니다.

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>" \
      --from-literal=project_id="<swift_project_id>" \
      --from-literal=project_name="<swift_project_name>" \
      --from-literal=project_domain_id="<swift_project_domain_id>" \
      --from-literal=project_domain_name="<swift_project_domain_name>" \
      --from-literal=region="<swift_region>"

10.2.3. Elasticsearch 로그 저장소 배포

OpenShift Elasticsearch Operator를 사용하여 OpenShift Container Platform 클러스터에 내부 Elasticsearch 로그 저장소를 배포할 수 있습니다.

참고

로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

10.2.3.1. Elasticsearch의 스토리지 고려 사항

각 Elasticsearch 배포 구성에는 영구 볼륨이 필요합니다. OpenShift Container Platform에서는 PVC(영구 볼륨 클레임)를 사용합니다.

참고

영구 스토리지에 로컬 볼륨을 사용하는 경우 LocalVolume 개체에서 volumeMode: block에 설명된 원시 블록 볼륨을 사용하지 마십시오. Elasticsearch는 원시 블록 볼륨을 사용할 수 없습니다.

OpenShift Elasticsearch Operator는 Elasticsearch 리소스 이름을 사용하여 PVC의 이름을 지정합니다.

Fluentd는 systemd 저널/var/log/containers/*.log 의 모든 로그를 Elasticsearch에 제공합니다.

Elasticsearch에는 대규모 병합 작업을 수행하기 위해 충분한 메모리가 필요합니다. 메모리가 충분하지 않으면 응답하지 않습니다. 이 문제를 방지하려면 애플리케이션 로그 데이터 양을 계산하고 사용 가능한 스토리지 용량의 약 2배를 할당합니다.

기본적으로 스토리지 용량이 85%인 경우 Elasticsearch는 새 데이터를 노드에 할당하는 것을 중지합니다. 90%에서 Elasticsearch는 가능한 경우 기존 shard를 해당 노드에서 다른 노드로 재배치합니다. 그러나 사용 가능한 용량이 85% 미만일 때 노드에 여유 스토리지 공간이 없는 경우 Elasticsearch는 새 인덱스 생성을 거부하고 RED가 됩니다.

참고

이 낮은 워터마크 값과 높은 워터마크 값은 현재 릴리스에서 Elasticsearch 기본값입니다. 이러한 기본값을 수정할 수 있습니다. 경고가 동일한 기본값을 사용하지만 경고에서 이러한 값을 변경할 수 없습니다.

10.2.3.2. 웹 콘솔을 사용하여 OpenShift Elasticsearch Operator 설치

OpenShift Elasticsearch Operator는 OpenShift Logging에 사용되는 Elasticsearch 클러스터를 생성하고 관리합니다.

사전 요구 사항

  • Elasticsearch는 메모리를 많이 사용하는 애플리케이션입니다. ClusterLogging 사용자 정의 리소스에서 달리 지정하지 않는 한 각 Elasticsearch 노드에는 메모리 요청 및 제한 모두에 최소 16GB의 메모리가 필요합니다.

    초기 OpenShift Container Platform 노드 세트는 Elasticsearch 클러스터를 지원하기에 충분히 크지 않을 수 있습니다. 권장 메모리 이상에서 각 Elasticsearch 노드에 대해 최대 64GB까지 실행하려면 OpenShift Container Platform 클러스터에 노드를 추가해야 합니다.

    Elasticsearch 노드는 더 낮은 메모리 설정으로 작동할 수 있지만 프로덕션 환경에는 권장되지 않습니다.

  • Elasticsearch에 필요한 영구 스토리지가 있는지 확인합니다. 각 Elasticsearch 노드에는 자체 스토리지 볼륨이 필요합니다.

    참고

    영구 스토리지에 로컬 볼륨을 사용하는 경우 LocalVolume 개체에서 volumeMode: block에 설명된 원시 블록 볼륨을 사용하지 마십시오. Elasticsearch는 원시 블록 볼륨을 사용할 수 없습니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator OperatorHub를 클릭합니다.
  2. 사용 가능한 Operator 목록에서 OpenShift Elasticsearch Operator 를 클릭하고 설치를 클릭합니다.
  3. 설치 모드에서 클러스터의 모든 네임스페이스 가 선택되어 있는지 확인합니다.
  4. 설치된 네임스페이스에서 openshift-operators-redhat이 선택되어 있는지 확인합니다.

    openshift-operators-redhat 네임스페이스를 지정해야 합니다. openshift-operators 네임스페이스에 신뢰할 수 없는 Community Operator가 포함될 수 있으며, 이로 인해 OpenShift Container Platform 지표와 동일한 이름의 지표를 게시할 수 있으므로 충돌이 발생합니다.

  5. 이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.

    이 옵션은 Namespace 오브젝트에서 openshift.io/cluster-monitoring: "true" 라벨을 설정합니다. 클러스터 모니터링이 openshift-operators-redhat 네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.

  6. stable-5.x업데이트 채널로 선택합니다.
  7. 업데이트 승인 전략을 선택합니다.

    • 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
    • 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
  8. 설치를 클릭합니다.

검증

  1. Operator 설치된 Operator 페이지로 전환하여 OpenShift Elasticsearch Operator가 설치되었는지 확인합니다.
  2. 상태성공인 모든 프로젝트에 OpenShift Elasticsearch Operator가 나열되어 있는지 확인합니다.

10.2.3.3. CLI를 사용하여 OpenShift Elasticsearch Operator 설치

OpenShift CLI(oc)를 사용하여 OpenShift Elasticsearch Operator를 설치할 수 있습니다.

사전 요구 사항

  • Elasticsearch에 필요한 영구 스토리지가 있는지 확인합니다. 각 Elasticsearch 노드에는 자체 스토리지 볼륨이 필요합니다.

    참고

    영구 스토리지에 로컬 볼륨을 사용하는 경우 LocalVolume 개체에서 volumeMode: block에 설명된 원시 블록 볼륨을 사용하지 마십시오. Elasticsearch는 원시 블록 볼륨을 사용할 수 없습니다.

    Elasticsearch는 메모리를 많이 사용하는 애플리케이션입니다. 기본적으로 OpenShift Container Platform은 메모리 요청 및 제한이 16GB인 3 개의 Elasticsearch 노드를 설치합니다. 이 초기 3개의 OpenShift Container Platform 노드 세트에는 클러스터 내에서 Elasticsearch를 실행하기에 충분한 메모리가 없을 수 있습니다. Elasticsearch와 관련된 메모리 문제가 발생하는 경우 기존 노드의 메모리를 늘리는 대신 클러스터에 Elasticsearch 노드를 더 추가합니다.

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. Namespace 오브젝트를 YAML 파일로 생성합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-operators-redhat 1
      annotations:
        openshift.io/node-selector: ""
      labels:
        openshift.io/cluster-monitoring: "true" 2
    1
    openshift-operators-redhat 네임스페이스를 지정해야 합니다. 지표와의 충돌을 방지하려면 openshift-operators 네임스페이스가 아닌 openshift-operators-redhat 네임스페이스에서 지표를 스크랩하도록 Prometheus 클러스터 모니터링 스택을 구성합니다. openshift-operators 네임스페이스에 신뢰할 수 없는 커뮤니티 Operator가 포함될 수 있으며 지표와 동일한 이름의 지표를 게시하면 충돌이 발생합니다.
    2
    문자열. 클러스터 모니터링이 openshift-operators-redhat 네임스페이스를 스크랩하도록 하려면 표시된 이 레이블을 지정해야 합니다.
  2. 다음 명령을 실행하여 Namespace 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml
  3. OperatorGroup 오브젝트를 YAML 파일로 생성합니다.

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-operators-redhat
      namespace: openshift-operators-redhat 1
    spec: {}
    1
    openshift-operators-redhat 네임스페이스를 지정해야 합니다.
  4. 다음 명령을 실행하여 OperatorGroup 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml
  5. OpenShift Elasticsearch Operator에 네임스페이스를 서브스크립션할 Subscription 오브젝트를 생성합니다.

    서브스크립션의 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: elasticsearch-operator
      namespace: openshift-operators-redhat 1
    spec:
      channel: stable-x.y 2
      installPlanApproval: Automatic 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace
      name: elasticsearch-operator

    1
    openshift-operators-redhat 네임스페이스를 지정해야 합니다.
    2
    stable 또는 stable-x.y 를 채널로 지정합니다. 다음 참고 사항을 참조하십시오.
    3
    자동으로 새 버전을 사용할 수 있을 때 OLM(Operator Lifecycle Manager)이 Operator를 자동으로 업데이트할 수 있습니다. 수동 에서는 적절한 인증 정보를 가진 사용자가 Operator 업데이트를 승인해야 합니다.
    4
    redhat-operators를 지정합니다. OpenShift Container Platform 클러스터가 제한된 네트워크(연결이 끊긴 클러스터)에 설치된 경우 OLM(Operator Lifecycle Manager)을 구성할 때 생성된 CatalogSource 오브젝트의 이름을 지정합니다.
    참고

    stable을 지정하면 안정적인 최신 릴리스의 현재 버전이 설치됩니다. installPlanApproval: "Automatic" 과 함께 stable 을 사용하면 Operator가 안정적인 최신 메이저 및 마이너 릴리스로 자동 업그레이드됩니다.

    stable-x.y 를 지정하면 특정 주요 릴리스의 현재 마이너 버전이 설치됩니다. installPlanApproval: "Automatic" 과 함께 stable-x.y 를 사용하면 Operator가 주요 릴리스 내에서 안정적인 최신 마이너 릴리스로 자동 업그레이드됩니다.

  6. 다음 명령을 실행하여 서브스크립션을 적용합니다.

    $ oc apply -f <filename>.yaml

    OpenShift Elasticsearch Operator는 openshift-operators-redhat 네임스페이스에 설치되고 클러스터의 각 프로젝트에 복사됩니다.

검증

  1. 다음 명령을 실행합니다.

    $ oc get csv -n --all-namespaces
  2. 출력을 관찰하고 OpenShift Elasticsearch Operator의 Pod가 각 네임스페이스에 있는지 확인합니다.

    출력 예

    NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
    default                                            elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-node-lease                                    elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-public                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-system                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    non-destructive-test                               elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    openshift-apiserver-operator                       elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    openshift-apiserver                                elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    ...

10.2.4. 로그 스토리지 구성

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
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.