这篇文章来源于一次内部讨论，大家突然聊到为什么要用k8s部署，是否还有其他的部署方案呢？大家现在好像都默认k8s部署服务，那么凭什么呢，k8s的核心优势有用到吗？私有化部署场景下需要k8s吗？甚至拆分这么多微服务是否合适，合并成大的单体应用是否可行？
以上问题虽然较多较杂，但都振聋发聩。是啊，难道除了k8s一把梭就没其他的部署方式了吗？这是否代表大家也缺少对于业务和成本的思考呢。
微服务的思想深入人心，可是部分业务真的有必要拆分成5-6个微服务吗？薄是真的薄，但是大家手头都维护好几个微服务是否会手忙脚乱呢？合并成一个单体应用就不能跑了吗？
为什么公司的云服务都用k8s部署，不用k8s行不行？公司当前的业务非要用k8s不可吗？
是啊，为什么现在的服务默认就使用k8s了呢？因为大家都用？因为习惯？因为运维那边的云厂商基建？因为成本低？
博主记得18年的时候公司还是自有机房，从19年就开始全面上k8s,再之后就是使用云厂商的服务。公司的运维也是经历了从机房到云厂商的转变，越来越方便的部署和低运维成本以及丰富的云厂商功能，使整个运维部门逐渐面向云厂商运维。
对于开发人员来说呢，一方面是对于新技术的追求，一方面是市面上的面试都开始问k8s相关的八股文。什么，你一个后端开发没用过k8s？回去等通知吧。所以近几年明显感受到大家对于k8s的热情，一直到现在，似乎服务不部署到k8s上就是low。
k8s相对于传统服务器来说，可以根据请求量动态扩展pod，再结合云厂商的无限资源，让公司可以坦然面对流量高峰以及低谷，不必为了高峰大量采购服务器，也不必因为低谷而心疼服务器的开销。特别是电商公司的促销以及节日场景尤为适合。
其次就是整个云原生的生态，从负载均衡到各种资源监控，到服务治理，服务网格等，强大而丰富的生态也促使云原生更加的深入人心。
现在可以说是微服务时代，一方面是服务数量多，一方面是异构服务多，使用k8s也可以节省研发的部署成本，异构服务间调用和运维成本。
另外就是CI/CD，让服务可以在分钟级别完成部署，相应的需要运维同学去开发这些运维平台，目标是尽量屏蔽掉部署细节，方便开发人员使用。
这么看起来，k8s带来的优势似乎很多很多。
当前部门业务有2个特点，一个是新业务流量较低，一个是考虑私有化部署。
流量低也就意味着大量服务开启2个pod，但使用率低下，且没有扩容场景。服务治理限于日志、指标、链路追踪等，不需要更复杂的治理场景。
私有化部署意味着客户的服务器资源有限，且客户不需要依赖云厂商的基建服务。客户的网络情况可能没互联网公司这么清晰。
举个例子，公司语音服务私有化部署遇到的问题，第一是基于minikube部署服务，发现minikube占用大量资源导致服务器资源不够用。第二是k8s的网络问题导致服务迟迟访问不了，需要不断的排查dns解析和网桥。 最终解决方案是使用docker compose的部署，占用资源低，网络要求低，一把起来。
分析完业务，那么问题来了，不使用k8s可以吗？ 如果我的场景流量比较固定，那么我就不需要动态扩展pod。如果我的服务不需要那么多云原生插件，那么整个k8s容器服务对我来说是不是就过于笨重了呢？如果私有化部署，k8s丰富的生态对我来说是不是累赘呢？
可以参考这篇文章：你是否真的思考过自己的业务模式是否真的需要k8s
参考：https://www.predicagroup.com/blog/why-kubernetes-2022/
成本这个可以参考Ruby on Rails作者的博客，他们是做邮件服务的，业务比较稳定，流量也基本可控。云厂商的账单让他们逐渐产生疑惑，最终他们选择来离开aws。结果是一年预计节省100w美金。。。
Why we’re leaving the cloud
Our cloud exit has already yielded $1m/year in savings
都2023年了，硬件成本特别是存储设备的价格也下降不少，小型计算机的配置逐渐提升，且价格合理。那么核心且流量大的服务，可以使用自建服务器。内部服务或者小流量的服务，使用apple mini或者小型计算机是不是就ok了呢？比如博主的英特尔NUC，i512代cpu+16GB内存，跑几个内部后台服务绰绰有余，3000块的成本仍到机房，相比云厂商服务的每月收费来说，便宜太多了。
就算是使用GPU的算法服务，性能要求不高的场景下，apple的m2芯片也足以胜任了，问题applemini的成本才多高？使用阿里云的A10卡，每个月就要6k+，一年下来7w。。
k8s只是一种方案，我们可能基于某种原因选择了k8s，而不是说我们只能和必须选择k8s。
对开发人员来说，服务不是开发完就结束的，部署方案是必须要考虑的部分，可能大家现在好像都默认使用云厂商的k8s服务，连第二方案都没考虑。。。（这一条更针对架构师这种角色）
开发人员逐渐丧失了对于成本的敏锐性，对自己的服务可能需要多少成本，带来多少收益，甚至支撑多少业务量都不知道，问就是运维在负责，不清楚。
对自己手头的业务以及整个项目的思考太少。如果部门目标是C端和B端，那么使用统一使用云厂商更适合C端的服务，但是B端交付的部署方案呢？去掉k8s和云原生的组件，你的服务还能跑起来了吗？替代方案有吗？
社会分工是越来越精细的，例如新能源车，上游专供各个组件，下游厂商进行统一的组装，精细化和专业化是趋势也是资源分散的方式。
集约更体现在面向人的场景，例如大型超市，早就不单单是卖货了，是销售，广告，娱乐一体化的综合性经营场所，是资源集中的方式。
互联网发展这么多年，岗位类别越来越多，前端，后端，算法，测试，运维等等。大家都更关注眼前的一亩三分地，超出部分就不了解或者细节被屏蔽，大大增加了沟通成本。微前端， 微服务的产生又让相同岗位之间产生巨大的沟通成本。。。 如果场景适合回归到单体应用的话，是否代表超级个体的时代又要回来了呢？ ？
底层细节的屏蔽确实带来了方便，某种意义上也带来了技术上的掌控力下降。团队没有大牛的情况下，不出问题就算了，出问题就是大问题，普通开发人员对于k8s的熟悉度不够，排查问题的难度也提升不少。
国内互联网从无序扩张到现在存量市场，除了新兴方向的业务会大量增长，那么是否有相当一部分业务都是“可预见”的呢？或者业务已经是稳定的状态了？
稳定的业务或者可预见的用户增长，是否代表回归机房才是最佳选择呢？ 成本？可维护性？甚至是：单体应用–>微服务–>单体应用 ?
有点三国的味道了，未来究竟会如何谁也不知道。就像金融市场很多时候是用脚投票一样，广大互联网公司也会逐渐选择最适合自己的方式吧。
以上部分更多是探讨性质的，但是也能看出来，面向B端和面向流量稳定的服务来说，自建服务器和容器部署也是不错的方案，部署方式简单且成本低了。
但是，针对流量较大的业务，例如电商业务来说，使用云厂商的k8s服务依然是最佳选择。云原生的丰富生态更有利于保证大型服务的稳定性。
所以仁者见仁智者见智了，抛开业务模式谈部署也是耍流氓，关键是我们要拔高思维层次，尽量考虑的全面。凡事有plan B才能波澜不惊，才能成为别人眼中靠谱的大佬。
end