- 主题:各位大神就这个架构的话招个人搭架构需要什么要求
k8s和你说的这些不在一个架构层面上
k8s某种意义上是在软件（容器虚拟化）层重建了整套网络基础架构
在这个架构之上才是lambda之类应用层的东西
当然，普通公司确实没有裸用k8s的必要，小公司直接跑docker
大了之后上云用公云自己的运维平台
私云自己搭k8这种不是常见场景
【 在 Xjt (Voldemort) 的大作中提到: 】
: 我可不鼓吹k8s，我现在最喜欢的是serverless函数计算，aws lambda或者阿里云的function compute，感觉这才是未来。比k8s好太多了
--
FROM 116.233.186.*
不用k8就意味着
从服务发现，请求路由到负载均衡，弹性伸缩自己攒全套
小规模的话用spring cloud/netflix组件之类攒了也就攒了
规模大的话自己得寨一堆东西
【 在 lushan5436 (密如) 的大作中提到: 】
: 微服务和k8s有必然关系么？
: 我觉得k8s核心是调度编排。其他组件还真没什么好
--
FROM 116.233.186.*
那原来是啥方案？
物理机？虚拟化？容器？
【 在 lushan5436 (密如) 的大作中提到: 】
: 公司也是几万人，组里的服务也有每秒2万五，根本不需要k8s，实际上评估的是用k8s，延时变大(本身不熟悉也有关系)，硬件成本还上升。
: lvs，nginx，frontend，mid，backend。都Java服务，基础组件zk，kafka，HBASE，hdfs，MySQL
--
FROM 116.233.186.*
是指pod的重启么？
设计思想问题，k8s从一开始就是实例数量换可靠性
默认应用场景就是一个服务至少>=3个实例在跑
个别实例重部署的延时无关大局，反正99%时间能保证有承诺的可用实例数量
不爽就自己在数量上加冗余去……
它的调度是定时轮询，印象中默认还有措施防止网络抖动或者重载下的响应延迟
相比zk那种要主动保持连接的，调度延时可想而知
【 在 lushan5436 (密如) 的大作中提到: 】
: 高可用，感觉还真不如zk，至少我发现k8s明显在服务宕机后到开始重启时间远大于使用zk管理。
--
FROM 116.233.186.*
CDN拼错了吧
【 在 guotie320 (纳尼) 的大作中提到: 】
: 网络层的CND是个什么东西？
--
FROM 116.233.186.*