数字系统架构分享

手里攒了几台小服务器,分散在不同的云、不同的地域,平时各管各的,越来越乱。某天我冒出一个念头:能不能用 Kubernetes 把它们统一管起来?于是有了这一整天的折腾。记录在这,给同样想试的人省点坑。

k8s 还是 k3s

先说结论:学习和中小规模,直接上 k3s。它是经过 CNCF 认证的完整 Kubernetes,API、生态、kubectl 全都通用,只是把控制平面打包得极轻。原生 k8s 光控制平面就能吃掉一台小机器,对我这种 2核4G 的机器划不来。纠结”k3s 还是 k8s”其实是个伪命题——你学到的就是 k8s 本身。

跨云,是这次最大的坎

我的机器分属两个云厂商,彼此不在同一个内网。k8s 要求节点之间能两两互通,跨云走公网既不安全也麻烦。解法是加一层 overlay 虚拟网络——我用的是 Tailscale,所有节点装上之后自动组成一张虚拟内网,k3s 在这层之上组集群,全程不用动任何云安全组,SSH 也不受影响。

国内特色三连坑

• 拉不动镜像:节点去 GitHub / docker.io 经常超时,连最基础的 pause 镜像都拉不下来。解法是配国内镜像加速源。
• 装工具失败:本机用 Homebrew 装 kubectl 也卡在 GitHub 的 ghcr.io 上,换成国内 Homebrew 镜像才好。
• 本地连不上集群:Tailscale 的中继链路 TCP 不稳,kubectl 直连 6443 超时。最后用一条 SSH 隧道把本地端口转发到 master,反而最稳。

你会发现,在国内搞这套,一大半时间是在和网络较劲,而不是和 Kubernetes 本身。

然后呢

集群跑起来了,三个节点跨云互通,本地 kubectl、k9s、图形面板都能管。但折腾到最后,我又把生产服务搬回了 Docker——为什么,下一篇细说。

上一篇我兴致勃勃搭了一套跨云 k3s 集群。这一篇我想泼盆冷水,也是给折腾完的自己一个交代:对我这种规模,Kubernetes 其实是过度工程。

答案取决于你的目标

如果只是”把几个服务跑好、少折腾”——几个自部署应用、几台小机器、一个人管——那 docker-compose 本来就够,而且更简单。k8s 带来的复杂度(控制平面吃内存、跨云组网、镜像分发、存储与故障转移),换来的好处我大多用不上。尤其当我还要求”每个服务只跑在一台机器上”,恰恰把 k8s 最值钱的能力都关掉了。

但如果目标是”学”——那 k3s 完全正确,这些麻烦正是它真正的课程。

两个容易搞反的点

• 故障转移 ≠ 数据安全。很多人以为上了高可用数据就安全了。错。副本只会把损坏的数据一起复制过去。防机器挂靠副本,防数据丢/坏靠备份,这是两套东西。
• 数据安全和用不用 k8s 无关。无论裸机、Docker 还是 k8s,生产数据都得有异地的、带历史版本的、验证过能恢复的备份。

我最后的姿势

有状态的、真生产的(数据库、网站)留在 Docker,稳、简单、好备份;无状态的、新项目、练手的放进 k3s 当学习沙盒。这样我学了 k8s,又没把身家压在它上面。

对小团队和个人,”可恢复”远比”永不宕机”重要。机器挂了停几分钟可以接受;数据没了是灾难。

这个博客原来是 WordPress 的默认主题,干净但没什么个性,像刚装好没人住的房子。趁周末给它做了一次极简改造,记录一下思路。

定调:现代编辑风

我想要的是”安静、好读、有质感”,于是定了现代编辑风:衬线字做标题带一点书卷气,无衬线做正文保证可读,配一抹克制的红色做点缀,窄栏排版让阅读更专注。内容至上,不堆装饰。

几个务实的决定

• 用系统字体:不引第三方网络字体,避开国内加载慢/被墙的问题,打开就快。
• 关掉评论:我只想发表自己的东西,不做互动。顺带也避开互动类服务的额外监管。
• 守住备案:改版第一原则是别把页脚的 ICP 和公安备案号搞丢——这是国内网站的底线。

改造的方式也尽量可逆:样式是叠加上去的一层,不喜欢随时能还原。慢一点,把想清楚的东西留下来,就挺好。