- 主题:各位大神就这个架构的话招个人搭架构需要什么要求
别鼓吹k8s，实际上很多组件在k8s上玩不转。
而且性能损失，延时都有。好处当然更多。
我知道有些大公司没有用k8s那一套，也活得好好的
【 在 Xjt 的大作中提到: 】
: 现在这些东西云原生基本都弄完了。。。自己搭和构建k8s集群的时代早过去了，如果业务量不大，连弹性都是云原生自动控制，后台配置下就行了
--
FROM 223.104.39.*
微服务和k8s有必然关系么？
我觉得k8s核心是调度编排。其他组件还真没什么好
【 在 guestking 的大作中提到: 】
: 微服务太多的话，如果没有k8s这类的东西，很难玩得转
: 你说有些大公司不用k8s，那是用了别的？
:
--
FROM 223.104.38.*
公司也是几万人，组里的服务也有每秒2万五，根本不需要k8s，实际上评估的是用k8s，延时变大(本身不熟悉也有关系)，硬件成本还上升。
lvs，nginx，frontend，mid，backend。都Java服务，基础组件zk，kafka，HBASE，hdfs，MySQL
【 在 oldwatch 的大作中提到: 】
: 不用k8就意味着
: 从服务发现，请求路由到负载均衡，弹性伸缩自己攒全套
:
: ...................
--
FROM 223.104.3.*
高可用，感觉还真不如zk，至少我发现k8s明显在服务宕机后到开始重启时间远大于使用zk管理。
【 在 javafish 的大作中提到: 】
: K8其实从应用角度看核心卖点是解决了服务可伸缩，高可用的问题
:
: 但是如果这不是核心诉求，那就没意思了
: ...................
--
FROM 117.136.0.*
你确信么？，我不清楚，k8s管理的是pod，不是服务本身，zk管理的是服务本身，如果服务主动退出，zk是立即生效。服务退出，pod退出，etcd监控到，怎么也谈不上快。而且etcd监控不知道是不是轮询，如果是更慢
【 在 sayinger 的大作中提到: 】
: 这里所谓"使用zk管理"能支持哪些特性呢，如果是某些特殊场景，那比k8s默认的scheduler快并不奇怪。
: 但是k8s scheduler本身是可以调优的，另外如果你的场景特殊也可以自己实现scheduler，应该不会比zk差，毕竟从性能上来说etcd比zk高
:
--
FROM 120.244.162.*