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

是否有必要用 K8S

  •  3
     
  •   beryl · 2021-06-02 20:29:40 +08:00 · 19545 次点击
    这是一个创建于 1279 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司是做 ToB 私有化部署,预估每个月有 5-10 个项目,产品加上中间件 大约十几个进程,有专门的交付同学,需要交付部署。现在方案是采用 docker 容器方式,准备上 K8S 。

    但是老板今天质疑为什么要上 K8S,主要是两点:

    1. 多了 K8S, 部署的时候服务资源就要多占用,毕竟 K8S 本身也需要资源
    2. K8S 能够带来哪些显著收益

    这两个问题也是自己在纠结的,同时也在想 K8S 能够带来什么,交付更快?

    第 1 条附言  ·  2021-06-03 10:57:25 +08:00
    补充一点:

    也不一定非要说服老板用 K8S
    站在自己的角度也是哪个对产品对公司更实际用,就用哪个
    109 条回复    2022-08-19 11:02:27 +08:00
    1  2  
    dany813
        101
    dany813  
       2021-06-06 12:55:47 +08:00
    我们私有部署都是,zip 一把梭
    tottea
        102
    tottea  
       2021-06-06 13:53:36 +08:00
    docker-compose 应付这种场景我理解是已经足够了吧
    calmzhu
        103
    calmzhu  
       2021-06-06 14:23:50 +08:00
    @plko345 就是周期性换密码。比如每个月换一下所有线上服务的密码 /token 之类
    axeprpr1
        104
    axeprpr1  
       2021-06-06 21:33:16 +08:00
    HA?
    ManjusakaL
        105
    ManjusakaL  
       2021-06-06 22:28:39 +08:00
    私有化何苦 K8S ?

    你说你做容器化是为了产物交付方便我理解,用 K8S 图啥?如果没有非常复杂的场景
    wangyzj
        106
    wangyzj  
       2021-06-07 11:01:30 +08:00
    上 k8s 后 ppt 上可以写的很帅
    可以要更多钱
    可以吹更多牛逼
    可以完成更多 kpi
    可以。。。。
    piping
        107
    piping  
       2021-07-14 10:31:49 +08:00
    make install + systemd unit.service 就好了。。。资源分配,当机重启都很简单
    Arcy
        108
    Arcy  
       2021-07-22 17:16:00 +08:00
    认真审题后
    每个月有 5-10 个项目
    那一年下来每月按 7 个项目 一年 84 个项目
    这样的增长量
    k8s 会更好点吧
    虽说私有化部署
    你们这边也还是要做测试环境的管理的呀
    至于客户方按什么方案部署,那就看客户方的情况来定呀
    workingpad2
        109
    workingpad2  
       2022-08-19 11:02:27 +08:00
    走个 500 米的路要啥自行车。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5882 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 03:02 · PVG 11:02 · LAX 19:02 · JFK 22:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.