01.istio架构

https://istio.io/latest/zh/docs/

1.1 istio流量治理

1、流量管理

• 在控制平面会经过如下流程
  • 管理员通过命令行或者 API 创建流量规则；
  • Pilot 将流量规则转换为 Envoy 的标准格式；
  • Piiot 将规则下发给 Envoy。
• 在数据平面会经过如下流程
  • Envoy 拦截 Pod 上本地容器的 Inbound 流量和 Outbound 流量；
  • 在流量经过 Envoy 时执行对应的流量规则，对流量进行治理。

2、数据平面和控制平面

• 数据平面

  • 数据平面由一组以 Sidecar 方式部署的智能代理(Envoy+Polit-agent)组成。

  • 这些代理承载并控制微服务之间的所有网络通信，管理入口和出口流量，类似于一线员工。

  • Sidecar 一般和业务容器绑定在一起（在 Kubernets 中以自动注入的方式注入到到业务 pod 中）

  • 来劫持业务应用容器的流量，并接受控制面组件的控制，同时会向控制面输出日志、跟踪及监控数据

  • Envoy 和 pilot-agent 打在同一个镜像中，即 sidecar Proxy。

• 控制平面

  • 控制平面负责管理和配置代理来路由流量。

  • 控制平面的核心，管理 Istio 的所有功能，主要包括 Pilot、Mixer、Citadel等服务组件。

1.2 istio架构

1、架构图

2、istio能力

• 1、自动注入

  • 在创建应用程序时自动注入 Sidecar 代理 Envoy 程序。
  • 在 Kubernetes 中创建 Pod 时，Kube-apiserver 调用控制面组件的 Sidecar-Injector 服务，自动修改应用程序的描述信息并注入Sidecar。
  • 在真正创建 Pod 时，在创建业务容器的 Pod 中同时创建 Sidecar 容器。

• 2、流量拦截

  • 在 Pod 初始化时设置 iptables 规则，基于配置的 iptables 规则拦截业务容器的 Inbound流量和 Outbound 流量到 Sidecar 上。
  • 而应用程序感知不到 Sidecar 的存在，还以原本的方式 进行互相访问。
  • 上图中，流出 frontend 服务的流量会被 frontend 服务侧的 Envoy 拦截，而当流量到达 forecast容器时，Inbound 流量被 forecast 服务侧的 Envoy 拦截。

• 3、服务发现

  • 服务发起方的 Envoy 调用控制面组件 Pilot 的服务发现接口获取目标服务的实例列表。

  • 上图中，frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到 forecast 服务各个实例的地址。

• 4、负载均衡

  • 服务发起方的 Envoy 根据配置的负载均衡策略选择服务实例，并连接对应的实例地址。
  • 上图中，数据面的各个 Envoy 从 Pilot 中获取 forecast 服务的负载均衡配置，并执行负载均衡动作。

• 5、流量治理

  • Envoy 从 Pilot 中获取配置的流量规则，在拦截到 Inbound 流量和 Outbound 流量时执行治理逻辑。
  • 上图中， frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则，并根据该流量治理规则将不同特征的流量分发到 forecast 服务的 v1 或 v2 版本。

• 6、访问安全

  • 在服务间访问时通过双方的 Envoy 进行双向认证和通道加密，并基于服务的身份进行授权管理。
  • 上图中，Pilot 下发安全相关配置，在 frontend 服务和 forecast 服务的 Envoy 上自动加载证书和密钥来实现双向认证
  • 其中的证书和密钥由另一个管理面组件 Citadel 维护。

• 7、服务监测

  • 在服务间通信时，通信双方的 Envoy 都会连接管理面组件 Mixer 上报访问数据，并通过Mixer 将数据转发给对应的监控后端。
  • 上图中，frontend 服务对 forecast 服务的访问监控指标、日志和调用链都可以通过这种方式收集到对应的监控后端。

• 8、策略执行

  • 在进行服务访问时，通过 Mixer 连接后端服务来控制服务间的访问，判断对访问是放行还是拒绝。
  • 上图中，Mixer 后端可以对接一个限流服务对从 frontend 服务到 forecast 服务的访问进行速率控制等操作。

• 9、外部访问

  • 在网格的入口处有一个 Envoy 扮演入口网关的角 色。
  • 上图中，外部服务通过 Gateway 访问入口服务 frontend，对 frontend 服务的负载均衡和一些流量治理策略都在这个 Gateway 上执行。

1.3 istio组件作用

1、Pilot

• Pilot 是 Istio 的主要控制组件，下发指令控制客户端，在整个系统中，Pilot 完成以下任务：

  • 1、从 Kubernetes 或者其他平台的注册中心获取服务信息，完成服务发现过程。

  • 2、读取 Istio 的各项控制配置，在进行转换之后，将其发给数据面进行实施。

• Pilot 将配置内容下发给数据面的 Envoy，Envoy 根据 Pilot 指令，将路由、服务、监听、集群等定义信息转换为本地配置，完成控制行为的落地。

  • 1）Pilot 为 Envoy 提供服务发现

  • 2）提供流量管理功能（例如，A/B 测试、金丝雀发布等）以及弹性功能（超时、重试、熔断器等）；

  • 3）生成 envoy 配置

  • 4）启动 envoy

  • 5）监控并管理 envoy 的运行状况，比如 envoy 出错时 pilot-agent 负责重启 envoy，或者 envoy 配置变更后 reload envoy

2、Envoy

• Envoy 是什么？

  • Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。

  • Envoy 有许多强大的功能

    • 动态服务发现 、负载均衡 、TLS 终端 、HTTP/2 与 gRPC 代理
    • 断路器 、健康检查 、流量拆分、灰度发布、故障注入

• Istio 中 Envoy 与服务什么关系？

  • Envoy和Service A同属于一个Pod，共享网络和命名空间，Envoy代理进出Pod A的流量
  • 并将流量按照外部请求的规则作用于Service A中

• Pilot-agent是什么？
  • Envoy 不直接跟 k8s 交互，通过 pilot-agent 管理的
  • Pilot-agent 进程根据 K8S APIserver 中的配置信息生成 Envoy 的配置文件，并负责启动 Envoy 进程。
  • Envoy 由 Pilot-agent 进程启动，启动后，Envoy 读取 Pilot-agent 为它生成的配置文件
  • 然后根据该文件的配置获取到Pilot 的地址，通过数据面从 pilot 拉取动态配置信息
  • 包括路由(route），监听器(1istener），服务集群(cluster）和服务端点 (endpoint)

3、Citadel

• 负责处理系统上不同服务之间的 TLS 通信。
• Citadel 充当证书颁发机构(CA)，并生成证书以允许在数据平面中进行安全的 mTLS 通信。
• Citadel 是 Istio 的核心安全组件，提供了自动生 成、分发、轮换与撤销密钥和证书功能。
• Citadel 一直监听 Kube- apiserver，以 Secret 的形式为每个服务都生成证书密钥，并在 Pod 创建时挂载到 Pod 上
• 代理容器使用这些文件来做服务身份认证，进而代 理两端服务实现双向 TLS 认证、通道加密、访问授权等安全功能
• 如图 所示，frontend 服 务对 forecast 服务的访问用到了HTTP 方式，通过配置即可对服务增加认证功能
• 双方的 Envoy 会建立双向认证的 TLS 通道，从而在服务间启用双向认证的 HTTPS

4、Galley

• Galley 是 istio 的配置验证、提取、处理和分发的组件。

• Galley 是提供配置管理的服务。实现原理是通过 k8s 提供的 ValidatingWebhook 对配置进行验证。

• Galley 使 Istio 可以与 Kubernetes 之外的其他环境一起工作，因为它可以将不同的配置数据转换为Istio 可以理解的通用格式。

5、 Ingressgateway

• Ingressgateway 就是入口处的 Gateway，从网格外访问网格内的服务就是通过这个 Gateway 进行的。
• istio-ingressgateway 是一个 Loadbalancer 类型的 Service，不同于其他服务组件只有一两个端 口
• istio-ingressgateway 开放了一组端口，这些就是网格内服务的外部访问端口
• 如下图所示，网格入口网关 istio-ingressgateway 的负载和网格内的 Sidecar 是同样的执行流程
• 也和网格内的其他 Sidecar 一样从 Pilot 处接收流量规则并执行。
• 注：网关配置应用于在网格边缘运行的独立 Envoy 代理，而不是与服务工作负载一起运行的 Sidecar Envoy 代理

6、Sidecar-injector

• Sidecar-injector 是负责自动注入的组件，只要开启了自动注 入，在 Pod 创建时就会自动调用istio-sidecar-injector 向 Pod 中注入 Sidecar 容器。

• 在 Kubernetes 环境下，根据自动注入配置，Kube-apiserver 在拦截到 Pod 创建的请求时

• 会调用自动注入服务 istio-sidecar-injector 生成 Sidecar 容器的描述并将其插入原 Pod 的定义中

• 这样，在创建的 Pod 内除了包括业务容器，还包括 Sidecar 容器，这个注入过程对用户透明。

02.Ingress部署nginx

2.1 入口网关

• 入口网关（Ingress Gateway）是 Istio 重要的资源对象之一，是用于管理网格边缘入站的流量
• 通过入口网关就可以很轻松的将网格内部的服务暴露到外部提供访问
• 注：网关配置应用于在网格边缘运行的独立 Envoy 代理，而不是与服务工作负载一起运行的 Sidecar Envoy 代理
• 所以我们配置的 gateway资源指的是 下图中的 ② istio-ingressgateway

2.2 nginx-gateway.yaml

通过命令访问 curl -H "Host: nginx.gateway.com" http://ingressgateway:nodeport/

• istio-ingressgateway 就是小区的大门（唯一的大门），所有进入的流量都需要经过，
• ingressgateway 相当于路标引导去到A B C D的一栋建筑里面，分开域名去导流，
• virtualservice 就像到建筑里的电梯一样，按照不同的楼层进行管理路由的作用
• destinationrule 到达具体的楼层后按照不同的门房号 1 2 3 4 进入到真正的屋里去。

注：安装istio后会有下面三个服务

istio-egressgateway : 管理进入的流量

istio-ingressgateway : 管理出去的流量

istiod

apiVersion: networking.istio.io/v1alpha3
kind: Gateway  # ② nginx-gw 是 ingressgateway
metadata: 
  name: nginx-gw 
spec:
  selector:
    app: istio-ingressgateway  # ① istio-ingressgateway 是默认已经创建好的istio网关控制器
                               # 将 ingressgateway（nginx-gw）关联到 网关 istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - nginx.test.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService  # ③ virtualservice 
metadata:
  name: nginx-vs
spec:
  hosts:
  - nginx.test.com
  gateways:
  - nginx-gw
  http:
  - route:
    - destination:
        host: nginx-svc
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - image: 'nginx:latest'
          name: nginx-deployment