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

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

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

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

可以说是几乎免运维的

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

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

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

个体户都可以用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用户数 < 节点数

@linxuan716

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