5.5. 安装后的任务

安装 Red Hat OpenShift Logging Operator 后,您可以通过创建和修改 ClusterLogging 自定义资源(CR)来配置部署。

提示

如果没有使用 Elasticsearch 日志存储,您可以从 ClusterLogging 自定义资源(CR)中删除内部 Elasticsearch logStore 和 Kibana visualization 组件。删除这些组件是可选的,但会保存资源。请参阅如果没有使用 Elasticsearch 日志存储,删除未使用的组件

5.5.1. 关于 ClusterLogging 自定义资源

要更改日志记录环境,请创建并修改 ClusterLogging 自定义资源(CR)。

ClusterLogging 自定义资源(CR)示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  managementState: Managed 3
# ...

1
名称必须是 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。
注意

OpenShift Elasticsearch Operator 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。

流程

  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
    指定日志存储类型。这可以是 lokistackelasticsearch
    2
    Elasticsearch 日志存储的可选配置选项。
    3
    指定冗余类型。这个值可以是 ZeroRedundancySingleRedundancyMultipleRedundancyFullRedundancy
    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 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已创建了 ClusterLogging CR。

流程

  1. 修改 ClusterLogging CR collection 规格:

    ClusterLogging CR 示例

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

    1
    要用于日志记录的日志收集器类型。这可以是 vectorfluentd
  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 Web 控制台进行视觉化,您必须启用日志记录控制台插件。请参阅有关 "Log visualization with the web console" 的文档。

流程

  1. 修改 ClusterLogging CR visualization 规格:

    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
    要用于日志记录的可视化工具类型。这可以是 kibanaocp-console。Kibana 控制台仅与使用 Elasticsearch 日志存储的部署兼容,而 OpenShift Container Platform 控制台只与 LokiStack 部署兼容。
    2
    Kibana 控制台的可选配置。
    3
    OpenShift Container Platform Web 控制台的可选配置。
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml

5.5.5. 启用网络隔离时允许项目间的流量

集群网络供应商可能会强制实施网络隔离。如果是这样,您必须允许包含 OpenShift Logging 部署的 Operator 的项目间的网络流量。

网络隔离会阻止位于不同项目中的 pod 或服务之间的网络流量。Logging 在 openshift-operators-redhat 项目中安装 OpenShift Elasticsearch Operator,在 openshift-logging 项目中安装 Red Hat OpenShift Logging Operator。因此,您必须允许这两个项目之间的流量。

OpenShift Container Platform 为默认 Container Network Interface(CNI)网络供应商(OpenShift SDN 和 OVN-Kubernetes)提供两个支持的选择。这两个提供程序实施各种网络隔离策略。

OpenShift SDN 有三种模式:

网络策略
这是默认的模式。如果没有定义策略,它将允许所有流量。但是,如果用户定义了策略,它们通常先拒绝所有流量,然后再添加例外。此过程可能会破坏在不同项目中运行的应用。因此,显式配置策略以允许从一个与日志记录相关的项目出口到另一个项目的流量。
多租户
这个模式强制实施网络隔离。您必须加入两个与日志记录相关的项目,以允许它们之间的流量。
subnet
此模式允许所有流量。它不强制实施网络隔离。不需要操作。

OVN-Kubernetes 始终使用网络策略。因此,与 OpenShift SDN 一样,您必须配置策略,以允许流量从一个与日志相关的项目出口到另一个项目。

流程

  • 如果您以多租户(multitenant)模式使用 OpenShift SDN,请加入这两个项目。例如:

    $ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
  • 否则,对于网络策略模式的 OpenShift SDN 以及 OVN-Kubernetes,请执行以下操作:

    1. openshift-operators-redhat 命名空间中设置标签。例如:

      $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
    2. openshift-logging 命名空间中创建一个网络策略对象,它允许从 openshift-operators-redhatopenshift-monitoringopenshift-ingress 项目的入站流量到 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