关于kubernetes:toB应用私有化交付发展历程技术对比和选型

因为数据隐衷和网络安全的思考，大多数 toB 场景的客户须要私有化利用交付，也就是须要交付到客户的环境里，这样的客户有政府、金融、军工、公安、大型企业、特色行业等，这些私有化场景限度很多，如何进步私有化利用交付的效率是个难题，本文将介绍，私有化利用交付有哪些技术？他们都各自有什么特点？私有化利用交付的倒退历程。

toB 利用私有化交付的艰难点

环境网络限度，影响交付效率

• 交付施行过程中不能不便查找材料；
• 在交付过程中，交付人员须要跟公司的开发进行沟通，网络限度会影响合作工具的应用，有些客户环境甚至不能带手机，会影响解决问题的效率，环境越简单影响越大；
• 在离线环境内，装置软件包也没方法间接下载，咱们须要将安装文件或配置文件打包成离线包，在客户环境导入。因为业务的复杂性会导致镜像很多且很大，只能有交付人员带移动硬盘到客户现场导入，导致在导入离线包就会破费较多工夫。甚至有些环境只能刻录光盘在客户环境导入，光盘自身存不了太大的包，只能分多个光盘刻录；

客户基础设施差别，须要适配过程

• 在私有化场景，不同客户的装置环境也不一样，有些应用物理服务器，有些应用虚拟机，不同的虚拟机厂商也有差别。操作系统也各有不同，例如常见的操作系统有 CentOS/Debian/Ubuntu/Redhat，以后还有很多国产化操作系统。CPU 架构也可能不同，有 X86、ARM 等；
• 资源筹备周期长，须要审批流程；
• 交付的利用须要很重的适配过程，要么在公司适配，要么在客户现场适配；
• 因为环境差别很大，利用交付完须要残缺测试和验证，须要大量的人力和工夫投入；

交付人员的技术门槛高

• 交付人员须要懂底层硬件和网络；
• 交付人员须要懂操作系统和零碎运维，须要懂服务治理、高可用、平安、性能剖析、备份复原、交付开发等等；
• 交付人员要能独立排查交付利用的问题，须要很强的技术根底；

定制化交付迭代效率低

• 在定制化交付场景，客户会参加到开发过程中，客户须要看到成果后反馈问题，再继续迭代，直到客户称心，过程中须要频繁降级产品；
• 如果开发人员在公司定制开发，降级过程简单，沟通低效；
• 如果开发人员在客户现场，没有好的开发工具和环境，开发效率低，人力投入大；

前期保护难度大

• 利用交付实现后，前期须要保障利用运行的稳定性，离线环境近程没方法运维，报警没方法收回来，运维的难度大；
• 产品有 Bug、一些预期内的变更或产品升级都须要出差客户现场，反对的老本比拟高；

传统利用交付

传统的利用交付是间接交付二进制的可执行文件或软件包：

• 二进制的可执行文件： Java 的 Jar，Linux 的可执行文件，Windows 的 EXE 等。
• 软件包： CentOS 应用 RPM 包，Debian 应用 DEB 包，Java Web 应用 WAR 包。

装置他们都须要先装置依赖的环境和根底软件，YUM 和 DEB 有本人的治理依赖的软件源，但离线环境用不了，如果客户的操作系统不同，还须要另外想方法解决，运行这类服务为了解决启动和主动重启的问题，还须要通过 Systemd 或 Supervisor 的形式来治理。如果交付单体架构的利用传统利用交付形式还能胜任，但如果是简单的微服务架构，传统利用交付形式将难以胜任。

在传统利用交付过程中，治理这些运行环境和操作系统差别是一个痛点，容器的呈现解决了这个问题。

以后云原生技术利用交付

云原生利用交付次要应用的容器和 Kubernetes 相干技术。

Docker 镜像交付

Docker 将业务和依赖的库一起打包成 Docker 镜像，在这个镜像中蕴含所有环境和利用，这样就能够达成一处打包、到处应用，咱们能够将该镜像在任何反对 Docker 的操作系统上运行。Docker 的个性确实解决了很多开发、交付以及其余许多问题，因而 Docker 容器概念迅速的被遍及。

在微服务架构场景，须要多个服务或利用一起交付，服务之间有依赖，还有简单的配置，DockerCompose 解决了这个问题。

Docker-Compose 利用交付

DockerCompose 将多个服务或利用应用 YAML 的形式治理，能够利用 DockerCompose 命令装置部署和治理，对于一个微服务架构的利用，利用 DockerCompose 命令就能够在任何操作系统实现一键装置和运行，当然前提是须要装置好 Docker 和 DockerCompose。

对于单机场景 DockerCompose 能够实用，当利用须要高可用或多节点分布式部署，DockerCompose 就不能胜任，Kubernetes 的呈现解决了容器的高可用和散布式调度问题。

Kubernetes YAML 利用交付

在 Kubernetes 中部署业务咱们须要定义 Deployment Statefulset Service 等资源类型，通过调整正本的形式 Kubernetes 会主动调度到多个节点实现业务高可用，在交付时咱们只须要将这些 YAML 资源和 Image 导出，在客户的 Kubernetes 环境中部署并交付给客户。这种交付形式须要客户环境有 Kubernetes 或在客户环境装置 Kubernetes。

当咱们将 Kubernetes YAML 交付很多客户的时候，就须要参数配置、版本治理和简略的装置和降级，Helm 在 Kubernetes YAML 的根底上解决了上述问题。

Helm 利用交付

Helm 是 Kubernetes 资源的包管理器，它能够将一组资源定义成 Helm Chart 模版，提供了基于 Helm Chart 模块的装置和降级，装置时能够配置不同的参数。Helm 同样也是在 Kubernetes 交付中大多数人抉择的工具。

Helm 最大的问题是须要开发者学习容器和 Kubernetes 整个技术栈，而且客户环境必须要有 Kubernetes，学习和应用的门槛太高。形象的利用模型是一个解决方案。

面向未来的云原生利用模型交付

利用模型强调以利用为核心的理念，让开发者专一在业务自身，在利用级形象和包装底层简单的技术，利用模型跟底层基础设施齐全解耦，依据对接和交付的基础设施不同，主动转换和适配，真正实现一次开发，处处自动化部署。

基于 OAM 的 KubeVela 利用交付

OAM（Open Application Model）是一个形容利用的标准规范。有了这个标准，利用形容就能够彻底与基础设施部署和治理利用的细节离开。通过将利用定义与集群的运维能力拆散，能够让利用开发者更专一于利用自身，而不是”利用部署在哪“这样的运维细节。KubeVela 基于 OAM 实现了利用跨云、跨环境继续交付。以后 KubeVela 对离线场景的利用交付反对较弱。

基于 RAM 的 Rainbond 利用交付

Rainbond 是一个云原生利用多云治理平台，Rainbond 遵循以利用为核心的核心理念，对立封装容器、Kubernetes 等简单技术，将 Kubernetes 资源对立形象成 RAM（Rainbond Application Model）利用模型，使用户能非常简单的应用 Kubernetes，升高用户应用的门槛，使用户专一于利用开发、利用交付和利用运维。

在对于离线交付场景，Rainbond 基于 RAM 能够导出三种离线交付包：

• Rainbond 利用模版包：其中蕴含了简单微服务架构交付的所有因素，反对降级和回滚，但要求客户环境装置 Kubernetes 和 Rainbond；
• 非容器的软件包：非容器包依照传统利用交付形式打包，但易用性更好，包中蕴含了环境依赖，并采纳动态编译，适宜大多数操作系统，应用 Systemd 治理；
• Docker-Compose 离线包：反对在规范 Docker Compose 环境一键启动和治理；

综合比照

• 利用交付门槛：传统形式交付门槛最高；Docker、DockerCompose、Kubernetes Yaml、Helm 和 KubeVela 交付的门槛中等，因为须要学习会容器和 Kubernetes 相干技术；Rainbond 应用最简略，不须要学习容器和 Kubernetes。
• 微服务反对：除传统利用交付和 Docker 镜像，其余形式都反对微服务编排和打包交付。
• 多节点调度和自动化运维：Kubernetes Yaml、Helm、KubeVela 和 Rainbond 反对 Kubernetes 的多节点调度。
• 离线迭代效率：传统形式交付效率最低；Docker 镜像有版本，而且一个命令就能够导出一个离线包，所以迭代效率高；Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela 须要手工一一打出镜像离线包，简单架构效率不高，而且手工容易出错；Rainbond 反对自动化导出一个离线包，导入离线环境，能够一键降级和回滚，迭代效率很高。
• 客户环境反对：不同客户有不同的运行环境，交付的包须要依据客户环境抉择，传统利用交付形式适宜老的一些基础设施，操作系统版本老，没方法装置运行容器；客户环境没有 Kubernetes，也不容许装置 Kubernetes，能够抉择 Docker 镜像和 DockerCompose；Kubernetes Yaml、Helm、KubeVela 和 Rainbond 反对有 Kubernetes 的环境。