使用Istio实现基于Kubernetes的微服务架构.docx

? ? 使用 Istio 实现基于 Kubernetes 的微服务架构 ? ? 本文“最初由 IBM developerWorks 中国网站发表，其网址是 /developerworks/cn”。原文题目为：使用 Istio 实现基于 Kubernetes 的微服务应用 概述 近两年，随着容器、Kubernetes 等技术的兴起，微服务这个概念被广泛提及并被大量使用。本文将会从以下几个方面着手，结合实验展现的方式，让读者真正理解微服务的含义。新一代的微服务架构 Istio基于 Istio 的微服务实验展现 Istio 的架构分析 Istio 介绍 Istio 是一个开源的 Service Mesh 架构，旨在通过与 Kubernetes 相结合，大幅降低微服务的复杂度，以便让代码开发人员更关注于代码本身。 Istio 开源项目由 Google 和 IBM 主导，根据 网站的统计，该社区代码 Commits 厂商排名如下： 18u7ugxrevij 图 1. Istio 各厂商代码贡献量图示 ku8y9mkvsgk 图 2. Istio 各厂商代码贡献量排名 在 Github 上，Istio项目受关注的程度非常高，您可进一步了解。接下来，我们详细介绍 Istio 的技术架构。 Istio 的架构 Istio 分为两个平面：数据平面和控制平面。 数据平面：数据平面由一组 sidecar 的代理（Envoy）组成。这些代理调解和控制微服务之间的所有网络通信，并且与控制平面的 Mixer 通讯，接受调度策略。 控制平面：控制平面通过管理和配置 Envoy 来管理流量。此外，控制平面配置 Mixers 来实施路由策略并收集检测到的监控数据。 w23e8rj8gjk 图 3. Istio 的架构图 在介绍了 Istio 的两个平面以后，我们详细介绍 Istio 的各个组件。 Envoy 是一个用 C ++开发的高性能代理，用于管理 Service Mesh 中所有服务的所有入站和出站流量。 Istio 利用 Envoy 的许多内置功能，例如： 动态服务发现 负载均衡 TLS 终止 HTTP / 2 和 gRPC 代理 断路器 健康检查 流量分割 故障注入 监控指标 我们知道，在 Kubernetes 中集群中，pod 是最小的计算资源调度单位。一个 pod 可以包含一个或者多个容器，但通常是一个。而使用 Istio 的时候，需要在 pod 中主容器旁注入一个 sidecar，也就是上面提到的代理（Envoy）。 举一个例子，我们查看一个被注入了 Envoy 的 pod，从下图结果可以看到，这个 pod 包含两个容器： xa1bvrzdir 图 4. 查看 pod 中的 Containers 在 Istio 中，每一个 pod 中都必须要部署一个 Sidecar。 Mixer：Mixer 是一个独立于平台的组件，负责在整个 Service Mesh 中执行访问控制和使用策略，并从 Envoy 代理和其他服务收集监控到的数据。 PilotPilot 为 Envoy 提供服务发现；为高级路由（例如，A / B 测试，金丝雀部署等）提供流量管理功能；以及异常控制，如：超时，重试，断路器等。 Citadel：Citadel 通过内置身份和凭证管理，提供强大的服务到服务和最终用户身份验证。我们可以使用 Citadel 升级 Service Mesh 中的未加密流量。我们可以使用 Istio 的授权功能来控制谁可以访问服务。 Istio 路由规则的实现 在 Istio 中，和路由相关的有四个概念：Virtual Services 、Destination Rules、ServiceEntry、Gateways。 Virtual Services 的作用是：定义了针对 Istio 中的一个微服务的请求的路由规则。Virtual services 既可以将请求路由到一个应用的不同版本，也可以将请求路由到完全不同的应用。 在如下的示例配置中，发给微服务的请求，将会被路由到 productpage，端口号为 9080。 清单 2. Virtual Services 规则route: destination: host: productpage port: number: 9080 Destination Rules 定义在路由发生后应用于服务的流量的策略，例如熔断等。 在下面的示例配置中，定义了熔断策略。清单 3. Destination 规则 spec: host: productpage subsets: - labels: version: v1 name: v1 tra