面试造航母，入职拧螺丝。这话在咱们这行已经说烂了，但你发现没有，现在连"拧螺丝"都得先背一套航母操作手册才行。
打开任何一个Java后端的面试题库，K8s八股文已经卷成标配了：
- Pod的生命周期是什么？
- Service有几种类型？
- Deployment和StatefulSet的区别？
- sidecar模式怎么实现？
背得滚瓜烂熟，面试官频频点头，入职offer到手。
然后呢？你满怀期待地打开公司的服务器，发现一共三台，跑着一个systemd服务，部署方式是ssh上去然后git pull。
你那些精心准备的HPA自动扩缩容、Istio服务网格、Helm Chart编排，全都没用上。不是公司落后，是公司清醒。
我有个朋友就没这么清醒。创业公司刚拿到天使轮，产品还没上线，用户在群里催了好几个月，他去学Kubernetes了。
整整三个月，天天泡在那堆YAML文件里，debug网络策略，研究服务网格，感觉自己特别谷歌。
我就问他：你的用户有几个？
他说还在内测，大概几十个吧。
我问你的服务器有几台？
他说两台，还在犹豫要不要上第三台。
我说你现在的服务器部署方案是什么？
他说ssh上去git pull。
那一刻我差点把咖啡喷出来。
两台服务器，你上什么Kubernetes？这就像什么？就像你家就两口人，非要买个能装五十人的大巴车上下班，每天早上把老婆抱上驾驶座，自己跳上后排，空荡荡地开到公司，停车的时候还要专门找大巴车位，倒车半小时。
车是好车，但真没必要。
Kubernetes这个名字来自希腊语，意思是"舵手"。谷歌开源它的时候，全世界都疯了：这是谷歌管理几十万台服务器的秘诀，我们也得用。
但问题是，你有多少台服务器？
大多数创业公司的真实情况是什么？
- 一台主服务器跑应用
- 一台托管数据库搞Postgres或者MySQL
- 再来个Redis缓存，完事儿
后台任务？一个systemd定时器加个bash脚本就能搞定。
备份？cron任务每天夜里三点跑一次。
就这么简单。
我给你看个真的在生产环境跑了好几年的systemd配置：
[Unit]
Description=Application Server
After=network.target
[Service]
User=app
WorkingDirectory=/app
ExecStart=/app/bin/server
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
就这些。二十行配置，你能看懂每一行。
半夜两点出问题，不需要查文档，不需要上Stack Overflow，扫一眼就知道哪里不对。
同样的东西用K8s写？
- Deployment
- Service
- ConfigMap
- Secret
- Ingress
一套下来至少五六个文件，每个文件几十行YAML。而且这还只是个最基础的单服务应用，没算上监控、日志、网络策略那些花里胡哨的东西。
我那个朋友学K8s的时候，我问过他为什么。他的回答特别经典：因为大家都在用。这句话毁掉的创业公司比烂点子多了去了。我们这个行业有个毛病，总觉得自己在Netflix，在谷歌，在Meta，天天看他们的技术博客，看他们的架构分享，然后觉得自己也得这么搞。这叫什么？这叫"优化剧场"——舞台效果很好，但没什么卵用。
大多数早期团队缺的不是容器编排，缺的是专注。你们的团队会议聊的是什么？是K8s还是Swarm，是托管还是自建，是Helm还是原生manifest。技术选型讨论了一周又一周，产品呢？用户反馈呢？都在讨论什么时候有空处理。
问题从来不是orchestration，问题是三台服务器够用半年，变成五台，再变成十台，这是线性增长，不是什么分布式系统科研课题，systemd表示这点活儿它完全扛得住。
来算笔账。一台t3.large服务器，大概100美元一个月，托管Postgres带备份200美元，监控日志加起来50美元。350美元一个月，这套配置能扛住百万级请求。
K8s呢？托管版先收你控制平面的钱，然后是工作节点，然后是存储，然后是负载均衡器，然后是那个半夜三点要起来修failed probe的工程师的工资。
真正的成本不是钱，是时间。
一个初级开发者花一天就能搞懂systemd，小团队跑起来不需要什么K8s专家。但Kubernetes就是什么都不坏，也得有个人专门盯着它。
每个月花在学那些你暂时还用不上的基础设施的时间，本可以用来从用户那里学点什么。
我们为什么偏爱复杂？原因很简单：怕。怕简单方案以后不够用，怕自己漏掉了什么重要的东西，怕真正的工程师都用复杂系统，自己用简单的就显业余。这恐惧能理解，但是错的。我见过最厉害的工程师，跑的系统简单到让你吃惊。有个朋友用单台VPS加几个脚本，月收入就六位数了。另一个整个交易平台就靠托管服务和systemd撑着。他们不会K8s吗？会得很，但就是不用。不是因为不懂，是因为懂。
系统出问题了，你需要知道。systemd给的是直球——一行journalctl -u app.service --since today，CPU高了、内存炸了、磁盘满了，故障是物理的，能理解的，修起来就完事。K8s的故障是抽象的，Pod不健康、Node ready但unavailable、Service存在但路由不到哪里去，debug变成考古现场，一层层挖下去，最后发现是某个selector写错了一个字母。
当然有一个转折点的。当单机真的扛不住的时候，当一天要部署几十次的时候，当五十个工程师同时推代码的时候，当服务器放哪儿都需要算法决定的时候，那时候K8s是礼物，不是之前。而且有个没人愿意大声说的事：等你到那一步，你有钱了，有时间了，有个真正的业务值得这复杂度了，那时候迁移是难，但值得。提前迁移？就是纯受罪。
最后活下来的工具都是那些能理解、能教、耐造的。Nginx、Postgres、MySQL、Bash、Systemd，这些工具不酷，它们也不吹自己，但它们坏得可以预测，老得体体面面。基础设施应该是隐形的，如果它占用了你太多注意力，那它已经太贵了。
说三件事。第一，K8s强大，systemd够用，强大不免费，够用被低估。第二，如果你的目标是做产品、发功能、睡安稳觉，选无聊的，不是因为简单，是因为诚实。第三，那个花了三个月学K8s的创始人，本来可以用那时间拿下一万个用户。别做那个创始人。
记住：够用是最高级的复杂。
你的小抄
# 查看服务状态
systemctl status app.service
# 启动停止重启
systemctl start app.service
systemctl stop app.service
systemctl restart app.service
# 查看日志
journalctl -u app.service --since today
journalctl -u app.service -f # 实时
# 开机自启
systemctl enable app.service
# 定时任务（cron风格）
systemctl list-timers
我想听听你的故事
聊聊你：你现在用的部署方式是什么？单机裸跑？Docker compose？还是已经上了K8s这艘大船？在评论区说说你的选择和遇到的坑。
下集预告：什么时候该真的上K8s——我给你三个硬指标，到了那一步再换也不迟。
觉得这篇文章有用吗？
- 点赞：如果觉得有帮助，点个赞让更多人看到
- 转发：分享给可能正在纠结要不要上K8s的朋友
- 关注：关注梦兽编程，不错过更多实用技术文章
- 留言：有什么问题或想法？欢迎在评论区交流
你的支持是我持续创作的最大动力！