关于云计算:容器实践线路图

随着容器技术越来越炽热，各种大会上标杆企业分享容器化收益，带动其余还未施行容器的企业也在思考施行容器化。不过真要在本人企业实际容器的时候，会意识到容器化不是一个简略工程，甚至会有一种茫然不知从何动手的感觉。

本文总结了通用的企业容器化施行线路图，次要针对企业有存量零碎革新为容器，或者局部新开发的零碎应用容器技术的场景。不蕴含企业零碎从 0 开始全新构建的场景，这种场景绝对简略。<!–more–>

容器实际路线图

企业着手实际容器的路线，倡议从 3 个维度评估，而后依据评估后果落地施行。3 个评估维度为：商业指标，技术选型，团队配合。

1. 商业指标是重中之重，须要答复为何要容器化，这个也是牵引团队在容器实际路上一直前行的能源，是遇到问题是解决问题的方向指引，最重要的是让决策者认同商业指标，并能理解到反对商业指标的技术原理，高低指标对齐才好办事。
2. 商业指标确定之后，须要确定容器相干的技术选型，容器是一种轻量化的虚拟化技术，与传统虚拟机比拟有长处也有毛病，要找出这些差别点辨认出对基础设施与利用的影响，提前辨认危险并采取应答措施。
3. 技术选型明确之后，在公司或部门外部推广与评审，让开发人员、架构师、测试人员、运维人员相干人员与团队了解与认同计划，听取他们意见，他们是间接应用容器的客户，不要让他们有埋怨。
4. 最初是落地策略，个别是选取一些辅助业务先试点，在实际过程中一直总结经验。

商业指标

容器技术是以利用为核心的轻量级虚拟化技术，而传统的 Xen 与 KVM 是以资源为核心的虚拟化技术，这是两者的实质差别。以利用为核心是容器技术演进的领导准则，正是在这个准则领导下，容器技术绝对于传统虚拟化有几个特点：打包既部署、镜像分层、利用资源调度。

• 打包即部署：打包即部署是指在容器镜像制作过程蕴含了传统软件包部署的过程（装置依赖的操作系统库或工具、创立用户、创立运行目录、解压、设置文件权限等等），这么做的益处是把利用及其依赖封装到了一个绝对关闭的环境，缩小了利用对外部环境的依赖，加强了利用在各种不同环境下的行为一致性，同时也缩小了利用部署工夫。
• 镜像分层：容器镜像包是分层构造，同一个主机上的镜像层是能够在多个容器之间共享的，这个机制能够极大缩小镜像更新时候拉取镜像包的工夫，通常应用程序更新降级都只是更新业务层（如 Java 程序的 jar 包），而镜像中的操作系统 Lib 层、运行时（如 Jre）层等文件不会频繁更新。因而新版本镜像本质有变动的只有很小的一部分，在更新降级时候也只会从镜像仓库拉取很小的文件，所以速度很快。
• 利用资源调度：资源（计算 / 存储 / 网络）都是以利用为核心的，核心 体现在资源分配是依照利用粒度分配资源、资源随利用迁徙。

基于上述容器技术特点，能够推导出容器技术的 3 大应用场景：CI/CD、晋升资源利用率、弹性伸缩。这 3 个应用场景天然推导出通用的商业层面收益：CI/CD 晋升研发效率、晋升资源利用率降低成本、按需弹性伸缩在体验与老本之间达成均衡。

当然，除了商业指标之外，可能还有其余一些思考因素，如基于容器技术实现计算任务调度平台、放弃团队技术先进性等。

CI/CD 晋升研发效率

为什么容器技术适宜 CI/CD

CI/CD 是 DevOps 的要害组成部分，DevOps 是一套软件工程的流程，用于继续晋升软件开发效率与软件交付品质。DevOps 流程来源于制造业的精益生产理念，在这个畛域的领头羊是丰田公司，《丰田套路》这本书总结丰田公司如何通过 PDCA(Plan-Do-Check-Act)办法施行继续改良。PDCA 通常也称为 PDCA 循环，PDCA 施行过程简要形容为：确定指标状态、剖析以后状态、找出与指标状态的差距、制订施行打算、施行并总结、开始下一个 PDCA 过程。

DevOps 根本也是这么一个 PDCA 流程循环，很容易认知到 PDCA 过程中效率是要害，同一时间段内，施行更多数量的 PDCA 过程，收益越高。在软件开发畛域的 DevOps 流程中，各种期待（期待编译、期待打包、期待部署等）、各种中断（部署失败、机器故障）是影响 DevOps 流程效率的重要因素。

容器技术进去之后，将容器技术利用到 DevOps 场景下，能够从技术手段打消 DevOps 流程中的局部期待与中断，从而大幅度晋升 DevOps 流程中 CI/CD 的效率。
容器的 OCI 规范定义了容器镜像标准，容器镜像包与传统的压缩包 (zip/tgz 等) 相比有两个要害区别点：1）分层存储；2）打包即部署。

分层存储能够极大缩小镜像更新时候拉取镜像包的工夫，通常应用程序更新降级都只是更新业务层（如 Java 程序的 jar 包），而镜像中的操作系统 Lib 层、运行时（如 Jre）层等文件不会频繁更新。因而新版本镜像本质有变动的只有很小的一部分，在更新降级时候也只会从镜像仓库拉取很小的文件，所以速度很快。

打包即部署是指在容器镜像制作过程蕴含了传统软件包部署的过程（装置依赖的操作系统库或工具、创立用户、创立运行目录、解压、设置文件权限等等），这么做的益处是把利用及其依赖封装到了一个绝对关闭的环境，缩小了利用对外部环境的依赖，加强了利用在各种不同环境下的行为一致性，同时也缩小了利用部署工夫。
基于容器镜像的这些劣势，容器镜像用到 CI/CD 场景下，能够缩小 CI/CD 过程中的等待时间，缩小因环境差别而导致的部署中断，从而晋升 CI/CD 的效率，晋升整体研发效率。

CI/CD 的要害诉求与挑战

1. 快

开发人员本地开发调试实现后，提交代码，执行构建与部署，期待部署实现后验证性能。这个期待的过程尽可能短，否则开发人员工作容易被打断，造成结果就是效率升高。如果提交代码后几秒钟就可能实现部署，那么开发人员简直不必期待，工作也不会被打断；如果须要好几分钟或十几分钟，那么能够设想，这十几分钟就是节约了，这时候很容易做点别的事件，那么思路又被打断了。
所以构建 CI/CD 环境时候，快是第一个须要思考的因素。要达到快，除了有足够的机器资源罢黜排队期待，引入并行编译技术也是罕用做法，如 Maven3 反对多核并行构建。

2. 自定义流程

不同行业存在不同的行业标准、监管要求，各个企业有一套外部品质标准，这些要求都对软件交付流程有定制需要，如要求应用商用的代码扫描工具做平安扫描，如构建后果与企业外部通信零碎对接发送音讯。
在团队协同方面，不同的公司，对 DevOps 流程在不同团队之间分工有差别，典型的有开发者负责代码编写构建出构建物（如 jar 包），而部署模板、配置由运维人员负责；有的企业开发人员负责构建并部署到测试环境；有的企业开发人员间接能够部署到生产环境。这些不同的场景，对 CI/CD 的流程、权限管控都有定制需要。

晋升资源利用率

OCI 规范蕴含容器镜像规范与容器运行时规范两局部，容器运行时规范聚焦在定义如何将镜像包从镜像仓库拉取到本地并更新、如何隔离运行时资源这些方面。得益于分层存储与打包即部署的个性，容器镜像从到镜像仓库拉取到本地运行速度十分快（通常小于 30 秒，依赖镜像自身大小等因素），基于此能够实现按需分配容器运行时资源（cpu 与内存），并限定单个容器资源用量；而后依据容器过程资源使用率设定弹性伸缩规定，实现主动的弹性伸缩。
这种形式绝对于传统的按峰值配置资源形式，能够晋升资源利用率。

按需弹性伸缩在体验与老本之间达成均衡

联动弹性伸缩

利用运行到容器，按需分配资源之后，现实状况下，Kubernetes 的池子里没有闲暇的资源。这时候扩容利用实例数，新扩容的实例会因资源有余调度失败。这时候须要资源池能主动扩容，退出新的虚拟机，调度新扩容的利用。
因为利用对资源的配比与 Flavor 有要求，因而新退出的虚拟机，该当是与利用所须要的资源配比与 Flavor 统一的。缩容也是相似。
弹性伸缩还有一个诉求点是“平滑”，对业务做到不感知，也称为“优雅”扩容 / 缩容。

申请风暴

下面提到的弹性伸缩个别是有打算或迟缓增压的场景，存在另外一种无奈预期的申请风暴场景，这种场景的特色是无奈预测、忽然申请量增大数倍或数十倍、持续时间短。典型的例子如行情交易系统，当行情渐变的时候，用户访问量徒增，继续几十分钟或一个小时。
这种场景的弹性诉求，要求短时间内能将资源池扩充数倍，要害是速度要快（秒级），否则会来不及扩容，零碎曾经被冲垮（如果有限流的话）。

目前基于 Virtual Kubelet 与云厂家的 Serverless 容器，实践上能够提供应答申请风暴的计划。不过在具体实施时候，须要思考传统托管式 Kubernetes 容器治理平台与 Serverless 容器之间互通的问题，须要基于具体厂家提供的能力来评估。

基于容器技术实现计算调度平台

计算（大数据 /AI 训练等）场景的特色是短时间内须要大量算力，算完即开释。容器的环境一致性以及调度便利性适宜这种场景。

技术选型

容器技术是属于基础设施范畴，然而与传统虚拟化技术（Xen/KVM）比拟，容器技术是利用虚拟化，不是纯正的资源虚拟化，与传统虚拟化存在差别。在容器技术选型时候，须要联合以后团队在利用治理与资源管理的现状，对照容器技术与虚拟化技术的差别，抉择最合适的容器技术栈。

什么是容器技术

(1)容器是 一种 轻量化 的利用虚拟化技术。

在探讨具体的容器技术栈的时候，先介绍目前几种罕用的利用虚拟化技术，以后有 3 种支流的利用虚拟化技术: LXC，MicroVM，UniKernel（LibOS）。

• LXC: Linux Container，通过 Linux 的 namespace/cgroups/chroot 等技术隔离过程资源，目前利用最广的 docker 就是基于 LXC 实现利用虚拟化的。
• MicroVM: MicroVM 介于 传统的 VM 与 LXC 之间，隔离性比 LXC 好，然而比传统的 VM 要轻量，轻量体现在体积小（几 M 到几十 M）、启动快（小于 1s）。AWS Firecracker 就是一种 MicroVM 的实现，用于 AWS 的 Serverless 计算畛域，Serverless 要求启动快，租户之间隔离性好。
• UniKernel: 是一种专用的（特定编程语言技术栈专用）、单地址空间、应用 library OS 构建进去的镜像。UniKernel 要解决的问题是缩小应用软件的技术栈档次，古代软件档次太多导致越来越臃肿：硬件 +HostOS+ 虚拟化模仿 +GuestOS+APP。UniKernel 指标是：硬件 +HostOS+ 虚拟化模仿 +APP-with-libos。

三种技术比照表：

根据上述比照来看，LXC 是利用虚拟化首选的技术，如果 LXC 无奈满足隔离性要，则能够思考 MicroVM 这种技术。以后社区曾经在着手交融 LXC 与 MicroVM 这两种技术，从利用打包 / 公布调度 / 运行层面对立标准，Kubernetes 集成 Kata 反对混合利用调度个性能够理解一下。

UniKernel 在利用生态方面绝对比较落后，目前在追赶中，目前通过 linuxkit 工具能够在 UniKernel 利用镜像中应用 docker 镜像。这种形式笔者还未验证过，另外 docker 镜像运行起来之后，如何监控目前还未知。

从上述三种利用虚拟化技术比照，能够得出结论:（2)容器技术与传统虚拟化技术一直交融中。

再从标准视角来看容器技术，能够将容器技术定义为: (3)容器 =OCI+CRI+ 辅助工具。

OCI 标准蕴含两局部，镜像标准与运行时标准。简要的说，要实现一个 OCI 的标准，须要可能下载镜像并解压镜像到文件系统上组成成一个文件目录构造，运行时工具可能了解这个目录构造并基于此目录构造治理（创立 / 启动 / 进行 / 删除）过程。

容器 (container) 的技术形成就是实现 OCI 标准的技术汇合。

对于不同的操作系统（Linux/Windows），OCI 标准的实现技术不同，以后 docker 的实现，反对 Windows 与 Linux 与 MacOS 操作系统。以后应用最广的是 Linux 零碎，OCI 的实现，在 Linux 上组成容器的次要技术：

• chroot: 通过分层文件系统重叠出容器过程的 rootfs，而后通过 chroot 设置容器过程的根文件系统为重叠出的 rootfs。
• cgroups: 通过 cgroups 技术隔离容器过程的 cpu/ 内存资源。
• namesapce: 通过pid, uts, mount, network, user namesapce 别离隔离容器过程的过程 ID，工夫，文件系统挂载，网络，用户资源。
• 网络虚拟化: 容器过程被搁置到独立的网络命名空间，通过 Linux 网络虚拟化 veth, macvlan, bridge 等技术连贯主机网络与容器虚构网络。
• 存储驱动: 本地文件系统，应用容器镜像分层文件重叠的各种实现驱动，以后举荐的是overlay2。

狭义的容器还蕴含容器编排，即当下很炽热的 Kubernetes。Kubernetes 为了把控容器调度的生态，公布了 CRI 标准，通过 CRI 标准解耦 Kubelet 与容器，只有实现了 CRI 接口，都能够与 Kubelet 交互，从而被 Kubernetes 调度。OCI 标准的容器实现与 CRI 标准接口对接的实现是 CRI-O。

辅助工具用户构建镜像，验证镜像签名，治理存储卷等。

容器定义

1. 容器是 一种 轻量化 的利用虚拟化技术。
2. 容器 =OCI+CRI+ 辅助工具。
3. 容器技术与传统虚拟化技术一直交融中。

什么是容器编排与调度

抉择了利用虚拟化技术之后，还须要利用调度编排，以后 Kubernetes 是容器畛域内编排的事实标准，不论应用何种利用虚拟化技术，都曾经纳入到了 Kubernetes 治理框架中。

Kubernetes 通过 CRI 接口标准，将利用编排与利用虚拟化实现解耦：不论应用何种利用虚拟化技术（LXC, MicroVM, LibOS），都可能通过 Kubernetes 对立编排。

以后应用最多的是 docker，其次是 cri-o。docker 与 crio 联合 kata-runtime 都可能反对多种利用虚拟化技术混合编排的场景，如 LXC 与 MicroVM 混合编排。

• docker(now): Moby 公司奉献的 docker 相干部件，以后支流应用的模式。

  • docker(daemon) 提供对外拜访的 API 与 CLI(docker client)
  • containerd 提供与 kubelet 对接的 CRI 接口实现
  • shim 负责将 Pod 桥接到 Host namespace。

• cri-o: 由 RedHat/Intel/SUSE/IBM/Hyper 公司奉献的实现了 CRI 接口的合乎 OCI 标准的运行时，以后包含 runc 与 kata-runtime，也就是说应用 cir-o 能够同时运行 LXC 容器与 MicroVM 容器，具体在 [Kata]() 介绍中有具体阐明。

  • CRI-O: 实现了 CRI 接口的过程，与 kubelet 交互
  • crictl: 相似 docker 的命令行工具
  • conmon: Pod 监控过程
• other cri runtimes: 其余的一些 cri 实现，目前没有大规模利用到生产环境。

容器与传统虚拟化差别

容器 (container) 的技术形成

后面次要讲到的是容器与编排，包含 CRI 接口的各种实现，咱们把容器畛域的标准演绎为南向与北向两局部，CRI 属于北向接口标准，对接编排零碎，OCI 就属于南向接口标准，实现利用虚拟化。

简略来讲，能够这么定义容器：

容器(container) ~= 利用打包(build) + 利用散发(ship) + 利用运行 / 资源隔离(run)。

build-ship-run 的内容都被定义到了 OCI 标准中，因而也能够这么定义容器：

容器(container) == OCI 标准

OCI 标准蕴含两局部，镜像标准与运行时标准。简要的说，要实现一个 OCI 的标准，须要可能下载镜像并解压镜像到文件系统上组成成一个文件目录构造，运行时工具可能了解这个目录构造并基于此目录构造治理（创立 / 启动 / 进行 / 删除）过程。

容器 (container) 的技术形成就是实现 OCI 标准的技术汇合。

对于不同的操作系统（Linux/Windows），OCI 标准的实现技术不同，以后 docker 的实现，反对 Windows 与 Linux 与 MacOS 操作系统。以后应用最广的是 Linux 零碎，OCI 的实现，在 Linux 上组成容器的次要技术：

• chroot: 通过分层文件系统重叠出容器过程的 rootfs，而后通过 chroot 设置容器过程的根文件系统为重叠出的 rootfs。
• cgroups: 通过 cgroups 技术隔离容器过程的 cpu/ 内存资源。
• namesapce: 通过pid, uts, mount, network, user namesapce 别离隔离容器过程的过程 ID，工夫，文件系统挂载，网络，用户资源。
• 网络虚拟化: 容器过程被搁置到独立的网络命名空间，通过 Linux 网络虚拟化 veth, macvlan, bridge 等技术连贯主机网络与容器虚构网络。
• 存储驱动: 本地文件系统，应用容器镜像分层文件重叠的各种实现驱动，以后举荐的是overlay2。

狭义的容器还蕴含容器编排，即当下很炽热的 Kubernetes。Kubernetes 为了把控容器调度的生态，公布了 CRI 标准，通过 CRI 标准解耦 Kubelet 与容器，只有实现了 CRI 接口，都能够与 Kubelet 交互，从而被 Kubernetes 调度。OCI 标准的容器实现与 CRI 标准接口对接的实现是 CRI-O。

容器与虚拟机差别比照

容器与虚拟机的差别能够总结为 2 点：利用打包与散发的差别 ， 利用资源隔离的差别 。当然，导致这两点差别的根基是容器是以利用为核心来设计的，而虚拟化是以资源为核心来设计的，本文比照容器与虚拟机的差别，更多的是站在利用视角来比照。
从 3 个方面比照差别：资源隔离，利用打包与散发，延长的日志 / 监控 /DFX 差别。

1. 资源隔离

1. 隔离机制差别

2. 差别引入问题与实际倡议

• 应用程序未适配 cgroup 的内存隔离导致问题: 典型的是 JVM 虚拟机，在 JVM 启动时候会依据零碎内存主动设置 MaxHeapSize 值，通常是零碎内存的 1 /4，然而 JVM 并未思考 cgroup 场景，读零碎内存时候任然读取主机的内存来设置 MaxHeapSize，这样会导致内存超过 cgroup 限度从而导致过程被 kill。问题具体论述与解决倡议参考 Java inside docker: What you must know to not FAIL。
• 屡次网络虚拟化问题: 如果在虚拟机内应用容器，会多一层网络虚拟化，并退出了 SNAT/DNAT 技术, iptables/ipvs 技术，对网络吞吐量与时延都有影响（具体依赖容器网络计划），对问题定位复杂度变高，同时还须要留神网络内核参数调优。

典型的网络调优参数有：转发表大小 ```/proc/sys/net/netfilter/nf_conntrack_max``` 

应用 iptables 作为 service 转发实现的时候，在转发规定较多的时候，iptables 更新因为须要全量更新导致十分耗时，倡议应用 ipvs。具体参考[华为云在 K8S 大规模场景下的 Service 性能优化实际](https://zhuanlan.zhihu.com/p/37230013)。

• 容器 IP 地址频繁变动不固定，周边零碎须要协调适配，包含基于 IP 地址的白名单或防火墙控制策略须要调整，CMDB 记录的利用 IP 地址须要适配动静 IP 或者应用服务名代替 IP 地址。
• 存储驱动带来的性能损耗: 容器本地文件系统是通过联结文件系统形式重叠进去的，以后主推与默认提供的是 overlay2 驱动，这种模式利用写本地文件系统文件或批改已有文件，应用 Copy-On-Write 形式，也就是会先拷贝源文件到可写层而后批改，如果这种操作十分频繁，倡议应用 volume 形式。

2. 利用打包与散发

1. 利用打包 / 散发 / 调度差别

2. 差别引入问题与实际倡议

• 部署提前到构建阶段，利用须要反对动静配置与动态程序拆散；如果在传统部署脚本中依赖内部动静配置，这部分须要做一些调整。
• 打包格局发生变化，制作容器镜像须要注意安全 / 效率因素，可参考 Dockerfile 最佳实际
• 容器镜像存储与散发是按 layer 来组织的，镜像在传输过程中放篡改的形式是传统软件包有差别。

3. 监控 / 日志 /DFX

1. 差别

2. 差别引入问题实际与倡议

• 应用成熟的监控工具，运行在 docker 中的利用应用 cadvisor+prometheus 实现采集与警报，cadvisor 中预置了罕用的监控指标项
• 对于 docker 治理过程（containerd/shim/docker-daemon）也须要一并监控
• 应用成熟的日志采集工具，如果已有日志采集 Agent，则能够思考将日志文件挂载到 volume 后由 Agent 采集；须要留神的是 stderr/stdout 输入也要一并采集
• 如果心愿容器内利用过程退出后保留现场定位问题，则能够将 Pod 的restartPolicy设置为never，过程退出后过程文件都还保留着(/var/lib/docker/containers)。然而这么做的话须要过程没有及时复原，会影响业务，须要本人实现过程重拉起。

团队配合

与周边的开发团队、架构团队、测试团队、运维团队评审并交换计划，与周边团队达成统一。

落地策略与注意事项

逐渐演进过程中网络互通

依据以后曾经存在的根底施行状况，抉择容器化落地策略。通常应用逐渐演进的形式，因为容器化引入了独立的网络 namespace 导致容器与传统虚拟机过程网络隔离，逐渐演进过程中如何买通隔离的网络是最大的挑战。

分两种场景探讨：

• 不同服务集群之间应用 VIP 模式互通: 这种模式绝对简略，基于 VIP 做灰度公布。

• 不同服务集群之间应用微服务点对点模式互通(SpringCloud/ServiceComb/Dubbo 都是这一类): 这种模式绝对简单，在逐渐容器化过程中，要求容器网络与传统虚拟机网络可能互通（难点是在虚拟机过程内可能间接拜访到容器网络的 IP 地址），以后解决这个问题有几种办法。

  • 自建 Kubernetes 场景，可应用开源的 kube-router，kube-router 应用 BGP 协定实现容器网络与传统虚拟机网络之间互通，要求网络交换机反对 BGP 协定。
  • 应用云厂商托管 Kubernetes 场景，抉择云厂商提供的 VPC-Router 互通的网络插件，如阿里云的 Terway 网络插件, 华为云的 Underlay 网络模式。

抉择物理机还是虚拟机

抉择物理机运行容器还是虚拟机运行容器，须要联合基础设施与业务隔离性要求综合思考。分两种场景：自建 IDC、租用私有云。

• 自建 IDC: 现实状况是应用物理机组成一个大集群，依据业务诉求，对资源保障与安全性要求高的利用，应用 MicorVM 形式隔离；一般利用应用 LXC 形式隔离。所有物理机在一个大集群内，不便削峰填谷晋升资源利用率。
• 租用私有云：以后私有云厂家提供的裸金属服务价格较贵且只能包周期，应用裸金属性价比并不高，应用虚拟机更适合。

集群规模与划分

抉择集群时候，是多个利用共用一个大集群，还是按利用分组分成多个小集群呢？咱们把节点规模数量 >=1000 的定义为大集群，节点数 <1000 的定义为小集群。

• 大集群的长处是资源池共享容器，不便资源调度（削峰填谷）；毛病是随着节点数量与负载数量的增多，会引入治理性能问题（须要量化）:

  • DNS 解析表变大，减少 / 删除 Service 或 减少 / 删除 Endpoint 导致 DNS 表刷新慢
  • K8S Service 转发表变大，导致工作负载减少 / 删除刷新 iptables/ipvs 记录变慢
  • etcd 存储空间变大，如果加上 ConfigMap，可能导致 etcd 拜访时延减少

• 小集群的长处是不会有治理性能问题，毛病是会导致资源碎片化，不容易共享。共享分两种状况:

  • 利用之间削峰填谷：目前无奈实现
  • 计算工作与利用之间削峰填谷：因为计算工作是短时工作，能够通过下层的任务调度软件，在多个集群之间散发计算工作，从而达到集群之间资源共享的目标。

抉择集群规模的时候，能够参考上述剖析，结合实际状况抉择适宜的集群划分。

Helm?

Helm 是为了解决 K8S 治理对象散碎的问题，在 K8S 中并没有 ” 利用 ” 的概念，只有一个个散的对象(Deployment, ConfigMap, Service, etc)，而一个 ” 利用 ” 是多个对象组合起来的，且这些对象之间还可能存在肯定的版本配套关系。
Helm 通过将 K8S 多个对象打包为一个包并标注版本号造成一个 ” 利用 ”，通过 Helm 治理过程部署 / 降级这个 ” 利用 ”。这种形式解决了一些问题（利用散发更不便）同时也引入了一些问题（引入 Helm 减少利用公布 / 治理复杂度、在 K8S 批改了对象后如何同步到 Helm）。对于是否须要应用 Helm，倡议如下：

• 在自运维模式下不应用 Helm: 自运维模式下，很多场景是开发团队交付一个运行包，运维团队负责部署与配置下发，外部通过兼容性或软件包与配置版本配套清单、治理软件包与配置的配套关系。
• 在交付软件包模式下应用 Helm: 交付软件包模式下，Helm 这种把散碎组件组装为一个利用的模式比拟适宜，应用 Helm 实现软件包散发 / 部署 / 降级场比较简单。

Reference

DOCKER vs LXC vs VIRTUAL MACHINES

Cgroup 与 LXC 简介

Introducing Container Runtime Interface (CRI) in Kubernetes

frakti

rkt

appc-spec

OCI 和 runc：容器标准化和 docker

Linux 容器技术史话：从 chroot 到将来

Linux Namespace 和 Cgroup

Java inside docker: What you must know to not FAIL

QEMU,KVM 及 QEMU-KVM 介绍

kvm libvirt qemu 实际系列(一)-kvm 介绍

[KVM 介绍（4）：I/O 设施间接调配和 SR-IOV [KVM PCI/PCIe Pass-Through SR-IOV]](https://www.cnblogs.com/sammy…

prometheus-book

到底什么是 Unikernel？

The Rise and Fall of the Operating System

The Design and Implementation of the Anykernel and Rump Kernels

UniKernel

Unikernel：从不入门到入门

OSv

京东如何打造 K8s 寰球最大集群撑持万亿电商交易

Cloud Native App Hub

更多云最佳实际 https://best.practices.cloud