第 7 章 配置集群日志记录部署


7.1. 关于配置集群日志记录

将集群日志记录安装到 OpenShift Container Platform 集群中后,您可以进行以下配置。

注意

除非另有说明,否则在执行这些配置之前,必须将集群日志记录设置为非受管状态。如需更多信息,请参阅更改集群日志记录管理状态

处于非受管状态的 Operator 不被正式支持,集群管理员需要完全掌控各个组件的配置和升级。

如需了解更多信息,请参阅非受管 Operator 的支持策略

7.1.1. 关于部署和配置集群日志记录

OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用,该配置针对中小型 OpenShift Container Platform 集群进行了调优。

以下安装说明包括一个示例集群日志记录自定义资源 (CR),您可以用它来创建集群日志记录实例并配置集群日志记录部署。

如果要使用默认集群日志记录安装,可直接使用示例 CR。

如果要自定义部署,请根据需要对示例 CR 进行更改。下文介绍了在安装集群日志记录实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息,包括可以在集群日志记录自定义资源之外进行的修改。

7.1.1.1. 配置和调优集群日志记录

您可以通过修改 openshift-logging 项目中部署的集群日志记录自定义资源来配置集群日志记录环境。

您可以在安装时或安装后修改以下任何组件:

内存和 CPU
您可以使用有效的内存和 CPU 值修改 resources 块,以此调整各个组件的 CPU 和内存限值:
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
     type: kibana
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"
Elasticsearch 存储
您可以使用 storageClass namesize 参数,为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数为 Elasticsearch 集群中的每个数据节点创建 PersistentVolumeClaim
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

本例中指定,集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PersistentVolumeClaim。每个主分片将由单个副本支持。

注意

省略 storage 块会导致部署中仅包含临时存储。

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch 复制策略

您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片:

  • FullRedundancy。各个索引的分片完整复制到每个数据节点上。
  • MultipleRedundancy。各个索引的分片分布到一半数据节点上。
  • SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点,日志就能始终可用且可恢复。
  • ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障, 则可能无法获得日志数据。
Curator 调度
cron 格式指定 Curator 的调度。
  spec:
    curation:
    type: "curator"
    resources:
    curator:
      schedule: "30 3 * * *"

7.1.1.2. 修改后集群日志记录自定义资源示例

以下是使用前述选项修改的集群日志记录自定义资源的示例。

修改后集群日志记录自定义资源示例

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
      storage: {}
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.