我的个人服务器为什么暂时不用 Kubernetes

重新整理个人服务器时，技术选择里有一个问题：是否需要 Kubernetes？真正列出要承载的东西，眼下只是个人网站、几个可能陆续出现的小工具和后端实验。它们共用一台主机，入口按域名区分。这个阶段最需要的不是调度能力，而是知道服务在哪里、出了问题怎么查、重建时怎么做。

把当前问题放在桌面上

我的起点是一台几乎空白的 Ubuntu 主机。要让静态页面和以后新增的应用从公网安全访问，至少要解决域名解析、HTTPS、进程运行和重复部署。我最后让 Caddy 负责公开的 HTTP 入口与证书，让 Docker Compose 承载应用，让 Ansible 保管基础配置。主机和应用之间的边界因此比较直观：请求先到 Caddy，再按 Host 到网站文件或只在本机开放的应用。

这不是说 Kubernetes 没有价值。它能处理多节点调度、声明式滚动更新等问题，只是我现在并没有这些问题。把集群的控制面、网络和存储引入一台个人主机，会多出需要维护的状态。尤其是我还没有完成替代主机的全流程恢复演练，先增加一层系统，并不会自动补上恢复能力。

做这个决定时，我也特意区分了“应用数量将来可能增加”和“现在就需要复杂调度”。前者可以通过清楚的域名和部署约定应对：每个项目有自己的配置、运行位置和健康检查，入口由 Caddy 按域名分开。等这种模式真的遇到容量或维护瓶颈，再根据具体瓶颈改造。因为担心未来而提前上集群，反而让我在最初几次部署时难以看清请求路径。

简单也要能验证

不使用 Kubernetes，并不等于靠手工记忆维护。仓库里的 Playbook 管 Caddy、Docker、站点文件和基础目录；域名与站点路由有明确配置；重复执行时要看到没有意外变更。公开页面则从普通客户端检查证书、状态码、跳转和实际内容。这样出了问题可以沿着 DNS、Caddy、应用的路径逐段排查，而不是先猜某个抽象层发生了什么。

我还用一个临时的容器 API 验过应用模式：容器只向本机发布端口，由 Caddy 按域名转发，在 HTTPS 下拿到预期响应后再移除临时资源。它证明了这条部署路径可走通，但没有证明未来每个应用都已经准备好上线。尤其是有持久数据时，备份和恢复还需要单独设计。

静态站点也给了我一个较小的起点。网页源文件和部署配置都在仓库里，改动能先看差异，再用 Ansible 更新；公网请求能核对两个域名是不是拿到相同页面。这样的反馈回路够短，我可以知道一次修改到底碰了哪些层。对个人维护者来说，弄清楚失败发生在哪一层，和新功能上线一样重要。

什么时候重新考虑

如果以后项目真的增加到单机无法合理承载，或出现多主机调度、跨节点故障转移的明确需求，我会重新比较方案。那时也应先写清楚要解决的故障模式和恢复目标，再选择工具。现在的选择只适合我目前的个人服务器：组件少、路径短，能用实际请求和配置重跑检验。

一个我会继续观察的信号是维护成本。如果每新增一个小项目，都要靠临时命令和脑中的记忆才能部署，那说明当前约定需要改进；但改进也可以先是更清楚的模板、检查和恢复文档。只有问题真的落在编排层，再引入编排层才有根据。