ZCF 支持容器服务能力，可将云平台的计算、网络和存储能力扩展到容器集群和云原生应用，为容器化业务提供集群管理、资源调度、应用编排、制品交付、运维治理和安全控制能力。容器服务能力由 ZStack Zaku 承载。

技术架构

容器服务采用管理集群、业务集群和托管集群相结合的架构。管理集群承载容器服务管理组件，业务集群承载通过容器服务创建和管理的容器业务，托管集群用于接入已有 Kubernetes 集群并纳入统一管理视图。

管理集群

管理集群承载容器服务的管理组件，每套容器服务部署仅包含一个管理集群。管理集群部署完成后，管理员可通过管理控制台统一管理业务集群、托管集群、镜像、应用包、工作负载和运维数据，并为管理员、运维人员和审计人员提供一致的操作入口。

容器服务主要支持管理以下资源：

• 集群：一组计算节点（物理机或虚拟机）的集合。
• 节点：为容器组实例提供计算、网络、存储等资源的节点（物理机或虚拟机）。
• 本地仓库：用于存储容器镜像、应用包的存储服务器。
• 容器镜像：容器的镜像模板文件。
• 应用：Helm 应用包，一组 Kubernetes 资源的集合。
• 工作负载：定义容器组的期望运行状态，例如容器组配置、副本数和调度策略。
• 容器组：实际运行容器实例的集合。
• 服务：为一组容器组提供服务发现与负载均衡入口。
• 路由：为一组容器组提供七层负载均衡入口。
• 网络策略：控制容器组入站与出站网络流量的策略。
• 数据卷：用于持久化存储容器数据，容器重启、迁移或删除时数据仍然能够保留。
• 配置集及保密字典：通过键/值对储存配置数据并映射到容器中，将容器镜像与配置信息解耦。

容器服务通过管理集群、业务集群和托管集群组织管理能力。管理集群承载容器服务管理组件，负责集群创建、资源管理、制品管理和运维能力；业务集群由管理集群创建并承载容器化业务；托管集群用于接入已有 Kubernetes 集群，使既有容器环境能够进入统一管理视图。

在业务集群中，节点提供计算、网络、存储和设备资源，Kubernetes 负责将这些资源抽象为可调度的容器运行环境。围绕业务集群和托管集群的边界，后续内容进一步展开计算资源隔离、调度策略和设备使用方式。

业务集群是由管理集群创建和管理的 Kubernetes 集群，用于承载容器化业务。一个管理集群可管理多套业务集群，使不同业务、租户或环境能够在独立集群中运行，并通过统一入口完成资源管理、应用交付和运维操作。

业务集群预置监控、日志事件采集、操作审计和服务治理等组件，可在业务交付后持续提供运行状态观测、问题定位和治理能力，降低用户自行拼装容器基础组件的复杂度。

业务集群主要支持以下能力：

• 业务集群生命周期管理
• 节点手动及自动扩缩容
• 标准 Kubernetes 资源管理
• 异构 CPU 架构、异构 GPU 设备等管理
• 支持多 Kubernetes 发行版本
• 支持 Calico VXLAN、Calico BGP、容器组外部网络、服务外部网络等 CNI 插件
• 支持对接 ZStack ZStone、ZStack ZBS、ZStack ZCE-X 等分布式存储
• 提供监控告警功能
• 提供日志、事件采集功能
• 提供微服务治理插件

托管集群是由第三方平台或外部环境创建的标准 Kubernetes 集群。管理员上传 kubeconfig 文件后，可将该集群接入统一管理视图，并在不迁移业务的前提下查看和管理集群资源。

托管集群适用于已有容器环境的接入场景，可降低业务迁移、重新调试和服务中断风险。但由于集群不是由容器服务创建和维护，部分集群级维护能力和增强能力存在边界：

• 不提供 Kubernetes 集群层面的维护工作，不保障托管集群的稳定性和高可用能力，不提供节点调优、节点添加和节点移除等操作。
• 部分功能不可用，例如微服务治理、监控日志报警和外部网络等。

容器服务的计算虚拟化面向容器化业务运行场景，将节点中的 CPU、内存和设备资源抽象为可申请、可调度、可隔离的容器运行资源。与 KVM 等硬件级虚拟化不同，Kubernetes 主要依托 Linux 命名空间（Namespace）和控制组（Cgroup）在操作系统层面提供资源隔离与容量控制。

命名空间用于隔离进程、网络、挂载点、用户和主机名等运行视图，控制组用于限制和统计 CPU、内存等资源使用。基于这些机制，容器可在共享宿主机内核的前提下获得相对独立的运行环境，并由调度器根据资源请求、资源限制和节点状态选择合适的运行位置。

CPU 虚拟化用于控制容器化业务对节点 CPU 资源的占用，使不同容器组能够在共享节点上稳定运行。Kubernetes 基于控制组（Cgroup）和 CPU 子系统，将容器的 CPU 请求和 CPU 限制转换为内核调度参数。

在宿主机内核看来，容器进程仍是普通调度实体，并不获得独立的 CPU 特权级。CPU 请求用于调度阶段的资源预留和节点筛选，CPU 限制用于运行阶段的时间片控制。当多个容器组竞争 CPU 资源时，内核调度器会根据这些参数分配 CPU 时间，避免单个容器组长期占用超出预期的计算资源。

内存虚拟化用于为容器组提供可预留、可限制的内存运行边界。Kubernetes 基于 Linux 内存管理子系统和控制组（Cgroup）记录容器内存使用量，并对容器运行时的内存申请进行约束。

容器实例可配置内存请求和内存限制。内存请求主要用于调度阶段的节点筛选与资源预留，决定容器组被分配到哪个节点；内存限制用于运行阶段的容量控制。当容器内进程申请的内存总量超过限制时，宿主机内核会尝试回收内存；如果回收后仍无法满足分配请求，将向容器触发 OOM（Out of Memory），避免异常内存占用继续影响节点和其他业务。

设备虚拟化用于将 GPU 等异构设备纳入容器调度体系，使 AI 推理、模型训练、图形处理等业务能够在容器环境中使用专用硬件资源。容器本身不提供类似 KVM 的硬件模拟能力，容器内进程通常通过宿主机暴露的设备节点访问物理设备或虚拟化后的设备资源。

Kubernetes 通过设备插件（Device Plugin）框架完成设备发现、资源上报和调度对接。设备插件运行在节点上，通过 gRPC 与 kubelet 通信，并将 GPU 等硬件能力注册为 Kubernetes 扩展资源。注册完成后，用户可在容器组规格中申请相应设备资源，调度器根据节点资源容量、请求量和调度策略选择运行节点。

容器网络虚拟化用于为容器化应用提供集群内通信、服务发现、访问控制和外部访问能力。容器服务基于 Kubernetes 网络模型和 CNI 插件，将节点网络资源组织为容器网络、服务网络、网络策略和外部网络，使容器组在创建、扩缩容、迁移和重建过程中保持稳定的网络访问路径。

容器业务集群默认使用 Calico VXLAN 模式作为容器网络插件。VXLAN 是一种 Overlay 网络方案，在容器组互相访问时，将容器数据包封装为 VXLAN 报文，并通过 UDP 4789 端口在节点间传输。该模式对底层网络依赖较低，不要求交换机支持 BGP，也不需要配置复杂路由，只要节点间 IP 可达即可工作，适用于网络条件相对受限或需要快速部署的场景。

在 VXLAN 模式下，Calico 的网络策略能力仍然可用，用户可以继续通过网络策略（NetworkPolicy）实现细粒度访问控制。对于底层网络支持 BGP 且对网络性能要求较高的场景，容器服务支持切换至 Calico BGP 路由模式。BGP 模式通过 BGP 协议和路由反射器将节点的容器组 CIDR 宣告给底层网络或其他节点，使容器组流量以原生 IP 报文转发，减少隧道封装带来的额外开销，并便于与企业现有三层网络融合。

在 Kubernetes 中，容器组的生命周期是短暂的。一旦容器组因滚动更新、节点故障或资源回收而被重建，其 IP 地址就会改变。如果客户端直接通过容器组 IP 访问应用，就必须实时感知这种变化，这在分布式系统中是不可持续的。服务的核心能力，就是为后端的动态容器组集合提供一个静态的网络入口。

当用户创建一个服务时，Kubernetes 会从集群预分配的服务 CIDR（通常是一个私有网段，如 10.233.0.0/16）中分配一个虚拟 IP 地址，称为 ClusterIP。这个 IP 地址不绑定到任何物理网卡或容器接口上，它纯粹是一个逻辑地址，由集群内部的路由和转发机制维护。服务通过标签选择器关联一组容器组，这组容器组的 IP 和端口被收集为端点（Endpoints）。客户端访问服务的 ClusterIP 时，流量被透明地分发到这些后端之一。

对于 NodePort 类型的服务，外部流量首先到达节点的物理网卡，经过 kube-proxy 的 NAT 规则转换为容器组 IP，再进入 Calico 的 VXLAN 转发平面。Calico 本身不处理服务的负载均衡逻辑，但为服务后端容器组的可达性提供了基础网络层。

Calico 在宿主机内核中通过网络策略（NetworkPolicy）实现容器组级别的访问控制。Calico 将 Kubernetes NetworkPolicy 资源翻译为 iptables 规则，施加在宿主机上的 cali 接口和转发路径上。对于进入容器组的流量，规则可以匹配源 IP、目的端口、协议类型和标签选择器，决定允许或拒绝。对于离开容器组的流量，同样可以在宿主机上实施出向策略。由于所有容器组流量都必须经过宿主机的内核转发平面，iptables 规则可以在流量进入 veth 设备之前或离开 veth 设备之后进行拦截。Calico 使用 Linux 内核的连接跟踪（conntrack）机制维护连接状态，允许已建立连接的返回流量自动通过，减少规则匹配的重复开销。在 VXLAN 隧道路径上，网络策略的应用点位于解封装之后。当远端节点发来的 VXLAN 报文被解封装后，内层数据包进入宿主机的转发平面，此时内核首先匹配 iptables 规则，只有通过策略检查的数据包才会被转发到目标容器组的 veth 设备。这意味着安全策略在目标节点的宿主机内核中执行，而非在隧道端点或源节点上提前过滤。

外部网络用于打通容器业务集群与集群外部网络之间的访问路径，使外部客户端能够访问容器化应用。容器服务提供服务外部网络和容器组外部网络两类能力，分别面向负载均衡访问和容器组直接访问场景。

• 提供服务外部网络功能，为 LoadBalancer 类型的服务提供一个独立的三层网络 IP 地址，并关联一组后端容器组，使集群外的客户端可通过这个 IP 负载均衡到后端容器组上。
• 提供容器组外部网络功能，为每个容器组分配一个独立的三层网络 IP 地址，使集群外的客户端可通过这些 IP 地址直接访问容器组。

NodePort 类型的服务提供对集群外客户端暴露访问端口的能力，但受限于节点 IP 无高可用以及端口号限制，并不是生产环境的首选方案。服务外部网络集成 MetalLB 组件以及地址管理能力，用于解决 IP 地址高可用以及端口号限制问题。当用户创建 LoadBalancer 的服务时，MetalLB 从预配置的地址池中自动分配一个外部 VIP 并写入服务状态，使集群外部客户端可通过该 VIP 访问后端容器组。它提供两种流量接入模式：Layer 2 模式通过 ARP/NDP 将 VIP 绑定到单个节点实现故障转移；BGP 模式则通过 BGP 协议将 VIP 宣告到上游物理路由器，实现真正多节点负载分担。

在 Kubernetes 中，容器组默认仅通过主 CNI（本平台使用 Calico）获得一个集群网络接口和单一 IP 地址。然而，在 Underlay 网络场景下，业务往往需要容器组直接暴露在物理网络中，或者需要多个网络接口分别承载管理流量、业务流量和存储流量。通过 Multus CNI、Macvlan 以及 Spiderpool 协同，为容器组提供了获取额外 IP 地址的能力。

Multus：允许在容器组创建时串联调用多个 CNI 插件，从而为主网卡之外附加额外的网络接口。

Macvlan：在宿主机物理网卡上创建虚拟子接口并直接移入容器组的网络命名空间，使容器组获得一个桥接到物理网络的二层接口，无需虚拟网桥即可与外部网络直接通信。

Spiderpool：为 Macvlan 等 CNI 提供 IP 地址的分配与回收，通过地址池管理、固定 IP、节点选择及垃圾回收机制，确保额外 IP 地址在物理网络中的正确分配与生命周期一致性。

这种能力也带来了额外的管理复杂度。每一个额外 IP 都消耗物理网络的真实地址资源，需要与现有的 IP 地址管理体系（如 DHCP、CMDB、防火墙策略）协同。网络管理员必须确保 IP 地址段在物理交换机上已正确配置 VLAN、网关和路由，否则容器组内的接口虽然获得了 IP，却无法与外部通信。

容器存储虚拟化用于为容器化业务提供持久化数据能力。容器服务基于 Kubernetes 存储模型，将主机路径和对接的存储抽象为可被容器组挂载的数据卷，使应用数据能够独立于容器生命周期保存，并支撑有状态应用的部署和运行。

对于临时性、节点相关或系统组件场景，可使用主机路径直接访问节点本地目录；对于生产业务和跨节点调度场景，可通过 CSI 容器存储接口对接集中式存储、分布式存储或其他存储系统。

主机路径（HostPath）允许将宿主机上的目录挂载到容器文件系统内，适用于日志采集、节点配置读取和系统级组件运行等需要访问节点本地文件的场景。该方式通过挂载命名空间（Mount Namespace）的绑定挂载（bind mount）操作，将宿主机文件系统中的指定路径映射到容器内。

容器内进程访问主机路径挂载点时，文件系统调用会直接进入宿主机内核文件系统层，无需经过块设备转换、虚拟磁盘驱动或额外 I/O 虚拟化栈，因此具备较直接的访问路径。以容器日志采集功能为例，可通过主机路径挂载 /var/log/pods 目录读取节点上的容器日志文件。

主机路径与具体节点强绑定，不具备容量虚拟化边界，也不适合作为跨节点迁移场景下的通用持久化存储。使用该能力时，需要结合业务类型、目录权限和节点容量进行规划，避免容器写入数据影响宿主机或其他容器的正常运行。

对接存储用于为容器业务提供独立于节点本地磁盘的持久化存储能力。通过对接外部存储系统，容器数据卷可以随业务需求完成创建、挂载、卸载、扩容和回收，降低容器重建、节点故障或业务迁移对应用数据的影响。

容器服务通过 Kubernetes 标准存储接口对接存储，具体能力取决于存储系统及其驱动实现。通过 CSI 容器存储接口、StorageClass、PV 和 PVC 等机制，外部存储卷可被纳入 Kubernetes 资源模型，并以数据卷形式供容器组使用。

CSI 容器存储接口

CSI（Container Storage Interface，容器存储接口）是 Kubernetes 对接外部存储系统的标准接口。通过 CSI，集中式存储、分布式存储和本地存储等能力可被抽象为 Kubernetes 存储资源，并以数据卷形式挂载到容器组中。

CSI 驱动通常分为控制器端插件（Controller Plugin）和节点端插件（Node Plugin）。控制器端通常以 Deployment 工作负载形式运行在集群中，通过 gRPC 与外部侧车（external-provisioner、external-attacher 等）通信，负责与存储系统控制平面交互，执行卷创建、删除、快照和扩容等操作。

节点端插件（Node Plugin）以 DaemonSet 守护进程集形式运行在每个工作节点上，通过节点驱动注册器（node-driver-registrar）向 kubelet 注册自身的 Unix 域套接字（Unix Domain Socket）。当容器组需要使用存储卷时，节点端插件（Node Plugin）在宿主机上执行具体的挂载操作。对于块存储类型的分布式卷，节点端插件（Node Plugin）首先通过 iSCSI、RBD 等协议将远程卷映射为宿主机上的一个块设备（如 /dev/rbd0），然后由 kubelet 或节点端插件（Node Plugin）将该块设备格式化为指定的文件系统（如 ext4、xfs），最后通过绑定挂载（bind mount）将文件系统树纳入容器的挂载命名空间（Mount Namespace）。对于文件存储类型的分布式卷（如 CephFS、NFS），节点端插件（Node Plugin）直接将远程文件系统挂载到宿主机的一个路径下，再通过绑定挂载穿透到容器内部。

当容器挂载存储成功后，容器内的进程看到的只是一个普通的目录或文件系统挂载点，与访问本地磁盘无异。但底层的文件系统调用从容器进程进入宿主机的 VFS 层，若底层是网络文件系统（如 CephFS、NFS）则直接进入内核的网络文件系统客户端；若底层是块设备则进入页缓存和块层，最终通过宿主机内核的驱动栈发往存储集群。

同时 CSI 规范定义了标准化的快照、克隆、扩容等接口，将底层分布式存储的快照能力暴露为 Kubernetes 的原生资源，并由第三方存储厂家提供具体功能的实现。

存储资源 PV 与 PVC

在 Kubernetes 资源管理层面，通过 CSI 建立了独立的存储发现与抽象层，将第三方存储数据卷的物理信息（例如卷的后端标识）与容器工作负载解耦。这一抽象层的核心由三个对象构成：StorageClass、PersistentVolumeClaim（PVC）和 PersistentVolume（PV）。

StorageClass 是存储资源的类别定义，由集群管理员预先创建。它指定了 CSI 驱动的名称、后端存储池的参数（如 Ceph 的 Pool 名称、副本策略、QoS 等级）、回收策略（Retain 或 Delete）以及卷绑定模式（Immediate 或 WaitForFirstConsumer）。StorageClass 的存在使得底层分布式存储的复杂配置对终端用户透明。

PVC 是终端用户的资源请求声明，创建在特定的命名空间内。用户只需声明所需的容量、访问模式和 StorageClass 名称，无需关心底层存储的具体位置、网络拓扑或物理介质类型。PVC 创建后，集群中的外部供给器（external-provisioner）监听到该请求，通过 gRPC 调用 CSI 控制器端的 CreateVolume 接口。CSI 控制器将这一请求翻译为分布式存储的 API 调用，在存储集群中实际分配空间，生成一个唯一的卷标识。

PV 是集群中实际存储卷的抽象对象，由供给器根据 StorageClass 和 PVC 的需求自动创建，或由管理员手动预先创建。PV 对象记录了卷的后端标识、容量、访问模式、节点亲和性约束以及对应的 CSI 驱动信息。一旦 PV 与 PVC 绑定，该卷就被视为已被占用，直到 PVC 释放。

应用与资源管理用于将 Kubernetes 资源、应用包和 DevOps 工程组织为可视化、可维护的应用交付对象。容器服务在保留 Kubernetes 标准资源模型的基础上，提供图形化资源管理、应用生命周期管理和工程化交付能力，使用户既可以直接管理工作负载、服务、路由、网络策略等基础资源，也可以通过应用和流水线完成更完整的发布流程。

应用管理用于将一组工作负载、服务、存储等 Kubernetes 资源作为一个整体进行部署和维护。容器服务基于 Helm 管理应用实例，使用户能够以应用为单位完成发布、升级、回滚、版本管理和运行状态查看。

应用涉及以下核心概念：

• Helm：Kubernetes 包管理工具，用于描述、安装和管理由 Kubernetes 资源构成的应用。容器服务集成 Helm 3.0 并扩展可视化操作能力，降低用户直接编写和维护应用资源定义的复杂度。
• 应用包：描述应用部署所需的工作负载、容器镜像、依赖关系和资源定义。用户可通过应用包部署一个完整应用，并在后续运行过程中统一维护应用相关资源。

容器服务支持将应用市场提供的开源软件或本地仓库中的应用包发布到集群，部署完整的应用实例，并提供应用生命周期管理、运行状态展示和基础运维能力。

标准资源管理面向需要直接维护 Kubernetes 原生资源的场景。除通过应用包发布应用外，容器服务还提供命名空间、工作负载、任务、容器组、服务、路由、网络策略、配置集和保密字典等主流资源的图形化管理能力。

通过标准资源管理，用户可以在不直接操作命令行或 YAML 文件的情况下查看和编辑资源配置，也可以在应用运行异常、资源关系排查或细粒度调整时直接定位到底层 Kubernetes 资源。

DevOps 工程用于将容器应用的构建、部署、测试和发布流程纳入统一工程管理。该能力基于 Kubernetes 运行底座，整合流水线、环境、测试、模板和效能数据等能力，帮助用户在多集群、多租户场景下管理容器应用全生命周期。

DevOps 工程主要包含以下功能模块：

工作流管理

工作流管理覆盖开发、测试、预发和生产发布等阶段，支持多服务并发构建、部署和测试，并通过发布策略编排保证配置、数据和业务变更过程可控。用户还可以通过自定义任务对接企业内部流程和系统。

环境管理

环境管理支持创建子环境、复制睡眠环境和维护多环境配置，并通过服务依赖编排管理复杂应用环境。开发者可使用共享环境和自测子环境进行调试验证，减少重复准备测试环境的工作量。

测试管理

测试管理支持对接测试框架和平台，覆盖单元测试、集成测试、系统测试和性能测试等自动化测试场景。测试结果可沉淀为报告，用于辅助发布验收和质量分析。

模板库模块

模板库模块用于沉淀不同技术栈和服务类型的构建模板。运维团队可通过模板统一工作流规范，开发团队可复用模板创建工程流程，减少跨项目重复配置。

效能洞察模块

效能洞察模块用于汇总质量、效率和成本等指标，并通过看板展示项目效能数据。团队可基于这些数据识别流程瓶颈和交付风险，为后续流程优化提供依据。

制品与交付用于管理容器应用从构建产物到部署配置的关键对象，包括容器镜像、应用包和 YAML 模板。容器服务通过本地仓库、应用市场和模板管理能力，将镜像存储、应用发布和资源配置组织到统一交付链路中。

本地仓库提供容器镜像和应用包存储能力，支持 OCI 容器镜像标准。用户可通过在线上传、UI 上传和命令行等方式上传、下载和管理制品，并通过权限管理控制不同用户对本地仓库的访问范围。

镜像管理还提供 container-package 组件，可将容器内的软件安装、配置文件和数据变更保存为新的镜像，并推送到平台内置的本地仓库中，便于用户制作和复用容器镜像。

应用包管理基于 Helm 实现应用部署。用户既可以使用 Helm 常规部署方式，也可以通过 YAML 参数配置方式完成应用发布。对于参数较多或配置项较复杂的应用，平台提供表单化配置能力，并展示表单内容与原始 YAML 的差异，部署时再将表单配置回填至 YAML。

表单化配置降低了直接编辑 YAML 的门槛，有助于减少格式错误、配置遗漏和参数填写不一致等问题，使应用包能够以更稳定的方式在不同集群或环境中交付。

Kubernetes 资源通常通过 YAML 文件完成发布、更新和查看。模板管理提供工作负载、服务、配置集等资源的 YAML 样板，也支持用户创建和维护符合自身业务需求的 YAML 模板。

通过模板管理，用户可以复用常见资源配置，减少重复编写 YAML 的工作量；对于暂不需要完整 Helm 应用包的场景，也可以通过模板快速创建所需资源。

容器服务通过微服务治理和服务拓扑能力支撑应用流量管理与运行分析。

集成 Istio 来实现服务治理功能，核心功能主要包括流量治理、应用拓扑、链路追踪。在部署容器业务集群时，可选择打开服务治理功能，会在容器业务集群的管理节点上会部署 Istio 控制平面的相关组件。

在容器组启动时，微服务治理组件会注入一个 sidecar 容器。这个 sidecar 通过 iptables 规则，将容器组内业务容器的所有入站和出站流量透明地重定向到服务治理组件代理上。也就是说，业务容器以为自己直接在和外部通信，实际上所有流量都先经过服务治理组件，再通过事先指定的负载均衡策略，比如轮询、最少连接、一致性哈希等，将请求分发到具体的后端实例。而在流量被治理的同时，还会生成遥测数据，获取服务访问速率、成功率、延迟等信息。同时提供工作负载的灰度发布方案。

当容器组被微服务治理功能纳管后，通过获取到的遥测数据做进一步梳理和展示，呈现出容器组间访问的实时网络拓扑，并提供基础的监控数据信息，更直观展示服务调用的状态。

容器服务提供巡检、监控告警、日志和事件管理等运维能力。

一键巡检功能支持对平台、集群基础组件以及计算、网络资源关键指标和服务进行一键式健康检查，并根据巡检结果进行健康评分，提供自动巡检、免登陆巡检、巡检建议、巡检报告导出等附加功能。旨在降低运维人员的运维门槛，大幅提升运维效率。

用户可自定义根据类别选择巡检项进行一键巡检，启动巡检后，容器服务将对所选择的巡检项涉及的资源或服务进行健康检查。一键巡检内置健康评分机制，支持对所巡检的资源或服务的健康状态进行量化评分，帮助用户直观准确把握平台整体运行状态。

监控模块由多个组件构成，实现集群、存储、工作负载、容器等级别的监控指标的采集以及监控数据的存储。在该设计中，Exporter 周期性采集监控数据，Prometheus 收集数据、Thanos 查询聚合、open-local 提供数据持久化存储空间。监控模块将集群组件、应用状态统计、资源用量等运维阶段需要关注的汇总数据经过统一化的多监控图表，方便直观的查看多种资源的多个监控指标，快速获取集群状态。此外，还兼容标准的 Prometheus API，可与 Grafana 等主流监控系统对接。

告警模块基于监控模块采集的数据指标，通过可视化灵活定义告警规则，对数据进行统一分析后实时通过 Alertmanager 推送告警通知，以浏览器页面通知、邮箱、企微信、钉钉、Webhook 等方式第一时间通知运维人员，有效提高运维效率、节约运维成本，满足大部分运维场景需求。

Kubernetes 仅将容器 stdout、stderr 的日志信息存放在节点本地，本地日志与节点生命周期强绑定，一旦节点故障、磁盘损坏或容器组被驱逐重建，历史日志即永久丢失。日志模块由日志收集器、日志存储器以及日志展示组成。日志模块轻量化设计并使用标签作为索引，比传统日志采集的方案采用全文检索对日志进行索引更快速高效，也极大地降低了日志索引的存储。此外，日志模块具备以下特点：支持容器日志的统一收集、集中展示，不限于容器的标准输出/标准错误。支持按照命名空间、工作负载、容器组、容器等方式分类和查询日志。

Kubernetes 将 事件存放在 etcd 中，并且默认只保留 1 小时，过期事件将自动删除，也仅能提供有限的数据保留。而事件查询功能通常用来排查工作负载、容器组、节点、存储挂载等异常时重要的排查方式。平台提供事件采集组件，将 Kubernetes 集群上所有的事件信息统一发送到日志模块内，实现事件信息的持久化存储及资源类型、资源名称、信息、事件类型、原因等信息的展示。