你认为什么规模的公司适合使用 k8s?

[linxuan716]

k8s 运维平台现在已经很流行了，但也有说认为只有大公司才能使用，小公司使用反而麻烦，你认为呢？

[idblife]

问出这个问题说明你还不需要

[lujiaxing]

看你的业务规模跟业务复杂程度.
如果二者已经到了单台设备能够承载的上限, 那分布式架构就是必然的选择. 上分布式架构之后, k8s 基本就是必须. 跟多少人没啥关系.

[songray]

跟规模没关系，跟业务有关系。
如果你的业务单机 8c 32g 不能支撑的话，基本就要上 k8s 分布式了。（不过据我观察这样的业务很少）
很多人觉得 k8s 是引入复杂度的，其实这玩意是分布式奶嘴，没这奶嘴更痛苦。

[linxuan716]

@idblife 我现在遇到一个问题，我们公司是做物联网平台的，有一个主服务，比较大，其它还有三、五个小服务，比较依赖于主服务，想转到 k8s 平台上，但又觉得会不会以后维护起来麻烦

[jiames1969]

以前专家有过讨论，通用业务日流量 1000w +上 k8s 才划算。

[songray]

@linxuan716 k8s 主要是解决横向扩容场景的。你这个不应该用 k8s 。

[linxuan716]

@lujiaxing 现在我们的平台单台在跑批的时间点会使用 CPU ，这样会导致正常的数据入库延迟，这样算不算是单台设备已经不能承受了

[linxuan716]

@songray 我们使用的阿里云已经是 8c ，32g 了

[sujin190]

主要问题是业务量不够上了 k8s 会贵不少，维护哪复杂了，更简单了吧

[linxuan716]

@jiames1969 我们所有的物联网设备加上数据与图片基本上已经达到了 1kw

[songray]

@linxuan716 k8s 的场景是，有时候你的主服务或子服务的流量会暴增，或者是你的业务天然需要部署多个相同服务（比如需要尽可能靠近客户端的边缘计算场景）。
那么你需要 k8s 作为编排器，为你管理这些服务，自动扩容、修复这些服务。
你这种场景主要是维护依赖关系和自动恢复的话，还不如用 kamal 之类的命令式工具。
https://kamal-deploy.org/

[linxuan716]

@sujin190 现在我们后台使用 django ，发布上线只需要拉下代码，然后使用 uwsgi 重启下服务就可以了，如果上了 k8s ，还需要打包镜像

[songray]

@linxuan716 如果计算和数据量增长是一个平滑曲线的话，我建议还是给服务器配置留下余量就好。

[linxuan716]

@songray kamal 这个工具可以

[CoderGeek]

@linxuan716 现在我们的平台单台在跑批的时间点会使用 CPU ，这样会导致正常的数据入库延迟，这样算不算是单台设备已经不能承受了

你可以把跑批任务分离出去 异步不影响你主要应用即可 不需要 k8s

[linxuan716]

@CoderGeek 这个确实也是一种新的思路

[johnniang]

感觉目前用 Docker Swarm 就足够了。

[linxuan716]

@songray 这们现在是磁盘不够了就直接扩容，CPU 与内存没有考虑过，所以就导致一年比一年难维护

[monkeyWie]

再小都可以上，前期可以直接用 k3s ，后面要是顶不住了再上集群，其实 k8s 配合 CI/CD 更方便部署，打好镜像然后一个命令就滚动升级了

[linxuan716]

@johnniang 这个原来也考虑过，后来考虑到这个只是换一种部署方式，并没有实现动态扩容也就没有想法了

[linxuan716]

@monkeyWie 如果再上一套 CI/CD ，又占用了更多的硬件资源，不知道这个会不会得不偿失

[litchinn]

k8s 最大的优势在自动扩缩容，也就是流量大时能够自动启动新节点，流量减小时自动关闭一些节点以节省资源
其它的功能基本都有更好的替代，或者它本身也是用的其它组件
为什么说需要一些规模才上 k8s ，因为如果你就一个 replication 就足够了根本用不着扩缩容，引入 k8s 也许反而会让服务不稳定，规模再小一点你业务的资源消耗还赶不上 k8s 的消耗，这种就更搞笑了

[qiangmin]

1.云公司
2.集团公司计划从公有云迁移。集团子公司太多，集团公司子公司业务杂乱（比如物流、工厂、物联，销售前端、售后端，内网的报销、物料流转、即时通讯、员工管理，海外各国分公司也都有这些业务）。

[testcgd]

可以先容器化，完了之后再考虑要不要用 k8s ，如果服务变更少，没有扩缩容需求可以先不上

[lujiaxing]

@linxuan716 额这不算啥新思路 这属于常规操作 正常来说 CPU 密集型的后台任务都是需要用单独的设备部署的. 绝对绝对不可以与核心业务共享硬件资源的.

[linxuan716]

@testcgd 是的，我们现在领导也想实现容器化，因为有一些客户想独立部署，我们也可以节省部署时间

[linxuan716]

@litchinn 是的，这也正是我担心的

[linxuan716]

@lujiaxing 以前为了方便，开发都是直接在主项目中直接开发代码，后来慢慢的就堆在一起，想拆出来不容易

[raydied]

如何界定需不需要，我不知道，但吞吐量绝对不是指标性要求。

我这边有一个智慧工地系统，业务场景边界比较清晰，模块比较多；
完全不能忍受升级一个模块全部重启；
恰好有个人会 K8S 。

然后就上了，甚至运行在现场的本地服务器上（客户一直看云视频，流量遭不住）——偶尔断个电，重启可方便了。

[linxuan716]

@raydied 我们的服务现在是在云服务器，打算迁移到机房，以前不用考虑意外问题，但现在也确实考虑这个问题

[salmon5]

当你需要练手的时候
当你需要 KPI 的时候
无论规模，哪怕整个公司就你一个开发，就可以用 K8S

[fishioon]

如果部署的服务比较多，k8s 带来的收益会高一些；架构切换，一定要想清楚收益啊

[qiangmin]

@qiangmin 业务重复度高，需要整合，降低维护成本（就是那个大中台，大后端啥的）。业务有弹性需求，类似双 11 有巨量访问需求，其他时间都是少量访问（扩缩容）。业务需要降本增效，公有云太贵，VMware 也太贵。业务需要国产化，需要完全的安全可控。

[linxuan716]

@salmon5 听君一席话，胜读十年书

[zmcity]

所有公司都适合 k8s ，维护成本直线降低，小型服务直线降低运维难度，大型服务很多轮子就不用重复造了

[hancai2]

我觉得再小都可以，除非你们一直就一台服务器一个服务。 我这边有个项目最开始就只有 3 个服务，两台 4c8g 服务器。我嫌麻烦就只弄了个 docker-compose, 后面就发现需要一堆 k8s 的能力。
1 、某个服务有假死的情况，需要健康检查，能自愈。docker 虽然有健康检查，但是无法自己重启。
2 、每次更新需要两台服务器都操作一遍，k8s 只需要改一次 yaml
3 、两台服务器的 docker-compose.yaml 需要保持一致，但是某些环境变量又不能完全一致。维护麻烦，易出错。
4 、新增服务麻烦，原本的 3 服务，增加了到了 6 个服务，还有个 elastic 集群了。

如果你们有专门的运维岗， 真不如 k8s 一把梭。

[ksmiloLove]

这玩意管理应用和资源好用，不是微服务啥的也好用阿。

[ksmiloLove]

这帖这么久了，期待 defunct9 来锐评一下

[nativeBoy]

我们公司在用，我发现这东西包含了注册中心、配置中心的功能，而且自动将异常 pod 重新拉起，都很适合现网的情况

k8s 对小公司来说比较重，但是降低了维护成本，当机器多起来的时候，现网有几千个 pod 在运行，维护成本会比较高。虽然你可以搭建管理平台来维护，但是在这之前你用 kubectl 就能处理多数问题，确实很方便

[zhengmin451607]

我们公司就我一个开发，现在是一个负载均衡+2 台服务器最传统的布局，也想搞这种 k8s 容器化之类的，但是对比了下成本，阿里云的 eci 容器什么的费用比单独自己买 ecs+负载均衡贵啊。

[fffq]

@hancai2 docker-compose 有个 restart 可以重启吧

[yuan1028]

只要不是单体服务，都是值得的，核心是有人要负责 k8s

小公司分享：
使用阿里云 k8s （ apiserver 等控制面节点免运维版），7 个小型服务。
1 、阿里云云效 CI/CD + 负载均衡，一键灰度发布、测试；
2 、节点自动扩缩、服务自动扩缩（夜间几乎无流量，跑离线服务和定时任务）；
3 、监控、报警、链路追踪使用 prometheus+SLS 日志服务；

可以说是几乎免运维的

[kennylam777]

@hancai2 對, 光是 health check 及 rediness check 就有上 k8s 的理由了, 自動重啟起碼能讓 devs 有更多時間去排查, 有時候 daemon 掛了但 fg process 是沒反應的

另外是 readiness, 用 readniess + service 起碼可以自動排除掉 health check 不過關的 pod, 在滾動升級但一直有請求進來的場景也可以減少對用戶的感知

[latifrons]

如果实在受不了 k8s/k3s 的学习曲线的话我推荐 Hashicorp 的 Consul+Nomad ，单文件轻量级，一样可以做容器编排/健康检查/服务发现/持久化，我们在生产上几十个服务上百个容器实例，很稳。

[jqknono]

个体户都可以用

[superchijinpeng]

现在就连政府也有很多单节点的 k8s ，3 节点以上的就更多了

[pkoukk]

公司有钱给钱就能用，和规模没关系

[cheng6563]

小公司，除非你孝道不用处理滚动跟新之类的问题，不然相对写一堆脚本，可能还不如上 k8s 容易些。
单机也能用 k3s ，也就占 500m 内存。

[pc10201]

k8s 能解决很多标准化的问题，比如发布，监控，计划任务等，所有的应用都跑在这个上面，后期能省很多事，另外阿里云有免费的 k8s 管理服务

[guoguobaba]

k8s 用在测试平台什么时候，什么规模都不会晚。

生产环境如果负载不大，k8s 也是运维成本最低的方案

[rickzrn]

看完之后我觉得需要, 因为:
1. 服务可以拆解成微服务, 微服务优点很多
2. 大部分时候省心, k8s 会自动重启 pod, 有时候你都不会意识到自己的服务出了问题
3. yaml 声明式编程, 平常运维会更简单(扩容简单, 更新镜像即使不用 CI/CD 也简单)
4. 有的私有化部署会很方便

但问题也有,
1. 容器化/k8s 还是有一定的上手成本(但技术上不难)
2. 不一定能解决私有化部署的问题, 因为客户 IT 实力不详, 不一定就能支持 k8s
3. 如果工作只是落到你自己头上也没什么好处, 需要掂量下

[Hieast]

@linxuan716 服务分离不代表代码也要分离

[bigbugbag]

@linxuan716 #7 我觉得这是你资源没有做隔离或限制，需要限制一下跑批的 CPU 使用量，不要影响到正常业务的用量

[wang1x1]

@latifrons 居然碰到了用 Consul + Nomad 的团队！我们目前也在深度的使用 Consul + Nomad ，总体感觉比运维 k8s 要简单很多。

[xiyou007]

不知道还以为是一个公司了， 我们跟你们非常相似，我们也是 Python 写的物联网平台。 加个 v 。交流一下啊

[hancai2]

@kennylam777 对的，像我们公司做私有化交付项目比较多。 客户环境不稳定，有时候客户维护物理服务器，可能都不告知我们。服务自愈能力挺重要。遇到扩容、缩容都好解决一点。比较麻烦的是，现在搞国产替代，有些垃国产系统对于 k8s 兼容性不好。

[hancai2]

@fffq 没有吧， 我查了都是 docker swarm 才有的功能

[realpg]

规模无关.
如果你公司有一个 devops 大佬出身的架构师或者 CTO, 他能有话语权, 且技术到位精通 k8s, 他自己操刀或者带两个他认可的人做架构和运维,开发服他, 且这个公司的业务规模大(互联网项目)或者重复性高(出售软件频繁反复部署) 就可上!

[lysShub]

用户数 < 节点数

[johnniang]

@linxuan716

Docker Swarm 可以添加管理节点和工作节点，服务副本可以手动伸缩（例如：docker service scale stack_service=3 ），不停机更新，负载均衡，服务实例也可以运行到任意节点，部分节点挂了也会自动在其他节点运行新的实例。

[fank99]

@linxuan716 #12 打包镜像显然更方便啊，遇到环境依赖很头疼的

[ytmsdy]

首先，不要为了上 k8s 而上 k8s 。你要先考虑一下现在运维的痛点是什么？
服务器太多发布不方便？那搞一个 jenkins 或者在 action 上配置好就行。
经常性的有突发性的流量，需要快速扩容？那个可能要上 k8s
为了提高稳定性，担心挂一台服务器，服务就挂了？那我觉得搞一个两个应用服务器，然后套个 cf 自动切换也行。
怎么方便怎么来，从 0 搭建一套东西其实非常痛苦，学习成本会很高，这个过程中服务也会面临不稳定。

[CheckMySoul]

先容器化，然后上阿里云 ACK 服务，就用基础版（免费），然后买几台 ECS 加到节点池里，再买个负载均衡或者 ALB 用就行。

[coderzhangsan]

中小公司基本不需要，业务日均流量超过百万都比较少，大多数情况下这些公司就几台服务器，出于成本考虑，nosql ，甚至是数据库都有可能是自建的。

[SanjinGG]

适合想用的公司，没有一定要到什么规模的规矩。只要有人会，他愿意搞，那就适合

[ipwx]

可以用阿里云的 k8s ，不用运维。这样用起来还是很舒服的。

[lbunderway]

上了就知道了，也不麻烦，维护简单 部署方便

[make115]

@linxuan716 #21 #21 单独本地服务器 cicd 不行吗， 发布镜像，主机执行部署指令

[locoz]

跟规模没什么关系，只要会用，并且基础设施到位（包括但不限于镜像源网络问题、程序容器化、自动构建、自动部署、可靠的存储服务），那上 K8S 是纯粹的收益。而且现在几乎不用考虑维护问题，现在的部署、配置工具都已经很傻瓜化了，K3S 之类的更不用说，按官方文档来，不搞骚操作，很难搞出问题。更别提还有公有云提供的容器服务了，更傻瓜化。

[linxuan716]

@hancai2 你说的第 1 点这个问题在我们的跑批任务脚本上也经常出现，我们使用的是 supervisorctl ，经常出现假死的情况，现在也没有办法解决，第 2 点是个通病，我们现在使用单服务器，如果更新的代码涉及多服务，我都要一个一个的处理

[linxuan716]

@zhengmin451607 我们公司也是用的阿里云服务器，加上我们的图片储存的需求，算起来每年的服务器成本需要大十几万，为了降低成本，自己买了服务器，托管到机房，现在打算把部署在阿里云的服务迁移到机房，这样成本就下来了，所以在考虑要不要使用 k8s

[linxuan716]

@superchijinpeng 政府在成本上的压力会小一些，但公司就要考虑成本了

[tairan2006]

规模不够的话，k8s 会提高成本而不是降低成本。

[linxuan716]

@xiyou007 肯定不是一个公司了，因为我们公司负责这块的开发就两个，一个前端，一个后端，负责对接设备还有一个，现在兼职我们这边的测试了，来来，一块交流下哈~ qlyan16

[linxuan716]

@ytmsdy 也有一方面担心 k8s 平台的稳定性可以不

[billzhuang]

分布式跟 k8s 没有必然关系，传统的自动伸缩也可以做到。

但首先要做到，
1 ，容器化
2 ，部署自动化

上不上 k8s 都可以。

如果使用 AWS 的 eks 的话，升级 k8s 最容易出错的部份。国内云这个问题还好。

k8s 保持最新版本-3 是最挑战的，其他还好，1.33 的无需重启 VPA 特别香。

[xubeiyou]

暂时还是 docker 这一套 K8s 对于传统行业 没啥必要- - 互联网是走有赞的

[cdlnls]

首先用 k8s 的前置条件是不差钱。

1. 开发要有点水平，别服务间调用都搞不清楚的也上 k8s 。
2. 用户数量比开发人员还少的别用（这里点名 增删改查的管理后台类）
3. 服务器没有快速扩容需求的别用
4. 没有 CICD 系统 没有 线上监控系统 的别用
5. 服务器不在云上的 建议 别用，除非你的节点够多
6. 在云上但是是自建集群的 建议 别用（大概率差钱）
7. 用 docker swarm 用得好好的，但是遇到了问题可以考虑用
8. 线上在跑的程序小于 2 位数的别用
9. 大多数服务很少更新 + 没有滚动更新需求 的别用

[sujin190]

@linxuan716 #12 还好吧，阿里云之类镜像服务都有自动化服务吧，授权仓库绑定建 tab 就自定 build ，镜像仓库在设置好触发器自动触发 k8s 更新滚动重启，这不比你拉代码重启还简单

[linxuan716]

@cdlnls 站在技术的角度分析，这个讲的非常中肯，囊括了大部分要考虑到的技术问题

[linxuan716]

@billzhuang 1.33 还没有稳定版的吧 生产上如果不是稳定版的真不敢用

[sagaxu]

90%以上的公司不适合微服务话，也不适合上 k8s ，搞一下 docker 就行了。
现在不是 2010s ，单机可以 64c256g ，3-5 台负载均衡能扛住很大流量。
一般业务服务数不超过 10 个，代码不超过 100 万行，没那么复杂。

有哪些适合引入 k8s 的特征？
流量波动很大，技术上不能简单削峰，经常需要快速扩容缩容；
服务数量很多，几十个上百个服务，且经常新增服务；
机器数量很多，且负载使用很不均匀，浪费和吃紧共存；
研发人员很多，几十个上百个，虚拟化分配资源不够灵活；
重复部署很多，比如 saas 私有化部署，有 k8s 批量部署容易。

[zcl0621]

多大都可以用，CI/CD 能简化不少，release 也方便，环境隔离也是重要的一点。
嫌管理麻烦，rancher+k3s 就解决了，配合 Prometheus ，grafana ，loki （日志），tracing （调用链追踪），研发都会感谢你的。
你也能省出很多麻烦重复的工作。

[coefu]

@songray #6 适合的，把大的拆成小的微服务。

[coefu]

@ksmiloLove #38 这哥们儿给 k8s 贡献过 pr 吗？

[moximo]

阿里云 sae 省心

[xuanbg]

看你有没有自动扩容的需求，有就上，没有的话简单容器化也是一样的。

[hcy]

有状态服务多不多？如果太多而且不好改造 。那建议不要上。

[fffq]

服务扩缩容方便，数据库怎么办？

[jimrok]

不明白为啥跑批会影响主服务，跑批可以独立申请一台主机做，而且可以连接到数据库的 Slaver 服务上读取数据。

[linxuan716]

@fffq 我也遇到了这个问题，我们现在使用的是 mongo 数据库，存储空间已经达到了 1T ，现在查询优化单靠加索引，如果部署到 k8s 上面是不是有什么更好的解决方案？

[linxuan716]

@jimrok 跑批会用到主服务的环境变量及配置，开发为了方便，现在想拆也很难了

[cxh116]

没专业运维不要上，维护成本高。

[cxh116]

23 年的滴滴 k8s 升级事故就知道了，这东西上手容易精通难，半吊子碰到升级之类的，只会带了更多的问题。

[idblife]

@linxuan716
不需要，手动维护成本更低。
等到了 100 个服务，每个服务几十个实例，你自然就去学习 k8s 了。

[bthulu]

先单机抗, 不够了先升级硬件, 目前 EPYC9755 支持 384C6T, 等这个也扛不住了, 就再加一台服务器, 手动部署. 当再次扛不住了, 再加一台服务器, 还是手动部署. 依次类推, 直到手动部署的人扛不住了, 加人. 当人加无可加的时候, 还是扛不住了, 就可以切换 K8S 了.

[Reficul]

想用的 2 个服务 2 台机器都会用，机器就算少也有一定的好处。 不想用的上百台机器也会想用 Ansible 之类的批量命令通道去管，自然也有他们的理由。

这个就和你信什么宗教一样，不信教的觉得信教的愚蠢，反过来也一样。 云原生就是一套方法论，和宗教一样你信不信用不用都可以达到目的。至于适不适合自己，只有自己试试看才有感觉。

[emptyqwer]

@qiangmin #23 哪为啥不用 SAP 呢

[kaicity]

@coefuqin #85 这哥们会叫你开 ssh 给他上去看看

[micean]

我就说一个事，公司曾经有一个项目被某人上了 K8S ，然后一次 deploy 要半个小时，某人还找不到原因……
所以最基本的，你得能解决 k8s 的运维问题，上船容易下船难