运维总监怒怼开发：你真的需要 K8s 吗？

我最近几年待过的公司，我只要一进公司，基本上都是主导或力推全面容器化、k8s 化，不论业务体量（当然，微服务是必须的）。

对于连续用了4年k8s的我来说，哪怕你只有三台服务器，我也要给你部个k8s。

如果你只有一台物理机，我恨不得给你虚拟化三台机器出来再装个 k8s（只是恨不得而已）。

如果你说没必要，我下意识的感觉就是你肯定还不熟悉k8s。

下面简单说一下我已经离不开 k8s 的理由。

从线上费用来讲，各种云已经有托管 master 的集群在售，你直接买 node 就行，一个 node 和 一个 ecs 的费用相差也不大（同等配置）。

从线下费用来讲，不管你用不用 k8s，服务器是必须的吧，这个无论如何免不了。

从服务器维护来讲，相对传统的公司服务器一般会用 esxi 等虚拟化技术将物理机分配成若干个虚拟机，而你用了 k8s 之后，你直接可以将物理机作为集群的一个 node，免去虚拟化的时间和维护成本，新购机器直接作为 node 加入资源池。

从维护难度来讲，你只要能熟练使用 kubectl，你的大部分运维工作都可以免去 ssh 这个操作了。

我要运行一个应用：

我要让服务可以外部访问：

我的应用要扩展一下副本，做下负载均衡：

我要配下域名、转发、黑白名单：

对于ci/cd、服务发布更新：

回想一下多年以前你写了一个 300 行的 shell 只为所谓的平滑更新一个应用的版本，k8s 依然只要你 kubectl 一下。

再进阶一点，你如果稍具开发技能，对接一下 k8s 的 api，把上面的这些操作做到 ui 让开发点点点，你会发现，如果你公司本来有 10 个运维，这么一搞可能两个就够了（留一个陪另一个吃饭）。

额，写到这里的时候重新看了下题，是对开发来讲的哈。。那我只能说，k8s 真的牛逼。。。

--- 另外补充一点（2023-12-26 15:00）---

据我这几年的感受而言，运维的工作时长很大一部分是耗在和开发扯皮这点。

所以要减轻运维工作量以达到 10 人 -> 2 人的目标，在标准化和自动化做好后，肯定要需要一个平台支撑（运开这个角色必须了）。

这个平台的核心作用就是将开发和运维隔开，比如现在还有不知道多少公司还在巴巴等着运维发版，流程大概是这样：
1. 开发：我代码提交了，构建好了，a 服务构建好的镜像 tag 是 001，b 服务的镜像 tag 是 002，运维你去发下版；
2. 运维：好的好的，我去更新，然后运维去一通 kubectl edit a 或者 kubectl set image，修改 tag 为 001，然后修改 b 服务的 tag 为 002（可能还有 c、d、e）。。。
3. 运维：修改完之后还要盯着 Pod 能不能过健康检查，如果没过，还要回头 call 开发，哪个服务是哪个开发负责，找到对应的开发，啊开发老弟你的服务挂了；
4. 开发：好的好的我去修一修，若干分钟后，修好了（这段时间运维处于干等状态），运维你再去构建发版一下；
5. 运维：重复 2；

所以这个平台要必须要具备的功能：
- 开发能自信的发版；
- 发版即便失败了也不要影响旧版本（正好 deployment 只有起了新的健康 pod 才会删旧版本 pod）；
- 开发能够第一时间知道发版的结果（成功或失败）；
- 如果发版失败了，开发能基于平台排错重新发版，比如让开发能够自己看 Pod 日志和进终端；

而且这个平台一旦落地，解决的并不只是扯皮问题，沟通时间省去了，你会发现整体发版效率都提高了超级多。

最近闲着没事的时候我开始尝试写一个尽量通用一点的平台能够完成上述操作，感兴趣可以关注：
https://github.com/zze326/devops-super

（其实我在当前在职的公司已经写好了一个相对成熟 devops 平台，但几乎是对公司环境定制的所以开源出来也没啥意义）

目前完成了简单的 CI 功能（可以替换掉 Jenkins，但是依赖于 k8s）和堡垒机功能；
更新可能有点慢，因为咱也是搬砖人，比较闲的时候有兴致的时候才写；
如果公司有 devops 平台的开发需求基于它二开我觉得是个不错的选择；