Fly Kubernetes
Fly.io 的新功能“Fly Kubernetes”在其现有 Machines 平台之上暴露了一个与 Kubernetes 兼容的 API，使用 k3s 和 Virtual Kubelet 将 Pod 直接映射到 Fly 的虚拟机。评论者权衡了这种方式的好处——声明式配置、工具兼容性以及按 Pod/VM 的自动扩缩——与其局限和非标准行为，例如对多容器 Pod 和持久卷支持不完整。有些人认为这对已经深度使用 Kubernetes 的组织来说是务实的适配层；也有人认为这偏离了 Fly 原本的简洁性，并提醒平台稳定性和文档仍需改进。
什么是 Fly Kubernetes (FKS)
- 被定位为构建在 Fly Machines 之上的一个可选的、与 Kubernetes 兼容的接口，而不是将 Fly 自身的基础设施转向 Kubernetes。
- 通过运行在单个 Fly Machine 上的 k3s + Virtual Kubelet 实现；Pods 与 Machines 进行 1:1 映射。
- 目标是让团队在 Fly 上复用 Kubernetes 工具链和声明式 YAML，同时将调度和基础设施交给 Fly 的平台。
与其他云产品的定位对比
- 有些人认为 FKS 在精神上类似于 GKE Autopilot 或 EKS Fargate：按 Pod 级别计费，无需管理节点。
- 也有人认为它主要是通往 Fly 平台的“Kubernetes API 适配层”，而不是完整的 Kubernetes 发行版。
- 一些评论者建议文档和市场宣传应更清楚地说明 FKS 是什么、不是什麼，以及支持哪些 Kubernetes 功能。
技术设计与限制
- 控制平面是带有 SQLite 的单节点 k3s；显然不是高可用。如果那台 Machine 挂了，API 访问可能会中断。
- 多条评论质疑是否支持多容器 Pod 和 sidecar；当前 Fly Machines 每个 Machine 只能运行单个镜像，因此是否能完全对齐还不明确，而且也被承认为仍在完善中。
- 当“node”变成一个每个 Pod 对应一台 VM 的 virtual-kubelet 时，affinity/anti-affinity 语义会发生变化；某些容错模式可能无法直接迁移。
- 持久化存储仍然绑定到 Fly Volumes 所在的物理主机；Fly 可以迁移卷，但硬件故障仍可能导致数据丢失，因此更推荐使用更高层的数据库复制或外部数据库。
Kubernetes 生态 vs 自定义平台
- 一种观点：使用 Kubernetes 能接入一个由标准、工具和人才组成的生态，并避免重复造编排轮子。
- 另一种观点：Kubernetes 很复杂，有时过于重；Fly 的自定义调度器和网络栈可能更简单，足以解决他们的问题。FKS 只是给坚持使用 K8s 的用户提供的适配器。
用户反应与担忧
- 一些人对能在 Fly 上获得声明式配置和基于 kubectl 的工作流感到兴奋。
- 另一些人担心这会削弱 Fly 的 PaaS 简洁性，或者是一个拥抱 Kubernetes 复杂性的“踩坑工具”。
- 有人对某些 Fly 区域以及 Fly 整体稳定性和文档一致性提出可靠性担忧。
- 还有人要求更清晰地说明可用性保证、Pod 生命周期、存储行为以及跨区域行为；许多细节仍然不明确。