使用 Istio 掌握服务网格架构

1. 简介

探索服务网格架构的魔力，了解它如何为您的分布式系统增压。

深入了解服务网格巨星 Istio，了解它如何完美地协调您的Kubernetes 集群。

2. 什么是服务网格？

单体应用已经演变成更小、更独立的服务。这种转变在云原生计算和微服务架构中获得了极大的欢迎。像Docker和 Kubernetes 这样的工具加速了这一趋势。

Kubernetes 等平台上的微服务提供了许多好处，但它们也引入了复杂性。管理这些分布式服务之间的通信需要仔细考虑发现、路由、重试和故障转移。

其他挑战包括安全性和可观察性。

这些代理为服务形成一个网状网络，因此得名。服务网格控制着服务到服务通信的各个方面，使其能够解决分布式计算的八大谬误。

4. Istio 揭秘

Istio 是 IBM、Google 和 Lyft 联合开发的开源服务网格，它通过流量管理、安全性和性能洞察力，无形地增强了分布式应用程序。

Istio 可灵活地部署在本地、云中、Kubernetes 内或虚拟机上，在 Kubernetes 上使用微服务时表现出色。尽管它与平台无关，但它非常适合容器化环境。

Istio 的核心是在每个微服务旁边部署 Envoy 代理作为边车：

这个代理网络构成了 Istio 的数据平面，由控制平面进行编排：

Istio 的适应性体现在与外部日志记录、遥测和策略系统的无缝集成。

5. 揭开 Istio 的构建模块

Istio 的架构是一个动态二人组：数据平面和控制平面。它们共同协调了 Istio 功能背后的魔力。让我们深入了解为这个卓越平台提供动力的核心组件。

准备好探索 Istio 核心组件的复杂细节。

5.1. 数据平面：Envoy 的中心

Istio 的数据平面本质上是 Envoy 代理的增强版本。这个开源奇迹处理网络复杂性，使应用程序能够专注于其核心业务。应用程序无缝交互，无需了解复杂的网络基础架构。

Envoy 的核心是一个在 OSI 模型的第 3 层和第 4 层运行的网络向导。它使用一系列可适应的网络过滤器巧妙地管理连接。除此之外，Envoy 的 L7 层过滤器使其能够轻松处理 HTTP 流量。这还不是全部 - 它天然支持 HTTP/2 和 gRPC 协议。

Istio 的许多突出功能实际上是从 Envoy 的内置功能继承的超能力：

• 流量控制：Envoy 可以对 HTTP、gRPC、WebSocket 和 TCP 流量进行粒度控制，并对其进行精确路由。
• 网络弹性：内置的自动重试、断路和故障注入可确保始终如一的网络可靠性。
• 安全性：通过强大的安全策略、访问控制和速率限制来保护您的通信。

当与 Istio 配合使用时，Envoy 的真正潜力才会显现出来。它由 WebAssembly 提供支持的可扩展性改变了自定义策略实施和遥测的游戏规则。此外，Istio 的 Proxy-Wasm 沙箱 API 为更多 Envoy 定制打开了大门。

5.2. 控制平面：Istiod 的指挥家

认识一下 istiod，Istio 控制平面乐队的指挥。这位指挥家将高级路由规则和流量管理指令转换为 Envoy 友好的配置，并将它们无缝地分发给边车。

还记得 Istio 之前带有各个组件的架构吗？为了简化事情，这些组件被合并到统一的 istiod 中。但不要担心，核心功能保持不变。

istiod 的核心是使用与其前辈相同的代码和 API。例如，Pilot 仍然是服务发现的指挥家，它将特定于平台的详细信息转换为边车可以理解的通用语言。这种灵活性使 Istio 能够与 Kubernetes 和虚拟机等不同环境相协调。

istiod 还负责安全性，使用其内置的身份和凭据管理系统建立强大的服务到服务和最终用户身份验证。轻松实施基于服务身份的粒度安全策略。此外，istiod 还充当可信证书颁发机构 (CA)，向使用相互 TLS (MTLS) 的服务之间的安全通信颁发证书。

6. Istio 如何工作

我们已经探讨了服务网格的典型功能，并剖析了 Istio 的架构和核心组件。现在，让我们来了解 Istio 如何使用其核心组件来提供这些功能。

我们将重新审视我们之前探讨的相同功能类别。

6.1. 流量管理

Istio 的流量管理 API 提供对服务网格流量的粒度控制。使用这些 API 定制流量配置，并使用 Kubernetes 自定义资源定义 (CRD) 定义 API 资源。用于流量路由的关键 API 资源是虚拟服务和目标规则：

虚拟服务规定了请求如何路由到 Istio 网格内的服务。它包含一个或多个按顺序评估的路由规则。在虚拟服务路由之后，将应用目标规则来控制到目标的流量，例如按版本对服务实例进行分组。

6.2. 安全

Istio 的安全基础是每个服务的强大身份。每个 Envoy 代理旁边的 Istio 代理与 istiod 协作，以自动化密钥和证书轮换：

Istio 支持两种身份验证类型：对等身份验证和请求身份验证。对等身份验证使用 Istio 的相互 TLS 解决方案保护服务到服务的通信。请求身份验证通过使用自定义身份验证提供程序或 OpenID Connect (OIDC) 提供程序进行 JSON Web 令牌 (JWT) 验证来处理最终用户身份验证。

Istio 通过应用授权策略来强制执行服务访问控制。这些策略 регулируют Envoy 代理中的入站流量，允许在网格、命名空间和服务级别进行访问控制。

6.3. 可观察性

Istio 为网格内的所有服务通信生成全面的遥测数据，包括指标、分布式跟踪和访问日志。此遥测数据涵盖代理级别、面向服务和控制平面的指标。

以前，Mixer 是 Istio 遥测架构中的中心组件。但是，遥测 v2 使用 Envoy 代理插件替换了 Mixer 的功能：

Istio 通过 Envoy 代理创建分布式跟踪，并支持各种跟踪后端，如 Zipkin、Jaeger、Lightstep 和 Datadog。跟踪生成采样率是可配置的。此外，Istio 还以可定制的格式为服务流量生成访问日志。

7. 深入了解 Istio

背景介绍得够多了，让我们来看看 Istio 的实际应用！我们将在 Kubernetes 集群上安装 Istio，并使用一个简单的微服务应用程序来展示它的强大功能。

7.1 安装

Istio 可以通过多种方式安装，但最简单的方法是下载并解压缩适用于您操作系统的最新版本（例如 Windows）。解压缩的软件包在 bin 文件夹中包含 istioctl 客户端。使用 istioctl 在您的 Kubernetes 集群上安装 Istio：

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

我们在这里使用 kubectl，假设您有一个 Kubernetes 集群（如 Minikube）并且 Kubernetes CLI kubectl 已设置好。

7.2 示例应用程序

想象一下，这个演示程序是一个简单的在线订购应用程序。它由三个微服务组成，这些微服务协同工作以完成订单：

我们不会深入探讨微服务的细节，但它们很容易使用Spring Boot和REST API来创建。至关重要的是，为这些微服务创建 Docker 映像以部署在 Kubernetes 上。

7.3 部署

在 Kubernetes 集群（如 Minikube）上部署容器化工作负载很简单。使用 Deployment 和 Service 资源来声明和访问工作负载。通常，在 YAML 文件中定义它们：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

由于我们为默认命名空间启用了 Envoy 边车代理的自动注入，因此一切都已处理妥当。或者，使用 istioctl 的 kube-inject 命令手动注入 Envoy 边车代理。

7.4 访问应用程序

Istio 主要处理网格流量。默认情况下，进出网格的流量将被阻止。Istio 使用网关来管理进出网格的流量，使您可以精确控制进出的内容。Istio 提供了预先配置的网关代理部署：istio-ingressgateway 和 istio-egressgateway。

为您的应用程序创建网关和虚拟服务：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 个常见的 Istio 用例

我们已经在 Kubernetes 上部署了一个带有 Istio 的简单应用程序。让我们探索 Istio 的强大功能，看看它们如何增强我们的应用程序。

8.1 请求路由

想象一下部署一个微服务（如 shipping-service）的多个版本。您希望逐步引入新功能，而不会影响所有用户。请求路由允许您通过将一部分流量定向到最新版本来实现这一点。

使用虚拟服务路由规则来实现这一点。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

路由规则还可以根据标头或其他属性过滤流量。destination 字段指定用于匹配请求的目标服务。

8.2 断路

使用断路器防止级联故障。此模式检测错误并暂时停止到故障服务的流量，从而保护应用程序的整体健康状况。

Istio 的 DestinationRule 允许您为 inventory-service 等服务配置断路行为。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

通过限制最大连接数、挂起请求数和每个连接的请求数，您可以有效地管理流量并防止过载。

8.3 启用相互 TLS

相互 TLS 通过要求双方进行身份验证来确保服务之间的安全通信。Istio 使用其代理自动为服务启用相互 TLS。

虽然 Istio 在代理服务之间强制执行相互 TLS，但纯文本流量仍然可以到达没有代理的服务。使用 PeerAuthentication 策略在整个网格中强制执行相互 TLS。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

您可以在网格、命名空间或服务级别应用相互 TLS。特定于服务的策略会覆盖命名空间范围的设置。

8.4 使用 JWT 进行访问控制

JSON Web 令牌 (JWT) 是一种安全传输用户信息的标准。它们被广泛用于身份验证和授权。

Istio 的 AuthorizationPolicy 允许您根据 JWT 声明控制对 booking-service 等服务的访问。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

要求具有特定声明的有效 JWT 才能获得授权访问。Istio 根据 JWT 的颁发者和主题声明创建 requestPrincipal 属性。

9. 最后的想法

Istio 简化了分布式微服务架构中常见挑战的管理。但是，它的复杂性可能会增加部署的开销。与任何工具一样，Istio 并不是一个神奇的解决方案，需要仔细考虑。

9.1. 服务网格是否始终必要？

虽然服务网格提供了优势，但也要考虑以下缺点：

服务网格提供了好处，但仔细评估应用程序的复杂性至关重要。权衡优势与增加的复杂性。

9.2. Istio 替代方案

Istio 是一个由行业领导者支持的流行服务网格，但它不是唯一的选择。以下是 Linkerd 和 Consul 的简要概述。

Linkerd 是一个 Kubernetes 原生的开源服务网格，越来越受欢迎。它是一个 CNCF 孵化项目，其工作原理与 Istio 类似，使用 TCP 代理。Linkerd 基于 Rust 的微代理称为 Linkerd-proxy。

由于 Linkerd 专注于 Kubernetes，因此它通常比 Istio 更简单。但是，它的功能集与 Istio 非常相似，并且其核心架构也类似。Linkerd 由用户界面、数据平面和控制平面组成。

Consul 是 HashiCorp 的开源服务网格，它与其他 HashiCorp 基础架构工具集成。Consul 的数据平面支持代理和本机集成模型。它提供了一个内置代理，但也可以与 Envoy 一起使用。

Consul 的运行范围超出了 Kubernetes，支持 Nomad 等平台。它在每个节点上使用代理进行健康检查，并与 Consul 服务器通信以进行数据存储和复制。虽然提供了标准的服务网格功能，但 Consul 的部署和管理更加复杂。

10. 总结

本教程探讨了服务网格架构的基本原理和 Istio 的强大功能。我们深入研究了 Istio 的核心结构、组件和实际应用。最后，您应该对如何安装和使用 Istio 处理常见场景有深入的了解。