这是一个创建于 1104 天前的主题，其中的信息可能已经有所发展或是发生改变。
新人问一下： 自动扩缩 pod 不都是基于物理主机现有资源吗？而物理主机的资源都是预付费了的，缩到 1 个和 20 个都不会影响成本啊？难道这句只能是云原生吗？还是说在云上的话有办法自动帮你购买主机然后添加进 Node 里面，缩的时候自动帮你把按量付费的主机释放了？？
 | 1 qiyuey 2022-10-06 22:59:19 +08:00 节省了造轮子的研发人员 |
 | 2 orFish 2022-10-06 23:03:30 +08:00 |
 | 3 momocraft 2022-10-06 23:05:52 +08:00 资源总量不变 也可能因为调度而增加利用率 比如用空闲资源跑允许中断的任务 |
 | 4 cs3230524 OP 那只能在 pod 层面意义不是很大啊，我还是得自己提前买主机放到集群里咯？ |
 | 5 lhx2008 2022-10-06 23:12:51 +08:00 云上的玩法当然是可以扩缩节点的，直接装到物理机上面的话可以考虑加上云上的节点。另外，如果程序数量少的话，只会增本。 |
 | 6 learningman 2022-10-06 23:15:09 +08:00 你自己不是把答案说出来了吗，你猜为啥云厂商要精确到按秒计费 |
 | 7 fisherwei 2022-10-06 23:18:58 +08:00 这话题说起来可大了。 简单来说，你可以把 k8s 简单理解为一个毛坯房，8s 为你的业务提供了缩放服务、健康检查、（微）服务级的负载均衡、基于容器技术的交付等等，可以开箱即食，也可以让 devops 针对业务需求二开。 当然这些能力，都是基于你现有的物理机、虚拟机等计算资源实现的。 如果你的运维团队可以 7*24 无休的手工处理这些运维事务的话，k8s 并不能帮你节省计算资源，但是这样的运维团队开销显然比部署一套 k8s 要贵多了。 类似的，CI/CD 也是一样，这些工作完全可以由运维手动来做，但是当你的业务数量增长、迭代加速之后，需要维持一个庞大的运维团队来做交付、部署工作。 所以，粗略来说，这就是 k8s 降本增效的原理。 |
 | 8 novolunt 2022-10-07 00:09:03 +08:00 对研发 降成本，暂时看不出来，量大，该多少内存多少 cpu 一个不拉，java 的坑并没有改善 提高效率，也看不出来，代码量还是那么多，跟业务无关，何来增效 对 DevOps 用的 helm+gitlab-ci +ingress/istio 前期投入比较大，后期几乎完全自动化，做更多的反而是 efk+prometheus 总体来讲，对研发增加工作量，对运维，前期增加工作量，后期变成看监控的技术员。有利于业务的健壮性，其他无 |
 | 10 dayeye2006199 2022-10-07 00:31:25 +08:00 即使物理机都是你的也可以降低成本。你本来的机器利用率是 50%，跑 10 个任务假设需要 16 台机器。 现在用了 k8s ，机器利用率提升到 80%，现在跑同样的任务量，你只需要 10 台机器。 这样在采购机器的时候，就可以少买机器，电费和维护费用也会降低。 提高利用率也是降低成本的一种 |
 | 11 cctv6 2022-10-07 00:42:46 +08:00 可能在某些大规模的集群场景下，通过对资源的调度，可以更加充分的把一些节点上过剩的计算资源重新利用上，也算是一种降低成本的体现。 |
 | 12 xy90321 2022-10-07 01:20:09 +08:00 via iPhone 不要把软件层面的问题和硬件层面的问题过分耦合来考虑，也不要把问题给扩大化 自动扩缩需要解决的问题，不是扩缩以后怎么办，而只是单纯的把扩缩的过程尽量自动化 另外，不是因为用了 K8s ，所以调度效率提高后的剩余资源就可以自动换钱了。 而是因为在调度效率提高后剩余资源可以换钱（不管是退记成本还是划作他用）的前提下，所以才去用 K8s 。 如果像你说的空出来的资源也没能力换钱的话，那么在这个场景下，是不是自动扩缩也确实不影响成本开支。 |
 | 13 nulIptr 2022-10-07 01:21:59 +08:00 还是说在云上的话有办法自动帮你购买主机然后添加进 Node 里面，缩的时候自动帮你把按量付费的主机释放了？？ --- 阿里云的 k8s 确实有这个解决方案，最近花了点时间测了一下也能达到文档说的效果，不过目前还没上生产环境。 对于需要大量 gpu 节点的服务还是有点用的。 |
 | 14 soclearn 2022-10-07 03:24:51 +08:00 这是针对专业研究和部署人员说的。因为它可以自动化，接上 devops ，还可以集群伸缩。 对于普通人员，没有所谓的增本降效 |
 | 15 slowman 2022-10-07 03:33:45 +08:00 可以砍掉 k8s 之前自研的系统了，运维减少，开发裁撤。省钱 |
 | 16 JaxXu 2022-10-07 08:46:34 +08:00 混合部署，之前很麻烦啊，而且利用率不高 |
 | 17 winglight2016 2022-10-07 09:01:36 +08:00 lz 首先要有集群思维，如果只有单机、单实例部署的经验，那 k8s 只是负担，如果有过集群部署，那就能体会到 k8s 有多么方便了。 其次，k8s 是屏蔽了硬件信息的，就像 ORM 对开发人员屏蔽了表结构，以后的趋势也是越来越专业化，开发人员不再关心部署的事情，只要做好业务实现即可。部署也不再关注要购买几台 VPS ，自动伸缩购买节点是可以实现，但是需要预付费。 最后，k8s 初期投入很大，我在公司项目推 k8s ，一个多月了生产环境还没有迁移过去，开发人员也需要时间理解 k8s 的概念。 |
 | 18 xzysaber 2022-10-07 10:02:45 +08:00 对于大规模部署来说确实非常方便，减少很多心智负担。 对于资源管理来说支持各种 autoscaler(包括自定义指标)，但是这块想要做好，还是需要不少功夫的。 |
 | 19 Alliot 2022-10-07 11:57:20 +08:00 首先，k8s 拥有容器的几乎所有优势，资源隔离， 资源颗粒度细化，在其基础上拥有完善的资源缩放，健康检查，流量与资源的负载均衡，调度。 至于你说的 自动帮你购买主机然后添加进 Node 里面，缩的时候自动帮你把按量付费的主机释放了。 几大云厂商都有这种服务，自己也可以通过接口与脚本实现。 另外就是对于突发的无状态型任务，完全可以调度到按量付费的虚拟节点上，虚拟节点按照你负载实际使用的资源来收费。 k8s 的降本增效，适用于中大规模，一俩个节点上 k8s 没必要。强行 k8s == 然并卵 |
 | 20 lancel 2022-10-07 14:34:23 +08:00 资源的自动调度，在增加资源利用率同时缩减运维成本。转对大规模部署 |
 | 21 SteveWoo 2022-10-07 15:15:14 +08:00 ：因为 k8s 火，高端文案一堆，背背概念到老板那里刷存在感。 对于一般的公司，或者说业务不存在突增突减的公司，没鸟用。 云主机公司推 k8s 因为粒度更细，新的收费项目。 扯一堆名词鬼玩意，啥自动扩缩、资源缩放，健康检查、负载均衡调度。 上个年系统总线的架构早就玩的很溜了。 |
 | 22 exkernel 2022-10-07 16:24:50 +08:00 腾讯云的 EKS, 就是按 pod 动态扩容 node 的 |
| 23 cs3230524 OP |
| 24 novolunt 2022-10-07 21:49:45 +08:00 @cs3230524 也是 k8s, k8s 还是要学，这是基础。然后各个厂商的服务还是要学。 厂商的主要是看 dns 和 storage class ，就是网络和存储，都有自己定制的功能，填补开源部分的空白。 |
| 25 cs3230524 OP @novolunt 技术学习 k8s 的话，你觉得需要细到什么程度。部署个面板能跑项目就 ok ？还是说必须很熟悉那些原始指令？ |
| 26 novolunt 2022-10-07 22:13:44 +08:00 |
 | 27 julyclyde 2022-10-08 10:23:58 +08:00 如果都是自有资产 /预付费资产，确实省不出什么资源，只是能提高部署效率而已 但如果不是预付费资产呢？ 举个例子，某东南亚电商企业，自有集群和某云相连，每次促销的时候就从云那边租一批机器来扩容，用完就退了 |
 | 28 qW7bo2FbzbC0 2022-10-08 10:57:32 +08:00 对阿里来说，双 11 如果都大促的话，应该还是没有空余资源可以调度？那成本节省在哪里？ |
 | 29 lazyfighter 2022-10-08 11:43:57 +08:00 @qW7bo2FbzbC0 弹性扩缩容的成本节省，省的是不必要的资源，16C32G 的资源 ，分给两个应用，为了确保应用在高峰期流量的平稳， 双方可能需要 10C 16G 的资源，如果直接 VM 是不是资源不够，需要申请资源，有了弹性扩缩容，可以根据流量的峰值进行动态分配，可以解决资源问题。 |
 | 30 LIYUNFAN 2022-10-08 11:48:28 +08:00 @cs3230524 看你角色呀。 普通业务无需关注； 业务运维会用上层平台就行； 集群运维会命令操作底层集群、对集群进行一定的故障分析； 集群设计研发人员需要对集群各个组件（ kubelet 、controller-manager 、kube-scheduler 等等）的工作流程熟悉，可协助集群运维人员分析解决问题，也要可以根据场景设计控制器增强集群能力。更高点的要求的话，还要对集群运行的各个组件的代码有一定了解，给时间能通过看代码分析问题解决问题。 |
 | 31 yyttrr 2022-10-10 17:01:34 +08:00 业务在发展，会不断的有新服务部署，老服务下线。服务直接的调用关系也在发生变化，有些服务今天可能只有要 0.2 核过几天就要 100 核甚至更多 |
Select Language