云原生网络：展望 Kubernetes 的下一个十年

声明

此文为个人翻译，仅供参考，不代表我个人立场。翻译过程中可能有删改或遗漏，如需了解原文，请自行查阅。如有疏漏，欢迎指正。

查看本文大纲

随着 Kubernetes 迈入青春期，让我们思考其网络和安全系统如何进一步发展与适应。

Kubernetes 最近迎来了十周年纪念。作为一名家有三子的父亲，我感觉有责任提醒 Kubernetes 的管理员们：成长中的 Kubernetes 并不总是“乖巧”。

可以预见，Kubernetes 将进入其“叛逆期”。

Kubernetes 未来将经历增长的阵痛（随着新用例迫使它进行调整）；它或许会遭遇“身份危机”（到底是平台还是API？）；它将寻求更少的监控与更大的自主性（依赖AI工具来减少人类的直接监督）。

借此机会，随着 KubeCon 北美大会即将在盐湖城召开，让我们展望一下云原生网络的发展方向，并探讨一些未来的趋势。

作为能够在 Linux 内核（未来也将支持 Windows）中运行自定义程序的技术，eBPF 的势头不减。除了网络和安全功能（例如 Cilium 和 Tetragon 项目），还出现了更多的应用场景：

我们可能会面临一种情况，不选择 eBPF 作为网络编程平台反而成为少数。尽管 eBPF 是一种强大的工具，我们不能将所有网络问题都视为“钉子”。

在 eBPF 可以访问每一个数据包的能力下，网络可视化是一个非常强大的用例。

OpenTelemetry 作为 CNCF 项目中最活跃的项目之一，提供了标准的可观测框架，通过简单的应用程序仪表来生成和管理遥测数据。

考虑到网络经常被认为是应用性能问题的根源，我们可以期待使用 OpenTelemetry Network，直接从 Linux 内核获取低级遥测数据，以提供关于应用健康状况的有价值见解。

在 Kubernetes 迈向十周年之际，我们也开始反思其网络架构的一些设计决策是否依然适用。

例如，Ingress API 是 Kubernetes 早期的一个重要选择，然而其继任者 Gateway API 正在取代它。

服务网格架构也在演变，从传统的 sidecar 架构向 Cilium Service Mesh 和 Istio Ambient 模式的无 sidecar 方式转变。

这似乎是反思的好时机。甚至 Kubernetes 的 SIG-Network 组也在考虑是否要放弃容器网络接口插件模型，并可能引入更现代的 Kubernetes 网络接口（KNI）。

Gateway API 是 Kubernetes 生态系统中最具创新性的项目之一。它不仅解决了 Ingress 的不足，且其开发充满合作与包容精神。

随着近三十个 Gateway API 的实现和即将推出的 1.2 版本，在今年的 KubeCon 上，Gateway API 的讨论将深入到实际的部署经验，而非入门课程。

Ingress 曾经广泛使用，但现在是时候迈向 Gateway API 了。

在讨论 AI 与网络时，我总是将其分为“面向 AI 工作负载的网络”和“用 AI 改善网络”。后者是当下的重点。

我曾经尝试使用大型语言模型（LLM）来创建网络策略和分析日志，然而效果不一。我们期待 Kubernetes 能借助 AI 技术做出更智能的网络决策，例如自动生成网络策略。

随着 Kubernetes 成为 AI/ML 应用的理想平台，AI 工作负载对网络的需求也愈加显著。它不仅需要本地 GPU，还需要通过远程直接内存访问（RDMA）连接远程 GPU。

或许 Kubernetes 近期的动态资源分配（DRA）功能可以用来访问专门的网络硬件资源。

是的，Kubernetes 将经历类似青少年的成长过程。但没关系，它有一个支持性强、不断创新的社区来帮助其发展成为一个稳定的系统。