K8其实从应用角度看核心卖点是解决了服务可伸缩，高可用的问题


但是如果这不是核心诉求，那就没意思了


【 在 lushan5436 的大作中提到: 】
: 公司也是几万人，组里的服务也有每秒2万五，根本不需要k8s，实际上评估的是用k8s，延时变大(本身不熟悉也有关系)，硬件 ...
--
FROM 39.144.44.*

是指pod的重启么？


设计思想问题，k8s从一开始就是实例数量换可靠性
默认应用场景就是一个服务至少>=3个实例在跑
个别实例重部署的延时无关大局，反正99%时间能保证有承诺的可用实例数量
不爽就自己在数量上加冗余去……


它的调度是定时轮询，印象中默认还有措施防止网络抖动或者重载下的响应延迟
相比zk那种要主动保持连接的，调度延时可想而知









【 在 lushan5436 (密如) 的大作中提到: 】
: 高可用，感觉还真不如zk，至少我发现k8s明显在服务宕机后到开始重启时间远大于使用zk管理。
--
FROM 116.233.186.*

zk只能记录服务是否活着，拉起的动作还得自己写

【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 是指pod的重启么？
: 设计思想问题，k8s从一开始就是实例数量换可靠性
: 默认应用场景就是一个服务至少>=3个实例在跑
: ...................
--
FROM 180.167.95.*

CDN拼错了吧


【 在 guotie320 (纳尼) 的大作中提到: 】
: 网络层的CND是个什么东西？
--
FROM 116.233.186.*

就这个单一场景来说，你的描述有些模糊的地方需要澄清：
1、服务因何“主动”，是指计划内的重启，还是意外崩溃？如果指前者，k8s的流程是，通过先在pod上修改状态，然后才会向下影响到容器，如果你所谓立即生效仅指作为一致性存储的zk/etcd感知到这个事情，那么都是立即生效。
2、如果所谓生效是指负载均衡器感知到，那么依赖于具体的负载均衡器策略，这恐怕不能算做zk或者etcd的差别，或者说类似的策略下，效果是几乎一样的。
3、如果是指重新调度，同样的，取决于你的调度器策略，zk本身恐怕没有调度能力，etcd也一样。k8s默认的调度器确实是基于轮询的，但更多是因为它要照顾到通用场景，而且可以通过调优来平衡调度的延迟和公平。也许你基于zk实现的调度方案对延迟更加重视，那么在k8s中你完全可以通过自定义调度器来实现类似的效果。

【 在 lushan5436 (密如) 的大作中提到: 】
: 你确信么？，我不清楚，k8s管理的是pod，不是服务本身，zk管理的是服务本身，如果服务主动退出，zk是立即生效。服务退出，pod退出，etcd监控到，怎么也谈不上快。而且etcd监控不知道是不是轮询，如果是更慢
--
FROM 221.220.225.*