容器云平台高可靠性设计

容器云平台高可靠性设计

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）人工运维，缺乏自动的弹性伸缩。下图为传统应用架构和微服务架构的对比。