基于国产云基座的私有化容器云平台构建研究

苏奕豪

（中国铁路兰州局集团有限公司 科技和信息化部,兰州 730000）

随着云计算技术的发展,云平台已经成为企业信息基础设施的重要组成部分。云计算发展初期,以基础设施即服务（IaaS,Infrastructure as a Service）模式为主的虚拟化技术有效解决了硬件层的资源共享与资源隔离等问题,但其承载应用的虚拟机操作系统占用了较多的宿主机硬件资源,增加了系统及应用的运营维护（简称：运维）、管理复杂度。

近年来,容器云平台凭借其轻量化、高可用、迁移便利、弹性计算等优势逐步成为助力企业发展及数字化变革的新兴技术。翁湦元等人[1]提出可将原业务系统进行容器化改造后迁移至云平台,以达到提高平台灵活性、稳定性,降低运维成本的目的；田源等人[2]为了解决乘客信息系统应用软件部署量大、部署效率低的问题,提出一种基于Docker 容器技术的软件部署架构,为乘客信息系统的进一步云化提供了技术支撑；许孟豪等人[3]阐述了云边架构下的应用协同架构,研究了基于容器的应用协同技术；郝晓培等人[4]提出了基于Kubernetes 容器的平台即服务（PaaS,Platform as a Service）平台,将容器云技术与深度学习相结合,实现了平台资源隔离及动态部署。基于以上研究,本文以国产Linux 操作系统为云基座,构建私有化容器云平台,为企业构建标准化、规范化的信息基础设施提供有力支撑。

1 私有化容器云平台及其构成

1.1 私有化容器云平台简介

容器云平台是指基于容器化和容器编排技术,结合云原生服务框架构建的一种轻量级云平台,其核心是在操作系统层面上实现对应用程序运行环境的隔离和封装[5],为应用提供开发、发布、编排、治理和运维管理的全生命周期管理能力。容器化在资源利用率、迁移便利性等方面较传统虚拟化技术有明显的优势,如图1 所示,传统虚拟化层中的虚拟机管理程序和虚拟机操作系统都被Docker 容器层所取代,采用容器化的部署、运行方式,进一步提高了底层硬件的资源利用率。

图1 虚拟化和容器化对比示意

私有化容器云平台是基于企业内部网络构建的与互联网隔离的容器云平台,仅服务于企业内部信息系统和应用,依托高速的内部网络和完善的边界防护体系,具备更高的稳定性、可用性和安全性。

1.2 私有化容器云平台构成

1.2.1 私有化容器云平台基座

本文所讨论的基座是指负载私有化容器云平台运行的服务器底层硬件和操作系统,基座中的底层硬件为平台提供计算能力、存储能力和网络链接,而平台运行所依赖的服务及组件则按照节点的属性和类型按需部署在基座操作系统上。随着国家提倡核心技术自主可控,为有效降低企业构建信息基础设施的成本,综合考量实际应用场景及稳定性、兼容性等需求,本文选择基于国产Linux 内核的OpenEuler操作系统作为搭建私有化容器云平台的云基座。

1.2.2 私有化容器云平台镜像仓库

在容器云中,镜像是用于创建容器的模板和基础,所有容器化应用均基于镜像启动,因此需要搭建私有镜像仓库对镜像资源进行统一管理,以确保容器云平台在构建和运行过程中所使用的各类镜像资源安全可靠。本文采用企业级开源容器镜像仓库Harbor[6],满足Docker 镜像的存储、分发及统一管理需求,提供图形化管理界面、基于角色访问控制、镜像远程复制及日志审计等企业级镜像管理功能。

2 私有化容器云平台设计

私有化容器云平台作为企业的核心信息基础设施,对安全性和容灾能力均有极高的要求,因此,在坚持高可用、易扩展原则的同时,须满足多租户在应用研发、测试、运维等方面的多样化需求。基于此,本文采用Kubernetes 容器编排工具,设计并搭建私有化容器云平台的集群环境,部署了10 台计算节点,包括3 台Master 节点、4 台Node 节点、2 台Proxy 代理节点及1 台负载Harbor 私有镜像仓库、Openssl（cfssl）证书签发环境、离线Yum 仓库和Yaml 资源配置仓库的Private-store 节点。当平台运算或存储能力不足时,仅增加Node 计算节点数量即可实现平台的快速横向扩容。私有化容器云平台总体架构如图2 所示。

2.1 Master 节点部署

Master 节点是Kubernetes 集群的管理核心,负责整个集群的管理,同时也是整个容器云平台的控制中枢。云平台在3 台Master 节点上分别部署了etcd分布式键值数据库及API Server、Controller manager、Scheduler 等核心组件[7]。

（1）Etcd 是一个分布式键值存储系统（数据库）[8],用于存储集群配置信息和服务注册信息[9]。为避免Etcd 出现单点故障,在测试环境中采用了集群方式部署,共安装了3 台Etcd 节点组建集群,最多可容忍2 台Etcd 节点同时故障。

（2）API Server 提供了对集群中各类资源对象（如Pod、Deployment、Daemonset、Service、Ingress、Configmap 等）的增、删、改、查操作,是整个集群的管理入口。

（3）Controller Manager（简称：CM）是集群内部的管理控制中心,负责集群内所有资源的动态管理[10],当集群中某一台Node 节点发生故障时,CM会及时发现故障并启动自动化修复流程,确保集群始终处于预期的工作状态[11]。

（4）Scheduler 主要负责整个集群中的资源调度管理,它按照特定的算法及策略,将Pod（Kubernetes中最小的管理单元,一个Pod 可以封装一个容器或多个容器[12]）调度到最优或最适合的Node 节点上,从而使集群内的资源分配更加合理、资源利用更加充分。

2.2 Node 节点部署

Node 节点是集群中的工作节点,提供了Pod 运行的基础环境,支撑着集群中运行容器的全生命周期管理。云平台在4 台Node 节点上分别部署了Kubelet 组件、Kube-proxy 组件及Docker 引擎。

（1）Kubelet 组件的主要功能是定期从API Server 接收新的或变更的Pod 定义,确保Pod 及其容器在期望的状态下运行,并实时向API Server 报送采集到的相关信息。

（2）Kube-proxy 是Pod 的TCP/UDP 代理,负责转发从Service 到后端多个Pod 实例的访问流量,引入IPVS（IP Virtual Server）模式,实现了在Kubernetes集群中负载更小、扩展性更高、性能更强的虚拟转发网络。

（3）Docker 引擎是支撑容器运行的基础,主要包含Docker 客户端（Docker Client）及Docker 守护进程（Daemon、Containerd、Runc）,各组件协同负责容器的创建和管理。

2.3 其他计算节点部署

（1）2 台Proxy 节点作为平台的入口,配置为高可用集群,分别部署DNS 和Nginx。其中,DNS负责解析Host 主机域和Kubernetes 服务域；Nginx提供反向代理。4 层反向代理指向3 台API Server,实现集群核心组件的高可用；7 层反向代理用于向外暴露Kubernetes 内部服务。

（2）1 台Private-store 节点同时部署Harbor 私有镜像仓库、Openssl 及cfssl 证书签发环境、离线Yum 仓库和Yaml 资源配置仓库。

2.4 集群核心组件部署

为构建完善的容器云平台管理及运维体系,在部署集群规划的节点和基础组件的基础上,还须安装部分功能性组件,用于承担域名解析、资源通信、服务发现、图形化管理及监控等任务。为确保组件具备高可用性,本文以容器化集群方式进行部署。

（ 1） 域名解析组件采用 CoreDNS 作为Kubernetes 集群的核心功能组件之一,主要承担服务发现配置中心的职责,负责对集群内创建的Service和Pod 自动生成对应的DNS 记录。

（2）资源通信组件采用符合CNI（Container Network Interface）接口规范的Flannel,提供了Pod间通讯的标准化网络解决方案。通过为每个Pod 分配独立IP 地址,并将数据包封装在独立网络（覆盖网络 Overlay Network）中进行转发,能够有效解决Pod 资源跨域、跨节点的通信问题。

（3）Traefik 组件承担了平台内服务自发现的功能,同时,实时监测Service 自动更新路由规则,实现更加便捷高效的服务发布。根据预先定义的逻辑规则对外部请求进行拦截,支持HTTP 反向代理或负载均衡等不同的工作模式。

（4）Dashboard 组件是一个基于Web 图形化界面的集群管理用户接口,用于部署容器化应用及服务,同时可监控集群状态、执行故障排查及管理集群资源[13],配合Metrics-Server 组件可实现对集群核心状态的聚合可视化监控。

3 私有化容器云平台关键技术

3.1 Node 节点证书自签机制

由于Master 节点中的API Server 组件启用了TLS 认证,当Node 节点中的Kubelet 和Kube-proxy组件与API Server 进行通信时,必须使用CA 认证中心签发的有效证书才能建立互信通道。因此当平台需要扩容时,通常需要手动为新加入集群的Node 节点签署和颁发证书,在带来较大工作量的同时会增加集群扩展的复杂度。

为了简化集群扩容工作流程,本文采用TLS Bootstraping 机制来实现客户端证书的自动颁发,证书自签流程如图3 所示。

图3 TLS bootstraping 证书自签流程

当新加入集群的Node 节点中的kubelet 组件在启动时会加载TLS Bootstraping 的Kubeconfig 认证配置文件,并以一个较低的用户权限向核心组件API Server 申请证书,当认证配置信息中的token 加密数据和权限验证通过后,会创建证书签名请求（CSR,Certificate Signing Request）并自动完成证书的签署和颁发。

3.2 分布式文件存储

传统容器云平台通常使用网络文件系统（NFS,Network File System）+ 持久存储卷声名（PVC,Persistent Volume Claim）+ 持久存储卷（PV,Persistent Volume）的存储资源配置方案,但由于NFS 共享存储安全性较低且存在单点故障隐患,因此本文引入了Ceph 分布式文件存储系统,利用多台存储服务器有效分担存储负荷,不仅可以提高系统的可靠性、可用性和存取效率,还能够有效将硬件设备引入的不稳定因素降到最低。Ceph 在存储数据时能够充分且均衡地利用每个计算节点的存储能力,同时,提供可供集群选择的块存储（RBD,Rados Block Device）、对象存储（RGW,Rados GateWay）及文件系统存储（cephFS,cephFleSorage）等服务[14]。ceph 在 Kubernetes 集群中的应用模式如图4 所示,利用集群中Node 节点的磁盘空间构建一个高性能、高可用、易拓展的分布式存储集群,为私有化容器云平台提供可负载多种业务的、安全可靠的数据存储服务。

图4 ceph 在Kubernetes 集群中的应用模式

4 应用方向及风险应对策略

4.1 应用方向

本文构建的私有化容器云平台具备高性能、高可用、易拓展等特性及较高的安全性,可为构建企业级数据中心提供全新的云计算参考模型,同时为企业内部存量信息系统及应用迁移上云提供最小化资源消耗的解决方案,能够实现研发项目的敏捷管理、自动化测试、持续集成和持续交付,完成需求交付端到端流程的自动化,横向打通设计、研发、测试、运维等部门间的数据壁垒,助力企业提升内部协同效率和工作质量。

4.2 风险及应对策略

私有化容器云平台在构建过程中可能存在以下风险：（1）在容器和容器编排技术领域,相关开源技术及产品种类繁多且良莠不齐,为技术选型带来了一定的难度；（2）平台采用了大量第三方开源产品及组件,社区开源软件相较于商业企业软件往往缺乏更可靠的技术支持服务,因此存在一定的供应链安全风险；（3）平台涉及网络、存储、日志、监控、安全、微服务等众多技术维度,研发、运维团队的技术储备和经验不足时将难以支撑企业在容器云平台下的应用开发和运维等需求。

为尽量规避上述风险,本文提出以下应对策略：（1）在选择构建容器云平台的技术路线或产品时,应确保各产品和组件之间保持松耦合架构,方便更新和替换,尤其要强化应对供应链产品出现重大安全漏洞及供应链产品断供等极端情况下的应急处置措施；（2）对于集群中核心组件的非缺陷性版本升级需求,要保持谨慎,至少应在非生产环境或测试环境中予以充分验证后再投入使用；（3）要不断强化相关技术领域的技术培训和人才培养工作,为企业全面应用容器化云平台提供强有力的技术支撑。

5 结束语

本文以国产开源Linux 系统为云基座,以Kubernetes+Docker 构建私有化容器云平台,为企业构建标准化、规范化的信息基础设施提供了研究方向,同时也为企业提升开发运维效率、优化信息资源配置提供了新的解决方案。

作为能够承载企业级应用需求的私有化容器云平台,如何在平台中提供通用的、基础的且具有共性需求的技术、数据及资源支撑服务,将是平台向标准化、成熟化演进的重要技术实践路径。未来将重点研究如何通过构建技术中台来逐步完善云平台基础设施,有效将技术能力与业务能力进行分离,通过标准应用程序接口实现快速集成,以标准化、产品化的方式为集群应用提供技术支撑。