很少有基础设施项目能够真正完成，但 Kubernetes API 已经达到了稳定状态。核心 API 已经进入 v1 版，可扩展性模型（自定义资源定义）也很稳定。
接下来是什么？作为自 2016 年以来一直使用 Kubernetes 的人的一些想法。
1. 本机缩放至零
Native Scale to Zero（本机缩放至零）—— Knative 等框架提供根据指标自动缩放功能。这对于许多基础设施初创公司（和客户）来说至关重要，尤其是那些处理昂贵资源（例如 GPU）的初创公司。但归零也有其自身的问题——最大的问题是冷启动。目前还没有一种放之四海而皆准的解决方案——您必须要么完整的环境规范（例如，容器），要么具有约束的启动速度（例如，WebAssembly 函数）。
2. 更小的API
更小的 API 界面——有些项目专注于更轻量级的部署（例如，我在 Google 维护的 minikube 或 k3s），但没有一个项目专注于限制 API 界面。
我认为这里有空间构建一个固执己见但通用的受限 API。专为开发人员而不是 DevOps 构建的 API。不像 Heroku 那么简单，但也不像 Kubernetes 那么通用。
3. 拥有自己的发行版
发行版——许多人认为我们会像 Linux 发行版一样拥有 Kubernetes 发行版（例如 Debian、Arch Linux、Red Hat Linux 等）。但事实并非如此。我的预感是，Kubernetes 中存在太多特定于云的耦合，无法使发行版获得足够的动力。
4. 配置更简单
Kubernetes 配置语言——自 Kubernetes 诞生以来一直困扰开发人员的另一个问题。如何轻松配置和部署 Kubernetes？YAML模板太复杂，其他配置语言的尝试都失败了。我认为基础设施即代码的角度很有前途（例如，AWS CDK 和 CDK8 的组合），但它仍然有很多不足之处。同样，我认为开发人员的角度至关重要。
5. 更加云原生
WebAssembly、函数或其它的编排——可以修改 Kubernetes 以运行容器以外的部署（例如，虚拟机、gVisor，甚至一些用于 WebAssembly 的部署），但下一个编排器可能会专注于新的原语。专门构建的系统很可能会优于通用系统（在开发人员体验和功能方面）。
无论接下来发生什么，都必须利用 Kubernetes 解决 Kubernetes 造成的一些问题。但不会取代 Kubernetes。
