赞
踩
这篇文章来源于一次内部讨论,大家突然聊到为什么要用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
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。