容器云平台高可靠性设计1 容器云平台高可靠的需求与价值 (01)1.1 容器技术与传统虚拟化技术可靠性架构的对比 (01)1.2 容器的集群需求 (02)1.3 Kubernetes对于容器云平台高可用的特性和价值 (03)2 容器云平台总体高可靠架构设计 (03)2.1 高可靠Docker容器集群设计和部署 (03)2.2 高可靠Kubernetes集群的设计和部署 (03)2.3 高可靠Etcd集群的设计和部署 (05)2.4 容器云整体高可靠的设计和实现 (05)2.5 支撑高可靠的VIP技术 (06)3 容器云平台高可靠架构的指标对比 (07)4 结语 (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技术为应用程序提供隔离性高、安全灵活的运行空间和运行资源，从下图的技术架构进行对比可以看出两者的技术优越性。
基于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）人工运维，缺乏自动的弹性伸缩。
下图为传统应用架构和微服务架构的对比。
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服务可以被分别部署在不同的节点上，从而实现硬件隔离和更好的性能，但这样做的硬件成本和维护成本都较高，因此在这里我们选择了将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各项服务可以正常通过防火墙，需要允许网络流量通过的端口详见下表。