PouchContainer技术分享体会

简介

昨天参加了一趟PouchContainer GA 的分享，刷新了很多思维观念，趁热打铁记录一下。

PouchContainer 的亮点

1. 更充分的隔离性，docker容器因为共享内核的缘故，类似 /proc 及其依赖的相关的组件无法 正常使用
2. 守护进程，一则为了一些依赖系统服务的组件可以正常使用；再则，使得容器 更像一点虚拟机

3. 容器与虚拟机混合部署。

   1. 以前认为的混合部署是 vm 搞vm、container 搞container，彼此互通就行了，且实施方式是由vm 环境 兼容容器。 2. PouchContainer 先支持container 后支持runv， 是从容器环境 兼容vm。PouchContainer 兼容vm 的一个重大区别是 都支持镜像发布，这样的混合发布才更有意义。

关于 docker 的使用

第一个新知道：远程镜像，镜像分发的一个重要问题是大镜像分发比较耗时，解决起来有几个办法

docker run

再一个很好奇的事情，mysql、es、hadoop 都docker 化，为什么要将这些服务docker化？

1. 分享者多来自云计算或 系统部门，支持很多的业务线，有一键交付一个hadoop 集群的需求
2. 业务集群和数据集群混合调度，提高资源利用率（这是个长远目标，都还在实践中）
3. mysql 服务可以拆分为三个部分：对外接口；计算服务；存储。三个部分独立后，计算服务可以自由升级，对外接口可以保持不变，存储部分使用CSI。没有体验过msyql 宕机（集群太小） 或者复杂的业务（需要各种版本的mysql）的我，对这个需求挺难理解的。
4. hadoop/es 等很多大公司都有自己的维护小组，小公司hadoop 集群一般不怎么变，自然无法理解 一个月一个小迭代升级的运维需求。

关于层次的划分（这一部分还有待学习的深入）：调度层 ==> grpc ==> runtime 管理层(dockerd/pouchd，预备存储、网络等) ==> runtime 层(oci，负责镜像push/pull、容器启动及 运行时数据管理)

P2P下载镜像，一个文件假设100m，按4m一块切分，客户端按块下载。局域网多个主机不一定都需要从第0块开始下载，假设4台主机在一个局域网内，分别下载25块，然后局域网内互传就行，比大家彼此都从第0块下载到100 要快很多。

paas/cloud native

在与一位大牛的讨论中，笔者听到，k8s 集群管理的服务 基本不访问本地磁盘，此时的存储不再是物理机的存储，而是一个“超级计算机”的存储。程序（对应镜像 + yml）、进程、存储、网络在“超级计算机” 的范畴里都变了形态。

PaaS/cloud native 之后，我们向用户交付的，不再是一个个物理机，而是直接的运行一个服务的能力，就好像物理机提供进程的运行能力一样。服务运行时包含：对外接口；计算；存储，三者独立变化和升级、调度、移动，互不干扰。 物理机 从小型机 到大型机， 单机的能力达到瓶颈之后，人们开始采用集群方式来提高能力，最终将集群又抽象为了一个超级计算机。

以前只有一个模糊的感觉，通过这次分享，笔者感受到在内部实践上，一直面临着传统运维和paas/cloud native 的博弈

1. 笔者的公司基本就两种服务，web服务（前面接nginx）和微服务（前面接服务注册中心）。服务发现、负载均衡等事情有微服务框架去做。所以笔者在16年调研调度框架时，觉得k8s的pod、service 等概念基本用不上，进而选择了marathon + mesos。很多概念很超前，cloud native 还没推动，service mesh 就来了， 但公司层面的实践演变却很慢（与公司的发展阶段相适应就好）。
2. 人员的接受成本，运维、开发还是物理机时代，光一个项目重新部署后服务ip 会改变就引起了很多同事的不理解。不适应他们就推不动，适应了他们就不符合新理念，很多问题也不只是技术问题。

需求驱动

为什么要用docker？ 笔者曾依次想了几个理由

1. 项目发布，因为公司全是 java 项目，因此已有的发布系统基本够用，docker 的优势体现不出来
2. 自动扩容缩容，这类业务（比如音视频编解码）可以直接使用云服务。
3. 提高资源利用率，快速发展的公司，资源按峰值压力分配就可以了，业务发展会很快跟上来。

docker 为什么要这么用？这么改？

1. 比如因为我司都是java项目，没考虑过一些项目依赖基础组件，自然对富容器的好处只有模糊而没有深刻的体会。

因此，一切还是跟需求有关系，有时候推动实践，不如推动需求。