3.4. 설치 후 작업

Kibana를 사용하려면 Kibana에서 데이터를 탐색하고 시각화하기 위해 Kibana 인덱스 패턴 및 시각화를 수동으로 생성해야 합니다.

클러스터 네트워크 공급자가 네트워크 분리를 적용하는 경우 OpenShift Logging Operator가 포함된 프로젝트 간에 네트워크 트래픽을 허용합니다.

3.4.1. Kibana 인덱스 패턴 정의

인덱스 패턴은 시각화하려는 Elasticsearch 인덱스를 정의합니다. Kibana에서 데이터를 탐색하고 시각화하려면 인덱스 패턴을 생성해야 합니다.

사전 요구 사항

  • Kibana에서 인프라감사 인덱스를 보려면 사용자에게 cluster-admin 역할이나 cluster-reader 역할 또는 두 역할이 모두 있어야 합니다. 기본 kubeadmin 사용자에게는 이러한 인덱스를 나열할 수 있는 적절한 권한이 있습니다.

    default, kube-, openshift- 프로젝트에서 Pod와 로그를 볼 수 있다면 이러한 인덱스에 액세스할 수 있어야 합니다. 다음 명령을 사용하여 현재 사용자에게 적절한 권한이 있는지 확인할 수 있습니다.

    $ oc auth can-i get pods/log -n <project>

    출력 예

    yes

    참고

    감사 로그는 기본적으로 내부 OpenShift Container Platform Elasticsearch 인스턴스에 저장되지 않습니다. Kibana에서 감사 로그를 보려면 Log Forwarding API를 사용하여 감사 로그에 default 출력을 사용하는 파이프라인을 구성해야 합니다.

  • 인덱스 패턴을 생성하려면 먼저 Elasticsearch 문서를 인덱싱해야 합니다. 이 작업은 자동으로 수행되지만 새 클러스터나 업데이트된 클러스터에서는 몇 분 정도 걸릴 수 있습니다.

프로세스

Kibana에서 인덱스 패턴을 정의하고 시각화를 생성하려면 다음을 수행합니다.

  1. OpenShift Container Platform 콘솔에서 Application Launcher app launcher 를 클릭하고 로깅을 선택합니다.
  2. 관리인덱스 패턴인덱스 패턴 생성을 클릭하여 Kibana 인덱스 패턴을 생성합니다.

    • 각 사용자는 프로젝트의 로그를 보려면 Kibana에 로그인할 때 수동으로 인덱스 패턴을 생성해야 합니다. 사용자는 app이라는 새 인덱스 패턴을 생성하고 @timestamp 시간 필드를 사용하여 컨테이너 로그를 확인해야 합니다.
    • 관리자는 @timestamp 시간 필드를 사용하여 app, infra, audit 인덱스에 대해 처음 Kibana에 로그인할 때 인덱스 패턴을 생성해야 합니다.
  3. 새로운 인덱스 패턴에서 Kibana 시각화를 생성합니다.

3.4.2. 네트워크 분리가 활성화될 때 프로젝트 간 트래픽 허용

클러스터 네트워크 공급자는 네트워크 분리를 실행할 수 있습니다. 이 경우 OpenShift Logging에서 배포한 operator가 포함된 프로젝트 간 네트워크 트래픽을 허용해야 합니다.

네트워크 분리는 다른 프로젝트에 있는 pod 또는 서비스 간의 네트워크 트래픽을 차단합니다. OpenShift Logging은 openshift-operators-redhat 프로젝트에 OpenShift Elasticsearch Operator를 설치하고 openshift-logging 프로젝트에 Red Hat OpenShift Logging Operator를 설치합니다. 따라서 이 두 프로젝트 간 트래픽을 허용해야 합니다.

OpenShift Container Platform은 기본 CNI(Container Network Interface) 네트워크 공급자인 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