- 主题:Dubbo, Spring Cloud, Kubernetes傻傻分不清楚！
多实例能保可靠性，方便交替部署
但是多实例就必须有前置的负载均衡
然后负载均衡自己又要多实例保可靠性
就必须用服务发现来隐藏部署细节
有没有k8s都是这一套路数顺下来
spring cloud这里走了一个取巧就是做客户端负载均衡
代价就是断路器什么的统统要一揽子放在客户端
【 在 MrBright (没有烟抽的日子) 的大作中提到: 】
: 顶多用个swarm就够了，大部分情况下单应用就行。
: 就图个负载均衡省事。
--
FROM 116.233.90.*
什么叫做k8s用docker部署？
只用k8s的pod/service/deployment 然后ingress/configmap什么都不用？
【 在 licy (上网不便, msg收不到) 的大作中提到: 】
: k8s跟spring cloud有些功能重合，但是个人严重不看好k8s istio这些，这东西如果做不到硬件里边，软件的永远有效率问题
: 我们是这么用的，k8s用docker部署，解决部署便利、内部网络等问题
: 然后用一个ng做统一入口
: ...................
--
FROM 116.233.90.*
ingress,dns那堆都不用的话
何不直接rancher里头点点镜像发布好了
【 在 licy (上网不便, msg收不到) 的大作中提到: 】
: 对
: k8s拉起docker就行了，用了docker网络
: 其他的几乎都没使用
: ...................
--
FROM 116.233.90.*
一般都会前置一个单独的负载均衡
K8s默认基于dns好像就是简单轮转
【 在 childewuque (childewuque) 的大作中提到: 】
: k8s里用dns，这样服务只请求域名就可以了
: 用不用k8s主要还是看业务规模和流量弹性吧
--
FROM 116.233.90.*
本来是service->pods
不过因为k8s在service一层能做（肯做）的东西太弱
最多就是面向Ip做个简单的LoaderBalancer，网络层无脑转发
所以业务需求比较高的（ssl加密/鉴权/业务级路由...）
还会在一个（或多个）service前面加一层ingress
一般拿nginx之类的跑
绑定dns（和ssl证书），鉴权诸如此类都放在这一层
一个单一url暴露出作为服务调用入口
其他内网服务就可以拿着url发http(s)调用了
如果是需要暴露到公网，还要再对接防火墙策略
【 在 childewuque (childewuque) 的大作中提到: 】
: 你这个单独的东东是指的 外部请求通过nginx转发到k8s内， 每个服务都有一个前置的gateway/类似的代理？
--
FROM 116.233.90.*