Istio：架构与技术

大纲

• 前言
• 为什么使用 Istio？
• Service Mesh
• Istio 架构基础
• Istio 基本概念
• Istio & Kubernetes：架构结合
• 运行第一个Istio集群

前言：

在后 Kubernetes 时代，服务网格（Service Mesh）技术已完全取代了使用软件库实现网络运维（例如 Hystrix 断路器）的方式。

听说过 Service Mesh 并试用过 Istio 的人可能都会有以下几个疑问：

• 为什么 Istio 一定要绑定 Kubernetes 呢？
• Kubernetes 和 Service Mesh 分别在云原生中扮演什么角色？
• Istio 扩展了 Kubernetes 的哪些方面？解决了哪些问题？
• Kubernetes、Envoy（xDS 协议）与 Istio 之间又是什么关系？
• 到底该不该上 Service Mesh？

这是因为

• Kubernetes 的本质是应用的生命周期管理，具体来说就是部署和管理（扩缩容、自动恢复、发布）。
• Kubernetes 为微服务提供了可扩展、高弹性的部署和管理平台。
• Service Mesh 的基础是透明代理，通过 sidecar proxy 拦截到微服务间流量后再通过控制平面配置管理微服务的行为。
• Service Mesh 将流量管理从 Kubernetes 中解耦，Service Mesh 内部的流量无需 kube-proxy 组件的支持，通过为更接近微服务应用层的抽象，管理服务间的流量、安全性和可观察性。
• Envoy xDS 定义了 Service Mesh 配置的协议标准。
• Service Mesh 是对 Kubernetes 中的 service 更上层的抽象，它的下一步是 serverless。

Istio 是一个功能十分丰富的 Service Mesh，它包括如下功能：

• 流量管理：这是 Istio 的最基本的功能。
• 策略控制：通过 Mixer 组件和各种适配器来实现，实现访问控制系统、遥测捕获、配额管理和计费等。
• 可观测性：通过 Mixer 来实现。
• 安全认证：Citadel 组件做密钥和证书管理

为什么使用 Istio？

Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

Kubernetes提供了部署、升级和有限的运行流量管理能力，但并不具备熔断、限流降级、调用链治理等能力。Istio是基于Kubernetes构建的开放平台，它很好的补齐了Kubernetes在微服务治理上的诸多能力。

通过负载均衡、服务间的身份验证、监控等方法，Istio 可以轻松地创建一个已经部署了服务的网络，而服务的代码只需很少更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio，这包括：

• 为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。

• 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。

• 可插拔的策略层和配置 API，支持访问控制、速率限制和配额。

• 集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。

• 在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。

Istio 为可扩展性而设计，可以满足不同的部署需求。

 

Service Mesh

Kubernetes

 Kubernetes 提供平台基础设施层强大的容器编排与调度能力

• – 服务部署与弹性伸缩： Deployment
• – 服务拆分与服务发现： Service

Kubernetes 提供简单的负载均衡

• – 负载均衡：基于IPVS或Iptables的简单均衡机制

Service Mesh

• 治理能力独立（ Sidecar）
• 应用程序无感知
• 服务通信的基础设施层

Istio问世

连接--Connect

支持智能控制服务流量以及服务间的API调用，通过灰度发布和持续测试优雅逐步的升级。

安全--Secure

智能化管理服务间通信的认证、鉴权和加密，为服务通信提供安全保障。

控制--Control

下发并执行流量控制策略，确保网络链路资源在客户侧的公平分配。

遥测--Observe

为服务提供丰富的、自动化的链路跟踪、监控和日志监控，可视化服务运行状态。

Istio关键能力

Istio 架构基础

Istio 架构基础

Istio service mesh 架构图

服务网格中分为控制平面和数据平面，当前流行的两款开源的服务网格 Istio 和 Linkerd 实际上都是这种架构，只不过 Istio 的划分更清晰，而且部署更零散，很多组件都被拆分，控制平面中包括 Mixer、Pilot、Citadel，数据平面默认是用 Envoy；而 Linkerd 中只分为 Linkerd 做数据平面，namerd 作为控制平面。

控制平面

Istio 中的安全性涉及多个组件：

• Citadel 用于密钥和证书管理
• Pilot 将授权策略和安全命名信息分发给代理 -- 主要用于服务发现和服务配置(服务访问规则维护)，Pilot中的adapter机制可以适配各种服务发现组件（Eureka、Consul、Kubenetes）,最好的是Kubernetes
• galley 验证规则（Pilot、Mixer、Citadel配置的规则）
• Mixer 管理授权和审计

控制平面的特点：

• 不直接解析数据包
• 与数据平面中的代理通信，下发策略和配置
• 负责网络行为的可视化
• 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署

数据平面

数据平面的特点：

• 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的
• 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等
• 对应用来说透明，即可以做到无感知部署
• Proxy默认就是Envoy
• Sidecar 和周边代理 实现客户端和服务器之间的安全通信

Pilot

Pilot

Mixer

Mixer

Citadel

Citadel

Istio & Kubernetes： 架构结合

Istio & Kubernetes： 架构结合

 

 

Envoy:xDS 协议

下面这张图大家在了解 Service Mesh 的时候可能都看到过，每个方块代表一个服务的示例，例如 Kubernetes 中的一个 Pod（其中包含了 sidecar proxy），xDS 协议控制了 Istio Service Mesh 中所有流量的具体行为，即将下图中的方块链接到了一起。

xDS 协议是由 Envoy 提出的，在 Envoy v2 版本 API 中最原始的 xDS 协议只指 CDS、EDS、LDS 和 RDS。

下面我们以两个 service，每个 service 都有两个实例的例子来看下 Envoy 的 xDS 协议。

Envoy xDS 协议

 

xDS 协议要点

最后总结下关于 xDS 协议的要点：

• CDS、EDS、LDS、RDS 是最基础的 xDS 协议，它们可以分别独立更新的。
• CDS 设置 Service Mesh 中有哪些服务。
• EDS 设置哪些实例（Endpoint）属于这些服务（Cluster）。
• LDS 设置实例上监听的端口以配置路由。
• RDS 最终服务间的路由关系，应该保证最后更新 RDS。
• 所有的发现服务（Discovery Service）可以连接不同的 Management Server，也就是说管理 xDS 的服务器可以是多个。
• Envoy 在原始 xDS 协议的基础上进行了一些列扩充，增加了 SDS（秘钥发现服务）、ADS（聚合发现服务）、HDS（健康发现服务）、MS（Metric 服务）、RLS（速率限制服务）等 API。
• 为了保证数据一致性，若直接使用 xDS 原始 API 的话，需要保证这样的顺序更新：CDS --> EDS --> LDS --> RDS，这是遵循电子工程中的先合后断（Make-Before-Break）原则，即在断开原来的连接之前先建立好新的连接，应用在路由里就是为了防止设置了新的路由规则的时候却无法发现上游集群而导致流量被丢弃的情况，类似于电路里的断路。

Envoy 配置文件

Istio 基本概念

Istio 中定义了如下的 CRD 来帮助用户进行流量管理：

• Gateway：Gateway 描述了在网络边缘运行的负载均衡器，用于接收传入或传出的HTTP / TCP连接。
• VirtualService：VirtualService 实际上将 Kubernetes 服务连接到 Istio Gateway。它还可以执行更多操作，例如定义一组流量路由规则，以便在主机被寻址时应用。
  • --服务如何被访问？访问的时候给他做什么控制（虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。）
  • 虚拟服务在增强 Istio 流量管理的灵活性和有效性方面，发挥着至关重要的作用，通过对客户端请求的目标地址与真实响应请求的目标工作负载进行解耦来实现。
  • 虚拟服务同时提供了丰富的方式，为发送至这些工作负载的流量指定不同的路由规则。
• DestinationRule：DestinationRule 所定义的策略，决定了经过路由处理之后的流量的访问策略。简单的说就是定义流量如何路由。这些策略中可以定义负载均衡配置、连接池尺寸以及外部检测（用于在负载均衡池中对不健康主机进行识别和驱逐）配置。
  • --目标服务的策略，包括目标服务的负载均衡，连接池管理等
    -- Istio延续了Kubernetes的语义，他是一个描述性的，不同于以前配置信息像维护数据样机械死板排列，通过背后或自身的逻辑组织起来。
• EnvoyFilter：EnvoyFilter 对象描述了针对代理服务的过滤器，这些过滤器可以定制由 Istio Pilot 生成的代理配置。这个配置初级用户一般很少用到。
• ServiceEntry：默认情况下 Istio Service Mesh 中的服务是无法发现 Mesh 外的服务的，ServiceEntry 能够在 Istio 内部的服务注册表中加入额外的条目，从而让网格中自动发现的服务能够访问和路由到这些手工加入的服务。

Istio 中的流量管理

VirtualService

DestinationRule

Gateway

ServiceEntry

运行第一个Istio集群

helm方式安装

vim setup-istio.yaml
# istio就是一个插件化部署到k8s上
# 第一步：建立CRD规则
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
# 第二步：通过helm把istio的配置写入一个配置文件
helm template install/kubernetes/helm/istio --name istio --namespace istio-system > $HOME/istio.yaml
# 第三步：创建分区:istio-system
kubectl create namespace istio-system
# 第四步：创建istio
kubectl apply -f $HOME/istio.yaml
# 第五步：允许pod进来自动注入sidecar
kubectl label namespace default istio-injection=enabled

 Istioctl

• proxy-status：状态同步情况
• proxy-config： envoy中具体规则查询
  • listener
  • route
  • cluster
  • endpoint
• kube-inject

参考链接：

https://www.servicemesher.com/istio-handbook/