1. 进入要存储 must-gather 信息的目录。

2. 针对 OpenShift Logging 镜像运行 oc adm must-gather 命令：

   $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

   must-gather 工具会创建一个以当前目录中 must-gather.local 开头的新目录。例如： must-gather.local.4157245944708210408。

3. 从刚刚创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令：

   $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408

4. 在红帽客户门户中为您的问题单附上压缩文件。

流程

1. 在 Red Hat OpenShift Service on AWS web 控制台中，点 Operators → OperatorHub。
2. 从可用的 Operator 列表中选择 OpenShift Elasticsearch Operator，然后点 Install。
3. 确保在 Installation mode 下选择了 All namespaces on the cluster。

4. 确定在 Installed Namespace 下选择了 openshift-operators-redhat。

   您必须指定 openshift-operators-redhat 命名空间。openshift-operators 命名空间可能会包含社区 Operator，这些 operator 不被信任，并可能会发布与 Red Hat OpenShift Service on AWS 指标相同的名称，从而导致冲突。

5. 选择 Enable operator recommended cluster monitoring on this namespace。

   这个选项在 Namespace 对象中设置 openshift.io/cluster-monitoring: "true" 标签。您必须设置这个选项，以确保集群监控提取 openshift-operators-redhat 命名空间。

6. 选择 stable-5.x 作为 更新频道。

7. 选择一个 Update 批准策略 ：

   • Automatic 策略允许 Operator Lifecycle Manager（OLM）在有新版本可用时自动更新 Operator。
   • Manual 策略需要拥有适当凭证的用户批准 Operator 更新。
8. 点 Install。

验证

1. 通过切换到 Operators → Installed Operators 页来验证 OpenShift Elasticsearch Operator 已被安装。
2. 确定 OpenShift Elasticsearch Operator 在所有项目中被列出，请 Status 为 Succeeded。

1. 在 Red Hat OpenShift Service on AWS Red Hat Hybrid Cloud Console 中，点 Observe → Dashboards。

2. 在 Dashboards 页面中，从 Dashboard 菜单中选择 Logging/Elasticsearch Nodes 或 OpenShift Logging。

   对于 Logging/Elasticsearch Nodes 仪表板，可以选择您要查看的 Elasticsearch 节点并设置数据解析。

   此时会显示正确的仪表板，显示多个数据图表。

3. 可选：从 Time Range 和 Refresh Interval 菜单中选择不同时间范围来显示或刷新数据。

1. 在 Red Hat OpenShift Service on AWS 控制台中，点 Application Launcher 并选择 Logging。

2. 点 Management → Index Patterns → Create index pattern 创建 Kibana 索引模式:

   • 首次登录 Kibana 时，每个用户必须手动创建索引模式才能查看其项目的日志。用户必须创建一个名为 app 的索引模式，并使用 @timestamp 时间字段查看其容器日志。
   • 每个 admin 用户在首次登录 Kibana 时，必须使用 @timestamp 时间字段为 app、infra 和 audit 索引创建索引模式。
3. 从新的索引模式创建 Kibana 视觉化。

1. 在 Red Hat OpenShift Service on AWS 控制台中，点 Application Launcher 并选择 Logging。

2. 使用您用来登录到 Red Hat OpenShift Service on AWS 控制台的相同凭证登录。

   Kibana 界面将出现。

3. 在 Kibana 中，点 Discover。

4. 从左上角的下拉菜单中选择您创建的索引模式： app、audit 或 infra。

   日志数据显示为时间戳文档。

5. 展开一个时间戳的文档。

6. 点 JSON 选项卡显示该文件的日志条目。

   例 6.1. Kibana 中的基础架构日志条目示例

   {
     "_index": "infra-000001",
     "_type": "_doc",
     "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3",
     "_version": 1,
     "_score": null,
     "_source": {
       "docker": {
         "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1"
       },
       "kubernetes": {
         "container_name": "registry-server",
         "namespace_name": "openshift-marketplace",
         "pod_name": "redhat-marketplace-n64gc",
         "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.7",
         "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f",
         "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a",
         "host": "ip-10-0-182-28.us-east-2.compute.internal",
         "master_url": "https://kubernetes.default.svc",
         "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38",
         "namespace_labels": {
           "openshift_io/cluster-monitoring": "true"
         },
         "flat_labels": [
           "catalogsource_operators_coreos_com/update=redhat-marketplace"
         ]
       },
       "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051",
       "level": "unknown",
       "hostname": "ip-10-0-182-28.internal",
       "pipeline_metadata": {
         "collector": {
           "ipaddr4": "10.0.182.28",
           "inputname": "fluent-plugin-systemd",
           "name": "fluentd",
           "received_at": "2020-09-23T20:47:15.007583+00:00",
           "version": "1.7.4 1.6.0"
         }
       },
       "@timestamp": "2020-09-23T20:47:03.422465+00:00",
       "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3",
       "openshift": {
         "labels": {
           "logging": "infra"
         }
       }
     },
     "fields": {
       "@timestamp": [
         "2020-09-23T20:47:03.422Z"
       ],
       "pipeline_metadata.collector.received_at": [
         "2020-09-23T20:47:15.007Z"
       ]
     },
     "sort": [
       1600894023422
     ]
   }

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   • 创建 CR 以将所有日志类型发送到内部 Elasticsearch 实例。您可以在不进行任何更改的情况下使用以下示例：

     apiVersion: logging.openshift.io/v1
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       pipelines: 1
       - name: all-to-default
         inputRefs:
         - infrastructure
         - application
         - audit
         outputRefs:
         - default

     1

     管道（pipeline）定义使用指定输出转发的日志类型。默认输出将日志转发到内部 Elasticsearch 实例。

     注意

     您必须在管道中指定所有三种类型的日志：应用程序、基础架构和审核。如果没有指定日志类型，这些日志将不会被存储并丢失。

   • 如果您有一个现有的 ClusterLogForwarder CR，请将管道添加到审计日志的默认输出中。您不需要定义默认输出。例如：

     apiVersion: "logging.openshift.io/v1"
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       outputs:
        - name: elasticsearch-insecure
          type: "elasticsearch"
          url: http://elasticsearch-insecure.messaging.svc.cluster.local
          insecure: true
        - name: elasticsearch-secure
          type: "elasticsearch"
          url: https://elasticsearch-secure.messaging.svc.cluster.local
          secret:
            name: es-audit
        - name: secureforward-offcluster
          type: "fluentdForward"
          url: https://secureforward.offcluster.com:24224
          secret:
            name: secureforward
       pipelines:
        - name: container-logs
          inputRefs:
          - application
          outputRefs:
          - secureforward-offcluster
        - name: infra-logs
          inputRefs:
          - infrastructure
          outputRefs:
          - elasticsearch-insecure
        - name: audit-logs
          inputRefs:
          - audit
          outputRefs:
          - elasticsearch-secure
          - default 1

     1

     此管道除外部实例外，还会将审计日志发送到内部 Elasticsearch 实例。

1. 编辑 ClusterLogging CR，以添加或修改 reservedPolicy 参数：

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   ...
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       retentionPolicy: 1
         application:
           maxAge: 1d
         infra:
           maxAge: 7d
         audit:
           maxAge: 7d
       elasticsearch:
         nodeCount: 3
   ...

   1

   指定 Elasticsearch 应该保留每个日志源的时间。输入一个整数和时间单位： 周(w)、小时(h/H)、分钟(m)和秒。例如，1d 代表一天。时间超过 maxAge 的旧日志会被删除。默认情况下，日志会保留 7 天。

2. 您可以验证 Elasticsearch 自定义资源（CR）中的设置。

   例如，Red Hat OpenShift Logging Operator 更新了以下 Elasticsearch CR 以配置保留策略，包括设置以每八小时滚动基础架构日志的活跃索引，并在滚动后 7 天删除滚动的索引。Red Hat OpenShift Service on AWS 每 15 分钟检查一次，以确定是否需要滚动索引。

   apiVersion: "logging.openshift.io/v1"
   kind: "Elasticsearch"
   metadata:
     name: "elasticsearch"
   spec:
   ...
     indexManagement:
       policies: 1
         - name: infra-policy
           phases:
             delete:
               minAge: 7d 2
             hot:
               actions:
                 rollover:
                   maxAge: 8h 3
           pollInterval: 15m 4
   ...

   1

   对于每个日志源，保留策略代表何时删除和滚动该源的日志。

   2

   当 Red Hat OpenShift Service on AWS 删除滚动索引时。此设置是在 ClusterLogging CR 中设置的 maxAge。

   3

   Red Hat OpenShift Service on AWS 的索引年龄，在滚动索引时需要考虑。此值由 ClusterLogging CR 中的 maxAge 决定。

   4

   当 Red Hat OpenShift Service on AWS 上检查是否应滚动索引。这是默认设置，不可更改。

   注意

   不支持修改 Elasticsearch CR。对保留策略的所有更改都必须在 ClusterLogging CR 中进行。

   OpenShift Elasticsearch Operator 部署 cron job，以使用定义的策略为每个映射滚动索引,并使用 pollInterval 调度。

   $ oc get cronjob

   输出示例

   NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   elasticsearch-im-app     */15 * * * *   False     0        <none>          4s
   elasticsearch-im-audit   */15 * * * *   False     0        <none>          4s
   elasticsearch-im-infra   */15 * * * *   False     0        <none>          4s

流程

1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   ....
   spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:1
           resources:
             limits: 2
               memory: "32Gi"
             requests: 3
               cpu: "1"
               memory: "16Gi"
           proxy: 4
             resources:
               limits:
                 memory: 100Mi
               requests:
                 memory: 100Mi

   1

   根据需要指定 Elasticsearch 的 CPU 和内存请求。如果这些值留白，则 OpenShift Elasticsearch Operator 会设置默认值，它们应足以满足大多数部署的需要。内存请求的默认值为 16Gi，CPU 请求为 1。

   2

   pod 可以使用的最大资源量。

   3

   调度 pod 所需的最小资源。

   4

   根据需要指定 Elasticsearch 代理的 CPU 和内存请求。如果这些值留白，则 OpenShift Elasticsearch Operator 会设置默认值，它们应足以满足大多数部署的需要。内存请求的默认值为 256Mi，CPU 请求的默认值为 100m。

流程

1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：

   $ oc edit clusterlogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         redundancyPolicy: "SingleRedundancy" 1

   1

   为分片指定冗余策略。更改会在保存后应用。

   • FullRedundancy：Elasticsearch 将每个索引的主分片完整复制到每个数据节点。这可提供最高的安全性，但代价是需要最大数量的磁盘并且性能最差。
   • MultipleRedundancy：Elasticsearch 将每个索引的主分片完整复制到一半的数据节点。这可在安全性和性能之间提供很好的折衷。
   • SingleRedundancy：Elasticsearch 为每个索引的主分片制作一个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。使用 5 个或更多节点时，性能胜过 MultipleRedundancy。您不能将此策略应用于单个 Elasticsearch 节点的部署。
   • ZeroRedundancy：Elasticsearch 不制作主分片的副本。如果节点关闭或发生故障， 则可能无法获得日志数据。如果您更关注性能而非安全性，或者实施了自己的磁盘/PVC 备份/恢复策略，可以考虑使用此模式。

流程

1. 编辑 ClusterLogging CR，将集群中的每个数据节点指定为绑定到持久性卷声明。

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   # ...
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         storage:
           storageClassName: "gp2"
           size: "200G"

流程

1. 编辑 ClusterLogging CR 以指定 emptyDir:

    spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           nodeCount: 3
           storage: {}

1. 进入 openshift-logging 项目：

   $ oc project openshift-logging

2. 获取 Elasticsearch Pod 的名称：

   $ oc get pods -l component=elasticsearch

3. 缩减收集器 pod，以便它们停止向 Elasticsearch 发送新日志：

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'

4. 使用 Red Hat OpenShift Service on AWS es_util 工具执行分片同步刷新，以确保在关闭前没有等待写入磁盘的待定操作：

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   例如：

   $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   输出示例

   {"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}

5. 使用 Red Hat OpenShift Service on AWS es_util 工具防止在有意关闭节点时进行分片平衡：

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

   例如：

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

   输出示例

   {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":

6. 完成后，会在每个部署中都有一个 ES 集群：

   1. 默认情况下，AWS Elasticsearch 集群上的 Red Hat OpenShift Service 会阻止部署到其节点上。使用以下命令来允许推出部署并允许 Pod 获取更改：

      $ oc rollout resume deployment/<deployment-name>

      例如：

      $ oc rollout resume deployment/elasticsearch-cdm-0-1

      输出示例

      deployment.extensions/elasticsearch-cdm-0-1 resumed

      部署了一个新 Pod。当 Pod 具有就绪的容器后，就能继续进行下一部署。

      $ oc get pods -l component=elasticsearch-

      输出示例

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h

   2. 部署完成后，重置 Pod 以禁止推出部署：

      $ oc rollout pause deployment/<deployment-name>

      例如：

      $ oc rollout pause deployment/elasticsearch-cdm-0-1

      输出示例

      deployment.extensions/elasticsearch-cdm-0-1 paused

   3. 检查 Elasticsearch 集群是否处于 green 或 yellow 状态：

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      注意

      如果您对先前命令中使用的 Elasticsearch Pod 执行了推出部署，该 Pod 将不再存在，并且此处需要使用新的 Pod 名称。

      例如：

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      {
        "cluster_name" : "elasticsearch",
        "status" : "yellow", 1
        "timed_out" : false,
        "number_of_nodes" : 3,
        "number_of_data_nodes" : 3,
        "active_primary_shards" : 8,
        "active_shards" : 16,
        "relocating_shards" : 0,
        "initializing_shards" : 0,
        "unassigned_shards" : 1,
        "delayed_unassigned_shards" : 0,
        "number_of_pending_tasks" : 0,
        "number_of_in_flight_fetch" : 0,
        "task_max_waiting_in_queue_millis" : 0,
        "active_shards_percent_as_number" : 100.0
      }

      1

      在继续操作前，请确保此参数值为 green 或者 yellow。

7. 如果更改了 Elasticsearch 配置映射，请对每个 Elasticsearch Pod 重复这些步骤。

8. 推出集群的所有部署后，重新启用分片平衡：

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

   例如：

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

   输出示例

   {
     "acknowledged" : true,
     "persistent" : { },
     "transient" : {
       "cluster" : {
         "routing" : {
           "allocation" : {
             "enable" : "all"
           }
         }
       }
     }
   }

9. 扩展收集器 Pod，以便它们会将新日志发送到 Elasticsearch。

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'

1. 进入 openshift-logging 项目：

   $ oc project openshift-logging

2. 从日志存储提取 CA 证书并写入 admin-ca 文件：

   $ oc extract secret/elasticsearch --to=. --keys=admin-ca

   输出示例

   admin-ca

3. 以 YAML 文件形式创建日志存储服务的路由：

   1. 使用以下内容创建一个 YAML文件：

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: elasticsearch
        namespace: openshift-logging
      spec:
        host:
        to:
          kind: Service
          name: elasticsearch
        tls:
          termination: reencrypt
          destinationCACertificate: | 1

      1

      添加日志存储 CA 证书或使用下一步中的命令。您不必设置一些重新加密路由所需的 spec.tls.key、spec.tls.certificate 和 spec.tls.caCertificate 参数。

   2. 运行以下命令，将日志存储 CA 证书添加到您在上一步中创建的路由 YAML 中：

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml

   3. 创建路由：

      $ oc create -f <file-name>.yaml

      输出示例

      route.route.openshift.io/elasticsearch created

4. 检查是否公开了 Elasticsearch 服务：

   1. 获取此服务帐户的令牌，以便在请求中使用：

      $ token=$(oc whoami -t)

   2. 将您创建的 Elasticsearch 路由设置为环境变量。

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`

   3. 要验证路由是否创建成功，请运行以下命令来通过公开的路由访问 Elasticsearch：

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"

      其响应类似于如下：

      输出示例

      {
        "name" : "elasticsearch-cdm-i40ktba0-1",
        "cluster_name" : "elasticsearch",
        "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
        "version" : {
        "number" : "6.8.1",
        "build_flavor" : "oss",
        "build_type" : "zip",
        "build_hash" : "Unknown",
        "build_date" : "Unknown",
        "build_snapshot" : true,
        "lucene_version" : "7.7.0",
        "minimum_wire_compatibility_version" : "5.6.0",
        "minimum_index_compatibility_version" : "5.0.0"
      },
        "<tagline>" : "<for search>"
      }

流程

1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：

   $ oc edit ClusterLogging instance

2. 如果存在，请从 ClusterLogging CR 中删除 logStore 和 visualization 小节。

3. 保留 ClusterLogging CR 的 collection 小节。结果应类似以下示例：

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: "openshift-logging"
   spec:
     managementState: "Managed"
     collection:
       logs:
         type: "fluentd"
         fluentd: {}

4. 验证收集器 Pod 是否已重新部署：

   $ oc get pods -l component=collector -n openshift-logging

流程

1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：

   $ oc -n openshift-logging edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: openshift-logging
   
   ...
   
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         resources: 1
           limits:
             memory: 16Gi
           requests:
             cpu: 200m
             memory: 16Gi
         storage:
           storageClassName: "gp2"
           size: "200G"
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         resources: 2
           limits:
             memory: 1Gi
           requests:
             cpu: 500m
             memory: 1Gi
         proxy:
           resources: 3
             limits:
               memory: 100Mi
             requests:
               cpu: 100m
               memory: 100Mi
         replicas: 2
     collection:
       logs:
         type: "fluentd"
         fluentd:
           resources: 4
             limits:
               memory: 736Mi
             requests:
               cpu: 200m
               memory: 736Mi

   1

   根据需要指定日志存储的 CPU 和内存限值及请求。对于 Elasticsearch，您必须调整请求值和限制值。

   2 3

   根据需要为日志 visualizer 指定 CPU 和内存限值和请求。

   4

   根据需要指定日志收集器的 CPU 和内存限值及请求。

流程

1. 使用以下命令，将污点添加到要在其上调度 OpenShift Logging pod 的节点：

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

   例如：

   $ oc adm taint nodes node1 elasticsearch=node:NoExecute

   本例在 node1 上放置一个键为 elasticsearch 且值为 node 的污点，污点效果是 NoExecute。具有 NoExecute 效果的节点仅调度与污点匹配的 Pod，并删除不匹配的现有 pod。

2. 编辑 ClusterLogging CR 的 logstore 部分，以配置 Elasticsearch Pod 的容忍度：

     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 1
         tolerations:
         - key: "elasticsearch"  1
           operator: "Exists"  2
           effect: "NoExecute"  3
           tolerationSeconds: 6000  4

   1

   指定添加到节点的键。

   2

   指定 Exists operator 需要节点上有一个带有键为 elasticsearch 的污点。

   3

   指定 NoExecute 效果。

   4

   （可选）指定 tolerationSeconds 参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。

流程

1. 使用以下命令，将污点添加到要在其上调度日志可视化 pod：

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

   例如：

   $ oc adm taint nodes node1 kibana=node:NoExecute

   本例在 node1 上放置一个键为 kibana 且值为 node 的污点，污点效果是 NoExecute。您必须使用 NoExecute 污点设置。NoExecute 仅调度与污点匹配的 pod，并删除不匹配的现有 pod。

2. 编辑 ClusterLogging CR 的 visualization 部分，以配置 Kibana pod 的容忍度：

     visualization:
       type: "kibana"
       kibana:
         tolerations:
         - key: "kibana"  1
           operator: "Exists"  2
           effect: "NoExecute"  3
           tolerationSeconds: 6000 4

   1

   指定添加到节点的键。

   2

   指定 Exists 运算符，以要求匹配 key/value/effect 参数。

   3

   指定 NoExecute 效果。

   4

   （可选）指定 tolerationSeconds 参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。

流程

1. 使用以下命令，将污点添加到要在其上调度日志记录收集器 pod 的节点：

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

   例如：

   $ oc adm taint nodes node1 collector=node:NoExecute

   本例在 node1 上放置一个键为 collector 且值为 node 的污点，污点效果是 NoExecute。您必须使用 NoExecute 污点设置。NoExecute 仅调度与污点匹配的 pod，并删除不匹配的现有 pod。

2. 编辑 ClusterLogging 自定义资源（CR）的 collection 小节，以配置日志记录收集器 Pod 的容忍度：

     collection:
       logs:
         type: "fluentd"
         fluentd:
           tolerations:
           - key: "collector"  1
             operator: "Exists"  2
             effect: "NoExecute"  3
             tolerationSeconds: 6000  4

   1

   指定添加到节点的键。

   2

   指定 Exists 运算符，以要求匹配 key/value/effect 参数。

   3

   指定 NoExecute 效果。

   4

   （可选）指定 tolerationSeconds 参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。

流程

1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源（CR）：

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ...
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

   1 2

   添加 nodeSelector 参数，并设为适用于您想要移动的组件的值。您可以根据为节点指定的值，按所示格式使用 nodeSelector 或使用 <key>: <value> 对。如果您在 infrasructure 节点中添加了污点，还要添加匹配的容限。

流程

1. 运行以下命令，列出处于 Pending 状态的 pod：

   oc get pods --field-selector status.phase==Pending -n openshift-logging

   oc get pods 输出示例

   NAME                           READY   STATUS    RESTARTS   AGE 1
   logging-loki-index-gateway-1   0/1     Pending   0          17m
   logging-loki-ingester-1        0/1     Pending   0          16m
   logging-loki-ruler-1           0/1     Pending   0          16m

   1

   这些 pod 处于 Pending 状态，因为它们对应的 PVC 位于失败的区中。

   1. 运行以下命令，列出处于 Pending 状态的 PVC：

      oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

      oc get pvc 输出示例

      storage-logging-loki-index-gateway-1
      storage-logging-loki-ingester-1
      wal-logging-loki-ingester-1
      storage-logging-loki-ruler-1
      wal-logging-loki-ruler-1

   2. 运行以下命令，删除 pod 的 PVC：

      oc delete pvc __<pvc_name>__  -n openshift-logging

   3. 然后，运行以下命令来删除 pod：

流程

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   apiVersion: "logging.openshift.io/v1"
   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     outputDefaults:
       elasticsearch:
         structuredTypeKey: kubernetes.labels.logFormat 1
         structuredTypeName: nologformat
         enableStructuredContainerLogs: true 2
     pipelines:
     - inputRefs:
       - application
       name: application-logs
       outputRefs:
       - default
       parse: json

   1

   使用 Kubernetes logFormat 标签形成的键值对值。

   2

   启用多容器输出。

2. 创建或编辑定义 Pod CR 对象的 YAML 文件：

       apiVersion: v1
       kind: Pod
       metadata:
         annotations:
           containerType.logging.openshift.io/heavy: heavy 1
           containerType.logging.openshift.io/low: low
       spec:
         containers:
         - name: heavy 2
           image: heavyimage
         - name: low
           image: lowimage

   1

   格式：containerType.logging.openshift.io/<container-name>: <index>

   2

   注解名称必须与容器名称匹配

流程

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   apiVersion: "logging.openshift.io/v1"
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: elasticsearch-insecure 3
        type: "elasticsearch" 4
        url: http://elasticsearch.insecure.com:9200 5
      - name: elasticsearch-secure
        type: "elasticsearch"
        url: https://elasticsearch.secure.com:9200 6
        secret:
           name: es-secret 7
     pipelines:
      - name: application-logs 8
        inputRefs: 9
        - application
        - audit
        outputRefs:
        - elasticsearch-secure 10
        - default 11
        labels:
          myLabel: "myValue" 12
      - name: infrastructure-audit-logs 13
        inputRefs:
        - infrastructure
        outputRefs:
        - elasticsearch-insecure
        labels:
          logs: "audit-infra"

   1

   ClusterLogForwarder CR 的名称必须是 instance。

   2

   ClusterLogForwarder CR 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 elasticsearch 类型。

   5

   指定外部 Elasticsearch 实例的 URL 和端口作为有效的绝对 URL。您可以使用 http （不安全）或 https （安全 HTTP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   对于安全连接，您可以通过指定 secret 来指定您进行身份验证的 https 或 http URL。

   7

   对于 https 前缀，请指定 TLS 通信端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的：tls.crt、tls.key 和 ca-bundle.crt 的密钥。否则，对于 http 和 https 前缀，您可以指定一个包含用户名和密码的 secret。如需更多信息，请参阅以下"示例：设置包含用户名和密码的 secret"。

   8

   可选：指定管道的名称。

   9

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   10

   指定使用此管道转发日志时使用的输出名称。

   11

   可选：指定将日志发送到内部 Elasticsearch 实例的 default 输出。

   12

   可选：字符串。要添加到日志中的一个或多个标签。

   13

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

2. 创建 CR 对象。

   $ oc create -f <file-name>.yaml

1. 创建类似于以下示例的 Secret YAML 文件。将 base64 编码的值用于 username 和 password 字段。secret 类型默认为 opaque。

   apiVersion: v1
   kind: Secret
   metadata:
     name: openshift-test-secret
   data:
     username: <username>
     password: <password>

2. 创建 secret：

   $ oc create secret -n openshift-logging openshift-test-secret.yaml

3. 在 ClusterLogForwarder CR 中指定 secret 的名称：

   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     outputs:
      - name: elasticsearch
        type: "elasticsearch"
        url: https://elasticsearch.secure.com:9200
        secret:
           name: openshift-test-secret

   注意

   在 url 字段中，前缀可以是 http 或 https。

4. 创建 CR 对象。

   $ oc create -f <file-name>.yaml

流程

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     pipelines:
      - name: forward-to-fluentd-secure 7
        inputRefs:  8
        - application
        - audit
        outputRefs:
        - fluentd-server-secure 9
        - default 10
        labels:
          clusterId: "C1234" 11
      - name: forward-to-fluentd-insecure 12
        inputRefs:
        - infrastructure
        outputRefs:
        - fluentd-server-insecure
        labels:
          clusterId: "C1234"

   1

   ClusterLogForwarder CR 的名称必须是 instance。

   2

   ClusterLogForwarder CR 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 fluentdForward 类型。

   5

   指定外部 Fluentd 实例的 URL 和端口作为有效的绝对 URL。您可以使用 tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的：tls.crt、tls.key 和 ca-bundle.crt 的密钥。

   7

   可选：指定管道的名称。

   8

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   9

   指定使用此管道转发日志时使用的输出名称。

   10

   可选：指定将日志转发到内部 Elasticsearch 实例的 default 输出。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

2. 创建 CR 对象。

   $ oc create -f <file-name>.yaml

流程

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: rsyslog-east 3
        type: syslog 4
        syslog: 5
          facility: local0
          rfc: RFC3164
          payloadKey: message
          severity: informational
        url: 'tls://rsyslogserver.east.example.com:514' 6
        secret: 7
           name: syslog-secret
      - name: rsyslog-west
        type: syslog
        syslog:
         appName: myapp
         facility: user
         msgID: mymsg
         procID: myproc
         rfc: RFC5424
         severity: debug
        url: 'udp://rsyslogserver.west.example.com:514'
     pipelines:
      - name: syslog-east 8
        inputRefs: 9
        - audit
        - application
        outputRefs: 10
        - rsyslog-east
        - default 11
        labels:
          secure: "true" 12
          syslog: "east"
      - name: syslog-west 13
        inputRefs:
        - infrastructure
        outputRefs:
        - rsyslog-west
        - default
        labels:
          syslog: "west"

   1

   ClusterLogForwarder CR 的名称必须是 instance。

   2

   ClusterLogForwarder CR 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 syslog 类型。

   5

   可选：指定 syslog 参数，如下所列。

   6

   指定外部 syslog 实例的 URL 和端口。您可以使用 udp （不安全）、tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   7

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的：tls.crt、tls.key 和 ca-bundle.crt 的密钥。

   8

   可选：指定管道的名称。

   9

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   10

   指定使用此管道转发日志时使用的输出名称。

   11

   可选：指定将日志转发到内部 Elasticsearch 实例的 default 输出。

   12

   可选：字符串。要添加到日志中的一个或多个标签。对值加引号（如 "true"），以便它们被识别为字符串值，而不是作为布尔值。

   13

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

2. 创建 CR 对象。

   $ oc create -f <file-name>.yaml

流程

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: app-logs 3
        type: kafka 4
        url: tls://kafka.example.devlab.com:9093/app-topic 5
        secret:
          name: kafka-secret 6
      - name: infra-logs
        type: kafka
        url: tcp://kafka.devlab2.example.com:9093/infra-topic 7
      - name: audit-logs
        type: kafka
        url: tls://kafka.qelab.example.com:9093/audit-topic
        secret:
           name: kafka-secret-qe
     pipelines:
      - name: app-topic 8
        inputRefs: 9
        - application
        outputRefs: 10
        - app-logs
        labels:
          logType: "application" 11
      - name: infra-topic 12
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        - default 13
        labels:
          logType: "audit"

   1

   ClusterLogForwarder CR 的名称必须是 instance。

   2

   ClusterLogForwarder CR 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 kafka 类型。

   5

   将 Kafka 代理的 URL 和端口指定为一个有效的绝对 URL，也可以同时指定特定标题。您可以使用 tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的：tls.crt、tls.key 和 ca-bundle.crt 的密钥。

   7

   可选： 要发送不安全的输出，在 URL 前面使用 tcp 前缀。另外，省略此输出中的 secret 键及其 name。

   8

   可选：指定管道的名称。

   9

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   10

   指定使用此管道转发日志时使用的输出名称。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

   13

   可选：指定 default 将日志转发到内部 Elasticsearch 实例。

2. 可选： 要将单个输出转发到多个 Kafka 代理，请指定 Kafka 代理数组，如下例所示：

   # ...
   spec:
     outputs:
     - name: app-logs
       type: kafka
       secret:
         name: kafka-secret-dev
       kafka:  1
         brokers: 2
           - tls://kafka-broker1.example.com:9093/
           - tls://kafka-broker2.example.com:9093/
         topic: app-topic 3
   # ...

   1

   指定一个带有 brokers 和 topic 键的 kafka 键。

   2

   使用 brokers 键指定一个或多个代理的数组。

   3

   使用 topic 键指定接收日志的目标主题。

3. 运行以下命令来应用 ClusterLogForwarder CR：

   $ oc apply -f <filename>.yaml

流程

1. 创建一个 Secret YAML 文件，它使用 aws_access_key_id 和 aws_secret_access_key 字段来指定您的 base64 编码的 AWS 凭证。例如：

   apiVersion: v1
   kind: Secret
   metadata:
     name: cw-secret
     namespace: openshift-logging
   data:
     aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
     aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=

2. 创建 secret.例如：

   $ oc apply -f cw-secret.yaml

3. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件。在文件中，指定 secret 的名称。例如：

   apiVersion: "logging.openshift.io/v1"
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: cw 3
        type: cloudwatch 4
        cloudwatch:
          groupBy: logType 5
          groupPrefix: <group prefix> 6
          region: us-east-2 7
        secret:
           name: cw-secret 8
     pipelines:
       - name: infra-logs 9
         inputRefs: 10
           - infrastructure
           - audit
           - application
         outputRefs:
           - cw 11

   1

   ClusterLogForwarder CR 的名称必须是 instance。

   2

   ClusterLogForwarder CR 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 cloudwatch 类型。

   5

   可选：指定如何对日志进行分组：

   • logType 为每个日志类型创建日志组
   • namespaceName 为每个应用程序命名空间创建一个日志组。它还会为基础架构和审计日志创建单独的日志组。
   • namespaceUUID 为每个应用命名空间 UUID 创建一个新的日志组。它还会为基础架构和审计日志创建单独的日志组。

   6

   可选：指定一个字符串来替换日志组名称中的默认 infrastructureName 前缀。

   7

   指定 AWS 区域。

   8

   指定包含 AWS 凭证的 secret 名称。

   9

   可选：指定管道的名称。

   10

   使用管道指定要转发的日志类型：application、infrastructure 或 audit。

   11

   指定使用此管道转发日志时使用的输出名称。

4. 创建 CR 对象：

   $ oc create -f <file-name>.yaml