入门了解Service Mesh+Istio？从本文开始_文化 & 方法_Rancher

Linux 之父出席、干货分享、圆桌讨论，精彩尽在 OpenCloudOS 社区开放日，报名戳了解详情 



 写点什么

诸如容器、Kubernetes 等云原生架构和技术的成熟推动了服务网格架构的极速增长以及广泛采用。尽管云原生环境可以为企业带来一系列好处，但是其复杂性也对负责开发维护这类系统的人员，如软件开发人员、网络运维人员、基础架构工程师以及 CIO、CTO 等带来了重大挑战。

服务网格框架能够为跨不同云原生环境的应用程序整合一致的服务和网络管理能力，它还极大地加快了 DevOps 实践的进程，正缘于此，服务网格近年来可谓是发展迅猛。云原生普及的加快，要求拥有云原生应用程序的工程团队必须熟悉服务网格功能，以判断该技术将来是否能为企业提供价值。

什么是服务网格？

服务网格可以连接、保护、控制以及监控在编排平台上的服务。“服务网格”这一术语本身用于分布式应用程序中服务之间的一组搭接网络连接，也适用于管理该组连接服务的一系列工具。如果你有两个通过网络连接进行交互的微服务，那就意味着你有了一个服务网格。下图是一个十分简单的示例，一个网格和两个服务：

更有可能的是，由于在环境中微服务的数量会继续增长，你的服务网格会如下图所示：

随着云环境扩展到混合云和多云部署，开发人员将会使用微服务来加速开发并且确保在多个容器和分布式云资源中的的可移植性。随着微服务生态系统的复杂性增长，我们需要高效且智能地管理它，并且深入了解微服务如何交互以及保护微服务之间的通信。

什么是 Istio？

如果你已经听说了服务网格，那么你一定顺带听说了 Istio。Istio 是一个开源的服务网格，它可以部署在已有的云原生应用程序上。它还具有类似于平台的功能——可以将集成到日志平台、遥测或策略系统中。策略集成使得 Istio 在创建一个统一的方法来保护、连接以及监控既定环境中的微服务中扮演一个安全工具的角色。当泛指“Istio 服务网格”时，通常是指 Istio 中的一系列工具，而特指“某个 Istio 服务网格”时则表明由 Istio 安装管理的指定应用程序集群。Istio 的许多 CRD 允许对应用程序网络层的行为进行编程配置（通过使用 Kubernetes API），其中应用程序是相互依赖的微服务集。Istio 在某种程度上可以称为当今云原生堆栈中服务网格的同义词，因为它的功能最丰富、最标准化。

我是否需要一个服务网格？

尽管服务网格的采用率可能会持续快速增长，特别是当功能设置和类似 Istio 的管理工具进一步完善之后，但并不是每个云原生环境都需要服务网格。所以你如何知道一个服务是否适合你的企业或者环境呢？如果你需要解决下面所描述的一个或多个需求或问题的方案，那么你应该考虑部署一个服务网格：

你在基于分布式微服务的应用程序中遇到性能问题
你需要为所有微服务收集并交付一致的请求和连接指标
你想直接默认在线加密设置，而无需直接管理 TLS 证书
你需要比 Kubernetes 网络策略提供的更细粒度的解决方案进行服务到服务的控制
你想使用金丝雀发布和应用程序 API 多版本支持进行自动 release
你想无需修改应用程序就可以添加用户的身份验证和授权认证信息

另一方面，如果在你的堆栈中不需要服务网格，那么你需要做一些权衡。考虑到这些环境的复杂性，部署一个服务网格（包括 Istio）需要大量的迁移工作和运维成本。如果你的微服务部署数量不会增长，或者如果有其他解决方案可以满足你内部的 HTTP 请求路由的需求，或者如果你已经有了一个可管理且高效的解决方案可以解决上述的关键需求，那么此刻服务网格对你来说真的不是一个最佳选择。

但是如果服务网格继续极速被广泛采用，为支持它而开发的功能生态系统将会继续扩展。这种增长将提升可管理性和功能性，以便将来 DevOps 团队可以更加轻松地访问更强大的服务网格工具，而不必担心将新的基础架构层部署到云原生堆栈中而出现棘手的问题或花费很高的成本。

Istio 工作原理

Istio 组件被分为两部分——控制平面和数据平面。控制平面是指管理配置和监控数据平面的服务。数据平面由作为 sidecar 由在应用程序 pod 中的智能代理（proxy）组成，这是 Kubernetes 对象模型中最小的可部署对象。这些 Istio proxy 有助于控制和监控微服务间的网络连接。从控制平面接收路由和策略规则，然后数据平面报告回连接处理遥测。

通过创建 Kubernetes 资源来配置 Istio 服务网格。此外，有许多 Kubernetes CRD 可以映射到 Istio 各种功能上。接下来，我们会讨论更多关于控制和数据平面的作用，但在此之前我们先了解关于 Istio 的潜在能力，以及它的不足。

潜力与不足

Istio 通过其可动态配置代理的网格提供了一系列用于处理和控制网络连接的特性。但这些功能配置繁重并且拥有陡峭的学习曲线。并且有时把已有的应用程序迁移到 Istio 架构时依旧会出现一些常见的问题，尽管这些架构已经是 Kubernetes 原生的微服务。

此外，Istio 缺乏对如何将用户提供的配置转换为 Envoy 路由的了解。Envoy 是作为服务网格中服务的入站和出站流量的中介开发的一种高性能的代理，是由来自共享出行服务公司 Lyft 的开发人员创建的，可以用于从单体架构转变为服务网格架构。其他在使用中的问题还包括部署和服务资源配置要求所需的学习曲线、在打开 mTLS 时中断 Kubernetes readiness 和 liveness 探针以及使用没有 ClusterIP 的 Kubernetes 服务或绕开 Kubernetes 服务发现流程的服务。

Istio 的优势在于可以让你在不修改微服务源代码的情况之下，很轻松地给微服务加上诸如负载均衡、身份验证、监控等等的功能。而且目前它正在快速发展迭代，频繁发布新版本，并且积极征求用户反馈。尽管目前 Envoy 还有很多局限，但是随着 Istio 持续发展，它也会积极开发和完善自己的功能。

配置控制平面

在 Kubernetes 集群中，一个典型的 Istio 部署应该包含以下服务：

Pilot，在 Istio 网络自定义资源中集合流量管理规范配置，并将该配置交付到 istio-proxy sidecar。
Mixer，用于处理由 proxy sidecar 生成的请求指标的遥测，并将其发送到已配置完成的后端，并执行授权策略。如果开启了策略检查（Istio 1.1 中默认关闭），proxy sidecar 将会连接到 Mixer 以确认连接是被允许的。但是，这个方法会稍微增加网络延迟。
Citadel，这个是 Istio 的公钥基础设施（PKI）服务，它可以生成、轮换和吊销用于身份验证的客户端 TLS 证书。
Galley，它是大多数 Istio CRD 的 Kubernetes controller，使用户可以更改自定义资源并将内容分配到其他 Istio 服务中。

数据平面

数据平面由 Envoy 服务代理提供支持，该代理使用 Istio 扩展构建。Proxy 会拦截到 pod 服务端口的传入流量，并默认拦截来自 pod 其他容器的所有创出 TCP 流量。在大部分情况下，无需更改应用程序代码，仅对应用程序的 Kubernetes 部署和服务资源规范进行较小的更改，proxy sidecar 就可以在 pod 中运行。Proxy sidecar 的配置由在 Istio 控制面板中的服务进行动态管理。

最终，也许会在某个时间点你需要部署服务网格以确保你的云原生环境完全正常运行并得到充分保护。因此，熟悉有关服务网格的基础只是将可以帮助你做出准确的判断——什么时候应该部署服务网格以及应该如何部署。如果你正在计划在 Kubernetes 和其他容器平台上进行扩展计划，那么你通过了解 Istio 的设计和功能以及它如何降低容器化微服务和云原生环境的固有复杂性，你可以知道 Istio 是一个功能强大且快速改进的解决方案并且正在积极增强弹性伸缩能力、安全性以及管理的简易性。

如果企业继续采用云原生和分布式架构，那么 Istio 的服务网格功能以及底层基础架构的网络控制和 Kubernetes 的安全实践将会极大程度解放 DevOps 团队在弹性伸缩和管理应用程序基础架构上的压力。

在 10 月 9 日GA的Rancher 2.3版本中，正式集成了 Istio，极大简化了 Istio 的安装和配置。你只需要在 UI 中使用工具菜单，即可启动 Istio。Rancher 中现已内置支持：