是否有必要用 K8S

私有化部署不是发布到客户的服务器上面吗？服务器资源不是客户提供？不知道你们老板为啥要纠结资源的问题。

如果是动态范围不是很大的，需要随时自动横向扩展 /收缩的，k8s 就完全没有必要了。增加无谓的复杂度，提高运维的工作量。直接 docker run 也不是不行。反正我的经验是，只要脚本写好，就是一个命令的事情，要什么 k8s 。

@beryl ansible salt 有太多方案能解决交付，完全能做到一键搞定

@xuanbg 强烈赞同！

我觉得可以用，不要被吓到，其实没那么难，你又不进行二次开发，只是使用而已，找一个专门的人专门运维这一块就可以了

只说优点: 对于无状态的 Web 服务，k8s 可以保证服务的高可用，例如进程挂了 k8s 自动给拉起来，否则需要管理员发现进程挂了去手动启动程序。只需要用 yaml 文件在 master 上部署，不需要自己去手动一个一个的到目标机器上部署，部署简单。

面向老板和薪水实施哈

私有化部署不是很有必要一定上 k8s 太重了。如果是你们提供公有服务的话，使用 k8s 就十分合适。

没有必要

k8s 节省的是程序员成本, 你在心疼机器成本那就没必要

巧了, 我也是做交付的 (可以加个好友). 目前在用 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 了

懂 k8s 的人应该还好吧，我们公司我自己搭建的，生产环境部分用了 k8s
k8s 的优势就是人家有一整套的流程和规范，扩容回滚什么超级方便

之前我用过 docker compse 真的是难用，自己还要写很多辅助脚本来控制

十几个进程还是算了吧，全部用 docker，（资源隔离和方便部署），稍微整理一下脚本就行了。

如果没有经验的话 k8s 还是很难调教的。

toB 项目，负载量一般没什么波动，弹性伸缩的功能基本上用不到的
不过部署灵活的好处始终存在

我的建议是：只学习不使用

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, 青云这种，都有相关的业务，一个项目就是上亿，这种都需要客户自己有专业的运维，开发团队的。

@rrfeng 可能描述有误，十几个进程是只有十几个模块，包括 Mysql ES Redis 这些。
但是最终交付是集群交付，做服务划分（编排），没台机器都要部署，也是非常费力的。

赞同 #52 的观点，运维 k8s 的成本远高于使用 k8s 带来的便利

@sangs 非常感谢，很有帮助, 可以一起聊聊
不过我不是交付，现在还没有找到合适的交付 (-_-

我想问下这种私有化部署后怎么做更新呢？ 是推送更新吗？

@AlexEzio
> 部署效率与标准化(决定了交付速度，现金流的稳定)
这点 K8S 不是优势么

场景和你说的类似，但不是容器平台私有化，而是我们服务依托于 K8S 进行交付，项目金额也没有这么大

k8s 的价值在于标准化,你围绕这点延伸出来说服老板吧

数据库这类持久化部署不建议在 docker 里跑, 数据恢复是个灾难.
本身服务就是 docker 部署, 上 k8s 业务上改动不大, 主要是 k8s 的集群如何部署, 裸机部署 k8s 集群, 必须得个能 hold 住的运维, 公有云部署的集群小问题比较多, 可以综合成本看看

@jack778 有专门的私有镜像仓库,配合 ci 做到推送更新很简单

@beryl 恩，我这里表述有点问题。实际我说的就是私有化中，用 k8s 交付服务这种场景。
据我个人经验，私有化如果有服务需要依托于 k8s 交付，客户最起码项目预算应该是百万以上，而且基本都是金融，银行，互联网公司这种不差钱的居多，有自已运维团队。
不过话说回来，如果是这种客户，那落地用什么架构，用什么技术，就不是你们说了算，而是客户说了算。
小项目，用 docker+ansible 轻装上阵， 快速部署加回款验收才是王道，整那些花里胡哨的没用， 对老板来说，项目成不成功，只看回款和金额， 不是看你用了多牛 b 的技术。
当然，想借项目来锻炼自己技术也是可以的， 我也试过 k8s 交付服务， 但是相信我，人总是趋利避害的，事少一点不好嘛~

@beryl 存储就放弃吧，小规模上 k8s 没意义反而带来更多麻烦。至于多台机器部署有很多现成的方案，ansible/saltstack 都很容易。甚至上了 docker 之后可以直接中控机上远程 docker api 去部署。

你这个场景 k8s 只有一种方案适合：你们所有客户共享一个 k8s 集群，统一在你们的中心管控，这样得到的效率提升确实高，只要给机器部署下 kubelet，其他都是一套了。

K8S 太重度了, 上 HashiCorp 的 Nomad 也是一样的, 复杂度一下就下来了, 需求还能实现
GitHub 也是用的这个组件

@beryl 私有化场景，k8s 和 docker 一把梭这种比起来，标准化一致(k8s 同样也是利用容器技术来实现运行时的标准化)，效率天差地别。 部署一套 k8s,和部署 docker daemon,那就是一天和几分钟的区别。

@AlexEzio 不是为了锻炼技术，也不一定非要用 K8S, 出发点还是为了项目和产品更容易交付

@AlexEzio 另外自己的感觉也是 K8S 太重，我理解的重是：
K8S 环境搭建起来，学习成本较大

但是如果有专门的人做过这套，搭建起来之后，用这个去编排、交付产品是不是方便？

另外请教下，如果现在用 docker-compose， 后面有人力和动机后，再迁移到 K8S 成本大么

我感觉自己部署 k8s 完全没必要，直接使用云厂商成熟的 k8s 解决方案，工程师不应该关注底层系统维护，应该更关注自己的业务。
k8s 带来的收益是很明显的：容器技术带来的降低资源占用、简化项目部署、高可用、环境一致性等等。
不太建议中间件、数据库用容器跑，监控、容灾需要很大成本，这类最好还是使用云产品。

外包搞什么 K8S，Tomcat 就完事了。

纯 k8s 搞下来挺复杂，目前用 rancher 管理 k8s 集群

@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 平台适配， 这种就更少了。基本前两种为主。

私有化这块，没有什么一成不变的交付方式，尤其是大客户这一块，会经常有定制，对接需要。
还是根据你们自己的情况，去制定一个效率和维护都兼顾的一种交付方式，先小步跑起来。

我是运维，我现在已经不想去没有 k8s 的公司了，累！

你们是做好软件卖给客户? k8s 环境也是你们软件一起提供？还是客户准备 k8s?

你老板反问的问题是对的，尤其是第二点，你自己都没有想清楚有什么显著收益，那为什么就要“准备上 k8s” 呢

大规模才有需要，小范围没必要

@napsterwu 我寻思能叫运维的人难道不会用 ansible 之类的批量部署工具来多机批量执行 docker run 么。。。

你们私有化交付的话是不太建议的，k8s 的优势体现得没那么明显，运维成本在你们这种场景中反而会被无限放大。前公司是用自研的 k8s 平台打包产品一起卖给客户的，早期产品不稳定的时候是挺麻烦的。
另外 k8s 不是搭建起来就完事了，相应的存储、网络、监控也要搞好，还有很多开发初期根本不知道怎么用，使用成本也是有一些的，毕竟还要去培训推广。
这种场景直接 ansible + docker 我觉得更好，如果是公司内部往 k8s 过渡我倒是觉得比较合适。

如无必要，勿增实体

都用容器了，说明对这点点的性能损耗应该是能够接受的，K8s 只是做调度和中间件，实际应用还是跑在 Docker 、Podman 之类的容器里的。

不同的项目情况决定是否适合用 K8s，我说说我们的情况吧，K8s 主要解决我们分布式角度的问题，应用很多，每个应用都需要部署多个实例作为集群，然后我们有多台服务器，以往是限定特定几台服务器只能部署特定的应用，用 K8s 可以把这些服务器看做一个计算池，不需要关心集群是如何分布的，也可以按照负载情况动态调整分布，这样能进一步榨干服务器的性能，不会有的机器超负载、有的机器空转。

另外就是微服务化之后，需要使用中间件来保障微服务之间通信的可靠性，比如需要熔断机制来避免雪崩，类似的这种服务与服务之间协作的问题，K8s 提供了大量插件，可以直接用。

最近在看 K8s 的 Secret，可以用 K8s 集中管理应用的配置，比如数据库连接地址、密码秘钥啥的，这是非侵入性的，而且可以统一管控，避免由开发人员泄露。

总之这些都是工具，最好是了解一下 K8s 能干啥，然后看看目前项目流程上是否有痛点可以用 K8s 的这些特性来解决，再评估成本如何，最终就能决定是不是要用了。

我家里自己的服务器也用容器，但只有 2 台机器，所以用的 Portainer，能提高不少便捷性。

toB 私有化部署，基本上都在人家内网环境平时你也上不去，上 k8s 基本上是给自己找麻烦啊，又没有持续继承动态增减容量的需求。。。

k8s 但是实际跑起来后，投入生产，确实挺方便的，扩充节点，下线节点，滚动更新，一把梭，目前我们用的是腾讯云的 tke，如果自己搭建 k8s 的话，运维成本确实很高

先熟悉传统同城双活和异地多活，再上 k8s 也不迟。开发团队人员和人员水平可以考虑 k8s

私有部署，没有突发流量扩容场景，docker-compose 就够，确实不需要 k8s 。

@bdnet 但是想稳定性，监控运维，和多机器部署，配置和维护，也是需要成本的吧

@lucays 可以协助上 k8s 。刚帮一家从 docker-compose 转换到 k8s

https://github.com/xiaojiaqi/deploy-microservices-to-a-Kubernetes-cluster 你需要这个，先入个门

如果是大公司，得利很多，小公司 ToB 可以多收钱啊。 建议学， 早 10 年 也许大家觉得 spring 复杂没必要，回头看 spring 占领了市场，回头看 k8s 也一样， 基本是标准配置了。 你逃不开。

@AlexEzio 你们目前还是只有 12 个 image 吗, 如果你们的项目有 52 个 image, 你对 k8s 私有化部署的态度还会是这样吗?

说下我对你回复的看法哈 (纯讨论)

[1] 部署效率与标准化(决定了交付速度，现金流的稳定)

使用 helm chart 一键拉起所有的应用. 有些时候因为应用启动顺序的问题, 做不到一键拉起. 我们现在项目 30 多个应用其实就做不到, 需要先拉起基础设施, 再拉业务应用, 大概 3~4 次拉起流程吧. 但是 3 次, 每次只需要执行 helm install 命令, 我认为很快啊. 我认为 k8s 的标准化和部署效率真的很高.

[2] 可维护性(决定了后续的维护成本)

可维护性的确是个问题, 需要客户或者自己团队有运维 k8s 的能力. 但是你后面也提到自己团队也搞了一个简单的部署系统, 但是这个部署系统再简单也是需要维护的. 对于客户来说, 一个是 k8s, 一个是乙方自建的系统, 我觉得客户会更容易接受 k8s, 对乙方自建的部署系统更加排斥吧 (因为出了问题不好找解决方案).

[3] 扩容，发布，cicd, 这些私有化都不需要

这一点是我最不认同的一点. 容器技术最大的优势就是能保证业务代码和基础设施在各个环境保持一致. 而 k8s 能够做到研发态和部署态一致. 虽然私有化部署以后很少升级, 但是研发态需要啊, 如果能够让研发态和部署态保持一致, 能少多少学习成本.

@johnsona #86 是 UI，可以做为 K8s 的前端，如果不装 K8s 的话，本身就支持添加多台机器作为 Endpoint 分别进行管理，虽说此时没有集群管理的能力，但是比手打指令方便太多了，特别是给容器更新镜像的时候。

@beryl #84 k8s 必然有很多优点，缺点在学习成本(能否驾驭 要不熟悉 遇到 BUG 没经验 估计难排查)

（这个场景 除了 k8s，ansible 等自动化工具也可以实现的）

在技术角度难免想用新技术，这是好事

站在老板角度考虑，首要考虑成本收益、风险承担，如果你准备好了，有一个 demo(先弄个 k3s)，他或许会愿意给机会尝试

@sangs
不要跳脱上下文噻，讨论是基于题主那个情况， 如果真有 52 个 image, 那项有化项目整体规模都不一样了，对应技术方案肯定是变化的。
另外我强调的几点， 是就题主这个情况，docker,和 k8s 私有化部署
1. docker 部署效率 > k8s 部署效率
2. docker 可维护性 >> k8s 可维护性
3. docker 私有化也是容器部署，不存在你说的生产研发不一致的情况，docker 和 k8s 对研发来讲都是一样的，最终部署都是一个 image，无非是 k8s 有更完善的扩容，抽象资源，调度机制。

最多一个 docker，这个搞 k8s 就是加戏。。

我们之前也是用的 docker-compose 就行开发部署的后来改成了 k8s 的方案目前遇到下面几种情况
docker-copose 不增加机器的情况下部署的比较省事,只需要装 docker 和 docker-compose 不需要再装额外的东西,但是如果服务更新的时候无法平滑更新会有短暂的服务不可用，还有一点就是如果要临时多家几台机器的话,部署起来会比较麻烦,后台改了用了 k8s,首先解决了平滑更新的问题,更新的时候线上服务可以正常使用的，其次就是如果需要加机器的话只需要执行一次安装节点脚本将节点安装在新增的机器上,之后服务更新的时候就自动分散到多个节点中,也不不需要在配置环境变量之类的东西和代码配置的东西

@746215017chen docker-compose 在不加机器的情况下， 如果机器比较多，是不是也比较麻烦，要每台单独安装

如果有 staging 先把这个换成 k8s 看看 不要

>96

不要急着上 prod

@dayeye2006199 #32 绝了，这也行...

@calmzhu 可以简单的说下第 3 点吗？这个轮换是指

是要去客户环境部署吗？那客户没 k8s 咋办？

现在这个时代不上 k8s 简直就是原罪，就像某些老年人口中说的 不买华为你就不爱国一样，业界不上 k8s 就感觉要被时代淘汰了一样