KubeCon China 2024 之旅-工具盒子

前言 {#前言}

很早就有了解到今年的 KubeCon China 会在香港举办，虽然有些兴趣，但我最初是有被 KubeCon 高昂的门票价格劝退了的。

有时候不得不相信运气的魔力，机缘巧合之下，我从朋友 @Kev 处得知了 KubeCon 的「最终用户门票计划」并借此 0 元购了门票，又邀上了 0xFFFF 社区的@Chever-John @0xdeadbeef @茗洛三位朋友一起参加，在香港租了个 airbnb 住宿，期间也逛了香港城市中的不少地方，收货颇丰。

其实本来也尝试过邀请其他认识的朋友同事，但都因为种种原因无法参加，略感遗憾。

TL;DR {#tldr}

本文多图，也挺多技术无关的内容，为了方便想了解技术的朋友，我先做个大致的总结。

从 KubeCon 回来后我又听了些 CNCF 其他的会议视频，其中比较有印象的是这几个：

Keynote: Cloud Native in its Next Decade - KubeCon Europe 2024: 聊了 CloudNative 的未来，结论跟这次在 KubeCon China 现场听到的内容类似。
Another Choice for Istio Multi-Cluster & Multi-Network Deployment Model - KubeCon Europe 2024: 提到了 Istio 多集群方案的痛点，介绍了中国移动的解决方案。我一直有想尝试多集群方案，但一直担心 hold 不住而不敢下手，这个视频给了我一些启发。
DRA in KubeVirt: Overcoming Challenges & Implementing Changes - KubeCon Europe 2024: DRA 也是 K8s 中的新 API，这里介绍如何在 kubevirt 中使用 DRA 解决一些问题。从这里能感觉到 K8s 这几年还是弄了不少新东西的。

结合 KubeCon China 三天的经历，以及上面这些视频的内容，我大概的感觉是：

（几乎）所有聊网络的人都在聊 eBPF, Envoy, Gateway API.
Istio 的 Ambient Mode 吸引了很多曾经因为 sidecar 性能问题而放弃使用服务网格的公司。
Karmada 多集群管理方案在许多公司得到了实际应用，挺多讲这个的。
AI 与 WASM 方面的演讲也有不少，但感觉有些无趣，可能是我对这方面不太感兴趣。
蔚来汽车、中国移动等公司正在尝试将 K8s 应用在边缘计算场景（智能汽车、通信基站），但这些离普通互联网公司有点远。
云原生的未来十年会变成什么样？
- Kubernetes, Service Mesh 等过去十年的新兴技术，现在已经成为了「Boring but useful infrastructrue」，它们将是其他云原生技术潮流的基石，被广泛应用，但自身不会再有太多的变化。
- AI, eBPF, WASM, Rust 等技术也将在未来十年走向成熟，取代 Kubernetes 当前的地位。

KubeCon China 2024 的会议视频将会陆续被添加到如下这个 Youtube Playlist 中，有兴趣的朋友可以一观：

KubeCon + CloudNativeCon + Open Source Summit + AI_dev China 2024 - Youtube

视频相关的 PPT 可以在这里下载：

KubeCon China 2024 - Schedule

技术 {#技术}

这次我主要关注的是 Istio、Gateway API 相关的议题，最近在研究 Istio 的 Ambient Mode，因此希望能够从会议中了解到更多的实现细节与其中的权衡。

三天下来听到的内容也很好的满足了我的期待，Istio / Envoy Gateway / Ingress Controller 的几位核心贡献者分享了很多这些项目的最新进展，实现细节，以及未来的发展方向。

Ambient Mode 在最近 beta 了，是我关注的重点，总结下目前了解到的几个关键点：

istio/ztunnel: 一个 userspace 的 l4 proxy，仅支持处理 L4 流量。
- ztunnel 会分别与上游和下游建立连接，导致 A <=> B 之间的一个连接会变成 A <=> ztunnel <=> ztunnel <=> B 三个连接，这也会带来性能开销。
- 因为所有流量都经由 ztunnel 转发，更新 ztunnel 会导致短暂的流量中断。感觉比较好的解决方案是采用 recreate 的更新策略 + 滚动更新节点组下的所有节点来更新 ztunnel.
- ztunnel 使用的 HBONE 协议强制启用 mTLS，无法关闭，对于不要求安全性的场景会带来额外的性能开销。
istio/proxy: 基于 envoy 的 l7 proxy，在 ambient mode 下它被单独部署为一个 waypoint, 用于处理 L7 流量。
- waypoint 架构下 proxy 与上下游 Pod 很可能在不同的节点上，这会导致比 sidecar 模式多一次网络跳转，可能带来性能损耗，以及跨 Zone 流量上涨。
- waypoint 与 sidecar 都是 envoy，它是通过减少 envoy 容器的数量来达到减少资源消耗的目的。

以及一些其他方案：

kmesh: 架构类似 Ambient Mode，特点是完全使用 eBPF 来实现 L4 proxy，好处是
- eBPF 直接在内核空间修改网络包，不需要与上下游分别建立连接。因此性能更好，而且 eBPF 程序更新不会中断流量。
cilium service mesh: 特点是 per-node proxy，l7 的 envoy proxy 运行在每个节点上，而不是像 waypoint 一样单独通过 deployment 部署。但也存在一些问题：
- per-node proxy 无法灵活地调整资源占用，可能会导致资源浪费。
- 同一节点上的所有流量都由同一 envoy proxy 处理，无法实现 waypoint 那样的 namespace 级别的流量隔离。
- 与 cilium cni 强绑定，必须使用 cilium cni 才能使用 cilium service mesh.
- 据说使用起来较为复杂？

总体而言，KubeCon 是一次了解行业前沿技术动态、跟项目开发者及其他行业内的技术人面对面认识交流的好机会，可以帮助自己提升技术视野，维持技术热情与动力，不至于局限在公司业务中闭门造车。