V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
cs3230524
V2EX  ›  Kubernetes

很多博主说的 K8S“降本增效”的体现在哪里?

  •  
  •   cs3230524 · 2022-10-06 22:58:37 +08:00 · 4729 次点击
    这是一个创建于 779 天前的主题,其中的信息可能已经有所发展或是发生改变。

    新人问一下: 自动扩缩 pod 不都是基于物理主机现有资源吗?而物理主机的资源都是预付费了的,缩到 1 个和 20 个都不会影响成本啊?难道这句只能是云原生吗?还是说在云上的话有办法自动帮你购买主机然后添加进 Node 里面,缩的时候自动帮你把按量付费的主机释放了??

    31 条回复    2022-10-10 17:01:34 +08:00
    qiyuey
        1
    qiyuey  
       2022-10-06 22:59:19 +08:00
    节省了造轮子的研发人员
    orFish
        2
    orFish  
       2022-10-06 23:03:30 +08:00
    momocraft
        3
    momocraft  
       2022-10-06 23:05:52 +08:00
    资源总量不变 也可能因为调度而增加利用率

    比如用空闲资源跑允许中断的任务
    cs3230524
        4
    cs3230524  
    OP
       2022-10-06 23:11:14 +08:00
    那只能在 pod 层面意义不是很大啊,我还是得自己提前买主机放到集群里咯?
    lhx2008
        5
    lhx2008  
       2022-10-06 23:12:51 +08:00
    云上的玩法当然是可以扩缩节点的,直接装到物理机上面的话可以考虑加上云上的节点。另外,如果程序数量少的话,只会增本。
    learningman
        6
    learningman  
       2022-10-06 23:15:09 +08:00
    你自己不是把答案说出来了吗,你猜为啥云厂商要精确到按秒计费
    fisherwei
        7
    fisherwei  
       2022-10-06 23:18:58 +08:00
    这话题说起来可大了。

    简单来说,你可以把 k8s 简单理解为一个毛坯房,k8s 为你的业务提供了缩放服务、健康检查、(微)服务级的负载均衡、基于容器技术的交付等等,可以开箱即食,也可以让 devops 针对业务需求二开。
    当然这些能力,都是基于你现有的物理机、虚拟机等计算资源实现的。

    如果你的运维团队可以 7*24 无休的手工处理这些运维事务的话,k8s 并不能帮你节省计算资源,但是这样的运维团队开销显然比部署一套 k8s 要贵多了。

    类似的,CI/CD 也是一样,这些工作完全可以由运维手动来做,但是当你的业务数量增长、迭代加速之后,需要维持一个庞大的运维团队来做交付、部署工作。

    所以,粗略来说,这就是 k8s 降本增效的原理。
    novolunt
        8
    novolunt  
       2022-10-07 00:09:03 +08:00
    对研发
    降成本,暂时看不出来,量大,该多少内存多少 cpu 一个不拉,java 的坑并没有改善
    提高效率,也看不出来,代码量还是那么多,跟业务无关,何来增效
    对 DevOps
    用的 helm+gitlab-ci +ingress/istio
    前期投入比较大,后期几乎完全自动化,做更多的反而是 efk+prometheus
    总体来讲,对研发增加工作量,对运维,前期增加工作量,后期变成看监控的技术员。有利于业务的健壮性,其他无
    novolunt
        9
    novolunt  
       2022-10-07 00:10:31 +08:00
    @cs3230524 很多厂商是有自动扩容的,比如微软云,可以自动扩容,最大两千多台
    dayeye2006199
        10
    dayeye2006199  
       2022-10-07 00:31:25 +08:00
    即使物理机都是你的也可以降低成本。你本来的机器利用率是 50%,跑 10 个任务假设需要 16 台机器。
    现在用了 k8s ,机器利用率提升到 80%,现在跑同样的任务量,你只需要 10 台机器。

    这样在采购机器的时候,就可以少买机器,电费和维护费用也会降低。
    提高利用率也是降低成本的一种
    cdlnls
        11
    cdlnls  
       2022-10-07 00:42:46 +08:00
    可能在某些大规模的集群场景下,通过对资源的调度,可以更加充分的把一些节点上过剩的计算资源重新利用上,也算是一种降低成本的体现。
    xy90321
        12
    xy90321  
       2022-10-07 01:20:09 +08:00 via iPhone
    不要把软件层面的问题和硬件层面的问题过分耦合来考虑,也不要把问题给扩大化

    自动扩缩需要解决的问题,不是扩缩以后怎么办,而只是单纯的把扩缩的过程尽量自动化

    另外,不是因为用了 K8s ,所以调度效率提高后的剩余资源就可以自动换钱了。

    而是因为在调度效率提高后剩余资源可以换钱(不管是退记成本还是划作他用)的前提下,所以才去用 K8s 。

    如果像你说的空出来的资源也没能力换钱的话,那么在这个场景下,是不是自动扩缩也确实不影响成本开支。
    nulIptr
        13
    nulIptr  
       2022-10-07 01:21:59 +08:00
    还是说在云上的话有办法自动帮你购买主机然后添加进 Node 里面,缩的时候自动帮你把按量付费的主机释放了??
    ---
    阿里云的 k8s 确实有这个解决方案,最近花了点时间测了一下也能达到文档说的效果,不过目前还没上生产环境。
    对于需要大量 gpu 节点的服务还是有点用的。
    soclearn
        14
    soclearn  
       2022-10-07 03:24:51 +08:00
    这是针对专业研究和部署人员说的。因为它可以自动化,接上 devops ,还可以集群伸缩。

    对于普通人员,没有所谓的增本降效
    1423
        15
    1423  
       2022-10-07 03:33:45 +08:00
    可以砍掉 k8s 之前自研的系统了,运维减少,开发裁撤。省钱
    JaxXu
        16
    JaxXu  
       2022-10-07 08:46:34 +08:00
    混合部署,之前很麻烦啊,而且利用率不高
    winglight2016
        17
    winglight2016  
       2022-10-07 09:01:36 +08:00
    lz 首先要有集群思维,如果只有单机、单实例部署的经验,那 k8s 只是负担,如果有过集群部署,那就能体会到 k8s 有多么方便了。
    其次,k8s 是屏蔽了硬件信息的,就像 ORM 对开发人员屏蔽了表结构,以后的趋势也是越来越专业化,开发人员不再关心部署的事情,只要做好业务实现即可。部署也不再关注要购买几台 VPS ,自动伸缩购买节点是可以实现,但是需要预付费。
    最后,k8s 初期投入很大,我在公司项目推 k8s ,一个多月了生产环境还没有迁移过去,开发人员也需要时间理解 k8s 的概念。
    xzysaber
        18
    xzysaber  
       2022-10-07 10:02:45 +08:00
    对于大规模部署来说确实非常方便,减少很多心智负担。
    对于资源管理来说支持各种 autoscaler(包括自定义指标),但是这块想要做好,还是需要不少功夫的。
    Alliot
        19
    Alliot  
       2022-10-07 11:57:20 +08:00
    首先,k8s 拥有容器的几乎所有优势,资源隔离, 资源颗粒度细化,在其基础上拥有完善的资源缩放,健康检查,流量与资源的负载均衡,调度。

    至于你说的 自动帮你购买主机然后添加进 Node 里面,缩的时候自动帮你把按量付费的主机释放了。 几大云厂商都有这种服务,自己也可以通过接口与脚本实现。

    另外就是对于突发的无状态型任务,完全可以调度到按量付费的虚拟节点上,虚拟节点按照你负载实际使用的资源来收费。

    k8s 的降本增效,适用于中大规模,一俩个节点上 k8s 没必要。强行 k8s == 然并卵
    lancel
        20
    lancel  
       2022-10-07 14:34:23 +08:00
    资源的自动调度,在增加资源利用率同时缩减运维成本。转对大规模部署
    SteveWoo
        21
    SteveWoo  
       2022-10-07 15:15:14 +08:00
    :因为 k8s 火,高端文案一堆,背背概念到老板那里刷存在感。

    对于一般的公司,或者说业务不存在突增突减的公司,没鸟用。
    云主机公司推 k8s 因为粒度更细,新的收费项目。
    扯一堆名词鬼玩意,啥自动扩缩、资源缩放,健康检查、负载均衡调度。 上个年系统总线的架构早就玩的很溜了。
    exkernel
        22
    exkernel  
       2022-10-07 16:24:50 +08:00
    腾讯云的 EKS, 就是按 pod 动态扩容 node 的
    cs3230524
        23
    cs3230524  
    OP
       2022-10-07 21:22:49 +08:00
    @novolunt @nulIptr 所以 k8s 和各大云服务商的容器服务器是两个东西咯?如果所有业务都必须基于那些云服务商,那还有必要学 k8s 么?这种场景下我理解他们自己的容器服务才更合适吧?
    novolunt
        24
    novolunt  
       2022-10-07 21:49:45 +08:00
    @cs3230524 也是 k8s, k8s 还是要学,这是基础。然后各个厂商的服务还是要学。
    厂商的主要是看 dns 和 storage class ,就是网络和存储,都有自己定制的功能,填补开源部分的空白。
    cs3230524
        25
    cs3230524  
    OP
       2022-10-07 22:08:57 +08:00
    @novolunt 技术学习 k8s 的话,你觉得需要细到什么程度。部署个面板能跑项目就 ok ?还是说必须很熟悉那些原始指令?
    julyclyde
        27
    julyclyde  
       2022-10-08 10:23:58 +08:00
    如果都是自有资产 /预付费资产,确实省不出什么资源,只是能提高部署效率而已
    但如果不是预付费资产呢?

    举个例子,某东南亚电商企业,自有集群和某云相连,每次促销的时候就从云那边租一批机器来扩容,用完就退了
    qW7bo2FbzbC0
        28
    qW7bo2FbzbC0  
       2022-10-08 10:57:32 +08:00
    对阿里来说,双 11 如果都大促的话,应该还是没有空余资源可以调度?那成本节省在哪里?
    lazyfighter
        29
    lazyfighter  
       2022-10-08 11:43:57 +08:00
    @qW7bo2FbzbC0 弹性扩缩容的成本节省,省的是不必要的资源,16C32G 的资源 ,分给两个应用,为了确保应用在高峰期流量的平稳, 双方可能需要 10C 16G 的资源,如果直接 VM 是不是资源不够,需要申请资源,有了弹性扩缩容,可以根据流量的峰值进行动态分配,可以解决资源问题。
    LIYUNFAN
        30
    LIYUNFAN  
       2022-10-08 11:48:28 +08:00
    @cs3230524
    看你角色呀。

    普通业务无需关注;
    业务运维会用上层平台就行;
    集群运维会命令操作底层集群、对集群进行一定的故障分析;
    集群设计研发人员需要对集群各个组件( kubelet 、controller-manager 、kube-scheduler 等等)的工作流程熟悉,可协助集群运维人员分析解决问题,也要可以根据场景设计控制器增强集群能力。更高点的要求的话,还要对集群运行的各个组件的代码有一定了解,给时间能通过看代码分析问题解决问题。
    yyttrr
        31
    yyttrr  
       2022-10-10 17:01:34 +08:00
    业务在发展,会不断的有新服务部署,老服务下线。服务直接的调用关系也在发生变化,有些服务今天可能只有要 0.2 核过几天就要 100 核甚至更多
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2641 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 02:58 · PVG 10:58 · LAX 18:58 · JFK 21:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.