嵊州建设局网站,快递网站建设需求分析,网站建设案例欣赏,快手做电商需要投资多少钱Istio 是一个开源的服务网格#xff0c;可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台#xff0c;开发者必须使用微服务设计架构以实现可移植性#xff0c;而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio 采用一…Istio 是一个开源的服务网格可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台开发者必须使用微服务设计架构以实现可移植性而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio 采用一种一致的方式来保护、连接和监控微服务降低了管理微服务部署的复杂性。
从架构设计上来看Istio 服务网格在逻辑上分为控制平面和数据平面两部分。其中控制平面 Pilot 负责管理和配置代理来路由流量并配置 Mixer 以实施策略和收集遥测数据数据平面由一组以 Sidecar 方式部署的智能代理Envoy组成这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。 作为代理Envoy 非常适合服务网格的场景但要发挥 Envoy 的最大价值就需要使它很好地与底层基础设施或组件紧密配合。Envoy 构成了服务网格的数据平面Istio 提供的支撑组件则是创建了控制平面。 一方面我们在 Envoy 中看到可以使用静态配置文件或使用一组发现服务来配置一组服务代理以便在运行时发现监听器、端点和集群。Istio 在 Pilot 中实现了这些 Envoy 代理的 xDS API。
另一方面Envoy 的服务发现依赖于某种服务注册表来发现服务端点。Istio Pilot 实现了这个 API但也将 Envoy 从任何特定的服务注册实现中抽象出来。当 Istio 部署在 Kubernetes 上时Kubernetes 的服务注册表是 Istio 用于服务发现的。其它注册表也可以像 HashiCorp 的 Consul 那样使用。Envoy 数据平面完全不受这些实施细节的影响。
此外Envoy 代理可以发出很多指标和遥测数据这些遥测数据发送到何处取决于 Envoy 的配置。Istio 提供遥测接收器 Mixer 作为其控制平面的一部分Envoy 代理可以将这些数据发送到 Mixer。Envoy 还将分布式跟踪数据发送到开放式跟踪引擎遵循 Open Tracing API。Istio 可以支持兼容的开放式跟踪引擎并配置 Envoy 将其跟踪数据发送到该位置。
剖析 Istio 控制平面
Istio 的控制平面和 Envoy 的数据平面共同构成了一个引人注目的服务网格实现。两者都拥有蓬勃发展和充满活力的社区并且面向下一代服务架构。Istio 是独立于平台的可运行于各种环境中包括跨云、内部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支持在 Kubernetes 上部署的服务、使用 Consul 注册的服务以及在虚拟机上部署的服务。
其中控制平面部分包括了 Pilot、Mixer、Citadel 和 Galley 四个组件。参见 Istio 架构一图。
1. Pilot
Istio 的 Pilot 组件用于管理流量可以控制服务之间的流量流动和 API 调用通过 Pilot 可以更好地了解流量以便在问题出现之前发现问题。这使得调用更加可靠、网络更加强健即使遇到不利条件也能让应用稳如磐石。借助 Istio 的 Pilot你能够配置熔断器、超时和重试等服务级属性并设置常见的连续部署任务如金丝雀发布、A/B 测试和基于百分比拆分流量的分阶段发布。Pilot 为 Envoy 代理提供服务发现功能为智能路由和弹性能力如超时、重试、熔断器等提供流量管理功能。Pilot 将控制流量行为的高级路由规则转换为特定于 Envoy 代理的配置并在运行时将它们传播到 Envoy。此外Istio 提供了强大的开箱即用故障恢复功能包括超时、支持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进行的定期主动运行状况检查以及被动运行状况检查。
Pilot 将平台特定的服务发现机制抽象化并将其合成为标准格式符合数据平面 API 的任何 Sidecar 都可以使用这种标准格式。这种松散耦合使得 Istio 能够在多种环境下运行例如 Kubernetes、Consul、Nomad同时可保持用于流量管理的操作界面相同。
2. Mixer
Istio 的 Mixer 组件提供策略控制和遥测收集功能将 Istio 的其余部分与各个后端基础设施后端的实现细节隔离开来。Mixer 是一个独立于平台的组件负责在服务网格上执行访问控制和使用策略并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性发送到 Mixer 进行评估。
Mixer 中包括一个灵活的插件模型使其能够接入到各种主机环境和后端基础设施从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。利用 Mixer你可以精细控制网格和后端基础设施后端之间的所有交互。
与必须节省内存的 Sidecar 代理不同Mixer 独立运行因此它可以使用相当大的缓存和输出缓冲区充当 Sidecar 的高度可伸缩且高度可用的二级缓存。
Mixer 旨在为每个实例提供高可用性。它的本地缓存和缓冲区可以减少延迟时间还有助于屏蔽后端基础设施后端故障即使后端没有响应也是如此。
3. Citadel
Istio Citadel 安全功能提供强大的身份验证功能、强大的策略、透明的 TLS 加密以及用于保护服务和数据的身份验证、授权和审计AAA工具Envoy 可以终止或向网格中的服务发起 TLS 流量。为此Citadel 需要支持创建、签署和轮换证书。Istio Citadel 提供特定于应用程序的证书可用于建立双向 TLS 以保护服务之间的流量。
借助 Istio Citadel确保只能从经过严格身份验证和授权的客户端访问包含敏感数据的服务。Citadel 通过内置身份和凭证管理提供了强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。Istio 的配置策略在服务器端配置平台身份验证但不在客户端强制实施该策略同时允许你指定服务的身份验证要求。Istio 的密钥管理系统可自动生成、分发、轮换与撤销密钥和证书。
Istio RBAC 为 Istio 网格中的服务提供命名空间级别、服务级别和方法级别的访问权限控制包括易于使用的基于角色的语义、服务到服务和最终用户到服务的授权并在角色和角色绑定方面提供灵活的自定义属性支持。
Istio 可以增强微服务及其通信包括服务到服务和最终用户到服务的通信的安全性且不需要更改服务代码。它为每个服务提供基于角色的强大身份机制以实现跨集群、跨云端的交互操作。
4. Galley
Galley 用于验证用户编写的 Istio API 配置。随着时间的推移Galley 将接管 Istio 获取配置、处理和分配组件的顶级责任。它负责将其他的 Istio 组件与从底层平台例如 Kubernetes获取用户配置的细节中隔离开来。
总而言之通过 PilotIstio 可在部署规模逐步扩大的过程中帮助你简化流量管理。通过 Mixer借助强健且易于使用的监控功能能够快速有效地检测和修复问题。通过 Citadel减轻安全负担让开发者可以专注于其他关键任务。
Istio 的架构设计中有几个关键目标这些目标对于系统应对大规模流量和高性能的服务处理至关重要。
最大化透明度要采用 Istio应该让运维和开发人员只需付出很少的代价就可以从中获得实际价值。为此Istio 将自身自动注入到服务间所有的网络路径中。Istio 使用 Envoy 代理来捕获流量并且在可能的情况下自动对网络层进行编程以便通过这些代理路由流量而无需对已部署的应用程序代码进行太多的更改甚至不需要任何更改。在 Kubernetes 中Envoy 代理被注入到 pod 中通过 iptables 规则来捕获流量。一旦注入 Envoy 代理到 pod 中并且修改路由规则Istio 就能够调节所有流量。这个原则也适用于性能。当将 Istio 用于部署时运维人员可以发现为提供这些功能而增加的资源开销是很小的。所有组件和 API 在设计时都必须考虑性能和规模。可扩展性随着运维人员和开发人员越来越依赖 Istio 提供的功能系统必然和他们的需求一起成长。在我们继续添加新功能的同时最需要的是能够扩展策略系统集成其他策略和控制来源并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外它允许扩展词汇表以允许基于网格生成的新信号来强制执行策略。可移植性使用 Istio 的生态系统在很多方面都有所不同。Istio 必须能够以最少的代价运行在任何云或本地环境中。将基于 Istio 的服务移植到新环境应该是轻而易举的而使用 Istio 将一个服务同时部署到多个环境中也是可行的例如可以在混合云上部署以实现冗余灾备。策略一致性策略应用于服务之间的 API 调用可以很好地控制网格行为。但对于无需在 API 级别表达的资源来说对资源应用策略也同样重要。例如将配额应用到机器学习训练任务消耗的 CPU 数量上比将配额应用到启动这个工作的调用上更为有用。因此Istio 将策略系统维护为具有自己的 API 的独特服务而不是将其放到代理中这允许服务根据需要直接与其集成。
剖析 Istio 数据平面
当介绍服务网格的概念时提到了服务代理的概念以及如何使用代理构建一个服务网格以调节和控制微服务之间的所有网络通信。Istio 使用 Envoy 代理作为默认的开箱即用服务代理这些 Envoy 代理与参与服务网格的所有应用程序实例一起运行但不在同一个容器进程中形成了服务网格的数据平面。只要应用程序想要与其他服务通信就会通过服务代理 Envoy 进行。由此可见Envoy 代理是数据平面和整个服务网格架构中的关键组成部分。
1. Envoy 代理
Envoy 最初是由 Lyft 开发的用于解决构建分布式系统时出现的一些复杂的网络问题。它于 2016 年 9 月作为开源项目提供一年后加入了云原生计算基金会CNCF。Envoy 是用 C 语言实现的具有很高的性能更重要的是它在高负载运行时也非常稳定和可靠。网络对应用程序来说应该是透明的当网络和应用程序出现问题时应该很容易确定问题的根源。正是基于这样的一种设计理念将 Envoy 设计为一个面向服务架构的七层代理和通信总线。
为了更好地理解 Envoy我们需要先搞清楚相关的几个基本术语
进程外Out of Process架构Envoy 是一个独立进程Envoy 之间形成一个透明的通信网格每个应用程序发送消息到本地主机或从本地主机接收消息但无需关心网络拓扑。单进程多线程模型Envoy 使用了单进程多线程的架构模型。一个主线程管理各种琐碎的任务而一些工作子线程则负责执行监听、过滤和转发功能。下游Downstream连接到 Envoy 并发送请求、接收响应的主机叫下游主机也就是说下游主机代表的是发送请求的主机。上游Upstream与下游相对接收请求的主机叫上游主机。监听器Listener监听器是命名网络地址包括端口、unix domain socket 等可以被下游主机连接。Envoy 暴露一个或者多个监听器给下游主机连接。每个监听器都独立配置一些网络级别即三层或四层的过滤器。当监听器接收到新连接时配置好的本地过滤器将被实例化并开始处理后续事件。一般来说监听器架构用于执行绝大多数不同的代理任务例如限速、TLS 客户端认证、HTTP 连接管理、MongoDB sniff?ing、原始 TCP 代理等。集群Cluster集群是指 Envoy 连接的一组逻辑相同的上游主机。xDS 协议在 Envoy 中 xDS 协议代表的是多个发现服务协议包括集群发现服务CDS Cluster Discovery Service、监听器发现服务LDSListener Discovery Service、路由发现服务RDSRoute Discovery Service、端点发现服务EDSEndpoint Discovery Service以及密钥发现服务SDSSecret Discovery Service。Envoy 代理有许多功能可用于服务间通信例如暴露一个或者多个监听器给下游主机连接通过端口暴露给外部的应用程序通过定义路由规则处理监听器中传输的流量并将该流量定向到目标集群等等。后续章节会进一步分析这几个发现服务在 Istio 中的角色和作用。
在了解了 Envoy 的术语之后你可能想尽快知道 Envoy 到底起到了什么作用
首先Envoy 是一种代理在网络体系架构中扮演着中介的角色可以为网络中的流量管理添加额外的功能包括提供安全性、隐私保护或策略等。在服务间调用的场景中代理可以为客户端隐藏服务后端的拓扑细节简化交互的复杂性并保护后端服务不会过载。例如后端服务实际上是运行的一组相同实例每个实例能够处理一定量的负载。
其次Envoy 中的集群Cluster本质上是指 Envoy 连接到的逻辑上相同的一组上游主机。那么客户端如何知道在与后端服务交互时要使用哪个实例或 IP 地址Envoy 作为代理起到了路由选择的作用通过服务发现SDSService Discovery ServiceEnvoy 代理发现集群中的所有成员然后通过主动健康检查来确定集群成员的健康状态并根据健康状态通过负载均衡策略决定将请求路由到哪个集群成员。而在 Envoy 代理处理跨服务实例的负载均衡过程中客户端不需要知道实际部署的任何细节。
2. Envoy 的启动配置
Envoy 目前提供了两个版本的 API即 v1 和 v2从 Envoy 1.5.0 起就有 v2 API 了为了能够让用户顺利地向 v2 版本 API 迁移Envoy 启动的时候设置了一个参数--v2-conf?ig-only。通过这个参数可以明确指定 Envoy 使用 v2 API 的协议。幸运的是v2 API 是 v1 的一个超集兼容 v1 的 API。在当前的 Istio 1.0 之后的版本中明确指定了其支持 v2 的 API。通过查看使用 Envoy 作为 Sidecar 代理的容器启动命令可以看到如下类似的启动参数其中指定了参数--v2-config-only
$ /usr/local/bin/envoy -c
/etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45
--parent-shutdown-time-s 60 --service-cluster ratings --service-node
sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local
--max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only
其中参数 -c 表示的是基于版本 v2 的引导配置文件的路径格式为 JSON也支持其他格式如 YAML、Proto3等。它会首先作为版本 v2 的引导配置文件进行解析若解析失败会根据 [--v2-conf?ig-only] 选项决定是否作为版本 v1 的 JSON 配置文件进行解析。其他参数解释如下以便读者及时理解 Envoy 代理启动时的配置信息
restart-epoch 表示热重启周期对于第一次启动默认为 0每次热重启后都应该增加它。service-cluster 定义 Envoy 运行的本地服务集群名称。service-node 定义 Envoy 运行的本地服务节点名称。drain-time-s 表示热重启期间 Envoy 将耗尽连接的时间秒默认为 600 秒10 分钟。通常耗尽时间应小于通过 --parent-shutdown-time-s 选项设置的父进程关闭时间。parent-shutdown-time-s 表示 Envoy 在热重启时关闭父进程之前等待的时间秒。max-obj-name-len 描述的是集群 cluster、路由配置 route_conf?ig 以及监听器 listener 中名称字段的最大长度以字节为单位。此选项通常用于自动生成集群名称的场景通常会超过 60 个字符的内部限制。默认为 60。Envoy 的启动配置文件分为两种方式静态配置和动态配置。具体表现为静态配置是将所有信息都放在配置文件中启动的时候直接加载。动态配置需要提供一个 Envoy 的服务端用于动态生成 Envoy 需要的服务发现接口也就是通常说的 xDS通过发现服务来动态调整配置信息Istio 实现了 v2 的 xDS API。
3. Envoy 静态与动态配置
Envoy 是由 JSON 或 YAML 格式的配置文件驱动的智能代理对于已经熟悉 Envoy 或 Envoy 配置的用户来说相信应该已经知道了 Envoy 的配置也有不同的版本。初始版本 v1 是 Envoy 启动时配置 Envoy 的原始方式。此版本已被弃用以支持 Envoy 配置的 v2 版本。Envoy 的参考文档https://www.envoyproxy.io/docs还提供了明确区分 v1 和 v2 的文档。本文将只关注 v2 配置因为它是最新的版本也是 Istio 使用的版本。
Envoy 版本 v2 的配置 API 建立在 gRPC 之上v2 API 的一个重要特性是可以在调用 API 时利用流功能来减少 Envoy 代理汇聚配置所需的时间。实际上这也消除了轮询 API 的弊端允许服务器将更新推送到 Envoy 代理而不是定期轮询代理。
Envoy 的架构使得使用不同类型的配置管理方法成为可能。部署中采用的方法将取决于实现者的需求。简单部署可以通过全静态配置来实现更复杂的部署可以递增地添加更复杂的动态配置。主要分为以下几种情况
全静态在全静态配置中实现者提供一组监听器和过滤器链、集群和可选的 HTTP 路由配置。动态主机发现仅能通过基于 DNS 的服务发现。配置重载必须通过内置的热重启机制进行。仅SDS/EDS在静态配置之上Envoy 可以通过该机制发现上游集群中的成员。SDS/EDS 和 CDSEnvoy 可以通过该机制发现使用的上游集群。SDS/EDS、CDS 和 RDSRDS 可以在运行时发现用于 HTTP 连接管理器过滤器的整个路由配置。SDS/EDS、CDS、RDS 和 LDSLDS 可以在运行时发现整个监听器。这包括所有的过滤器堆栈包括带有内嵌到 RDS 的应用的 HTTP 过滤器。
静态配置
我们可以使用 Envoy 的配置文件指定监听器、路由规则和集群。如下示例提供了一个非常简单的 Envoy 配置
static_resources:listeners:- name: httpbin-demoaddress:socket_address: { address: 0.0.0.0, port_value: 15001 }filter_chains:- filters:- name: envoy.http_connection_managerconfig:stat_prefix: egress_httproute_config:name: httpbin_local_routevirtual_hosts:- name: httpbin_local_servicedomains: [*]routes:- match: { prefix: /
}route:auto_host_rewrite: truecluster: httpbin_servicehttp_filters:- name: envoy.routerclusters:- name: httpbin_serviceconnect_timeout: 5stype: LOGICAL_DNS# Comment out the following line to test on v6 networksdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINhosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]
在这个简单的 Envoy 配置文件中我们声明了一个监听器它在端口 15001 上打开一个套接字并为其附加一个过滤器链。过滤器 http_connection_manager 在 Envoy 配置中使用路由指令在此示例中看到的简单路由指令是匹配所有虚拟主机的通配符并将所有流量路由到 httpbin_service 集群。配置的最后一部分定义了 httpbin_service 集群的连接属性。在此示例中我们指定端点服务发现的类型为 LOGICAL_DNS、与上游 httpbin 服务通信时的负载均衡算法为 ROUND_ROBIN。
这是一个简单的配置文件用于创建监听器传入的流量并将所有流量路由到 httpbin 集群。它还指定要使用的负载均衡算法的设置以及要使用的连接超时配置。
你会注意到很多配置是明确指定的例如指定了哪些监听器路由规则是什么我们可以路由到哪些集群等。这是完全静态配置文件的示例。
有关这些参数更多信息的解释请参阅 Envoy 的文档www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns。 在前面的部分中我们指出 Envoy 能够动态配置其各种设置。下面将介绍 Envoy 的动态配置以及 Envoy 如何使用 xDS API 进行动态配置。
动态配置
Envoy 可以利用一组 API 进行配置更新而无需任何停机或重启。Envoy 只需要一个简单的引导配置文件该配置文件将配置指向正确的发现服务 API其余动态配置。Envoy 进行动态配置的 API 通常统称为 xDS 服务具体包括如下
监听器发现服务LDS一种允许 Envoy 查询整个监听器的机制通过调用该 API 可以动态添加、修改或删除已知监听器每个监听器都必须具有唯一的名称。如果未提供名称Envoy 将创建一个 UUID。路由发现服务RDSEnvoy 动态获取路由配置的机制路由配置包括 HTTP 标头修改、虚拟主机以及每个虚拟主机中包含的单个路由规则。每个 HTTP 连接管理器都可以通过 API 独立地获取自身的路由配置。RDS 配置隶属于监听器发现服务 LDS 的一部分是 LDS 的一个子集用于指定何时应使用静态和动态配置以及指定使用哪个路由。集群发现服务CDS一个可选的 APIEnvoy 将调用该 API 来动态获取集群管理成员。Envoy 还将根据 API 响应协调集群管理根据需要添加、修改或删除已知的集群。在 Envoy 配置中静态定义的任何集群都不能通过 CDS API 进行修改或删除。端点发现服务EDS一种允许 Envoy 获取集群成员的机制基于 gRPC 或 RESTJSON 的 API它是 CDS 的一个子集集群成员在 Envoy 术语中称为端点Endpoint。对于每个集群Envoy 从发现服务获取端点。EDS 是首选的服务发现机制。密钥发现服务SDS用于分发证书的 APISDS 最重要的好处是简化证书管理。如果没有此功能在 Kubernetes 部署中必须将证书创建为密钥并挂载到 Envoy 代理容器中。如果证书过期则需要更新密钥并且需要重新部署代理容器。使用密钥发现服务 SDS那么 SDS 服务器会将证书推送到所有 Envoy 实例。如果证书过期服务器只需将新证书推送到 Envoy 实例Envoy 将立即使用新证书而无需重新部署。聚合发现服务ADS上述其他 API 的所有更改的序列化流你可以使用此单个 API 按顺序获取所有更改ADS 并不是一个实际意义上的 xDS它提供了一个汇聚的功能在需要多个同步 xDS 访问的时候ADS 可以在一个流中完成。 配置可以使用上述服务中的一个或其中几个的组合不必全部使用它们。需要注意的一点是Envoy 的 xDS API 是建立在最终一致性的前提下正确的配置最终会收敛。例如Envoy 最终可能会使用新路由获取RDS的更新该路由将流量路由到尚未在 CDS 中更新的集群。这意味着路由可能会引入路由错误直到更新 CDS。Envoy 引入了聚合发现服务 ADS 来解决这种问题而 Istio 实现了聚合发现服务 ADS并使用 ADS 进行代理配置的更改。
例如Envoy 代理要动态发现监听器可以使用如下配置
dynamic_resources:lds_config:api_config_source:api_type: GRPCgrpc_services:- envoy_grpc:cluster_name: xds_cluster
clusters:
- name: xds_clusterconnect_timeout: 0.25stype: STATIClb_policy: ROUND_ROBINhttp2_protocol_options: {}hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]
通过上面的配置我们不需要在配置文件中显式配置每个监听器。我们告诉 Envoy 使用 LDS API 在运行时发现正确的监听器配置值。但是我们需要明确配置一个集群这个集群就是 LDS API 所在的位置也就是该示例中定义的集群 xds_cluster。
在静态配置的基础上比较直观地表示出各个发现服务所提供的信息。 在静态配置的基础上比较直观地表示出各个发现服务所提供的信息。
本文摘自于《Istio 服务网格解析与实战》经出版方授权发布。本书由阿里云高级技术专家王夕宁撰写详细介绍 Istio 的基本原理与开发实战包含大量精选案例和参考代码可以下载可快速入门 Istio 开发。Gartner 认为2020 年服务网格将成为所有领先的容器管理系统的标配技术。本书适合所有对微服务和云原生感兴趣的读者推荐大家对本书进行深入的阅读。
原文链接 本文为云栖社区原创内容未经允许不得转载。
