左边是CNCF推广大使 太田航平，而右边是CNCF技术监督委员会成员 Katie Gamanji，两位来台在K8s Summit中分享K8s未来三大发展方向

两位苹果工程师Katie Gamanji和太田航平(Kohei Ota)，在今年Kubernetes Summit研讨会第二天的主题演讲中，回顾了K8s十年发展，并揭露了接下来三大发展方向。Katie Gamanji是CNCF技术监督委员会成员，她主导设立了云原生证照KCNA认证制度和相关课程，而太田航平则是CNCF推广大使，去年参与创立了日本云原生社群，是日本开源社群的活跃者。

Katie Gamanji指出，K8s是杰出的容器调度框架，关键是通过声明式配置和各种自动化机制，提供了很好的移植性和适应力，今年是K8s诞生十周年，超过8万8千人参与贡献，横跨8千家企业，超过4,200万次上传。十年来发展出了很完整的云原生技术版图（Cloud Native LandScape）。

目前CNCF拥有190个开源项目，分布在三个不同成熟度的等级，127个处于创意解方尝试阶段的沙盒项目，37个开始有企业贡献和采用的孵化项目，以及27个达到稳定和成熟，甚至成为业界标准的毕业项目。另外，还有些项目发展不如预期，会落入归档的项目，目前有9个。

太田航平指出，因为跨不同操作系统和云端供应商，推动了CRI（容器Runtime界面）和CNI（容器网络界面）这两类项目的蓬勃发展，可以针对特定云端业者量身克制，提供更多弹性，也支持更多样化的容器运行环境。随着大规模应用和有态工作流程的需求，带动了CSI（容器存储界面）和服务网格技术的兴起，可用于管理超级复杂的网络流量。

为了满足多租户架构，让每个用户可以有自己专属的集群，太田航平表示，K8s的集群API成了关键标准化机制，可以将集群的身分验证功能，和底层的基础设施脱离。通过集群API，不论是本地端、公有云或边缘环境，都可以提供一致的K8s集群创建和管理方式，也能创建一套涵盖集群生命周期的标准化管理方式。

未来K8s三大发展：WebAssembly、eBPF和持久性

K8s的下一波发展，太田航平指出有三大重要机制，第一项就是WebAssembly。为何这项技术对云原生的发展，非常重要？太田航平解释，WebAssembly可以提供一个独立的环境，不受限于任何开发语言、操作系统和CPU。换句话说，WebAssembly等于是提供了一个可以通吃任何开发环境、操作系统，甚至是CPU架构的运行程序。WebAssembly也是一个二进位文件，可以用不同的开发语言编译成这种格式的文件，再部署到浏览器或非浏览器的环境中运行。「WebAssembly提供了一个安全、轻便而且可以在任何地方运行的环境。

太田航平举例说明如何用K8s开发者熟悉的GO语言、行动开发者惯用的Swift，甚至网页开发者会用的Ruby语言，来编译成WebAssembly的wasm格式档，都可以很容易完成。也很容易用Docker来打包出一个可以运行WebAssembly二进位档的容器映像档。

eBPF应用越来越广，从网络处理，扩大到资安监控和可观察性

除了WebAssembly之外，第二个重要新发展是eBPF，这项技术原本只是一项用来过滤网络封包的技术，但现在的应用越来越多元，不只是网络处理，也扩大应用到资安监控和可观察性工具上。

太田航平指出，eBPF的威力是，在同一套一致的安全模式下，提供了低负载的过滤机制以及内核等级的程序化能力，主要通过JIT即时编译技术和运行前验证机制来实现。由于eBPF的代码具有Linux内核等级的运行能力，因此采取许多预先验证机制，也采取了一些预防runtime时期出现意外行为的机制，例如限制可用的系统调用。另外，还会随时监控数据类型和存取模式，来避免代码非法存取内存。

目前，eBPF主要有三大应用场景，资安监控，网络路由和过滤，以及可观察性中的矩阵数据搜集，都各有不少知名的开源项目。这三类应用都是云原生环境运作需要的核心能力。例如像New Relic的Pixie可观察性工具，就是用eBPF技术来取得K8s运作的矩阵数据。

为了确保安全，eBPF二进位档会先加载到用户空间，经过各种运行前验证检查后，才会把文件放入到内核空间，再用JIT编译器完成编译后，才允许链接到系统调用。
最后一项K8s的新发展方向是持久性。

技术部门若不行动，未来技术碳排不减反而会大增

Katie Gamanji指出，根据调查，全球碳排放量有1.4%来自技术部门，如果将数据中心和信息基础架构改用再生能源来运作，可以减少80%的碳排，但是，目前技术部门的行动力不够，导致技术部门未来十年产生碳排量，不但不会减少，反而预估还会增加了10%。

「如何让技术部门可以观察，纪录和评估他们自己的碳排放，在云原生环境中，需要新的工具来解决这个课题。」Katie Gamanji指出。这正是K8s接下来在持久性的发展方向。目前K8s有两项重要的永续工具，第一个Kepler项目，可以用来追踪K8s的能耗，另一个工具则是碳察觉KEDA工具，可以依据碳排量数据变化来调度的自动扩充机制。

Kepler利用了eBPF技术来探测K8s集群在系统层级的能耗数据，再导出到Prometheus中汇整，可以用Gafana来可视化，这项项目是由IBM和红帽在2022年发起，2023年捐给CNCF基金会，目前处于沙盒阶段，意味着还是一项新兴的创意尝试解决项目，还没有足够多的企业案例，也很需要尝试者来贡献意见。Kepler可以追踪到不同命名空间，甚至是每一个容器，每一天的碳排数据变化。若用命名空间来区分不同的应用，就可以找出碳排量特别高的应用系统。

不只追踪碳排数据，还可依碳排密度自动调度K8s集群

有了追踪碳排数据的工具后，如何运用到K8s集群的调度上，另一个关键工具就是具备碳察觉自动扩充操作器Carbon Aware KEDA Operator。KEDA（Kubernetes Event-driven Autoscaling）项目是一项K8s的自动扩充、缩小集群规模工具，可以用事件驱动来触发。碳察觉KEDA操作器则是可以让KEDA工具，可以依据集群外部的事件，来调整应用程序的规模，达到碳排放量调整的效果。

例如可以设计系统使用「碳排密度」指针来调整规模，碳排放量密度是一个新兴的绿色IT指针，以每千瓦小时排放多少二氧化碳量来计算。可以在配置档中，通过KEDA Scaler CRD或自定义资源设置，来定义不同碳排密度事件的层级，当密度高时，自动降低应用系统的副本数量，来达到减少碳排的效果。

Katie Gamanji表示，参与CNCF项目有很多种形式，不一定要贡献代码，也可以参与白皮书制定，或加入工作小组。例如有不少中小企业参与了形形色色各种议题的技术咨询小组，云原生生态圈是一个随着更多参与和交互，而不断改变的环境，需要一个健康的社群来支持，社群也需要永续的发展。