Istio
2024-06-07 20:09:32 1 举报
AI智能生成
登录查看完整内容
Istio的优势、原理
作者其他创作
大纲/内容
从微服务的工具集观点来看, Kubernetes本身是支持微服务的架构, 在Pod中部署微服务很合适, 也已经解决了微服务的互访互通问题, 但对服务间访问的管理如服务的熔断、 限流、 动态路由、 调用链追踪等都不在Kubernetes的能力范围内
Istio的服务发现就是从Kube-apiserver中获取 Service和 Endpoint, 然后将其转换成 Istio服务模型的 Service 和 ServiceInstance, 但是其数据面组件不再是Kube-proxy, 而是在每个 Pod 里部署的 Sidecar, 也可以将其看作每个服务实例的13;Proxy。 这样, Proxy 的粒度就更细了, 和服务实例的联系也更紧密了, 可以做更多更细粒度的服务治理
Kubernetes的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息, 并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。 Kubernetes只提供了4层负载均衡能力, 无法基于应用层的信息进行负载均衡, 更不会提供应用层的流量管理, 在服务运行管理上也只提供了基本的探针机制, 并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。
数据面Sidecar运行在Kubernetes的Pod里, 作为一个Proxy和业务容器部署在一起
1. 数据面
Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成, 省去了再搭一个类似Eureka 的注册中心的麻烦, 更避免了在 Kubernetes 上运行时服务发现数据不一致的问题。
2.统一服务发现
Istio的所有路由规则和控制策略都是通过 Kubernetes CRD实现的, 因此各种规则策略对应的数据也被存储在 Kube-apiserver 中, 不需要另外一个单独的 APIServer 和后端的配置管理。
3.基于Kubernetes CRD描述规则
Istio优势
分支主题
Istio与 k8s
架构对比
概要
工作机制及架构图
Istio
0 条评论
回复 删除
下一页