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