这是一个创建于 1269 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司是做 ToB 私有化部署，预估每个月有 5-10 个项目，产品加上中间件 大约十几个进程，有专门的交付同学，需要交付部署。现在方案是采用 docker 容器方式，准备上 K8S 。
但是老板今天质疑为什么要上 K8S，主要是两点：
- 多了 K8S, 部署的时候服务资源就要多占用，毕竟 K8S 本身也需要资源
- K8S 能够带来哪些显著收益
这两个问题也是自己在纠结的，同时也在想 K8S 能够带来什么，交付更快？
第 1 条附言 · 2021-06-03 10:57:25 +08:00
补充一点：
也不一定非要说服老板用 K8S
站在自己的角度也是哪个对产品对公司更实际用，就用哪个
也不一定非要说服老板用 K8S
站在自己的角度也是哪个对产品对公司更实际用，就用哪个
 |
1
chenqh 2021-06-02 20:33:54 +08:00
这种私有化部署的 docker, registry 哪里来的? registry 也是自己搭建吗?
|
 |
2
whileFalse 2021-06-02 20:33:55 +08:00 via iPhone
docker-compose/swarm 也不是不能用…
|
 |
3
Itanium 2021-06-02 20:34:45 +08:00
先上 k3s 试个点，k8s 水太深不一定把握的住
|
 |
4
beryl OP |
 |
5
cz5424 2021-06-02 20:47:03 +08:00
我司目前为了省事直接用阿里云的 k8s 了
|
 |
7
plko345 2021-06-02 21:20:56 +08:00 via Android
我觉得小规模没必要，k8s 那么多组件，那么多细节要了解，需要的配套基础设施也不少，不过还是很稳定的，能 hold 住也能上，但没必要
|
|
8
beryl OP @plko345 但是如果不上 K8S， 服务部署交付的时候成本挺大的吧，每天机器都要执行脚本部署不同的进程，还要设置资源分配
|
 |
9
andstack 2021-06-02 21:33:36 +08:00
这点项目上 K8S 还早了点
|
 |
11
napsterwu 2021-06-02 21:40:22 +08:00 via iPhone
k8s+helm 模版部署呀，一般 ci/cd 都支持的吧。而且私有 registry 也不是很难，我司一个只有内网的公司都可以正常开发，用的是 Harbor 。
|
|
13
napsterwu 2021-06-02 21:41:32 +08:00 via iPhone
反正运维老大说了算呗，看他愿不愿意每个环境每次部署都要找他跑一下 docker run
|
 |
14
ysjiang4869 2021-06-02 21:41:39 +08:00 via Android
只针对一个公司，几台服务器，还是 docker-compose 吧，k8 不值得折腾的
|
 |
15
12101111 2021-06-02 21:46:37 +08:00
k8s 并不会占用很多资源, 尤其是没有任何运维操作时
|
|
16
beryl OP @ysjiang4869 但是需要频繁部署交付项目，大项目可能需要几十台，小项目需要几台
K8S 是不是交付起来更方便 |
 |
19
calmzhu 2021-06-02 22:01:42 +08:00 via Android  3
有下面需求 建议上 k8s 。下面需求都可以自己二开实现，但是工作量不比维护 k8s 少。
k8s 的定义是云操作系统,不是基础硬件设施。操作系统上开发应用总比裸机方便。 1.CD 持续部署，k8s 自带机制可以省很多事情。比如蓝绿部署减少当机时间;测试开发过程中防止单个应用部署失败造成其他人工作中断。 2.多个环境的频繁创建维护，甚至动态部署一套全新的应用。 3. 配置以及密码的集中管理和密码的定期轮换 4. 可视化展示交互需求。比如获取应用状态信息。k8s 本身 api 交互就比 docker compose 方便 |
|
20
beryl OP @calmzhu 这些感觉我们这个可能都用不到，因为现在主要是私有化部署。
我能想到的一点是，如果不用 K8S 部署，我们需要规划每台机器的需要 部署什么类型服务，然后再分别在每天机器上去启动部署脚本 然后机器之间还需要更改配置去调试，以及每次代码还需要改动中间件的配置 不知道这个算不算我们当前场景，依赖 K8S 的优势 |
|
22
calmzhu 2021-06-02 22:34:57 +08:00 via Android
@beryl 存粹 toB 不高频私有化部署的话。个人觉得 docker-compose pxe/系统自定义镜像+hook 脚本更好 。k8s 优势在于可以把各种变更的成本降低到极致之后，做一些高抽象层级的事更方便
|
|
24
12101111 2021-06-02 22:40:49 +08:00
@beryl 单节点建议改用 k3s, k8s 至少 3 节点吧
Pod 数量一般两位数, 一位数就高射炮打蚊子了,三位数没有 CPU 带的动, 至于是十几个还是几十个,那就看 CPU 和内存配置了 |
 |
25
lucays 2021-06-02 22:53:49 +08:00
k8s 细节太复杂了，，我前公司把握不住后来换回 docker-compose 了
|
 |
26
djoiwhud 2021-06-02 23:45:27 +08:00 via Android 9
面向练手编程。
应届生:什么新，什么高大上，怎么搞。毕竟只看一下博客写高大上的技术心里没底。搞黄了企业可以再找工作 double 一下。 老员工:什么简单稳定用什么，毕竟瞎搞公司黄了要找工作。 |
 |
27
mazyi 2021-06-03 00:02:56 +08:00 via iPhone
k8s 比几十个进程复杂几十倍。。。
|
 |
29
zqcolor 2021-06-03 00:15:13 +08:00
应该要上，之后跳槽简历好看很多
用上 helm chart 后，ci cd 很方便 |
 |
30
mooyo 2021-06-03 00:19:12 +08:00
你们现有的服务会需要经常进行调整么？
目前的发版流程方便么？ 常规发布是无损的么？ 上了 k8s 以后还能比较方便的对不同服务进行扩缩容，也可以考虑下这些是不是你们现在的痛点。 |
|
31
mooyo 2021-06-03 00:20:54 +08:00
上 k8s 不一定会导致复杂性的增加，常规使用并不需要用到高级特性，只需要有一个能 cover 住的人搞定环境其他人上去点点点就行。 但是服务多起来以后会有其他额外的问题需要考虑....以及你现有的服务是不是可以比较方便的改造成适合 k8s 部署的状态。
|
 |
32
dayeye2006199 2021-06-03 01:31:46 +08:00 3
给你老板看看这个：F16 战斗机里面跑 k8s - https://www.cncf.io/blog/2020/05/07/with-kubernetes-the-u-s-department-of-defense-is-enabling-devsecops-on-f-16s-and-battleships/
如果你们交付都在一台机器上，只是想用容器，推荐 docker-compose ； 如果你们需要在私有网络内多机部署，推荐轻量级 k3s 如果你们在公有云上部署，推荐云厂商提供的 managed k8s k8s 的一些好处： * 持续交付速度比较快，原生支持 zero downtime 部署 * 原生支持配置中心 * 周边生态比较丰富，如果需要动态服务伸缩，监控，日志等服务，都有比较成熟的周边产品 但推荐至少团队里面得有一个老司机对这块比较熟悉，否则至少得做一下 POC，一下直接上生产环境，在 deadline 的逼迫下会比较挣扎。 |
 |
33
ReferenceE 2021-06-03 02:50:48 +08:00 via Android
K8S 这业务量没必要，框架学习成本远大于收益
|
 |
34
kennylam777 2021-06-03 04:53:24 +08:00
證明你公司的東西太簡單.....有時候用簡單的 docker-compose 做 deployment，health-check 麻煩點太多而且不好 scale，果斷換回 k8s 。
雖然 k8s master 節點也是資源，但三台 4GB RAM+的機器面對業務來說不是錢吧。要不就上 EKS 一類的 managed k8s 。 |
 |
35
zenwong 2021-06-03 06:18:08 +08:00
老板想用，所以有必要。
|
 |
36
holulu 2021-06-03 07:01:42 +08:00
看实际情况，如果没几十上百个微服务要管理就没必要。服务数量少，维护 k8s 的成本比管理服务还要高。
|
 |
37
xuanbg 2021-06-03 07:04:27 +08:00 1
私有化部署不是发布到客户的服务器上面吗？服务器资源不是客户提供？不知道你们老板为啥要纠结资源的问题。
如果是动态范围不是很大的，需要随时自动横向扩展 /收缩的，k8s 就完全没有必要了。增加无谓的复杂度，提高运维的工作量。直接 docker run 也不是不行。反正我的经验是，只要脚本写好，就是一个命令的事情，要什么 k8s 。 |
 |
39
csdreamdong 2021-06-03 09:01:27 +08:00
@xuanbg 强烈赞同！
|
 |
40
Rwing 2021-06-03 09:03:12 +08:00
我觉得可以用，不要被吓到，其实没那么难，你又不进行二次开发，只是使用而已，找一个专门的人专门运维这一块就可以了
|
 |
41
jorneyr 2021-06-03 09:03:33 +08:00
只说优点: 对于无状态的 Web 服务，k8s 可以保证服务的高可用，例如进程挂了 k8s 自动给拉起来，否则需要管理员发现进程挂了去手动启动程序。只需要用 yaml 文件在 master 上部署，不需要自己去手动一个一个的到目标机器上部署，部署简单。
|
 |
42
fannas 2021-06-03 09:09:50 +08:00 via iPhone
面向老板和薪水实施哈
|
 |
43
star7th 2021-06-03 09:16:23 +08:00
私有化部署不是很有必要一定上 k8s 太重了。如果是你们提供公有服务的话，使用 k8s 就十分合适。
|
 |
44
defunct9 2021-06-03 09:24:33 +08:00
没有必要
|
 |
45
zone10 2021-06-03 09:49:57 +08:00
k8s 节省的是程序员成本, 你在心疼机器成本那就没必要
|
 |
46
sangs 2021-06-03 09:56:21 +08:00 6
巧了, 我也是做交付的 (可以加个好友). 目前在用 k8s. 呃, 一直都是 k8s, 就没用过别的.
k8s 的优势: [1] 使用 helm chart 一键拉起整套环境 (我们有 30 多个应用) [2] 可以使用 helm chart 应用商店, 可以 [3] 公私有云下, 都可以直接购买 k8s [4] k8s 带界面, 可以使用 k8s-dashboard, rancher 或者云服务控制台的界面, 对于研发来说, 更新代码非常迅速 [5] CI/CD 方便, 写完代码, 直接提交到 gitlab, 驱动 jenkins 打包, 直接推送到 k8s 集群 k8s 的劣势: [1] 维护成本高, 门槛高. 想象一下, master 节点报错了, 你们运维不知道怎么处理, 老板慌不慌. 我们是配有 k8s 专家的, 所以这个问题不是很大 [2] 本身需要资源 至少需要 2 台 4c8g 的. 这个每年得多花 1 万块钱吧. 我们 toB 的都是大客户, 对价格不敏感, 这点钱不算啥 我认为, 10 个应用以内用 docker-compose 吧, 反正简单, 随便搞都行. 10+ (像我们 30+) 应用的, 只能用 k8s 了 |
 |
47
dunhanson 2021-06-03 10:17:22 +08:00
懂 k8s 的人应该还好吧，我们公司我自己搭建的，生产环境部分用了 k8s
k8s 的优势就是人家有一整套的流程和规范，扩容回滚什么超级方便 |
|
48
dunhanson 2021-06-03 10:18:04 +08:00
之前我用过 docker compse 真的是难用，自己还要写很多辅助脚本来控制
|
 |
49
rrfeng 2021-06-03 10:29:19 +08:00
十几个进程还是算了吧，全部用 docker，（资源隔离和方便部署），稍微整理一下脚本就行了。
如果没有经验的话 k8s 还是很难调教的。 |
 |
50
windghoul 2021-06-03 10:29:37 +08:00
docker-compose 那一套文件的维护就很费事，而且多节点之间的网络这些的都是需要考虑的成本
|
 |
51
julyclyde 2021-06-03 10:30:29 +08:00
toB 项目，负载量一般没什么波动，弹性伸缩的功能基本上用不到的
不过部署灵活的好处始终存在 我的建议是：只学习不使用 |
 |
52
AlexEzio 2021-06-03 10:32:37 +08:00 6
ToB 交付老油条(4 年经验)来回答:
就你目前所说的信息，完全没有必要上 k8s. k8s 的优势在私有化部署中并不明显，因为运维成本高，而且不可控，不是所有客户都玩得转 k8s, 而且你评估下一个客户一个 k8s 的维护量? 私有化部署最重要的两点: 1. 部署效率与标准化(决定了交付速度，现金流的稳定) 2. 可维护性(决定了后续的维护成本) 在这两点上，k8s 私有化都只有缺点。 k8s 的优势在于应用的 zero downtime，扩容，发布，cicd, 这些私有化都不需要，私有化更新的频率，可能是一个月，基于半年，一年一次。 你这种场景，我之前也设计过部署方案，就是一套 docker-compose 搞定(我司当时是 12 个左右的 image)。定义好 docker entrypoint, 配置变量放在 env 文件里，初始化时脚本替换一下，加下 docker 自带的容器发现，很容易几分钟之内就部署好一套标准的环境出来。 配合上 ansible, 自己二开的 compose 配置平台, 能轻松实现部署，监控，预警，自动发布的效果。 另外，k8s 私有化是什么场景？ 都是针对金融，银行机构，做容器平台私有化，像 daocloud, 青云这种，都有相关的业务，一个项目就是上亿，这种都需要客户自己有专业的运维，开发团队的。 |
|
53
beryl OP @rrfeng 可能描述有误，十几个进程是只有十几个模块，包括 Mysql ES Redis 这些。
但是最终交付是集群交付，做服务划分（编排），没台机器都要部署，也是非常费力的。 |
 |
54
basefas 2021-06-03 10:35:43 +08:00
赞同 #52 的观点，运维 k8s 的成本远高于使用 k8s 带来的便利
|
 |
56
jack778 2021-06-03 10:37:59 +08:00
我想问下这种私有化部署后怎么做更新呢？ 是推送更新吗？
|
|
57
basefas 2021-06-03 10:39:44 +08:00
@beryl Mysql 这类有状态项目部署到 k8s 中运维难度更大，没有专家的话完全不建议在生产环境的 k8s 上部署有状态项目，建议 ansible 配合 docker 使用
|
|
58
beryl OP |
 |
59
securityCoding 2021-06-03 10:45:42 +08:00
k8s 的价值在于标准化,你围绕这点延伸出来说服老板吧
|
 |
60
snail00 2021-06-03 10:46:39 +08:00
数据库这类持久化部署不建议在 docker 里跑, 数据恢复是个灾难.
本身服务就是 docker 部署, 上 k8s 业务上改动不大, 主要是 k8s 的集群如何部署, 裸机部署 k8s 集群, 必须得个能 hold 住的运维, 公有云部署的集群小问题比较多, 可以综合成本看看 |
|
61
securityCoding 2021-06-03 10:47:22 +08:00
@jack778 有专门的私有镜像仓库,配合 ci 做到推送更新很简单
|
|
62
AlexEzio 2021-06-03 10:47:49 +08:00
@beryl 恩，我这里表述有点问题。实际我说的就是私有化中，用 k8s 交付服务这种场景。
据我个人经验，私有化如果有服务需要依托于 k8s 交付，客户最起码项目预算应该是百万以上，而且基本都是金融，银行，互联网公司这种不差钱的居多，有自已运维团队。 不过话说回来，如果是这种客户，那落地用什么架构，用什么技术，就不是你们说了算，而是客户说了算。 小项目，用 docker+ansible 轻装上阵， 快速部署加回款验收才是王道，整那些花里胡哨的没用， 对老板来说，项目成不成功，只看回款和金额， 不是看你用了多牛 b 的技术。 当然，想借项目来锻炼自己技术也是可以的， 我也试过 k8s 交付服务， 但是相信我，人总是趋利避害的，事少一点不好嘛~ |
|
63
rrfeng 2021-06-03 10:48:04 +08:00
@beryl 存储就放弃吧，小规模上 k8s 没意义反而带来更多麻烦。至于多台机器部署有很多现成的方案，ansible/saltstack 都很容易。甚至上了 docker 之后可以直接中控机上远程 docker api 去部署。
你这个场景 k8s 只有一种方案适合：你们所有客户共享一个 k8s 集群，统一在你们的中心管控，这样得到的效率提升确实高，只要给机器部署下 kubelet，其他都是一套了。 |
 |
64
th00000 2021-06-03 10:48:45 +08:00 1
K8S 太重度了, 上 HashiCorp 的 Nomad 也是一样的, 复杂度一下就下来了, 需求还能实现
GitHub 也是用的这个组件 |
|
65
AlexEzio 2021-06-03 10:50:44 +08:00
@beryl 私有化场景，k8s 和 docker 一把梭这种比起来，标准化一致(k8s 同样也是利用容器技术来实现运行时的标准化)，效率天差地别。 部署一套 k8s,和部署 docker daemon,那就是一天和几分钟的区别。
|
|
67
beryl OP @AlexEzio 另外自己的感觉也是 K8S 太重，我理解的重是：
K8S 环境搭建起来，学习成本较大 但是如果有专门的人做过这套，搭建起来之后，用这个去编排、交付产品是不是方便？ 另外请教下，如果现在用 docker-compose， 后面有人力和动机后，再迁移到 K8S 成本大么 |
 |
68
killerv 2021-06-03 11:06:07 +08:00
我感觉自己部署 k8s 完全没必要，直接使用云厂商成熟的 k8s 解决方案，工程师不应该关注底层系统维护，应该更关注自己的业务。
k8s 带来的收益是很明显的：容器技术带来的降低资源占用、简化项目部署、高可用、环境一致性等等。 不太建议中间件、数据库用容器跑，监控、容灾需要很大成本，这类最好还是使用云产品。 |
 |
69
Illusionary 2021-06-03 11:20:08 +08:00
外包搞什么 K8S，Tomcat 就完事了。
|
 |
70
tandaly 2021-06-03 11:20:38 +08:00
纯 k8s 搞下来挺复杂，目前用 rancher 管理 k8s 集群
|
|
71
AlexEzio 2021-06-03 11:57:02 +08:00
@beryl k8s 学习成本大，维护成本也高。如果有专人做 k8s,搭建，维护啥的，那肯定会方便一些，helm chat 加上写好的 yaml 梭就行了。 但是这个专人成本也会高，风险也很大，如果这个人走了，后续集群更新，漏洞修复，证书更新啥的，都是麻烦事。
docker 编排，和 k8s 编排，迁移成本就是在各类资源 yaml 或 helm chat 编写上， 对开发来讲是无感的。 说下我目前交付的场景: 1. POC 部署， 直接 docker-compose 一把梭，一台机器搞定，就是演示核心功能 2. 测试，UAT,生产部署: 用 ansible + 源码编译的形式， 中间件能复用客户的，就复用客户的，这样只需要专注于自己的业务这块。这种适用于有自己技术团队的客户，ansible 多机部署非常方便，设计好 playbook, 设计好 role 的复用就可以了。我目前都是这种方式为主，规模从几台，到几十台不等都 okay. 3. k8s 部署， 这种都是客户自己有上云需求，会要求你去对接他们 cicd, k8s, 成本就是前期的上云适配， 后续维护除了版本更新，其他都是客户自己负责。 这种方式比较小，客户很少有完善和成熟的云原生维护体系。 4. 小众的 paas 平台适配， 这种就更少了。基本前两种为主。 私有化这块，没有什么一成不变的交付方式，尤其是大客户这一块，会经常有定制，对接需要。 还是根据你们自己的情况，去制定一个效率和维护都兼顾的一种交付方式，先小步跑起来。 |
 |
72
wandehul 2021-06-03 12:00:08 +08:00 3
我是运维，我现在已经不想去没有 k8s 的公司了，累！
|
 |
73
hijoker 2021-06-03 12:04:38 +08:00
你们是做好软件卖给客户? k8s 环境也是你们软件一起提供？还是客户准备 k8s?
|
 |
74
xingzhi 2021-06-03 12:05:47 +08:00
你老板反问的问题是对的，尤其是第二点，你自己都没有想清楚有什么显著收益，那为什么就要“准备上 k8s” 呢
|
 |
75
ferock 2021-06-03 12:12:53 +08:00 via iPhone
大规模才有需要，小范围没必要
|
 |
76
pckillers 2021-06-03 14:58:46 +08:00
@napsterwu 我寻思能叫运维的人难道不会用 ansible 之类的批量部署工具来多机批量执行 docker run 么。。。
|
 |
77
tanghanyu 2021-06-03 17:22:45 +08:00
你们私有化交付的话是不太建议的，k8s 的优势体现得没那么明显，运维成本在你们这种场景中反而会被无限放大。前公司是用自研的 k8s 平台打包产品一起卖给客户的，早期产品不稳定的时候是挺麻烦的。
另外 k8s 不是搭建起来就完事了，相应的存储、网络、监控也要搞好，还有很多开发初期根本不知道怎么用，使用成本也是有一些的，毕竟还要去培训推广。 这种场景直接 ansible + docker 我觉得更好，如果是公司内部往 k8s 过渡我倒是觉得比较合适。 |
 |
78
liuzhedash 2021-06-03 17:25:02 +08:00 1
如无必要，勿增实体
|
 |
79
libook 2021-06-03 17:26:45 +08:00
都用容器了，说明对这点点的性能损耗应该是能够接受的，K8s 只是做调度和中间件，实际应用还是跑在 Docker 、Podman 之类的容器里的。
不同的项目情况决定是否适合用 K8s，我说说我们的情况吧，K8s 主要解决我们分布式角度的问题，应用很多，每个应用都需要部署多个实例作为集群，然后我们有多台服务器，以往是限定特定几台服务器只能部署特定的应用，用 K8s 可以把这些服务器看做一个计算池，不需要关心集群是如何分布的，也可以按照负载情况动态调整分布，这样能进一步榨干服务器的性能，不会有的机器超负载、有的机器空转。 另外就是微服务化之后，需要使用中间件来保障微服务之间通信的可靠性，比如需要熔断机制来避免雪崩，类似的这种服务与服务之间协作的问题，K8s 提供了大量插件，可以直接用。 最近在看 K8s 的 Secret，可以用 K8s 集中管理应用的配置，比如数据库连接地址、密码秘钥啥的，这是非侵入性的，而且可以统一管控，避免由开发人员泄露。 总之这些都是工具，最好是了解一下 K8s 能干啥，然后看看目前项目流程上是否有痛点可以用 K8s 的这些特性来解决，再评估成本如何，最终就能决定是不是要用了。 我家里自己的服务器也用容器，但只有 2 台机器，所以用的 Portainer，能提高不少便捷性。 |
 |
80
bomb77 2021-06-03 17:36:20 +08:00
toB 私有化部署，基本上都在人家内网环境平时你也上不去，上 k8s 基本上是给自己找麻烦啊，又没有持续继承动态增减容量的需求。。。
|
 |
81
leeyom 2021-06-03 17:40:57 +08:00
k8s 但是实际跑起来后，投入生产，确实挺方便的，扩充节点，下线节点，滚动更新，一把梭，目前我们用的是腾讯云的 tke，如果自己搭建 k8s 的话，运维成本确实很高
|
 |
82
yalin 2021-06-03 17:45:56 +08:00
先熟悉传统同城双活和异地多活，再上 k8s 也不迟。开发团队人员和人员水平可以考虑 k8s
|
 |
83
bdnet 2021-06-03 19:19:43 +08:00
私有部署，没有突发流量扩容场景，docker-compose 就够，确实不需要 k8s 。
|
 |
87
firefox12 2021-06-03 22:41:55 +08:00 1
https://github.com/xiaojiaqi/deploy-microservices-to-a-Kubernetes-cluster 你需要这个，先入个门
如果是大公司，得利很多，小公司 ToB 可以多收钱啊。 建议学， 早 10 年 也许大家觉得 spring 复杂没必要，回头看 spring 占领了市场，回头看 k8s 也一样， 基本是标准配置了。 你逃不开。 |
|
88
sangs 2021-06-04 10:25:58 +08:00
@AlexEzio 你们目前还是只有 12 个 image 吗, 如果你们的项目有 52 个 image, 你对 k8s 私有化部署的态度还会是这样吗?
说下我对你回复的看法哈 (纯讨论) [1] 部署效率与标准化(决定了交付速度，现金流的稳定) 使用 helm chart 一键拉起所有的应用. 有些时候因为应用启动顺序的问题, 做不到一键拉起. 我们现在项目 30 多个应用其实就做不到, 需要先拉起基础设施, 再拉业务应用, 大概 3~4 次拉起流程吧. 但是 3 次, 每次只需要执行 helm install 命令, 我认为很快啊. 我认为 k8s 的标准化和部署效率真的很高. [2] 可维护性(决定了后续的维护成本) 可维护性的确是个问题, 需要客户或者自己团队有运维 k8s 的能力. 但是你后面也提到自己团队也搞了一个简单的部署系统, 但是这个部署系统再简单也是需要维护的. 对于客户来说, 一个是 k8s, 一个是乙方自建的系统, 我觉得客户会更容易接受 k8s, 对乙方自建的部署系统更加排斥吧 (因为出了问题不好找解决方案). [3] 扩容，发布，cicd, 这些私有化都不需要 这一点是我最不认同的一点. 容器技术最大的优势就是能保证业务代码和基础设施在各个环境保持一致. 而 k8s 能够做到研发态和部署态一致. 虽然私有化部署以后很少升级, 但是研发态需要啊, 如果能够让研发态和部署态保持一致, 能少多少学习成本. |
|
89
libook 2021-06-04 10:26:11 +08:00
@johnsona #86 是 UI，可以做为 K8s 的前端，如果不装 K8s 的话，本身就支持添加多台机器作为 Endpoint 分别进行管理，虽说此时没有集群管理的能力，但是比手打指令方便太多了，特别是给容器更新镜像的时候。
|
|
90
bdnet 2021-06-04 10:36:36 +08:00
@beryl #84 k8s 必然有很多优点，缺点在学习成本(能否驾驭 要不熟悉 遇到 BUG 没经验 估计难排查)
（这个场景 除了 k8s，ansible 等自动化工具也可以实现的） 在技术角度难免想用新技术，这是好事 站在老板角度考虑，首要考虑成本收益、风险承担，如果你准备好了，有一个 demo(先弄个 k3s)，他或许会愿意给机会尝试 |
|
91
AlexEzio 2021-06-04 14:12:53 +08:00
@sangs
不要跳脱上下文噻，讨论是基于题主那个情况， 如果真有 52 个 image, 那项有化项目整体规模都不一样了，对应技术方案肯定是变化的。 另外我强调的几点， 是就题主这个情况，docker,和 k8s 私有化部署 1. docker 部署效率 > k8s 部署效率 2. docker 可维护性 >> k8s 可维护性 3. docker 私有化也是容器部署，不存在你说的生产研发不一致的情况，docker 和 k8s 对研发来讲都是一样的，最终部署都是一个 image，无非是 k8s 有更完善的扩容，抽象资源，调度机制。 |
 |
92
OneMan 2021-06-04 14:16:17 +08:00
最多一个 docker，这个搞 k8s 就是加戏。。
|
 |
93
746215017chen 2021-06-04 16:23:14 +08:00
我们之前也是用的 docker-compose 就行开发部署的后来改成了 k8s 的方案目前遇到下面几种情况
docker-copose 不增加机器的情况下部署的比较省事,只需要装 docker 和 docker-compose 不需要再装额外的东西,但是如果服务更新的时候无法平滑更新会有短暂的服务不可用，还有一点就是如果要临时多家几台机器的话,部署起来会比较麻烦,后台改了用了 k8s,首先解决了平滑更新的问题,更新的时候线上服务可以正常使用的，其次就是如果需要加机器的话只需要执行一次安装节点脚本将节点安装在新增的机器上,之后服务更新的时候就自动分散到多个节点中,也不不需要在配置环境变量之类的东西和代码配置的东西 |
|
94
beryl OP @746215017chen docker-compose 在不加机器的情况下， 如果机器比较多，是不是也比较麻烦，要每台单独安装
|
 |
95
momocraft 2021-06-04 17:41:28 +08:00
如果有 staging 先把这个换成 k8s 看看 不要
|
|
96
momocraft 2021-06-04 17:41:45 +08:00
>96
不要急着上 prod |
 |
97
locoz 2021-06-05 05:43:11 +08:00
@dayeye2006199 #32 绝了，这也行...
|
 |
99
zhoujinjing09 2021-06-05 17:16:23 +08:00
是要去客户环境部署吗？那客户没 k8s 咋办？
|
 |
100
hotsymbol 2021-06-05 21:17:30 +08:00
现在这个时代不上 k8s 简直就是原罪，就像某些老年人口中说的 不买华为你就不爱国一样，业界不上 k8s 就感觉要被时代淘汰了一样
|
Select Language