容器云平台高可靠性设计

目录

1 容器云平台高可靠的需求与价值.........................................................................................................................................................................011.1 容器技术与传统虚拟化技术可靠性架构的对比..........................................................................................................................................011.2 容器的集群需求...............................................................................................................................................................................................021.3 Kubernetes对于容器云平台高可用的特性和价值.....................................................................................................................................032 容器云平台总体高可靠架构设计..........................................................................................................................................................................032.1 高可靠Docker容器集群设计和部署..............................................................................................................................................................032.2 高可靠Kubernetes集群的设计和部署..........................................................................................................................................................032.3 高可靠Etcd集群的设计和部署.......................................................................................................................................................................052.4 容器云整体高可靠的设计和实现...................................................................................................................................................................052.5 支撑高可靠的VIP技术.....................................................................................................................................................................................063 容器云平台高可靠架构的指标对比.....................................................................................................................................................................074 结语..........................................................................................................................................................................................................................07

Ⅱ

前言

高可靠是容器云平台功能架构中的关键的一环，在业务连续性和系统可靠性两个关键指标中，容器云的高可靠起到了至关重要的作用。在通用企业级的容器云平台构建和设计中，相应的设计方案和技术框架体现在高可用方面。对于企业的业务连续性而言，容器云平台的高可靠主要分为高可用、高性能、高安全性、易扩展性四个方面。高可靠的容器云平台用于承载微服务系统的应用，仅仅依靠Docker容器技术是无法满足需求的，因此Kubernetes作为服务编排和部署工具不断的和Docker以及CRI容器运行时进行融合，衔接传统的PaaS平台，在功能上不仅可以保证容器集群的编排和运维，又可以提供优越的平台层服务。Kubernetes具备完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制及多颗粒度的资源配合管理能力。

在本文”基于Docker/CRI+Kubernetes的容器云平台的高可靠设计”中，通过对Docker/CRI、Kuberne-tes和相关支撑组件的可靠性特性以及架构设计的详细分析，从而论证了其未来可以满足云平台可靠性需求的能力。

1 容器云平台高可靠的需求与价值

1.1 容器技术与传统虚拟化技术可靠性架构的对比

以Wmware为代表的虚拟化实现了内部私有云IaaS平台的技术，给企业带来了服务器运算资源的集中、应用开发速度提升、运维成本下降和系统稳定性提高等显著成效。同时，随着微服务应用的迅速发展及容器技术的逐渐成熟和广泛应用，虚拟化云平台有了相应的局限性，如何提升效率和提高稳定性成为了其新的瓶颈，因此容器技术开始进入云平台的契机已经到来。

Docker是最早开始广泛应用的容器引擎，得益于其容器仓库和社区。Docker是Dockerd，containerd，containerd-shim和runc的组合。Docker容器技术对效率和稳定性的进一步提升进行的探索实践具体为：Docker Engine取代原有重复的虚拟化层Hypervisor和系统服务层Guest OS，可以更灵活、高效地利用Linux Namespaces和Cgroups技术为应用程序提供隔离性高、安全灵活的运行空间和运行资源，从下图的技术架构进行对比可以看出两者的技术优越性。

01

基于Docker容器技术相对于Vmware虚拟化给云平台带来的提升有以下几点：可以有更快的持续部署和测试环境，可以有更多的跨平台的支持、可以有更统一的环境标准化模板，可以有更精确的版本控制，可以有更高的资源利用率，可以有可靠的安全沙箱等等。微服务的价值和意义

Docker守护进程的存在引起的稳定性问题，必须要以root特权权限启动，容器引擎的复杂性，以及C/S客户端服务器复杂模型，都已经显示Docker逐渐不再适合新一代的容器架构。随着Kubernetes在2018/2019年的发展和流行，需要更为轻量级，更加云原生的容器运行时，在Google/Redhat/Intel/IBM等厂家推动下，新的运行时引擎CRI-O得到快速发展。为了适应这种需求，Docker将Containerd剥离并贡献给CNCF基金会，获得了原生CRI的支持，低阶运行时仍然使用OCI的Runc；而cri-o 是一个 CRI 容器运行时接口的实现，为 kubernetes 提供 CRI 接口支撑。 cri-o 提供了一组最小化的工具和接口来下载、提取和管理镜像、维护容器生命周期、并提供满足 CRI 所需的监控和日志记录。 CRI-O可以让用户直接从 Kubernetes 运行容器，而不需要任何不必要的代码或工具。cri-o可以使用任何符合OCI标准的低阶运行时和容器工作，默认的运行时仍然是runc。cri-o的主要目标是作为Kubernetes的容器运行时，版本控制也与K8S一致。在此基础上出现了基于libpod的podman，来兼容docker cli中的绝大多数命令；buildah复制了docker-file的所有命令来构建oci镜像；Skopeo来传输容器镜像。Podman+Skopeo+Buildah这一符合标准CRI-O的容器套件，基于fork/exec模型，解决了由Docker守护进程导致的启动和安全问题，提高了容器的性能和安全性。当Docker不再作为缺省的容器运行时存在的情况下，企业级的容器云平台将遵循CRI-O+Kubernetes的高可靠设计模式来实现，在这里就不得不提到微服务，作为容器云平台所承载业务的主体，微服务技术的应用在可靠性设计中充当服务输出的直接方式。微服务指的是开发一种单纯、小型、有意义的功能作为一项单一服务。通过微服务能将功能分解到离散的各服务中去，降低系统的耦合性，提供更加灵活的服务支持。微服务的优点包括：（1）体量小，用于实现一种特定的功能或业务需求；（2）可由一个小的开发组完成开发；（3）松耦合，服务之间可进行开发和部署；（4）可用不同的语言开发； （5）可通过持续集成工具，便捷地自动集成部署；（6）易于理解、修改和维护；（7）易扩展。

1.2 容器的集群需求

原先的Docker等容器引擎提供有编译、上传、下载、启动和停止容器的所有必要功能，对于在单主机环境中容器数量最少的情况下，管理这些过程而言是很合适的。但是，对于企业级应用而言，当需跨多个主机管理大量的容器时，集群环境下的容器宿主机所面对的网络、负载均衡、服务发现和高可用等特殊需求都带来了很大的困扰，盲目的进行Docker容器技术陆续开展并实现容器化和微服务的转型，但在大规模群集部署和应用时，传统的容器应用依然存在诸多问题，并不能有效的避免容器云平台的可靠性问题，比如：（1）多元化平台不利于统一管理；（2）的容器服务不利于企业进行大规模信息系统的建设；（3）高可用、高冗余副本缺失，灵活度低；（4）人工运维，缺乏自动的弹性伸缩。下图为传统应用架构和微服务架构的对比。

02

1.3 Kubernetes对于容器云平台高可用的特性和价值

调度和编排是集群管理的重要组成部分。当应用被扩展到多台宿主机时，管理每个宿主系统和抽象化底层平台的复杂性变得更高。编排是一个广义的概念，是指容器调度、集群管理和为可能的其他主机供应配置。容器管理是控制一组宿主机的过程，包括从一个集群中添加或移除主机、获取宿主机或容器当前的状态、信息和启动或管理进程。集群管理与调度紧密相连，因为调度必须有权限通过集群中的每台宿主机来管理服务。Kubernetes作为 作为流行的容器编排项目，在容器之上实现包括应用部署、服务编排、高可用管理和弹性伸缩在内的一系列功能，具有以下优点：（1）提供高可用、高冗余的群集化管理模式；（2）为容器组件提供高效的弹性伸缩；（3）提供一整套易于对接的RESTfullAPI API；（4）能与企业级微服务架构无缝结合；（5）实现零停机的灰度发布。

2 容器云平台总体高可靠架构设计

在实际的架构设计中，要根据企业的实际情况进行分析和落地，设计原则是通过合理的资源和组件架构设计，按不同业务功能和模块对容器云平台的容器资源进行拆分，并纳入到不同的容器群集服务中，通过借助Kubernetes的Pod和Service分组化管理实现不同业务类型服务器资源的最大隔离及促进企业应用微服务的合理有效拆分和运营，并通过组件级的冗余设计，来达到平台级高可靠架构的实现。

2.1 高可靠Docker容器集群设计和部署

在容器集群规划中，将承载微服务的 Docker容器部署于 Kubernetes集群体系中，利用其 Master组件（APIs、Scheduler、Etcd）和多个 Node节点组件（Kubelet、Kube-proxy）及分布式存储系统保障容器群集的 高效、稳定服务，将整个系统模块分为运行在 Node节点上的容器服务和运行在 Master节点上的用于组成集群级别的控制管理服务。 Kubernetes节点有运行应用容器必备的服务，而这些都受 Master的控制。每个节点上都需运行Docker服务，用来负责所有具体的映像下载和容器运行。Kubernetes体系主要由以下核心组件组成：（1）Etcd，负责提供和保存整个集群的状态；（2）APserver，负责提供资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；（3）ControllerManger，负责维护集群的状态，如故障检测、自动扩展和滚动更新等；（4）Scheduler，负责调度资源，按照预定的调度策略将 Pod调度到相应的机器上；（5）Kubernetes，负责容器的生命周期维护及 Volume（CVI）和网络（CNI）管理；（6）Containerruntime，负责镜像管理及Pod和容器的真正运行（CRI）；（7）Kube-proxy，负责为Service提供 Cluster内部的服务发现和负载均衡。

2.2 高可靠Kubernetes集群的设计和部署

Kubernetes集群中的节点主要有三个角色：Etcd服务器、Kubernetes API服务器和应用节点(Workers)，总体框架图如下图。在该系统中，Etcd 服务和Kubernetes API服务被同时部署在三台相同的节点上，以实现服务的高可用。虽然技术上Etcd服务和Kubernetes API服务可以被分别部署在不同的节点上，从而实现硬

03

件隔离和更好的性能，但这样做的硬件成本和维护成本都较高，因此在这里我们选择了将Etcd服务和API服务同时部署在三台相同的节点上。我们这里统一将Etcd服务器、Kubernetes API服务器称为Master节点，将应用节点称为Worker节点，各个节点均运行CentOS/RHEL操作系统，其它Linux操作系统部署方法类似。

首先，在各个节点的/etc/hosts文件中加入各个节点的host-name，部署高可用Etcd服务器集群时需要使用各个节点的hostname；其次，为了安全考虑，我们需要enforcing SELinux；第三，如果是Redhat/Cen-tOS系统，将net.bridge.bridge-nf-call-iptables和net.bridge.bridge-nf-call-ipta-bles6 两项系统参数设置为1，否则部署过程中创建的iptables规则不能生效，；第四，设置防火墙规则，允许Etcd和Kubernetes各项服务可以正常通过防火墙，需要允许网络流量通过的端口详见下表。防火墙（所有主机之间通讯打通）

协议 TCP TCP TCP TCP TCP UDP UDP UDP UDP

端口 2379-2380 43 9000-9999 10249-10259 10256 47 6081 9000-9999 30000-32767

作用

etcd 服务，对等和指标端口 Kubernetes API服务

主机级别的服务，包括端口 9100-9101 上的节点导出器和端口 9099 上的 Cluster Version Operator Kubernetes 保留的默认端口 Kubernetes-SDN VXLAN 和 GENEVE VXLAN 和 GENEVE

主机级别的服务，包括端口 9100-9101 上的节点导出器 Kubernetes NodePort

节点类型 Master节点 Master节点 Master节点 Master节点 Master节点 Master节点 Worker节点 Worker节点 Worker节点

协议 TCP TCP TCP TCP TCP TCP TCP TCP TCP

流量方向 传入 传入 传入 传入 传入 传入 传入 传入 传入

端口 43 2379-2380 10250 10251 10252 10255 10250 10255 30000- 32767

作用

Kubernetes API服务 Etcd API服务 Kublet API服务 Kube-Scheduler服务 Kube-ControllerManager 只读Kublet API服务 Kubelet API服务 只读Kublet API服务 Kubernetes NodePort服务

04

设置完防火墙规则之后，分别安装Docker、Ku-beadm、Kubelet和Kubectl。由于Kubeadm不能用于安装和管理Kubelet、Kubectl，因此Kubelet、Kubectl的软件版本最好与Ku-beadm保持一致，以避免部署和运行过程中出现不兼容的风险。在容器运行时方面，目前Kubernetes原生支持CRI-O，尤其是像RHEL最新版的操作系统已经内置了CRI-O容器运行时，在部署Kubernetes集群的时候更为方便和快捷。Etcd节点和Kubernetes部署时需要使用TLS自签名证书，因此我们还需要安装证书制作工具cfssl和cfssljson。另外，为了节点之间互相访问的方便，我们往往会设置各个节点之间的SSH互信，这样通过ssh命令节点间互相访问以及节点间拷贝数据时可以免于输入密码。SSH互信可以通过ssh-keygen和ssh-copy-id命令实现，节点较多时也可以通过Shell脚本方式实现。

2.3 高可靠Etcd集群的设计和部署

Etcd是一套分布式键值对存储系统，主要用于配置共享和服务发现。Kubernetes正是基于Etcd构建的。生产环境中需要部署Etcd服务器集群以避免单点故障。部署Etcd服务器集群首先需要安装相关证书，以三台Etcd服务器(master01、mas-tert02、master03)为例，具体步骤如下：（1）在master01节点生成CA证书ca.pem和ca-key.pem；（2）在master01节点生成Etcd客户端证书client.pem和cli-ent-key.pem；（3）将上述4个证书文件拷贝到master02、master03节点的对应目录；（4）利用上述的根证书，分别在master01、master02、master03上创建Etcd Server和Peer证书，即server.pem，server-key.pem，peer.pem，peer-key.pem。完成上述证书制作以后，即可安装Etcd软件集群，实现高可靠的需求。

在某些Kubernetes发行版中，如红帽的OpenShift，我们可以方便地通过托管节点获取远程资源从而完成master和etcd集群的搭建，从而完成control plane的部署。

2.4 容器云整体高可靠的设计和实现

第一种方式是通过ReplicationController/ReplicatSet服务提供Pod组件的冗余性。RC是Kubernetes集群中用来保证Pod服务组件高可用的API对象。通过旁路监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的PodReplication数目既可是多个，也可是１个；若运行中的Pod少于指定数目，RC就会启动并运行新的Pod副本；若运行中的Pod多于指定数目，RC就会消除多余的Pod副本。即使是在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更合理，因为RC也可发挥其高可用的能力，保证始终有1个Pod在运行。ReplicatSet是Kubernetes体系中的新一代RC，具有与RC相同的高可用能力，主要区别在于Repli-catSet能支持更多种类的匹配模式，更灵活便捷。ReplicatSet一般不单独使用，而是作为Deployment的理想状态参数使用。

上面谈的更多是对于无状态应用的高可靠性实现，随着有状态应用Operator的出现和发展，对于有状态应用的高可靠性也得到了进一步的提升。通过Operator，我们可以管理有状态容器Pod的生命周期，包括应用部署，应用更新，应用告警，自动伸缩等，提升Pod的高可靠性。

第二种方式是通过多节点Master和Etcd群集保障群集服务的冗余性。鉴于Kubernetes中Master和Etcd组件的重要性，在设计容器云的部署架构时，通过采用部署Active-Active的方式和Etcd服务集群的模式来保障其整个容器群集的冗余和稳定。Kubernetes高可用群集架构，如第2小节高可靠Kubernetes集群的设计和部署所描述的高可靠架构图进行细化如下。

05

Master服务的Active-Active设 计。Kube-Controller-Manger和Kube-scheduler服 务 通过添加lead-er-elect=true参数来保证其服务同时启动，系统会自动选举leader；Kube-Apiserver原生则支持多节点同时运行，通过配置VIP对其进行浮动指向。

Etcd服务的集群设计。Etcd支持集群化部署方式，规划通过利用Static的方式对其集群进行配置。

2.5 支撑高可靠的VIP技术

通过HA部署拓扑和VIP动态漂移实现容器云平台的高可靠。在部署集群的时候，通过在cluster目录的host文件中指定多个master，worker，proxy和management节点实现HA 部署拓扑。

Linux VIP技术利用的是给网卡起一个别名，然后绑定一个新的IP地址，这样这个网卡就绑定了两个IP地址，但是这两个IP地址对应的是一个相同的物理MAC地址。因为IP地址只是一个逻辑地址，在以太网中MAC地址才是真正用来进行数据传输的物理地址，每台主机中都有一个ARP高速缓存，存储同一个网络内的IP地址与MAC地址的对应关系，以太网中的主机发送数据时会先从这个缓存中查询目标IP对应的MAC地址，会向这个MAC地址发送数据。操作系统会自动维护这个缓存。当一个节点出现问题时，VIP会自动的绑定另一个节点上，从何实现高可用。合理的故障检测，准确的在节点之间选举leader，动态漂移VIP是实现高可用的关键，只有可靠VIP漂移算法，才能避免产生“脑裂”问题。Kubernetes 使用etcd 作为存储的后端，etcd本身已经实现了Raft算法，从而实现了etcd集群的自身的leader选举。本文中的平台高可靠的设计利用etcd的V3 API分布式锁和事务的相关API实现VIP的自动漂移算法。算法的基本原理如下：持有VIP地址节点获得etcd中绑定了一个固定key的lease，TTL为8秒，在节点在lease失效前不停刷新这个lease，其他节点持续观察这个lease，如果lease到期而没有被更新，备用节点将假定第一个leader失败，并尝试自己绑定lease，使自己成为新的leader节点，并绑定VIP地址，任何操作出错等待的时间为5秒，它小于TTL，保证了在TTL的时间窗口内，一直存在节点去竞争leader。本算法使用随机选择来减少任何竞争条件下，多个节点试图成为 leader的机会，而算法的本质就是集群中的多个节点都去抢这个lease，谁抢到了谁就是 leader，etcd会保证同时只有一个人能抢到这个lease。下图为RaFc的协议图。

06

3 容器云平台高可靠架构的指标对比

对于高可靠的指标分解，分别以平台服务可靠性、资源伸缩可靠性、部署可靠性、API扩展的可靠

性来度量，下面我们就以Vmware代表的私有云，传统的Docker架构，基于CRI-O+Kubernetes的容器云平台的指标进行对比。

指标 容器服务 弹性伸缩

Vmware（私有云） 有高可靠集群保障 手工部署，无法做到自动弹性伸缩

手工配置，对于零停机较为繁琐困难 有扩展API接口，对接较为繁琐困难

传统Docker架构 零散的容器孤岛，无群集等高可用保障 手工部署、配置服务模块，无法做到自动弹性伸缩

手工配置，对于零停机较为繁琐困难

CRI-O+Kubernetes（标准容器云平台）

提供高可用、高冗余的群集化管理模式

提供容器组件高效的弹性伸缩

提供rolling-update渐进式的更新方式

部署发布 API扩展

无扩展API接口，只提供一整套易于对接服务提供命令行方式管理 的RESTfullAPI

通过指标对比发现，容器云服务平台的建设不仅使整体容器云服务的管理、伸缩性和性能等得到了提升，通过这些提升完善了整体的高可靠的特性，同时给整个架构体系模式带来了质的飞跃。

4 结语

如今越来越多的企业面临IaaS和PaaS云平台的建设及微服务系统的构建和转型。对于容器云平台

的架构设计和平台落地的过程中，要充分考虑高可靠的设计，不光是整体全局的设计，还要兼顾组件内部和组件之间的高可靠设计，通过开源的VIP技术或微服务的应用，最终达成业务连续性高水位指标的达成。

本文部门内容和插图参考于下列文献和资料：Kubernetes权威指南

Kubernetes高可用集群的部署实践

基于Kubernetes和Docker技术的企业级容器云平台解决方案通过OpenShift实现企业的数字化转型

07