【笔记】不一样的 双11 技术，阿里巴巴经济体云原生实践
释放云原生价值才是拥抱 Kubernetes 的正确姿势
在 Kubernetes 中对于故障机的处理要"简单和粗暴"得多，不再要求对应用先扩容，而是直接把故障机上的容器进行删除，删除后才由负载控制器进行扩容。这种方案乍一听简直胆大妄为，落地 Kubernetes 的时候很多 PaaS 的同学都非常排斥这种方法，认为这会严重影响业务的稳定性。事实上呢，绝大多数核心的业务应用都维护着一定的冗余容量，以便全局的流量切换或者应对突发的业务流量，临时删除一定量的容器根本不会造成业务的容量不足。
我们所面临的关键问题是如何确定业务的可用容量，当然这是个更难的问题，但对于自愈的场景完全不需要准确的容量评估，只需要一个可以推动自愈运转的悲观估计就可以。在 Kubernetes 中可以通过 PodDisruptionBudget 来定量地描述对应用的可迁移量，例如可以设置对应用进行驱逐的并发数量或者比例。这个值可以参考发布时的每批数量占比来设置。假如应用发布一般分 10 批，那么可以设置PodDisruptionBudget 中的 maxUnavailable 为 10%（对于比例，如果应用只有 10 个以内的实例，Kubernetes 还是认为可以驱逐 1 个实例）。万一应用真的一个实例都不允许驱逐呢，那么对不起，这样的应用是需要改造之后才能享受上云的收益的。一般应用可以通过改造自身架构，或者通过 operator 来自动化应用的运维操作，从而允许实例的迁移。
不过，阿里巴巴传统的容器形态是富容器，即应用程序服务器，以及日志采集进程这些相关的组件都部署在一个大的系统容器中，这造成了日志采集等组件的资源消耗无法单独限制，也无法方便地进行独立的升级。因此，在阿里巴巴这次上云中， 开始把系统容器中除业务应用外的其他组件都拆分到独立的 sidecar 容器，我们称之为轻量化容器改造。改造后，一个 pod 内会包括一个运行业务的主容器的，一个运行着各种基础设施 agent 的运维容器，以及服务网格等的 sidecar。轻量化容器之后， 业务的主容器就能以比较低的开销运行业务服务，从而为更方便进行 serverless 的相关改造。
因此，相比 pod 层次的不可变，我们认为坚持容器级别的不可变原则，更能发挥 Kubernetes 多容器 pod 的技术优势。为此，我们建设了支持应用发布时，只原地修改 pod 中部分容器的能力，特别的，建设了支持容器原地升级的工作负载控制器，并替换 Kubernetes 默认的 deployment 和 statefulset 控制器作为内部的主要工作负载。另外，还建设了支持跨应用进行 sidecar 容器升级的 sidecarset， 方便进行基础设施以及中间件组件的升级。此外，通过支持原地升级还带来了集群分布确定性、加速镜像下载等的额外优势。这部分能力，我们已经通过 OpenKruise 项目开源出来。OpenKruise 中的 Kruise 是 cruise的谐音，‘K’ for Kubernetes, 寓意 Kubernetes 上应用的自动巡航，满载着满载阿里巴巴多年应用部署管理经验和阿里经济体云原生化历程的最佳实践. 目前，OpenKruise 正在计划发布更多的 Controller 来覆盖更多的场景和功能比如丰富的发布策略，金丝雀发布，蓝绿发布，分批发布等等。
阿里云上万个 Kubernetes 集群大规模管理实践
一般讲到单元化，大家都会联想到单机房容量不够或二地三中心灾备等场景。那单元化和 Kubernetes 管理有什么关系？对我们来说，一个地域（比如：杭州）可能会管理几千个 Kubernetes，需要统一维护这些 Kubernetes 的集群生命周期管理。作为一个 Kubernetes 专业团队，一个朴素的想法就是通过多个 Kubernetes 元集群来管理这些guest K8s master。而一个 Kubernetes 元集群的边界就是一个单元
曾经我们经常听说某某机房光纤被挖断，某某机房电力因故障而导致服务中断，容器服务 ACK 在设计之初就支持了同城多活的架构形态，任何一个用户 Kubernetes 集群的 master 组件都会自动地分散在多个机房，不会因单机房问题而影响集群稳定性；另外一个层面，同时要保证 master 组件间的通信稳定性，容器服务 ACK 在打散 master 时调度策略上也会尽量保证 master 组件间通信延迟在毫秒级。
大家都知道，Kubernetes 集群的 master 组件的负载主要与 Kubernetes 集群的节点规模、worker 侧的 controller 或 workload 等需要与 kube-apiserver 交互的组件数量和调用频率息息相关，对于上万个 Kubernetes 集群，每个用户 Kubernetes 集群的规模和业务形态都千差万别，我
们无法用一套标准配置来去管理所有的用户 Kubernetes 集群。同时，从成本经济角度考虑，我们提供了一种更加灵活、更加智能的托管能力。考虑到不同资源类型会对 master 产生不同的负载压力，因此我们需要为每类资源设置不同的因子，最终可归纳出一个计算范式，通过此范式可计算出每个用户 Kubernetes 集群 master 所适应的档位。另外，我们也会基于已构建的 Kubernetes 统一监控平台实时指标来不断地优化和调整这些因素值和范式，从而可实现智能平滑换挡的能力。
元集群托管用户 Kubernetes 集群的 master
针对每个集群，需要采集的主要指标类别包括
OS 指标，例如节点资源（CPU, 内存，磁盘等）水位以及网络吞吐；
元集群以及用户集群 Kubernetes master 指标，例如 kube-apiserver, kube-controller-manager, kube-scheduler 等指标；
Kubernetes 组件（kubernetes-state-metrics，cadvisor）采集的关于 Kubernetes 集群状态；
etcd 指标，例如 etcd 写磁盘时间，DB size，Peer 之间吞吐量等等。
为了合理的将监控压力负担分到多个层次的 Prometheus 并实现全局聚合，我们使用了联邦 Federation 的功能。在联邦集群中，每个数据中心部署单独的 Prometheus，用于采集当前数据中心监控数据，并由一个中心的 Prometheus 负责聚合多个数据中心的监控数据。基于 Federation 的功能，我们设计的全球监控架构图如下，包括监控体系、告警体系和展示体系三部分。
常用的透传 Kubernetes 集群内 Prometheus 指标到集群外的方式是通过 API server 代理功能，优点是可以重用 API server 的 6443 端口对外开放数据，管理简便；缺点也明显，增加了 API server 的负载压力。如果使用 API Server 代理模式，考虑到客户集群以及节点都会随着售卖而不断
扩大，对 API server 的压力也越来越大并增加了潜在的风险。对此，针对边缘 Prometheus 增加了 LoadBalancer 类型的 service，监控流量完全 LoadBalancer，实现流量分离。即便监控的对象持续增加，也保证了 API server 不会因此增加 Proxy 功能的开销。
在中心 Prometheus 只收集需要使用的指标，一定不能全量抓取，否则会造成网络传输压力过大丢失数据。
Label 用于在级联 Prometheus 上标记 region 和元集群，所以在中心 Prometheus 汇聚是可以定位到元集群的颗粒度。同时，尽量减少不必要的 label，实现数据节省。
2019 年 6 月，阿里巴巴将内部的云原生应用自动化引擎 OpenKruise 开源，这里我们重点介绍下其中的 BroadcastJob 功能，他非常适用于每台 worker 机器上的组件进行升级，或者对每台机器上的节点进行检测。（Broadcast Job 会在集群中每个 node 上面跑一个 pod 直至结束。类似于社区的 DaemonSet, 区别在于 DaemonSet 始终保持一个 pod 长服务在每个 node 上跑，而 BroadcastJob 中最终这个 pod 会结束。）
深入 Kubernetes 的“无人区” ：蚂蚁金服双11 的调度系统
蚂蚁金服在落地 Kubernetes 实现统一调度目标时遵循了标准化的扩展方式：
一切业务扩展均围绕 Kubernetes APIServer，通过 CRD + Operator 方式完成业务功能的适配和扩展；
基础服务通过 Node 层定义的资源接口完成个性化适配，有益于形成资源接入的最佳实践。
在大促过程中，不同业务域的洪峰流量通常都是在不同时间段来临，而应对这些不同时间到来的业务流量往往都需要大量的额外计算资源做保障。在以往的几次活动中，我们尝试了通过应用快速腾挪的方式来做到资源上的分时复用，但是服务实例上下线需要预热，腾挪耗时不可控，大规模调度的稳定性等因素都影响了最终腾挪方案的实践效果。
今年 双11 我们采用了资源共享调度加精细化切流的技术以达到资源分时利用的目标，为了达到资源充分利用和极速切换的目标，我们在以下方面做了增强：
在内部的调度系统引入了联合资源管理（Union-Resource Management），他可以将波峰波谷不重叠的业务实例摆放在相同的资源集合内，达到最大化的资源利用。
研发了一套融合资源更新，流量切换及风险控制的应用分时复用平台，通过该平台 SRE 可以快速稳定的完成资源切换以应对不同的业务洪峰。
在蚂蚁金服内部我们持续的使用 Kubernetes 支持各类计算业务，例如各类AI 训练任务框架，批处理任务和流式计算等。他们都有一个共同的特点：资源按需申请，即用即走。
我们通过 Operator 模型适配计算型任务，让任务在真正执行时才会调用 Kubernetes API 申请 Pod 等资源，并在任务退出时删除 Pod 释放资源。同时我们在调度引擎中引入了动态资源调度能力和任务画像系统，这为在线和计算的不同等级业务提供了分级资源保障能力，使在线业务不受影响的情况下资源被最大化的利用。
蚂蚁金服是目前少数运行了全球最大规模的 Kubernetes 集群的公司之一，单集群机器规模过万，Pods 数量数十万。随着类似计算型任务混部和资源分时复用这类业务的落地，资源的动态使用以及业务自动化运维都对 Kubernetes 的稳定性和性能带来了巨大的挑战。
首先需要面对的挑战是调度性能，社区的调度器在 5k 规模测试中调度性能只有 1~2 pods/s，这显然无法满足蚂蚁金服的调度性能需求。
针对同类业务的资源需求往往相同的特点，我们自研了批量调度功能，再加上例如局部的 filters 性能优化等工作，最终达到了百倍的调度性能提升！
面对这种“核按钮”不在集群管理员手上的情况，蚂蚁内部通过两方面入手解决规模化带来的问题：
我们通过持续总结迭代过程中的经验，形成了内部的最佳实践原则，以帮助业务更好的设计 Operator
CRD 在定义时需要明确未来的最大数量，大量 CR 业务最好采用 aggregate-apiserver 进行扩展；
CRD 必须 Namespaced scope，以控制影响范围；
MutatingWebhook + 资源 Update 操作会给运行时环境带来不可控破坏，尽量避免使用这种组合；
任何 controllers 都应该使用 informers，并且对写操作配置合理限流；
DaemonSet 非常高阶，尽量不要采用这类设计，如果必需请在 Kubernetes 专家的辅导下使用
我们已经在 Kubernetes 实施了一系列的优化，包含多维度流量控制，WatchCache 处理全量 List 请求，controller 自动化解决更新冲突，以及 APIServer 加入自定义索引等。
当前我们面对的一大挑战是多租户带来的不确定性。蚂蚁金服内部不可能为每个业务部门都维护一套 Kubernetes 集群，而单个 Kubernetes 集群的多租户能力十分薄弱，这体现在以下两个维度：
APIServer 和 etcd 缺少租户级别的服务保障能力；
Namespace 并不能有效的隔离全部资源，并且由于Namespace 只提供了部分资源能力，对平台型的接入方也很不友好。
为此我们接下来一起推动 Operator 的标准化工作。从接入标准，Operator 框架，灰度能力建设和控制治理上入手，让 Kubernetes 上的自动化运维变的更加可视可控。
云原生应用万节点分钟级分发协同实践
随着云原生技术的迅速普及，Kubernetes 已经成为事实上应用容器化平台的标准，成为了云原生领域的“一等公民”。Kubernetes 以一种声明式的容器编排与管理体系，让软件交付变得越来越标准化。Kubernetes 提供了统一模式的 API，能以 YAML 格式的文件定义 Kubernetes 集群内的资源。这一些 YAML 格式的资源定义使得 Kubernetes 能轻松被上下游系统所集成，完成一系列原本需要用非标准化脚本、人工来完成的操作。同时社区根据应用交付场景及需求，在原生 YAML 格式的资源定义文件之外衍生出了更多系列的云原生应用交付标准，例如 Helm Chart、Opeartor、Open Application Model 等。
通过控制容器镜像大小、采用 P2P 分发镜像层、优化 Registry 服务端等方式，我们极大优化了大规模分发的性能，最终达成了万节点分钟级分发的目标：
阿里巴巴大规模神龙裸金属 K8s 集群运维实践
在阿里 双11 大规模迁移到神龙架构前，通过在 618/99 大促的验证，我们发现集团电商的容器运行在云上神龙反而比非云物理机的性能要好 10%～15%，这令我们非常诧异。经过分析，我们发现主要的原因是因为虚拟化开销已经 offload 到 MOC 卡上，神龙的 CPU/Mem 是无虚拟化开销的，而上云后运行在神龙上的每个容器都独享 ENI 弹性网卡，性能优势明显。同时每个容器独享一块 ESSD 块存储云盘，单盘 IOPS 高达 100 万，比 SSD 云盘快 50 倍，性能超过了非云的 SATA 和 SSD 本地盘。这也让我们坚定了大规模采用神龙来支撑 双11 的决心。
ASI Pod 运行在神龙裸金属节点上，将网络虚拟化和存储虚拟化 offload 到独立硬件节点 MOC 卡上，并采用 FPGA 芯片加速技术，存储与网络性能均超过普通物理机和 ECS；MOC 有独立的操作系统与内核，可为 AVS（网络处理）与 TDC（存储处理）分批独立的 CPU 核；
双11 需要海量的计算资源来扛住洪峰流量，但这部分资源不可能常态化持有，所以需要合理划分日常集群与大促集群，并在 双11 前几周，通过大规模节点弹性扩容能力，从阿里云弹性申请大批量神龙，部署在独立的大促集群分组里，并大规模扩容 Kubernetes Pod 交付业务计算资源。在 双11 过后，立即将大促集群中的 Pod 容器批量缩容下线，大促集群神龙实例整体销毁下线，日常只持有常态化神龙实例，通过大规模集群弹性扩缩容能力，可大幅节约大促成本。另外从神龙交付周期而言、今年上云后从申请到创建机器，从小时/天级别缩短到了分钟级，上千台神龙可在 5 分钟内完成申请，包括计算、网络、存储资源，并在 10 分钟完成创建并导入 Kubernetes 集群，集群创建效率大幅度提高，为未来常态化弹性资源池奠定基础。
对于大规模神龙集群运维，有三个非常核心的指标可以来衡量集群整体健康度，分别是宕机率、可调度率、在线率。云上神龙宕机原因通常分为硬件问题和内核问题。通过对日宕机率趋势统计和宕机根因分析，可量化集群的稳定性，避免出现潜在的大规模宕机风险出现。可调度率是衡量集群健康度的关键指标，集群机器会因为各种软硬件原因出现容器无法调度到这些异常机器上，例如 Load 大于 1000、磁盘出现压力、docker 进程不存在，kubelet 进程不存在等，在 Kubernetes 集群中，这批机器的状态会是 notReady。2019 年 双11，我们通过神龙宕机重启与冷迁移特性，极大提升了故障机轮转效率，使神龙集群的可调度率始终维持在 98% 以上，大促资源备容从容。而 双11 神龙的宕机率维持在 0.2‰ 以下，表现相当稳定。
随着集群规模的增加，管理难度也随之变大。例如如何能筛选出“cn-shanghai”Region 下生产环境，且实例规格为“ecs.ebmc6-inc.26xlarge”的所有机器。我们通过定义大量的预置标签来实现批量资源管理。在 Kubernetes 架构下，通过 定义Label 来管理机器。Label 是一个 Key-Value 健值对，可在神龙节点上使用标准Kubernetes的接口打Label。例如机器实例规格的label可定义"sigma.ali/machine-model":“ecs.ebmc6-inc.26xlarge”, 机器所在的 Region 可定义为"sigma.ali/ecs-region-id":“cn-shanghai”。通过完善的标签管理系统，可从几万台神龙节点中快速筛
选机器，执行诸如灰度分批次服务发布、批量重启、批量释放等常规运维操作。
对于超大规模集群，日常宕机是非常普遍的事情，对宕机的统计与分析非常关键，可以甄别出是否存在系统性风险。宕机的情况分为很多种，硬件故障会导致宕机，内核的 bug 等也会导致宕机，一旦宕机以后，业务就会中断，有些有状态应用就会受到影响。我们通过 ssh 与端口 ping 巡检对资源池的宕机情况进行了监控，统计宕机历史趋势，一旦有突增的宕机情况就会报警；同时对宕机的机器进行关联分析，如根据机房、环境、单元、分组 进行归类，看是否跟某个特定的机房有关；对机型、CPU 进行分
类统计，看是否跟特定的硬件有关系；同时 OS 版本，内核版本进行归类，看是否都发生在某些特定的内核上。对宕机的根因，也进行了综合的分析，看是硬件故障，还是有主动运维事件。内核的 kdump 机制会在发生 crash 的时候生成 vmcore，我们也对 vmcore 里面提取的信息进行归类，看某一类特定的 vmcore 关联的宕机数有多少。内核日志有些出错的信息，如 mce 日志，soft lockup 的出错信息等，也能发现系统在宕机前后的是否有异常。通过这一系列的宕机分析工作，把相应的问题提交给内核团队，内核专家就会分析 vmcore，属于内核的缺陷的会给出 hotfix 解决这些导致宕机的问题。
运维大规模神龙集群不可避免遇到软硬件故障，而在云上技术栈更厚，出现问题会更为复杂。如果出问题单纯依靠人工来处理是不现实的，必须依赖自动化能力来解决。1-5-10 节点自愈可提供 1 分钟异常问题发现，5 分钟定位，10 分钟修复的能力。主要的神龙机器异常包括宕机、夯机、主机 load 高、磁盘空间满、too many openfiles、核心服务（Kubelet、Pouch、Star-Agent）不可用等。主要的修复动作包括宕机重启、业务容器驱逐、异常软件重启、磁盘自动清理，其中 80% 以上问题可通过重启宕机机器与将业务容器驱逐到其他节点完成节点自愈。另外我们通过监听神龙 Reboot 重启与 Redepoly 实例迁移二个系统事件来实现 NC 侧系统或硬件故障的自动化修复。
PouchContainer 容器技术演进助力阿里云原生升级
无论是 LXC 还是 runc 都是让所有容器共享 Linux 内核，利用 cgroup 和 namespace 来做隔离，对于强安全场景和强隔离场景是不适用的。为了容器这种开发和运维友好的交付形式能给更多场景带来收益，我们很早就开始探索这方面的技术，和集团 os 创新团队以及蚂蚁 os 虚拟化团队合作共建了 kata 安全容器和 gvisor 安全容器技术，在容器生态嫁接，磁盘网络系统调用性能优化等方面都做了很多的优化。在兼容性要求高的场景我们优先推广kata 安全容器，已经支持了 SAE 和 ACK 安全容器场景。在语言和运维习惯确定的场景我们也在 618 大促时上线了一些合适的电商使用了 gvisor 的运行时隔离技术，稳定性和性能都得到了验证。
镜像化以后必然会引入困难就是镜像分发的效率，一个是速度另一个是稳定性，让发布扩容流程不增加太多时间的情况下，还要保证中心节点不被压垮。
PouchContainer 在一开始就支持了使用 Dragonfly 来做 P2P 的镜像分发，就是为了应对这种问题，这是我们的第一代镜像分发方案。在研发域我们也对镜像分层的最佳实践做了推广，这样能最大程度的保证基础环境不变时每次下载的镜像层最小。镜像加速要解决的问题有：build 效率/push 效率/pull 效率/解压效率/组装效率。第一代镜像加速方案，结合 Dockerfile 的最佳设计解决了 build 效率和 pull 效率和中心压力。
第一代镜像分发的缺点是无论用户启动过程中用了多少镜像数据，在启动容器之前就需要把所有的镜像文件都拉到本地，在很多场景都是又浪费的，特别影响的是扩容场景，所以第二代的镜像加速方案，我们调研了阿里云的盘古，盘古的打快照、mount、再打快照完美匹配打镜像和分发的流程。能做到秒级镜像 pull，因为 pull 镜像时只需要鉴权，下载镜像 manifest，然后 mount 盘古。也能做到镜像内容按需读取。2018 年 双11，我们小规模上线了盘古远程镜像，也验证了我们的设计思路，这一代的镜像加速方案结合新的 overlay2 技术在第一代的基础上有解决了PouchContainer 效率/pull 效率/解压效率和组装效率。
但是也存在一些问题，首先镜像数据没有存储在中心镜像仓库中，只有 manifest 信息，这样镜像的分发范围就受限，在哪个盘古集群做的镜像，就必须在那个盘古集群所在的阿里云集群中使用这个镜像，其次没有 P2P 的能力，在大规模使用时对盘古后端的压力会很大，特别是离线场景下由于内存压力导致很多进程的可执行文件的 page cache 被清理然后需要重新 load 这种场景，会给盘古后端带来更大的压力。基于这两个原因，我们和 ContainerFS 团队合作共建了第三代镜像分发方案：DADI（基于块设备的按需p2p加载技术，后面有计划开源）。
daidi在构建阶段保留了镜像的多层结构，保证了镜像在多次构建过程中的可重用性，并索引了每个文件的在每层的offset 和 length，推送阶段还是把镜像推送到中心镜像仓库中，保证在每个机房都能拉取到这个镜像。在每个机房都设置了超级节点做缓存，每一块内容在特定的时间段内都只从镜像仓库下载一次。如果有时间做镜像预热，像双十一这种场景，预热阶段就是从中心仓库中把镜像预热到本地机房的超级节点，后面的同机房的数据传输会非常快。镜像 pull 阶段只需要下载镜像的 manifest 文件
（通常只有几 K大小），速度非常快，启动阶段大地会给每个容器生成一个快设备，这个块设备的 chunk 读取是按需从超级节点或临近节点 P2P 的读取内容。这样就保证了容器启动阶段节点上只读取了需要的部分内容。为了防止容器运行过程中出现 iohang，我们在容器启动后会在后台把整个镜像的内容全部拉到 node 节点，享受超快速启动的同时最大程度的避免后续可能出现的 iohang。
提供容器平台给应用使用，在容器启动之前必然有很多平台相关的逻辑需要处理，这也是我们以前用富
容器的原因。
1 安全相关：安全路由生成、安全脚本配置
2 cpushare 化相关配置：tsar 和 nginx 配置
3. 运维agent 更新相关：运维agent 更新相对频繁，基础镜像更新特别慢，不能依赖于基础镜像更新来更新运维agent
4. 配置相关逻辑：同步页头页尾，隔离环境支持， 强弱依赖插件部署
5. SN 相关：模拟写 SN 到/dev/mem，保证 dmidecode 能读到正确的 SN
6. 运维相关的的 agent 拉起，很多运维系统都依赖于在节点上面有一个 agent，不管这个节点是容器/ecs 还是物理机
7. 隔离相关的配置：比如 nproc 这个限制是在用户上面的，用统一个镜像的容器不能使用统一 uid 不然无法隔离 nproc
现在随着基于 K8s 的编排调度系统的推广，我们有了 Pod 能力，可以把一些预置逻辑放到前置 hook 中去执行，当然富容器可以瘦下来还要依赖于运维 agent 可以从主容器中拆出来，那些只依赖于 volume 共享就能跑起来的 agent 可以先移动到 sidecar 里面去，这样就可以把运维容器和业务主容器分到不同的容器里面去，一个 Pod 多个容器在资源隔离上面分开，主容器是 Guaranteed 的 QOS，运维容器是 Burstable 的 QOS。同时在 kubelet 上支持 Pod 级别的资源管控，保证这个 Pod 整体是 Guaranteed 的同时，限制了整个 pod 的资源使用量不超过应用单实例的申请资源。
还有一些 agent 不是只做 volume 共享就可以放到 sidecar 的运维容器中的，比如 monkeyking、arthas 需要能 attach 到主容器的进程上去，还要能 load 主容器中非 volume 路径上面的 jar 文件才能正常工作。对于这种场景 PouchContainer 容器也提供了能让同 Pod 多容器做一些 ns 共享的能力，同时配合 ns 穿越来让这些 agent 可以在部署方式和资源隔离上是和主容器分离的，但是在运行过程中还可以做它原来可以做的事情。
可插拔的插件化的架构和更精简的调用链路在容器生态里面还是主流方向，kubelet 可以直接去调用 containerd 的 CRI 接口，确实可以减少一调，不过 CRI 接口现在还不够完善，很多运维相关的指令都没有，logs 接口也要依赖于 container API 来实现。还有运行环境和构建环境分离，这样用户就不需要到宿主机上面执行 build。所有的运维系统也不再依赖于 container API。在这些约束下我们可以做到减少一跳，直接用 kubelet 去调用 containerd 的 CRI 接口。
现在每个应用都有很多的 Dockerifle，怎么让 Dockerfile 更有表达能力，减少 Dockerfile 数量。构建的时候并发构建也是一个优化方向，buildkit 在这方面是可选的方案，Dockerfile 表达能力的欠缺也需要新的解决方案，buildkit 中间态的 LLB 是 go 代码，是不是可以用 go 代码来代替 Dockerfile，定义更强表达能力的 Dockerfile 替代品。
容器化是云原生的关键路径，容器技术在运行时和镜像技术逐渐趋于稳定的情况下，热点和开发者的目光开始向上层转移，K8s 和基于其上的生态成为容器技术未来能产生更多创新的领域, PouchContainer 技术也在向着更云原生，更好适配 K8s 生态的方向发展，网络/diskquota/试图隔离等 PouchContainer 的插件在 K8s 生态系统中适配和优化也我们后面的方向之一。