8.4. 配置 Elasticsearch 以存储和整理日志数据

流程

1. 在 openshift-logging 项目中编辑集群日志记录自定义资源 (CR)：

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   ....
   spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           resources: 1
             limits:
               memory: "16Gi"
             requests:
               cpu: "1"
               memory: "16Gi"

   1

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

   如果调整了 Elasticsearch CPU 和内存的数量，您必须同时更改请求值和限制值。

   例如：

         resources:
           limits:
             cpu: "8"
             memory: "32Gi"
           requests:
             cpu: "8"
             memory: "32Gi"

   Kubernetes 一般遵循节点 CPU 配置，DOES 不允许 Elasticsearch 使用指定的限制。为 requests 和 limits 设置相同的值可以确保 Elasticseach 可以使用您需要它们使用的 CPU 和内存数量（假定节点有足够可用 CPU 和内存）。

流程

1. 在 openshift-logging 项目中编辑集群日志记录自定义资源 (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. 编辑集群日志记录 CR，将集群中的每个数据节点指定为绑定到 PVC。

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

流程

1. 编辑集群日志记录 CR 以指定 emptyDir：

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

1. 进入 openshift-logging 项目：

   $ oc project openshift-logging

2. 从 Elasticsearch 提取 CA 证书并写入 admin-ca 文件：

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

3. 以 YAML 文件形式创建 Elasticsearch 服务的路由：

   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

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

   2. 运行以下命令将 Elasticsearch 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. 获取此 ServiceAccount 的令牌，以便在请求中使用：

      $ 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}/.operations.*/_search?size=1" | jq

      其响应类似于如下：

        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
      100   944  100   944    0     0     62      0  0:00:15  0:00:15 --:--:--   204
      {
        "took": 441,
        "timed_out": false,
        "_shards": {
          "total": 3,
          "successful": 3,
          "skipped": 0,
          "failed": 0
        },
        "hits": {
          "total": 89157,
          "max_score": 1,
          "hits": [
            {
              "_index": ".operations.2019.03.15",
              "_type": "com.example.viaq.common",
              "_id": "ODdiNWIyYzAtMjg5Ni0TAtNWE3MDY1MjMzNTc3",
              "_score": 1,
              "_source": {
                "_SOURCE_MONOTONIC_TIMESTAMP": "673396",
                "systemd": {
                  "t": {
                    "BOOT_ID": "246c34ee9cdeecb41a608e94",
                    "MACHINE_ID": "e904a0bb5efd3e36badee0c",
                    "TRANSPORT": "kernel"
                  },
                  "u": {
                    "SYSLOG_FACILITY": "0",
                    "SYSLOG_IDENTIFIER": "kernel"
                  }
                },
                "level": "info",
                "message": "acpiphp: Slot [30] registered",
                "hostname": "localhost.localdomain",
                "pipeline_metadata": {
                  "collector": {
                    "ipaddr4": "10.128.2.12",
                    "ipaddr6": "fe80::xx:xxxx:fe4c:5b09",
                    "inputname": "fluent-plugin-systemd",
                    "name": "fluentd",
                    "received_at": "2019-03-15T20:25:06.273017+00:00",
                    "version": "1.3.2 1.6.0"
                  }
                },
                "@timestamp": "2019-03-15T20:00:13.808226+00:00",
                "viaq_msg_id": "ODdiNWIyYzAtMYTAtNWE3MDY1MjMzNTc3"
              }
            }
          ]
        }
      }