人人共享 Istio ⛵️💡🎉
什么是服务网格?
那么,Istio是做什么的呢?
那么,什么是边车模式?
Istio 的工作原理是什么?
这只需要(非常)一点 Kubernetes 知识。
假设您有一个电子商务应用程序。该应用程序包含以下组件:
- 产品服务 - 此服务负责处理所有与产品相关的信息,例如名称、价格和库存。
- 发票服务 - 此服务负责处理所有与发票相关的信息,例如创建账单、跟踪付款情况等。
- 通知服务 - 此服务负责处理所有与通知相关的信息,例如发送电子邮件。
请注意,可能还有其他服务,但为了简洁起见,我们先到此为止。
在单体架构中,所有这些服务都运行在同一个应用程序(执行环境)中。
因此,每当发票服务需要调用通知服务时,它通常只需要进行一个简单的方法调用即可。
也就是说,发票服务无需检查通知服务是否正常运行,无需查找其所在位置,也无需通过网络建立连接来请求并等待响应。
在微服务架构中,当发票服务需要调用通知服务时。
发票服务首先需要验证通知服务是否可用。(暂且称之为服务imaginary。)
如果通知服务可用,则发票服务必须找到连接到通知服务的方法(例如,其 DNS 名称)。
然后,发票服务将向通知服务发出请求。
TL;DR 在微服务世界中,服务之间存在一个网络来进行通信。
该imaginary服务名为Service registers。
服务在启动或关闭时,会将它们的位置和状态告知服务注册表。
任何invoice想要连接到另一个服务(例如)的服务(例如notification)都会首先查询服务注册表,以获取有关如何以及在哪里连接的信息,然后进行连接。
但如果服务突然终止会发生什么?服务无法shut down向服务寄存器发送正确的信号。这意味着服务寄存器显示该服务正在运行,但实际上它已停止运行。
为了避免这些情况,我们需要health checkers……
健康检查器会不时地向服务发送 ping 请求,或者服务会不时地通知健康检查器其状态。
这些提示音叫做heart beat💗。
当服务停止发送心跳信号时(通常是在达到阈值水平以补偿网络损失之后),该服务将被标记为已关闭。
将来任何向服务注册中心提出的服务请求都将获得正常服务的地址。
为了使微服务正常工作,健康检查器和服务注册中心需要是高可用性的组件。
TL;DR 在微服务架构中,我们需要服务注册中心和健康检查器才能使我们的应用程序正常工作。
在这篇文章中,我们将了解 Istio 是什么,以及它如何帮助解决问题。
在深入了解 Istio 之前,我们需要了解service mesh……
什么是服务网格?
Istio 网站对服务网格的描述如下:
服务网格一词用于描述构成此类应用程序的微服务网络以及它们之间的交互。
在微服务架构中,会有许多不同容量的服务实例运行,它们是分布式的,并且这些服务之间需要相互连接。服务网格描述了这些相互连接的服务及其交互。
那么,Istio是做什么的呢?
简而言之,Istio 的功能如下:
微服务架构中的每个服务都将包含一些公共服务,例如日志记录、监控和网络(用于负载均衡等)。Istio 会将这些公共服务从您的应用程序中提取出来,因此您的应用程序无需关心这些公共服务。
Istio 在服务网格中提供以下服务:
- 连接
- 连接服务网格内的各项服务
- 有助于管理交通
- 自动负载均衡
- 控制
- 控制进入服务的请求
- 路由规则
- 重试
- 故障转移
- 故障注入及其他
- 控制进入服务的请求
- 安全的
- 确保服务间通信安全
- 授权并验证请求
- 观察
- 自动收集指标、日志和跟踪信息。
最重要的是,它能做到所有这些(以及其他一些事情)without any changes in the application code。
哇!Istio 是如何在不修改任何代码的情况下实现这一点的?
Istio 通过以下方式实现Sidecar pattern:
那么,什么是边车模式?
目前,Istio 运行在 Kubernetes 之上。
如果您想了解 Kubernetes 是什么,请查看这篇文章。
在 Kubernetes 环境中,一个 Pod 包含一个或多个容器。Istio 会将一个容器附加到 Pod 内部,与应用程序容器一起运行。这个与应用程序容器并行运行的容器被称为 Istio 容器sidecar。
这种将边车集装箱连接到摩托车上的方式(就像将边车连接到摩托车上一样)被称为sidecar pattern。
点击这里查看更多关于边车模式的信息。
好的,那么这个边车函数是如何帮助 Istio 实现其承诺的功能的呢?
继续阅读……
Istio 的工作原理是什么?
在 Istio 术语中,这个 sidecar 容器被称为proxy容器。代理容器与应用容器同步运行,并随其生命周期结束而终止。代理容器将决定哪些请求可以进出应用容器。
等等,这是否意味着应用程序的性能会降低?延迟会增加?
The short answer is yes.
添加此代理容器会增加延迟并降低性能。
但是代理容器将使用Envoy代理。
Envoy 是一款专为大型现代面向服务架构设计的 L7 代理和通信总线。 - Envoy 网站
Envoy是用C++编写的,它轻量级且速度极快⚡️。
这意味着每次服务调用增加的开销非常小。
想了解更多关于 Envoy 代理的信息?请点击这里。
这些代理负责应用程序中发生的所有通信。
好的,现在有了边车代理,我们可以控制请求,但是如何向代理提供规则或配置呢?如何从边车代理收集所有遥测数据呢?如果您有这些疑问,那么我们找对了方向。
边车代理的遥测数据由混音器收集。
混合器还负责在整个服务网格中应用策略和访问控制。
Mixer + Envoy 代理 => 数据平面
混合器和代理服务器被称为data planeIstio。
简而言之,Envoy 代理负责将请求和响应代理到容器中。而 Mixer 则负责在整个服务网格中强制执行访问控制和使用策略,并从 Envoy 代理(以及其他服务)收集遥测数据。
与 Kubernetes 类似,Istio 也有控制平面control plane。控制平面是brainIstio 的核心。
在这里我们可以定义策略/配置/规则。这些规则会即时应用,不会造成任何停机时间。
Istio 的控制平面由以下部分组成:
- 飞行员👩✈️
- 城堡🏛
- 厨房🛒
飞行员
顾名思义,飞行员是帮助使节代理处理请求的向导。
他们向特使代理人提供以下信息:
- 服务发现
- 交通管理
- 弹性
我们通过文件向 Istio 提供路由规则yaml。规则生效后,Pilot 会获取这些规则,并在运行时将其提供给 Envoy 代理。这使我们能够灵活地动态应用配置更改。
借助 Pilot,我们可以通过路由规则提供服务发现功能。我们可以指定如果 URI 指向/review运行reviews在特定端口上的应用程序,9080如下所示:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
http:
- match:
- uri:
exact: /review
route:
- destination:
host: reviews
port:
number: 9080
点击这里了解更多关于虚拟服务的信息。
我们可以使用 Pilot 来管理服务的流量。例如,我们可以将 90% 的请求路由到v1应用程序,其余的路由10%到v2如下所示的优秀服务:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
我们还可以指定目的地规则。
- 要使用哪种类型的负载均衡器?
- 最大连接数
- 超时和其他规则如下。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: destall
namespace: testns
spec:
# DNS name, prefix wildcard, short name relative to context
# IP or CIDR only for services in gateways
host: destall.default.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
connectionPool:
tcp:
maxConnections: 99
connectTimeout: 6s
了解更多关于DestinationRule 的信息。
这里提供多种负载均衡选项。
注意:配置方式有数百种之多,一篇博文根本无法全部解释清楚。
简而言之,Pilot 为 Envoy 代理提供配置数据。
厨房
我们提供给 Istio 的所有配置都必须经过正确验证。验证后的规则或配置应被接收和处理。最后,处理后的数据应发送到 Pilot 和 Mixer。
Galley 负责验证、摄取、处理并将配置发送到 Pilot 和 Mixer。
Istio运行在Kubernetes之上。Galley还负责从Kubernetes获取用户信息并将其提供给Istio组件。
简而言之,Galley 是一个验证和分发代理,负责验证配置数据并将其分发给 Pilot 和 Mixer。
堡垒
Citadel 负责加密服务间的通信和终端用户身份验证。借助 Citadel,我们可以对 Envoy 代理强制执行安全策略。
简而言之,Citadel 是代理的保单提供商。
然后,代理服务器将利用来自 Citadel 和 Pilot 的信息来控制、连接(限制和路由流量)并保护服务。
希望以上内容能让您对 Istio 有个大致的了解Istio。访问istio.io可获取更多关于 Istio 的信息。
现在你想在 Kubernetes 上使用 Istio 部署一个示例应用程序,请查看这篇文章。
如果你喜欢这篇文章,请点赞或留言。❤️
如果您觉得文章中有什么错误或遗漏,欢迎留言评论 :)
你可以在推特上关注我。
文章来源:https://dev.to/sendilkumarn/istio-for-everyone-5hgb

