这是一个创建于 327 天前的主题，其中的信息可能已经有所发展或是发生改变。
k8s 运维平台现在已经很流行了，但也有说认为只有大公司才能使用，小公司使用反而麻烦，你认为呢？
 |
1 idblife 2025 年 7 月 23 日 via iPhone 2
问出这个问题说明你还不需要 |
 |
2 lujiaxing 2025 年 7 月 23 日看你的业务规模跟业务复杂程度. |
 |
3 songray 2025 年 7 月 23 日跟规模没关系，跟业务有关系。 |
 |
4 linxuan716 2025 年 7 月 23 日@idblife 我现在遇到一个问题，我们公司是做物联网平台的，有一个主服务，比较大，其它还有三、五个小服务，比较依赖于主服务，想转到 k8s 平台上，但又觉得会不会以后维护起来麻烦 |
 |
5 jiames1969 2025 年 7 月 23 日以前专家有过讨论，通用业务日流量 1000w +上 k8s 才划算。 |
|
7 linxuan716 2025 年 7 月 23 日@lujiaxing 现在我们的平台单台在跑批的时间点会使用 CPU ，这样会导致正常的数据入库延迟，这样算不算是单台设备已经不能承受了 |
 |
9 sujin190 2025 年 7 月 23 日主要问题是业务量不够上了 k8s 会贵不少，维护哪复杂了，更简单了吧 |
|
11 songray 2025 年 7 月 23 日@linxuan716 k8s 的场景是，有时候你的主服务或子服务的流量会暴增，或者是你的业务天然需要部署多个相同服务（比如需要尽可能靠近客户端的边缘计算场景）。 |
|
12 linxuan716 2025 年 7 月 23 日@sujin190 现在我们后台使用 django ，发布上线只需要拉下代码，然后使用 uwsgi 重启下服务就可以了，如果上了 k8s ，还需要打包镜像 |
 |
15 CoderGeek 2025 年 7 月 23 日@linxuan716 现在我们的平台单台在跑批的时间点会使用 CPU ，这样会导致正常的数据入库延迟，这样算不算是单台设备已经不能承受了 你可以把跑批任务分离出去 异步不影响你主要应用即可 不需要 k8s |
 |
17 johnniang 2025 年 7 月 23 日 via Android 1
感觉目前用 Docker Swarm 就足够了。 |
|
18 linxuan716 2025 年 7 月 23 日@songray 这们现在是磁盘不够了就直接扩容，CPU 与内存没有考虑过，所以就导致一年比一年难维护 |
 |
19 monkeyWie 2025 年 7 月 23 日 1
再小都可以上，前期可以直接用 k3s ，后面要是顶不住了再上集群，其实 k8s 配合 CI/CD 更方便部署，打好镜像然后一个命令就滚动升级了 |
 |
22 litchinn 2025 年 7 月 23 日k8s 最大的优势在自动扩缩容，也就是流量大时能够自动启动新节点，流量减小时自动关闭一些节点以节省资源 |
 |
23 traderlqm 2025 年 7 月 23 日1.云公司 |
 |
24 testcgd 2025 年 7 月 23 日 via Android可以先容器化，完了之后再考虑要不要用 k8s ，如果服务变更少，没有扩缩容需求可以先不上 |
|
25 lujiaxing 2025 年 7 月 23 日 1
@linxuan716 额这不算啥新思路 这属于常规操作 正常来说 CPU 密集型的后台任务都是需要用单独的设备部署的. 绝对绝对不可以与核心业务共享硬件资源的. |
|
26 linxuan716 2025 年 7 月 23 日@testcgd 是的，我们现在领导也想实现容器化，因为有一些客户想独立部署，我们也可以节省部署时间 |
 |
29 raydied 2025 年 7 月 23 日如何界定需不需要，我不知道，但吞吐量绝对不是指标性要求。 我这边有一个智慧工地系统，业务场景边界比较清晰，模块比较多； 然后就上了，甚至运行在现场的本地服务器上（客户一直看云视频，流量遭不住）——偶尔断个电，重启可方便了。 |
|
30 linxuan716 2025 年 7 月 23 日@raydied 我们的服务现在是在云服务器，打算迁移到机房，以前不用考虑意外问题，但现在也确实考虑这个问题 |
 |
31 salmon5 2025 年 7 月 23 日 1
当你需要练手的时候 |
 |
32 fishioon 2025 年 7 月 23 日如果部署的服务比较多，k8s 带来的收益会高一些；架构切换，一定要想清楚收益啊 |
|
33 traderlqm 2025 年 7 月 23 日@qiangmin 业务重复度高，需要整合，降低维护成本（就是那个大中台，大后端啥的）。业务有弹性需求，类似双 11 有巨量访问需求，其他时间都是少量访问（扩缩容）。业务需要降本增效，公有云太贵，VMware 也太贵。业务需要国产化，需要完全的安全可控。 |
 |
35 zmcity 2025 年 7 月 23 日 1
所有公司都适合 k8s ，维护成本直线降低，小型服务直线降低运维难度，大型服务很多轮子就不用重复造了 |
 |
36 hancai2 2025 年 7 月 23 日 1
我觉得再小都可以，除非你们一直就一台服务器一个服务。 我这边有个项目最开始就只有 3 个服务，两台 4c8g 服务器。我嫌麻烦就只弄了个 docker-compose, 后面就发现需要一堆 k8s 的能力。 如果你们有专门的运维岗， 真不如 k8s 一把梭。 |
 |
37 ksmiloLove 2025 年 7 月 23 日这玩意管理应用和资源好用，不是微服务啥的也好用阿。 |
|
38 ksmiloLove 2025 年 7 月 23 日这帖这么久了，期待 defunct9 来锐评一下 |
 |
39 nativeBoy 2025 年 7 月 23 日 via Android我们公司在用，我发现这东西包含了注册中心、配置中心的功能，而且自动将异常 pod 重新拉起，都很适合现网的情况 k8s 对小公司来说比较重，但是降低了维护成本，当机器多起来的时候，现网有几千个 pod 在运行，维护成本会比较高。虽然你可以搭建管理平台来维护，但是在这之前你用 kubectl 就能处理多数问题，确实很方便 |
 |
40 zhengmin451607 2025 年 7 月 23 日我们公司就我一个开发，现在是一个负载均衡+2 台服务器最传统的布局，也想搞这种 k8s 容器化之类的，但是对比了下成本，阿里云的 eci 容器什么的费用比单独自己买 ecs+负载均衡贵啊。 |
 |
42 yuan1028 2025 年 7 月 23 日只要不是单体服务，都是值得的，核心是有人要负责 k8s 小公司分享： 可以说是几乎免运维的 |
 |
43 kennylam777 2025 年 7 月 23 日@hancai2 對, 光是 health check 及 rediness check 就有上 k8s 的理由了, 自動重啟起碼能讓 devs 有更多時間去排查, 有時候 daemon 掛了但 fg process 是沒反應的 另外是 readiness, 用 readniess + service 起碼可以自動排除掉 health check 不過關的 pod, 在滾動升級但一直有請求進來的場景也可以減少對用戶的感知 |
 |
44 latifrons 2025 年 7 月 23 日 3
如果实在受不了 k8s/k3s 的学习曲线的话我推荐 Hashicorp 的 Consul+Nomad ，单文件轻量级，一样可以做容器编排/健康检查/服务发现/持久化，我们在生产上几十个服务上百个容器实例，很稳。 |
 |
45 jqknono 2025 年 7 月 23 日个体户都可以用 |
 |
46 cutiechi 2025 年 7 月 23 日现在就连政府也有很多单节点的 k8s ，3 节点以上的就更多了 |
 |
47 pkoukk 2025 年 7 月 23 日公司有钱给钱就能用，和规模没关系 |
 |
48 cheng6563 2025 年 7 月 23 日小公司，除非你孝道不用处理滚动跟新之类的问题，不然相对写一堆脚本，可能还不如上 k8s 容易些。 |
 |
49 pc10201 2025 年 7 月 23 日k8s 能解决很多标准化的问题，比如发布，监控，计划任务等，所有的应用都跑在这个上面，后期能省很多事，另外阿里云有免费的 k8s 管理服务 |
 |
50 guoguobaba 2025 年 7 月 23 日k8s 用在测试平台什么时候，什么规模都不会晚。 生产环境如果负载不大，k8s 也是运维成本最低的方案 |
 |
51 rickzrn 2025 年 7 月 23 日看完之后我觉得需要, 因为: 但问题也有, |
 |
53 bigbugbag 2025 年 7 月 23 日@linxuan716 #7 我觉得这是你资源没有做隔离或限制，需要限制一下跑批的 CPU 使用量，不要影响到正常业务的用量 |
 |
54 wang1x1 2025 年 7 月 23 日 1
@latifrons 居然碰到了用 Consul + Nomad 的团队！我们目前也在深度的使用 Consul + Nomad ，总体感觉比运维 k8s 要简单很多。 |
 |
55 xiyou007 2025 年 7 月 23 日不知道还以为是一个公司了， 我们跟你们非常相似，我们也是 Python 写的物联网平台。 加个 v 。交流一下啊 |
|
56 hancai2 2025 年 7 月 23 日@kennylam777 对的，像我们公司做私有化交付项目比较多。 客户环境不稳定，有时候客户维护物理服务器，可能都不告知我们。服务自愈能力挺重要。遇到扩容、缩容都好解决一点。比较麻烦的是，现在搞国产替代，有些垃国产系统对于 k8s 兼容性不好。 |
 |
58 realpg 2025 年 7 月 23 日规模无关. |
 |
59 lysShub 2025 年 7 月 23 日用户数 < 节点数 |
|
60 johnniang 2025 年 7 月 23 日Docker Swarm 可以添加管理节点和工作节点，服务副本可以手动伸缩（例如：docker service scale stack_service=3 ），不停机更新，负载均衡，服务实例也可以运行到任意节点，部分节点挂了也会自动在其他节点运行新的实例。 |
 |
62 ytmsdy 2025 年 7 月 23 日 1
首先，不要为了上 k8s 而上 k8s 。你要先考虑一下现在运维的痛点是什么？ |
 |
63 CheckMySoul 2025 年 7 月 23 日先容器化，然后上阿里云 ACK 服务，就用基础版（免费），然后买几台 ECS 加到节点池里，再买个负载均衡或者 ALB 用就行。 |
 |
64 coderzhangsan 2025 年 7 月 23 日中小公司基本不需要，业务日均流量超过百万都比较少，大多数情况下这些公司就几台服务器，出于成本考虑，nosql ，甚至是数据库都有可能是自建的。 |
 |
65 SanjinGG 2025 年 7 月 23 日适合想用的公司，没有一定要到什么规模的规矩。只要有人会，他愿意搞，那就适合 |
 |
66 ipwx 2025 年 7 月 23 日可以用阿里云的 k8s ，不用运维。这样用起来还是很舒服的。 |
 |
67 lbunderway 2025 年 7 月 23 日上了就知道了，也不麻烦，维护简单 部署方便 |
 |
69 locoz 2025 年 7 月 23 日 1
跟规模没什么关系，只要会用，并且基础设施到位（包括但不限于镜像源网络问题、程序容器化、自动构建、自动部署、可靠的存储服务），那上 K8S 是纯粹的收益。而且现在几乎不用考虑维护问题，现在的部署、配置工具都已经很傻瓜化了，K3S 之类的更不用说，按官方文档来，不搞骚操作，很难搞出问题。更别提还有公有云提供的容器服务了，更傻瓜化。 |
|
70 linxuan716 2025 年 7 月 23 日@hancai2 你说的第 1 点这个问题在我们的跑批任务脚本上也经常出现，我们使用的是 supervisorctl ，经常出现假死的情况，现在也没有办法解决，第 2 点是个通病，我们现在使用单服务器，如果更新的代码涉及多服务，我都要一个一个的处理 |
|
71 linxuan716 2025 年 7 月 23 日@zhengmin451607 我们公司也是用的阿里云服务器，加上我们的图片储存的需求，算起来每年的服务器成本需要大十几万，为了降低成本，自己买了服务器，托管到机房，现在打算把部署在阿里云的服务迁移到机房，这样成本就下来了，所以在考虑要不要使用 k8s |
 |
73 tairan2006 2025 年 7 月 23 日规模不够的话，k8s 会提高成本而不是降低成本。 |
|
74 linxuan716 2025 年 7 月 23 日@xiyou007 肯定不是一个公司了，因为我们公司负责这块的开发就两个，一个前端，一个后端，负责对接设备还有一个，现在兼职我们这边的测试了，来来，一块交流下哈~ qlyan16 |
 |
76 billzhuang 2025 年 7 月 23 日 via iPhone分布式跟 k8s 没有必然关系，传统的自动伸缩也可以做到。 但首先要做到， 上不上 k8s 都可以。 如果使用 AWS 的 eks 的话，升级 k8s 最容易出错的部份。国内云这个问题还好。 k8s 保持最新版本-3 是最挑战的，其他还好，1.33 的无需重启 VPA 特别香。 |
 |
77 xubeiyou 2025 年 7 月 23 日暂时还是 docker 这一套 K8s 对于传统行业 没啥必要- - 互联网是走有赞的 |
 |
78 cctv6 2025 年 7 月 23 日 4
首先用 k8s 的前置条件是不差钱。 1. 开发要有点水平，别服务间调用都搞不清楚的也上 k8s 。 |
|
79 sujin190 2025 年 7 月 23 日@linxuan716 #12 还好吧，阿里云之类镜像服务都有自动化服务吧，授权仓库绑定建 tab 就自定 build ，镜像仓库在设置好触发器自动触发 k8s 更新滚动重启，这不比你拉代码重启还简单 |
 |
82 sagaxu 2025 年 7 月 23 日 1
90%以上的公司不适合微服务话，也不适合上 k8s ，搞一下 docker 就行了。 有哪些适合引入 k8s 的特征？ |
 |
83 zcl0621 2025 年 7 月 23 日多大都可以用，CI/CD 能简化不少，release 也方便，环境隔离也是重要的一点。 |
 |
86 moximo 2025 年 7 月 23 日 via Android阿里云 sae 省心 |
 |
87 xuanbg 2025 年 7 月 23 日看你有没有自动扩容的需求，有就上，没有的话简单容器化也是一样的。 |
 |
88 hcy 2025 年 7 月 23 日有状态服务多不多？如果太多而且不好改造 。那建议不要上。 |
 |
89 fffq 2025 年 7 月 23 日服务扩缩容方便，数据库怎么办？ |
 |
90 jimrok 2025 年 7 月 23 日不明白为啥跑批会影响主服务，跑批可以独立申请一台主机做，而且可以连接到数据库的 Slaver 服务上读取数据。 |
|
91 linxuan716 2025 年 7 月 23 日@fffq 我也遇到了这个问题，我们现在使用的是 mongo 数据库，存储空间已经达到了 1T ，现在查询优化单靠加索引，如果部署到 k8s 上面是不是有什么更好的解决方案？ |
 |
93 cxh116 2025 年 7 月 23 日 via Android没专业运维不要上，维护成本高。 |
|
94 cxh116 2025 年 7 月 23 日 via Android23 年的滴滴 k8s 升级事故就知道了，这东西上手容易精通难，半吊子碰到升级之类的，只会带了更多的问题。 |
|
95 idblife 2025 年 7 月 23 日@linxuan716 |
 |
96 bthulu 2025 年 7 月 23 日先单机抗, 不够了先升级硬件, 目前 EPYC9755 支持 384C6T, 等这个也扛不住了, 就再加一台服务器, 手动部署. 当再次扛不住了, 再加一台服务器, 还是手动部署. 依次类推, 直到手动部署的人扛不住了, 加人. 当人加无可加的时候, 还是扛不住了, 就可以切换 K8S 了. |
 |
97 Reficul 2025 年 7 月 23 日想用的 2 个服务 2 台机器都会用，机器就算少也有一定的好处。 不想用的上百台机器也会想用 Ansible 之类的批量命令通道去管，自然也有他们的理由。 这个就和你信什么宗教一样，不信教的觉得信教的愚蠢，反过来也一样。 云原生就是一套方法论，和宗教一样你信不信用不用都可以达到目的。至于适不适合自己，只有自己试试看才有感觉。 |
 |
100 micean 2025 年 7 月 23 日我就说一个事，公司曾经有一个项目被某人上了 K8S ，然后一次 deploy 要半个小时，某人还找不到原因…… |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
