Istio 服务网格从逻辑上分为数据平面和控制平面,因为Istio是Envoy的控制平面。
从完整意义上来讲,Istio服务网格逻辑上分为数据平面
和控制平面
。
目前Istio已经回归单体服务架构了
Pilot、Citadel、Galley
,新版已经移除限流的组件Mixer
。 Pilot
: 控制面的核心组件,负责对接 Envoy 数据面,也可以解析上层抽象出来的 lstio 配置,转换成数据面可以识别的 xDS 协议配置并分发到各个 Envoy。Galley
: 为更好的解耦职责,它在 lstio 1.1 后由仅负责配置验证升级成了控制面的配置管理中心,可以对接不同注册中心,用于为服务网格提供配置输入能力。Citadel
: 责服务网格里安全相关功能,为服务和用户提供认证和鉴权、管理凭据和 RBAC 等相关能力。Istiod
: 新加入的istiod接手了很多很多的功能,简单的来说,istiod承担所有功能!sidecar
的形式与服务进程一起运行.不存在服务网格的业务
一般典型的基于kubernetes
部署的应用有前端、后端、数据库,其应用的流量大致有两部分组成
service-to-service
,即东西向流量。
Ingress Gateway
,其实IngressGateway
与Istio
的代理服务sidecar
类似。以及网格内部的服务不止需要请求网格内部的服务,甚至可能需要请求网格之外的服务。例如:redis外置、MySQL外置等,出口流量一般通过EgressGatewy
,即南北向流量。
如果没有用到服务网格,那么你可能会遇到以下问题
0信任网络
,通常的网络插件是支持节点到节点之间的数据加密的,但是从Pod内部流出到出口之间的流量依旧无法保证其安全性。
ipvs
,无法实现高级负载。例如流量切割、流量镜像、AB测试等等…
目前很多服务网格的特性上重叠性颇高,他们几乎都具有下列功能.
通过负载均衡、服务间的身份验证、监控等方法,Istio 可以轻松地创建一个已经部署了服务的网络,而服务的代码只需很少 更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持,而代理会拦截微服务之间的所有网络通信,然后使用其控制平面的功能来配置和管理 Istio,这包括:
Kubernetes
平台基于Service
的服务发现是相对于简陋的,因为基于内核形态和dns以及iptables来进行服务发现,这些是远远满足不了高级需求的.