第 1 章 关于集群日志记录和 OpenShift Container Platform

作为集群管理员,您可以部署集群日志记录来聚合 OpenShift Container Platform 集群中的所有日志,如节点系统日志、应用程序容器日志等。

1.1. 集群日志记录

OpenShift Container Platform 集群管理员可以使用一些 CLI 命令和 OpenShift Container Platform Web 控制台安装 Elasticsearch Operator 和 Cluster Logging Operator,以此部署集群日志记录。安装 Operator 后,可创建集群日志记录自定义资源 (CR) 以调度集群日志记录 pod 和支持集群日志记录所需的其他资源。Operator 负责部署、升级和维护集群日志记录。

您可以通过修改集群日志记录自定义资源 (CR)(名为 instance)来配置集群日志记录。CR 定义包括日志记录堆栈的所有组件在内的完整集群日志记录部署,以收集、存储和视觉化日志。Cluster Logging Operator 监控 ClusterLogging 自定义资源并相应地调整日志记录部署。

管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。

1.1.1. 关于集群日志记录组件

集群日志记录组件基于 Elasticsearch、Fluentd 或 Rsyslog 以及 Kibana(EFK)。收集器 Fluentd 部署到 OpenShift Container Platform 集群中的每个节点。它收集所有节点和容器日志,并将它们写入 Elasticsearch (ES)。Kibana 是一个集中式 Web UI,用户和管理员可以在其中使用汇总的数据创建丰富的视觉化和仪表板。

目前有 5 种不同类型的集群日志记录组件:

  • logStore(存储) - 存储日志的位置。当前的实现是 Elasticsearch。
  • collection(收集) - 此组件从节点收集日志,将日志格式化并存储到 logStore 中。当前的实现是 Fluentd。
  • visualization(可视化) - 此 UI 组件用于查看日志、图形和图表等。当前的实现是 Kibana。
  • curation(策展) - 此组件按日志时间进行筛检。当前的实现是 Curator。

除非特别说明,在本文中我们可能会互换使用日志存储或 Elasticsearch、视觉化或 Kibana、策展或 Curator、收集或 Fluentd。

1.1.2. 关于日志存储

OpenShift Container Platform 使用 Elasticsearch (ES) 将日志数据从 Fluentd 整理到数据存储或索引中。

Elasticsearch 将各个索引进一步划分成多个碎片(称为分片),分散到 Elasticsearch 集群中的一组 Elasticsearch 节点上。您可以配置 Elasticsearch 来为分片制作拷贝(称为副本)。Elasticsearch 也将这些副本分散到多个 Elasticsearch 节点上。借助 ClusterLogging 自定义资源,您可以在自定义资源定义 (CRD) 中指定复制策略,以提供数据冗余和故障恢复能力。

集群日志记录 Elasticsearch 实例经过优化并测试,用于大约 7 天的简短存储。如果要更长时间保留日志,建议您将数据移至第三方存储系统。

注意

索引模板的主分片数量等于 Elasticsearch 数据节点的数目。

Cluster Logging Operator 和相应的 Elasticsearch Operator 确保每个 Elasticsearch 节点都使用带有自身存储卷的唯一 Deployment 来进行部署。您可以使用集群日志记录自定义资源 (CR) 来增加 Elasticsearch 节点的数量。如需有关选择存储和网络位置的注意事项,请参考 Elastic 文档,如下所示。

注意

高可用性 Elasticsearch 环境需要至少三个 Elasticsearch 节点,各自在不同的主机上。

Elasticsearch 索引中应用的基于角色的访问控制 (RBAC) 可让开发人员控制对日志的访问。使用 project.{project_name}.{project_uuid}.* 格式对索引进行访问将会根据特定项目中的用户权限进行限制。

如需更多信息,请参阅 Elasticsearch (ES)

1.1.3. 关于日志记录收集器

OpenShift Container Platform 使用 Fluentd 来收集集群的相关数据。

日志记录收集器部署为 OpenShift Container Platform 中的 DaemonSet,将各个 Pod 部署到每个 OpenShift Container Platform 节点中。journald 是系统日志源,提供来自操作系统、容器运行时和 OpenShift Container Platform 的日志消息。

容器运行时提供少许信息来标识日志消息的来源,如项目、容器名称和容器 ID。这不足以唯一地标识日志来源。如果在日志收集器开始处理日志之前删除了具有指定名称和项目的 Pod,则来自 API 服务器的信息(如标签和注解)可能会不可用。可能没有办法区分来自名称相似的 Pod 和项目的日志消息,也无法追溯日志的来源。这种局限性意味着日志收集和规范化仅属于尽力而为

重要

可用的容器运行时提供少许信息来标识日志消息来源,无法确保唯一的个别日志消息,也不能保证可以追溯这些消息的来源。

如需更多信息,请参阅 Fluentd

1.1.4. 关于日志记录视觉化

OpenShift Container Platform 使用 Kibana 显示由 Fluentd 收集并由 Elasticsearch 索引的日志数据。

Kibana 是基于浏览器的控制台界面,可通过直方图、折线图、饼图、热图、内置地理空间支持和其他视觉化方式,来查询、探索和视觉化您的 Elasticsearch 数据。

如需更多信息,请参阅 Kibana

1.1.5. 关于日志记录策展

Elasticsearch Curator 工具在全局范围和/或以项目为基础执行调度的维护操作。Curator 根据其配置执行操作。建议每个 Elasticsearch 集群仅使用一个 Curator Pod。

spec:
  curation:
  type: "curator"
  resources:
  curator:
    schedule: "30 3 * * *" 1
1
cron 格式指定 Curator 计划。

如需更多信息,请参阅 Curator

1.1.6. 集群日志记录自定义资源 (CR)

要更改集群日志记录部署,请创建并修改集群日志记录自定义资源 (CR) 。本文根据需要提供了有关创建或修改 CR 的说明。

以下是集群日志记录的典型自定义资源的示例。

集群日志记录 CR 示例

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: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      storage:
        storageClassName: "gp2"
        size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      proxy:
        resources:
          limits:
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      replicas: 2
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/10 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi