Istio 流量治理（介绍、安装、gw、vs、dr使用）-Day01

1. 介绍

1.1 什么是服务网格

服务网格（Service Mesh）是一种用于管理和控制微服务架构中服务间通信的基础设施层。它提供了一种透明的方式来处理服务间的通信、负载均衡、服务发现、安全性、监控和故障恢复等功能。


服务网格通常由一组网络代理（称为 sidecar）组成，这些代理与每个微服务应用程序部署在一起。这些代理通过拦截和管理服务间的通信流量，提供了一些关键的功能和特性，包括：


(1) 服务发现和负载均衡：服务网格能够自动发现注册的微服务实例，并根据负载均衡算法将流量分配到不同的实例上，以实现高可用性和性能优化。


(2) 安全性和认证授权：服务网格提供了强大的安全功能，包括服务间的身份验证、认证和授权。它可以确保只有经过授权的服务可以相互通信，并提供了对通信流量的加密和解密。


(3) 监控和追踪：服务网格可以收集和汇总微服务的指标和日志，提供对流量和性能的实时监控。它还支持分布式追踪，可以跟踪请求在不同微服务之间的路径和性能。


(4) 故障恢复和熔断：服务网格具备故障恢复的能力，可以在服务出现故障或不可用时自动进行故障转移和重试。它还支持熔断机制，可以在服务不可用时限制对该服务的请求，以避免级联故障。


通过引入服务网格，开发人员可以将关注点从底层的通信细节中解放出来，更专注于业务逻辑的开发和微服务的功能。服务网格还提供了对微服务架构的可观测性和管理性的增强，使得整体的系统更易于管理和维护。


Istio 和 Linkerd 是两个比较流行的开源服务网格实现，它们在不同的方面提供了类似的功能和特性。

1.2 什么是Istio

Istio 是一个开源的服务网格平台，用于管理和连接微服务架构中的服务。
它提供了一套功能强大的工具和组件，用于处理服务之间的通信、流量控制、安全性、监控和故障恢复等方面。


以下是 Istio 的一些关键特性：
（1）服务发现和负载均衡：Istio 可以自动发现和注册微服务实例，并提供负载均衡功能，以均衡流量分发到不同的服务实例上，实现高可用性和性能优化。


（2）流量管理：Istio 允许开发人员通过配置和路由规则来控制服务之间的流量。它支持灵活的流量分发、A/B 测试、金丝雀发布和蓝绿部署等策略，以便更好地管理和控制服务间的通信。


（3）安全性：Istio 提供了强大的安全功能，包括服务间的身份验证、授权和加密。它可以确保只有经过授权的服务可以相互通信，并提供对通信流量的加密和解密。


（4）监控和追踪：Istio 支持对微服务架构的实时监控和追踪。它可以收集、聚合和可视化服务的指标和日志，提供对流量、延迟和错误率等关键指标的监控和分析。


（5）故障恢复：Istio 具备故障恢复的能力，可以在服务出现故障或不可用时自动进行故障转移和重试。它支持熔断和限流机制，以避免级联故障和资源耗尽。


（6）可观测性：Istio 提供了丰富的可观测性功能，包括请求跟踪、指标收集和分析、日志记录等。这些功能可以帮助开发人员了解系统的运行状况，快速排查问题并进行性能优化。


Istio 通过将 sidecar 代理注入到每个微服务实例中，实现了对服务间通信的控制和管理。它与 Kubernetes 等容器编排平台紧密集成，为微服务架构提供了一个强大的基础设施层，简化了服务间通信的复杂性，并提供了丰富的功能和工具来提高整体系统的可靠性和可观测性。

1.3 Istio如何工作（架构）

Istio从逻辑上来说，由两个部分组成:数据平面和控制平面。
（1）数据平面（sidecar）
负责在服务网格应用程序中管理实例之间的网络流量的部分。


（2）控制平面（Istiod）
负责生成和部署控制数据平面行为的相关配置。
控制平面通常包括API接口、命令行界面和用于管理应用程序的图形用户界面等。


大致的工作流程：
首先我们服务启动的时候，会被自动注入一个sidecar 代理到pod中，这个sidecar 代理就是数据平面，主要就是负责进出流量管理。
我们代理的配置，就主要由我们控制平面进行定义，然后动态下发到数据平面。

1.4 Istio版本演进

1.4.1 三次重要的变革

（1）2018年7月，Istio v1.0发布，且生产可用，但是实际用的人很少，因为Istio大概会占据整个系统30%的资源。


（2）2019年3月，Istio V1.1发布，并且完全分布式，但是从1.0到1.1，就性能上来说，不但没有增强，反而进一步恶化了，因为完全分布式增加了网络的开销。


（3）2020年3月，Istio v1.5发布，这次彻底回归到了单体模式，经过了这次版本重构后，系统资源损耗从原来的30%降到了10%左右。

1.4.2 Istio V1.0 架构

控制平面主要由3个组件组成
（1）Pilot：控制平面流量治理核心组件

• 管理和配置部署在Istio服务网格中的所有Envoy代理实例。
• 为Envoy Sidecar 提供服务发现、智能路由的流量管理功能 (例如，A/B 测试、金丝雀推出等) 和弹性 (超时、重试、断路器等）
  
  

（2）Citadel：提供身份和凭据管理等安全相关的功能，实现强大的服务到服务和最终用户身份验证。
主要就是控制平面的安全组件，负责服务的私钥和数字证书管理，用于提供自动生成、分发轮换及撤销私钥和数据证书的功能;


（3）Mixer：遥测（可观测性，周期性的抓取sidecar的监控指标）和策略（限流、配额等）

• 通过内部插件接口扩展支持第三方组件。
• 插件的修改或更新，需要重新部署Mixer。
  
  

数据平面这里不在做过多介绍，没变。

1.4.3 Istio V1.1 架构

主要有2个变化
（1）Mixer
将插件模型替换为使用进程外的Adapter进行扩展（性能表现更差）。
完成了Mixer与扩展间的解耦，就是插件的修改或更新，不再要重新部署Mixer，只需要去操作对应的Adapter，但由于是进程外通信，所以对网络也造成了不小的开销。
1.1的性能恶化，主要也就是因为Mixer的变化。


（2）Galley
控制平面新增了Galley组件。
主要就是负责让Pliot和不同平台对接。

1.4.4 Istio V1.5 架构

（1）回归单体
抛弃影响性的Mixer，遥测功能交由Envoy自行完成。
将Pilot、Citadel、Galley和Sidecar Injector整合为一个单体应用istiod。


（2）Istiod
Istiod充当控制平面，将配置分发到所有Sidecar代理和网关。
它能够为支持网格的应用实现智能化的负载均衡机制，且相关流量绕过了kube-proxy;


截止到目前Istio 1.19.3，仍然还在沿用该架构。

1.4.5 Pilot功能简介

1.4.5.1 Pilot配置分发机制

Pilot负责网格中数据平面相关的配置信息的获取、生成及分发。
它通过用户的配置及服务注册表获取网格配置信息并将其转换为xDS接口的标准数据格式，而后经gPRC分发至相关的Envoy代理;


如下图：
Service Registry: 服务注册表中存储有相关平台上注册的各Service的相关信息，例如kubernetes的services等。
Config Storage：配置存储。就是通过vs和dr额外定义的一些高级配置，都存在这里。

1.4.6 Citadel功能简介

1.4.7 Galley功能简介

1.5 东西南北向流量

如下图：
首先我们客户端的操作，是直接通过api和控制平面进行交互的，然后由控制平面把数据更新到数据平面。
下图的最右侧的Observer就是我们的日志，Trace就是链路追踪，它们都是通过Sidecar代理去获取的数据。


在数据平面的流量，称之为“东西向流量”，可以理解为网格内部，服务与服务之间的请求流量。
当网格外部有客户端需要请求网格内部时，这种属于网格外部的“入向流量”，如果是网格内部的服务访问网格外部的服务时，这种就属于网格内部的“出向流量”。
“入向流量”对于网格而言，一般由IngressGateway来统一治理，“出向流量”由EngressGateway来统一治理，这部分流量就被称为“南北向流量”。

1.6 Isito Sidecar Injector

Istio服务网格中的每个Pod都必须伴随一个Istio兼容的Sidecar一同运行，常用的将Sidecar注入Pod中的方法有两种:
（1）手工注入：使用istioctl客户端工具进行注入。
（2）自动注入：使用Istio sidecar injector自动完成注入过程。

• 利用Kubernets webhook实现sidecar的自动注入。
• 创建Pod时自动注入过程发生在Admission Controller的Mutation阶段，根据自动注入配置，kube-apiserver拦截到Pod创建请求时，调用自动注入服务istio-sidecar-injector生成Sidecar容器的描述，并将其插入到Pod的配置清单中。
  
  

扩展：
为啥sidecar能够代理请求？
首先回顾下puase容器，该容器共享了POD中的网络（network、IPC、UTS）和存储，后续所有加入该pod中的服务都会共享网络和存储。
正常情况下启动一个服务，比如端口是80，pod中都会监听一个socket（0.0.0.0:80），这就意味着我的业务服务是可以靠自己实现流量进出控制的，进出流量默认情况下根本不由sidecar处理。
那istio是如何实现流量都由sidecar控制的呢？
当我们的sidecar注入到pod中的时候，会创建iptables规则，来对应用程序的进出流量进行拦截和转发，通过iptables规则，让所有进出流量都通过它来进行处理。

2. 部署Isito控制平面1.14

2.1 Istio的系统组件

（1）控制平面
控制平面的组件默认都部署在istio-system名称空间下，主要有以下几个组件：

• istiod
  
  

（2）数据平面

• istiod # istio二次开发的envoy
• ingress-gateway # ingressgateway是暴露网格内部服务到网格外部的关键入口
• egress-gateway
  
  

（3）适配1 2 的组附加组件
Addons（Kiali、Prometheus、Grafana、Jaeger）

2.2 部署方法

（1）istioctl

• Istio的专用管理工具，支持定制控制平面及数据平面。
• 通过命令行的选项支持完整的 IstioOperator API。
• 命令行各选项可用于单独设置、以及接收包含IstioOperator自定义资源(CR)的yaml文件。# 各CR资源对应组件的升级等功能，需要由管理员手动进行
  
  

（2）Istio Operator

• Istio相关的自定义资源 (CR) 的专用控制器，负责自动维护由CR定义的资源对象。
• 管理员根据需要定义相应的CR配置文件，提交至Kubernetes APIServer后，即可由Operator完成相应的操作。
  
  

（3）helm

• 基于特定的Chart，亦可由Helm安装及配置Istio。
• 截止目前，该功能仍处于alpha阶段。
  
  

提示：
各部署工具依赖的前提条件会有所不同，使用前，需要分别按照其实际要求事先进行准备。
各工具的部署操作，最终都要转换为Kubernetes的资源配置文件，并创建于集群上。

2.3 Istio内置的配置档案

2.3.1 什么是配置档案

Isito的配置档案，事实上是Istio Operator API内置的特定CR格式的配置文件。 # 就是配置文件
CR名称：istio operators
所属的资源群组：installistio.io/vlalpha1


因此，各配置档案也是该资源类型下的资源对象的定义。

2.3.2 配置档案的类型

（1）istioctl提供了内置配置文件(配置档案)用于快速部署。

• default：根据IstioOperator API的默认设置启用相关的组件，适用于生产环境;
• demo：会部署较多的组件，旨在演示istio的功能，适合运行Bookinfo一类的应用程序；
• minimal：类似于default profle，但仅部署控制平台组件；
• remote：用于配置共享Control Plane的多集群环境；
• empty：不部署任何组件，通常帮助用户在自定义profle时生成基础配置信息；
• preview：包含预览性配置的profle，用于探索Istio的新功能，但不保证稳定性、安全性和性能；

2.4 下载并部署Isito1.14

官方文档：https://istio.io/latest/zh/docs/setup/getting-started/

2.4.1 下载并解压

下载地址：https://github.com/istio/istio/releases/download/1.14.3/istio-1.14.3-linux-amd64.tar.gz

[root@k8s-harbor01 ~]# cd /usr/local/
[root@k8s-harbor01 local]# ll -h istio-1.14.3-linux-amd64.tar.gz # 因为翻墙，所以这里我已经提前上传上来了
-rw------- 1 root root 23M 10月 24 17:08 istio-1.14.3-linux-amd64.tar.gz

[root@k8s-harbor01 local]# tar xf istio-1.14.3-linux-amd64.tar.gz
[root@k8s-harbor01 local]# ll -d istio-1.14.3
drwxr-x--- 6 root root 115 7月  29 2022 istio-1.14.3

[root@k8s-harbor01 local]# ln -s istio-1.14.3 istio
[root@k8s-harbor01 local]# ll istio
lrwxrwxrwx 1 root root 12 10月 24 17:10 istio -> istio-1.14.3
[root@k8s-harbor01 istio]# ll
总用量 28
drwxr-x---  2 root root    22 7月  29 2022 bin # 该目录下是istioctl 客户端二进制文件。
-rw-r--r--  1 root root 11348 7月  29 2022 LICENSE
drwxr-xr-x  5 root root    52 7月  29 2022 manifests # 内置部署清单（配置档案）
-rw-r-----  1 root root   882 7月  29 2022 manifest.yaml
-rw-r--r--  1 root root  6016 7月  29 2022 README.md
drwxr-xr-x 23 root root  4096 7月  29 2022 samples # 该目录下的示例应用程序
drwxr-xr-x  3 root root    57 7月  29 2022 tools

2.4.2 将 istioctl添加到系统环境变量

[root@k8s-harbor01 istio]# export PATH=$PWD/bin:$PATH
[root@k8s-harbor01 istio]# istioctl version
client version: 1.14.3
control plane version: 1.14.3
data plane version: 1.14.3 (8 proxies)

# 列出内置的配置档案
[root@k8s-harbor01 ~]# istioctl profile list
Istio configuration profiles:
    default
    demo
    empty
    external
    minimal
    openshift
    preview
    remote

# 查看配置档案的具体内容
[root@k8s-harbor01 ~]# istioctl profile dump demo
# 内容如下图

2.4.3 安装 Istio

2.4.3.1 基于demo配置安装isito

# 直接部署
istioctl install --set profile=demo -y

# 假设我们需要自定义demo配置，再安装就如下
[root@k8s-harbor01 ~]# istioctl profile dump demo > istio-demo.yaml
[root@k8s-harbor01 ~]# ll istio-demo.yaml
-rw-r--r-- 1 root root 5024 10月 24 17:28 istio-demo.yaml

[root@k8s-harbor01 ~]# istioctl apply -f istio-demo.yaml -y # -y不用输入yes

[root@k8s-harbor01 ~]# kubectl get po -n istio-system
NAME                                    READY   STATUS    RESTARTS   AGE
istio-egressgateway-55748d4c9b-q5pqk    1/1     Running   0          49s
istio-ingressgateway-66867b46f4-rzjqb   1/1     Running   0          49s # 
istiod-744dc8cf66-ldqt7                 1/1     Running   0          57s

# 检查部署是否成功
[root@k8s-harbor01 ~]# istioctl verify-install -f istio-demo.yaml
……省略部分内容
✔ Istio is installed and verified successfully

2.4.3.2 添加标签，开启自动注入Sidecar功能

[root@k8s-harbor01 ~]# kubectl label namespace default istio-injection=enabled
namespace/default labeled

[root@k8s-harbor01 ~]# kubectl get ns default --show-labels
NAME      STATUS   AGE   LABELS
default   Active   68d   istio-injection=enabled,kubernetes.io/metadata.name=default

2.4.4 部署附加组件

[root@k8s-harbor01 ~]# cd /usr/local/istio/samples/addons/
[root@k8s-harbor01 addons]# ls
extras  grafana.yaml  jaeger.yaml  kiali.yaml  prometheus.yaml  README.md

[root@k8s-harbor01 addons]# kubectl apply -f .

[root@k8s-harbor01 addons]# kubectl get po -n istio-system
NAME                                    READY   STATUS              RESTARTS   AGE
grafana-6794b7cd4d-hwrqv                0/1     ContainerCreating   0          15s
istio-egressgateway-55748d4c9b-q5pqk    1/1     Running             0          15m
istio-ingressgateway-66867b46f4-rzjqb   1/1     Running             0          15m
istiod-744dc8cf66-ldqt7                 1/1     Running             0          15m
jaeger-7bb75985cf-ptwff                 1/1     Running             0          15s
kiali-577d898bfd-76x8d                  0/1     ContainerCreating   0          15s
prometheus-55f7f779f8-v7th8             2/2     Running             0          14

2.4.5 部署istio后生成的crd资源

[root@k8s-harbor01 ~]# kubectl get crd|grep istio

2.4.6 查看属于networking.istio.io群组的资源

该群组是提供高级网络功能（流量治理）的关键资源

[root@k8s-harbor01 ~]# kubectl api-resources --api-group=networking.istio.io

2.5 卸载Isito

Istio官网：卸载Istio

3. Istio流量治理

3.1 Istio流量治理的关键配置

（1）Istio通过Ingress Gateway为网格引入外部流量;

• Gateway中运行的主程序为Envov，它同样从控制平面接收配置，并负责完成相关的流量传输；
• 换言之，Gateway资源对象，用于将外部访问映射到内部服务，它自身只负责通信子网的相关功能，例如套接字，而七层路由功能则由VirutalService实现;
  
  

（2）Istio基于ServiceEnty资源对象将外部服务注册到网格内，从而像将外部服务以类同内部服务一样的方式进行访问治理;

• 对于外部服务，网格内Sidecar方式运行的Envoy即能执行治理；
• 若需要将外出流量收束于特定几个节点时则需要使用专用的Egress Gateway完成，并基于此Egress Gateway执行相应的流量治理;
  
  

（3）Virtual Services和Destination Rules是Istio流量路由功能的核心组件；


（4）Virtual Services用于将分类流量，并将其路由到指定的目的地(Destination)，而Destination Rules则用于配置那个指定Destination如何处理流量；

3.1.1 Virtual Services

用于在Istio及其底层平台（例如Kubernetes）的基础上，配置如何将请求路由到网格中的各Service之上。
通常由一组路由规则（routingrules）组成，这些路由规则按顺序进行评估，从而使Istio能够将那些对Virtual Service的每个给定请求匹配到网格内特定的目标之上。
事实上，其定义的是分发给网格内各Envoy的VirtualHost和Route的相关配置。


简单来说：Virtual Service定义虚拟主机及相关的路由规则，包括路由至哪个目标(集群或子集)。
下图是vs所有字段配置：

3.1.2 Destination Rules

定义流量在“目标”内部的各端点之间的分发机制，例如将各端点进行分组，分组内端点间的流量均衡机制，异常探测等。
事实上，其定义的是分发给网格内各Envoy的Cluster的相关配置。


简单来说：Destination Rule定义集群或子集内部的流量分发机制。

3.1.3 Gateway

3.2 流量治理相关资源总结

（1）Gateway（入向）
生效在istio-ingressgateway上，用于配置接入哪些外部流量。
流量进来后，如何和网格内部的服务建立关联关系呢？
其实这个Gateway就相当于是生成了一个Listener，如果Listener已经存在，则在它之上生成一个VirtualHost，
但该VirtualHost从Listener接收到的流量，到底该发往何处（流量目标），并不会自动生成。
所以我们还需要一个VirtualService资源，在VirtualService上配置流量路由的具体路径。


（2）VirtualService
配置流量路由的具体路径，它有两种生效逻辑：

• 生效在istio-ingressgateway上。 # 如果VirtualService只是生效在istio-ingressgateway上，那么这个配置并不会下发到网格内部的sidecar。
• 生效在服务网格上。 # 这种方式就会把配置下发到网格内部所有的sidecar。
  
  

（3）DestinationRule
配置集群内部的流量分发逻辑，如负载均衡算法、连接池等。

3.3 流量治理演示

3.3.1 配置istio-ingressgateway svc

3.3.1.1 默认配置查看

[root@k8s-harbor01 ~]# kubectl get svc -n istio-system istio-ingressgateway # 这里的svc类型默认就是LoadBalancer，也可以按需改成nodeport，EXTERNAL-IP挂起，是因为我们这个不是云服务器，所以它获取不到IP。
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   10.100.125.148   <pending>     15021:31412/TCP,80:31697/TCP,443:32672/TCP,31400:31337/TCP,15443:31272/TCP   22h

3.3.1.2 修改istio-ingressgateway svc类型为nodeport

当kube-proxy代理模式是ipvs时，不要用k8s节点的ip绑定为EXTERNAL-IP，不然集群内网络会出问题。
这里我使用nodeport。

# 调整svc配置
[root@k8s-harbor01 ~]# kubectl edit svc -n istio-system istio-ingressgateway
……省略部分内容
  type: NodePort

[root@k8s-harbor01 ~]# kubectl get svc -n istio-system istio-ingressgateway

3.3.2 示例一：内部服务访问

3.3.2.1 编辑yaml

[root@k8s-harbor01 ~]# cat deploy-demoapp01.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: demoappv10
    version: v1.0
  name: demoappv10
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  selector:
    matchLabels:
      app: demoapp
      version: v1.0
  template:
    metadata:
      labels:
        app: demoapp
        version: v1.0
    spec:
      containers:
      - image: ikubernetes/demoapp:v1.0
        imagePullPolicy: IfNotPresent
        name: demoapp
        env:
        - name: "PORT"
          value: "8080"
        ports:
        - containerPort: 8080
          name: web
          protocol: TCP
        resources:
          limits:
            cpu: 50m
---
apiVersion: v1
kind: Service
metadata:
  name: demoappv10
spec:
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    app: demoapp
    version: v1.0
  type: ClusterIP
---

3.3.2.2 创建pod

[root@k8s-harbor01 ~]# kubectl apply -f deploy-demoapp01.yaml
deployment.apps/demoappv10 created
service/demoappv10 created

[root@k8s-harbor01 ~]# kubectl get po,svc # pod都是2/2，表示都被注入了一个istio-proxy

NAME                          READY   STATUS    RESTARTS   AGE
demoappv10-54757f48d6-77g4l   2/2     Running   0          2m22s
demoappv10-54757f48d6-fcv4b   2/2     Running   0          2m22s
demoappv10-54757f48d6-n2hzh   2/2     Running   0          2m22s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/demoappv10   ClusterIP   10.100.77.133   <none>        8080/TCP   3m31s
service/kubernetes   ClusterIP   10.100.0.1      <none>        443/TCP    69d

3.3.2.3 部署一个测试用的客户端

这里直接使用istio官方提供的客户端

[root@k8s-harbor01 ~]# kubectl apply -f /usr/local/istio/samples/sleep/sleep.yaml
serviceaccount/sleep unchanged
service/sleep unchanged
deployment.apps/sleep created

[root@k8s-master1 ~]# kubectl get po,svc|grep sleep
pod/sleep-645b966fc4-qjgns        2/2     Running   0          17s
service/sleep        ClusterIP   10.200.214.100   <none>        80/TCP     17s

3.3.2.4 请求测试

[root@k8s-harbor01 ~]# kubectl exec -it sleep-645b966fc4-qjgns -- /bin/sh

# 可以看到下面的请求，都是被demoappv10轮询响应的
# ClientIP: 127.0.0.6，表示出站请求是被本地的sidecar响应的处理的。
/ $ curl demoappv10:8080
iKubernetes demoapp v1.0 !! ClientIP: 127.0.0.6, ServerName: demoappv10-54757f48d6-fcv4b, ServerIP: 10.200.135.152!
/ $ curl demoappv10:8080
iKubernetes demoapp v1.0 !! ClientIP: 127.0.0.6, ServerName: demoappv10-54757f48d6-n2hzh, ServerIP: 10.200.85.218!
/ $ curl demoappv10:8080
iKubernetes demoapp v1.0 !! ClientIP: 127.0.0.6, ServerName: demoappv10-54757f48d6-77g4l, ServerIP: 10.200.58.214!

3.3.2.5 目前的请求链路分析

当前的请求链路大致如下：
（1）首先在我们default名称空间下，有一个sleep pod和demoapp pod，这俩pod都分别被注入的一个sidecar。
（2）在sleep pod中发起一个curl请求到demoapp，请求会先到sleep中的sidecar（出向侦听器），然后由sleep的sidecar代理到demoapp 的sidecar（入向侦听器）然后由demoapp的sidecar把这个请求代理到demoapp本身。
（3）所以，在sleep上，应该有一个出向侦听器和cluster，这个cluster上的endpoint，就是demoapp的3个pod，然后由于默认负载策略是轮询，所以每次请求，流量都会到达其中一个pod。
（4）在demoapp上也有一个入向侦听器，并且也有一个cluster，这个cluster对应的endpoint就只有demoapppod中的进程了。
（5）这些信息都是哪儿来的呢？那就是Istiod控制平面更新的。
（6）Isitod会通过apiserver去watch etcd中和service相关的信息。
（7）比如新创建的demoapp service，Istiod会把它的端口读取出来，在sleep的代理上生成一个出向侦听器，然后把pod ip读取出来，形成cluster 上对应的endpoint。

3.3.3 代理配置查看

3.3.3.1 istioctl proxy-status

获取Istiod向网格中每个Envoy最后发送和最后确认的xDS同步。
简单点说：显示 Istio 服务网格中代理（Envoy）的状态信息

# istioctl ps：用于显示与 Istio 服务网格相关的代理（Envoy）的运行状态
[root@k8s-harbor01 ~]# istioctl ps # proxy-status可以简写为ps
NAME                                                   CLUSTER        CDS        LDS        EDS        RDS          ECDS         ISTIOD                      VERSION
demoappv10-54757f48d6-77g4l.default                    Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-744dc8cf66-ldqt7     1.14.3
demoappv10-54757f48d6-fcv4b.default                    Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-744dc8cf66-ldqt7     1.14.3
demoappv10-54757f48d6-n2hzh.default                    Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-744dc8cf66-ldqt7     1.14.3
istio-egressgateway-55748d4c9b-q5pqk.istio-system      Kubernetes     SYNCED     SYNCED     SYNCED     NOT SENT     NOT SENT     istiod-744dc8cf66-ldqt7     1.14.3
istio-ingressgateway-66867b46f4-rzjqb.istio-system     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-744dc8cf66-ldqt7     1.14.3
sleep-645b966fc4-h9jhm.default                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-744dc8cf66-ldqt7     1.14.3

# SYNCED：同步完成
# NOT SENT：没有发送。没有发送不一定是错误的。
# ISTIOD：表示分发配置的控制平面实例是谁

3.3.3.2 istioctl proxy-config

用于检索和显示 Istio 服务网格中代理（Envoy）的配置信息。
所有和envoy相关的配置都可以看，具体查看帮助信息。–help

# 查看sleep的listeners配置
# istioctl proxy-config <clusters|listeners|routes|endpoints|bootstrap|log|secret> <pod-name[.namespace]>
[root@k8s-harbor01 ~]# istioctl pc listeners --port 8080 sleep-645b966fc4-h9jhm # 8080就是demoapp的端口，同时也是sleep上的出向侦听器
ADDRESS PORT MATCH                                DESTINATION
0.0.0.0 8080 Trans: raw_buffer; App: http/1.1,h2c Route: 8080
0.0.0.0 8080 ALL                                  PassthroughCluster

# 查看sleep的routes配置（大概）
[root@k8s-harbor01 ~]# istioctl pc routes sleep-645b966fc4-h9jhm --name 8080 # 这里可以大概看到路由的名称、域名配置、路径匹配
NAME     DOMAINS                                        MATCH     VIRTUAL SERVICE
8080     demoappv10, demoappv10.default + 1 more...     /*
 
# 查看sleep的routes配置（详细）
[root@k8s-harbor01 ~]# istioctl pc routes sleep-645b966fc4-h9jhm --name 8080 -o json # 这里就会显示出详细的路由配置，内容很多，和之前学envoy时的配置内容差不多

# 查看clusters配置
[root@k8s-harbor01 ~]# istioctl pc clusters sleep-645b966fc4-h9jhm --port 8080 # 可以看到下面的集群信息是属于出站的一个集群信息，并且端点信息是通过EDS分发的	
SERVICE FQDN                             PORT     SUBSET     DIRECTION     TYPE     DESTINATION RULE
demoappv10.default.svc.cluster.local     8080     -          outbound      EDS

# 查看endpoints信息
[root@k8s-harbor01 ~]# kubectl get ep |grep demoapp
demoappv10   10.200.135.152:8080,10.200.58.214:8080,10.200.85.218:8080   46h

[root@k8s-harbor01 ~]# istioctl pc endpoints sleep-645b966fc4-h9jhm --port 8080 # 可以看到端点也是svc后的端点。
ENDPOINT                STATUS      OUTLIER CHECK     CLUSTER
10.200.135.147:8080     HEALTHY     OK                outbound|80||istio-egressgateway.istio-system.svc.cluster.local
10.200.135.148:8080     HEALTHY     OK                outbound|80||istio-ingressgateway.istio-system.svc.cluster.local
10.200.135.152:8080     HEALTHY     OK                outbound|8080||demoappv10.default.svc.cluster.local
10.200.58.214:8080      HEALTHY     OK                outbound|8080||demoappv10.default.svc.cluster.local
10.200.85.218:8080      HEALTHY     OK                outbound|8080||demoappv10.default.svc.cluster.local

3.3.3 示例二：把内部服务通过istio-ingressgateway暴露到集群外部

上面示例一的现状：
内部服务之间可以通过自己的sidecar进行流量转发，并且所有sidecar都会同步到istiod发来的svc信息，但是目前是没法在外部访问到的。
具体原因可以查看istio-ingressgateway的配置
# 查看集群配置
[root@k8s-harbor01 ~]# istioctl pc clusters -n istio-system istio-ingressgateway-66867b46f4-rzjqb --port 8080 # 这里确实可以看到，是有demoapp的集群信息的
SERVICE FQDN                             PORT     SUBSET     DIRECTION     TYPE     DESTINATION RULE
demoappv10.default.svc.cluster.local     8080     -          outbound      EDS

# 查看侦听器配置
[root@k8s-harbor01 ~]# istioctl pc listeners -n istio-system istio-ingressgateway-66867b46f4-rzjqb # 看下面是没有8080相关的侦听器的，所以外部请求是没法到内部的
ADDRESS PORT  MATCH DESTINATION
0.0.0.0 15021 ALL   Inline Route: /healthz/ready*
0.0.0.0 15090 ALL   Inline Route: /stats/prometheus*

3.3.3.1 准备相关配置

# 这里下载马哥提供的yaml: https://github.com/iKubernetes/istio-in-practise
[root@k8s-master1 ~]# ls
istio-in-practise-main

[root@k8s-master1 ~]# cd istio-in-practise-main/Traffic-Management-Basics/ms-demo/04-proxy-gateway/
[root@k8s-master1 04-proxy-gateway]# ll
总用量 8
-rw-r--r-- 1 root root 328 6月  13 13:43 gateway-proxy.yaml
-rw-r--r-- 1 root root 354 6月  13 13:43 virtualservice-proxy.yaml
[root@k8s-master1 04-proxy-gateway]#

3.3.3.2 创建网关

[root@k8s-master1 04-proxy-gateway]# cp gateway-proxy.yaml /tmp/gateway-demoapp.yaml
[root@k8s-master1 04-proxy-gateway]# vim /tmp/gateway-demoapp.yaml
[root@k8s-master1 04-proxy-gateway]# cat /tmp/gateway-demoapp.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway # 该资源是由istio提供的crd
metadata:
  name:  demoapp-gateway
  namespace: istio-system        # 要指定为ingress gateway pod所在名称空间
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "demoapp.magedu.com" # 该hosts配置就相当于在listener之上创建一个virtual_hosts虚拟主机配置，可以回看下envoy的知识点。

# 创建网关
[root@k8s-master1 04-proxy-gateway]# kubectl apply -f /tmp/gateway-demoapp.yaml
gateway.networking.istio.io/demoapp-gateway created

[root@k8s-master1 04-proxy-gateway]# kubectl get gw -n istio-system
NAME              AGE
demoapp-gateway   88s # 这就是刚刚创建的gw

上述gw创建出来有什么用呢？看下面

3.3.3.3 查看istio-ingressgateway的配置

[root@k8s-master1 04-proxy-gateway]# istioctl pc listeners istio-ingressgateway-66867b46f4-6mdsn -n istio-system
ADDRESS PORT  MATCH DESTINATION
0.0.0.0 8080  ALL   Route: http.8080 # 在我们创建gw之前，这里是没有8080相关的侦听器的。这里的8080是后端进程的真实端口
0.0.0.0 15021 ALL   Inline Route: /healthz/ready*
0.0.0.0 15090 ALL   Inline Route: /stats/prometheus*

3.3.3.4 请求测试

[root@k8s-master1 04-proxy-gateway]# curl -I 10.31.200.100:32070 # 这里是istio-ingressgateway 80对应的nodeport
HTTP/1.1 404 Not Found
date: Wed, 01 Nov 2023 08:23:46 GMT
server: istio-envoy
transfer-encoding: chunked

[root@k8s-master1 04-proxy-gateway]#

从上面的返回，看到的是一个404，为什么会返回404呢？原因如下：
首先我们现在的请求链路是：客户端---》服务端nodeport---》istio-ingressgateway---》demoappgateway---》后端服务（？）
正常来说，肯定要有一个后端服务来响应我们的请求的，但是我们只定义了gw，并没有定义相关路由信息，所以istio-ingressgateway根本不知道该把这个请求给谁。

可以通过查看istio-ingressgateway的配置来验证上面的说法。
[root@k8s-master1 04-proxy-gateway]# istioctl pc routes -n istio-system istio-ingressgateway-66867b46f4-6mdsn
NAME          DOMAINS     MATCH                  VIRTUAL SERVICE
http.8080     *           /*                     404
              *           /healthz/ready*
              *           /stats/prometheus*

通过上面的返回可以看到，8080对应的 VIRTUAL SERVICE就是定义的一个404，所以这就是为什么请求的时候返回了一个404状态码。

3.3.3.5 创建virtual service

这个vs就相当于envoy listener配置中的route配置

[root@k8s-master1 04-proxy-gateway]# cp virtualservice-proxy.yaml /tmp/virtualservice-demoapp.yaml

[root@k8s-master1 04-proxy-gateway]# vim /tmp/virtualservice-demoapp.yaml
[root@k8s-master1 04-proxy-gateway]# cat /tmp/virtualservice-demoapp.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: demoapp
spec:
  hosts:
  - "demoapp.magedu.com" # 定义匹配的主机头。如果从istio-system/demoapp-gateway进来的请求中包含主机头：demoapp.magedu.com，就把流量转发给名为default的route。
  gateways:
  - istio-system/demoapp-gateway # 在istio-system下，有一个名为demoapp-gateway的网关。就是和该网关建立绑定关系
  #- mesh
  http:
  - name: default
    route:
    - destination:
        host: demoappv10.default.svc.cluster.local # 满足上面条件的请求，被路由到该svc，同一ns下可以不写后缀。

[root@k8s-master1 04-proxy-gateway]# kubectl apply -f /tmp/virtualservice-demoapp.yaml
virtualservice.networking.istio.io/demoapp created
[root@k8s-master1 04-proxy-gateway]# kubectl get vs
NAME      GATEWAYS                           HOSTS                    AGE
demoapp   ["istio-system/demoapp-gateway"]   ["demoapp.magedu.com"]   3s

通过上述返回，可以看到一个名为demoapp 的vs，负责在istio-system/demoapp-gateway网关中接收请求头为demoapp.magedu.com的流量。

3.3.3.6 查看路由

[root@k8s-master1 04-proxy-gateway]# istioctl pc routes -n istio-system istio-ingressgateway-66867b46f4-6mdsn
NAME          DOMAINS                MATCH                  VIRTUAL SERVICE
http.8080     demoapp.magedu.com     /*                     demoapp.default
              *                      /healthz/ready*
              *                      /stats/prometheus*

通过上面的返回能看到，原来VIRTUAL SERVICE是404，当我们创建了vs后，就变成了demoapp.default。

3.3.3.7 请求测试

# 新增一个dns解析
root@k8s-master1 04-proxy-gateway]# tail -1 /etc/hosts
10.31.200.100 demoapp.magedu.com

# 请求
[root@k8s-master1 04-proxy-gateway]# curl demoapp.magedu.com:32070

3.3.4 流量治理小结

3.3.4.1 网格内部通信

要将任何一个serivce资源自动配置到网格内的每个sidecar上，需要生成以下几个关键的配置：
（1）Listener
由serivce的端口指定，80会被istio自动处理为8080。


（2）Route
由一个service的listener进入的所有流量（match /*），全部路由给该service的各pod生成的cluster。


（3）Cluster
由service基于其名称生成，并通过EDS下发给每个sidecar，所以集群名称，同service名称。


（4）Eendpoint
由service基于其Label Selector发现的各pod ip生成。

3.3.4.2 网格外部通信

流量必须经由某个istio-ingressgateway进入，因而，接入流量的前提是在istio-ingressgateway上开启一个Listener。
开启Listener的方法就是定义一个新的业务gateway，和istio-ingressgateway相关联。
然后定义我们流量的匹配方式，比如基于host匹配。
匹配到的流量，需要经由vs进行路由。


Client ----> Istio-Ingressgateway Service ----> Istio-Ingressgateway Pod（Listener由业务pod定义的Gateway生成） ----> Route（由业务pod定义的VirtualService生成） ----> Cluster（由Istiod发现的Service自动生成） ----> Endpoint

3.3.4.3 为什么上面的示例没有用到DestinationRule

当Cluster中的端点就那么两三个的时候，并且也不需要做一些高级的配置的时候，其实不定义DestinationRule也可以。

3.3.5 示例三：为示例二增加DestinationRule

3.3.5.1 DestinationRule简单介绍

[root@k8s-master1 ~]# cp istio-in-practise-main/Traffic-Management-Basics/ms-demo/03-demoapp-subset/destinationrule-demoapp.yaml /tmp/destinationrule-demoapp.yaml

[root@k8s-master1 ~]# cat /tmp/destinationrule-demoapp.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: demoapp
spec:
  host: demoapp # 这里定义的是目标service名称
  subsets: # 定义子集（不需要划分子集的话，就不需要该配置）
  - name: v10
    labels:
      version: v1.0 # pod中有标签version: v1.0的为一个子集
  - name: v11
    labels:
      version: v1.1 # pod中有标签version: v1.1的为一个子集

3.3.5.2 调整DestinationRule配置

[root@k8s-master1 ~]# cat /tmp/destinationrule-demoapp.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: demoapp
spec:
  host: demoappv10 # 这里定义的是目标service名称，这里一定要和目标service保持一致。
  trafficPolicy: # 流量策略配置
    loadBalancer: # 负载均衡配置
      simple: LEAST_CONN # simple：简单的负载均衡算法。LEAST_CONN：将流量发送到当前连接数最少的实例。默认策略：LEAST_REQUEST。
      # LEAST_CONN已经废弃了，所以设置LEAST_CONN，然后查看默认策略依然还是LEAST_REQUEST。

所以，这个配置的含义是，针对名为 "demoapp" 的目标serivce，使用LEAST_CONN 负载均衡策略，将流量均匀分发给连接数最少的实例。

3.3.5.3 创建DestinationRule

[root@k8s-master1 ~]# kubectl apply -f /tmp/destinationrule-demoapp.yaml
destinationrule.networking.istio.io/demoapp created

[root@k8s-master1 ~]# kubectl get dr
NAME      HOST      AGE
demoapp   demoapp   12s

3.3.6 示例四：暴露kiali到集群外部

[root@k8s-master1 ~]# kubectl get po,svc -n istio-system|grep kiali
pod/kiali-577d898bfd-pp2pg                  1/1     Running   0             2d19h
service/kiali                  ClusterIP   10.200.82.11     <none>        20001/TCP,9090/TCP  

首先kiali是没有接入sidecar的，也就是说它是属于网格外部的服务，但是，只要在k8s集群内部的service，都会被istiod发现。
只要能被istiod发现，就能够被配置成Listener。

3.3.6.1 配置解读

# kiali-gateway.yaml
[root@k8s-master1 ~]# cat istio-in-practise-main/Traffic-Management-Basics/kiali/kiali-gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: kiali-gateway
  namespace: istio-system
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 80
      name: http-kiali
      protocol: HTTP
    hosts:
    - "kiali.magedu.com"  # 该hosts配置就相当于在listener之上创建一个virtual_hosts虚拟主机配置，可以回看下envoy的知识点。
---
上面这段配置很简单，就是基于kiali.magedu.com这个host创建一个gateway，在 istio-ingressgateway上生成一个入向listener。

# kiali-virtualservice.yaml
[root@k8s-master1 ~]# cat istio-in-practise-main/Traffic-Management-Basics/kiali/kiali-virtualservice.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: kiali-virtualservice
  namespace: istio-system
spec:
  hosts: # 该配置必须和gateway中的 hosts:相同
  - "kiali.magedu.com"
  gateways: # 该配置必须和gateway中的name: kiali-gateway相同
  - kiali-gateway
  http: # 7层协议
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: kiali
        port:
          number: 20001
---
上面这段配置的意思是，创建一个和kiali-gateway相关联的vs，然后把来自kiali.magedu.com并且请求路径是/的请求，路由到端口为20001，名为kiali的serivce。

# kiali-destinationrule.yaml
[root@k8s-master1 ~]# cat istio-in-practise-main/Traffic-Management-Basics/kiali/kiali-destinationrule.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: kiali
  namespace: istio-system
spec:
  host: kiali
  trafficPolicy:
    tls:
      mode: DISABLE
---
上面这段配置的意思是，为名为kiali的service创建一个dr，流量分发策略使用默认配置，并且指明了不使用tls加密传输（默认就是关闭的）。

3.3.6.2 创建gw、vs、dr

[root@k8s-master1 ~]# kubectl apply -f istio-in-practise-main/Traffic-Management-Basics/kiali/.
destinationrule.networking.istio.io/kiali created
gateway.networking.istio.io/kiali-gateway created
virtualservice.networking.istio.io/kiali-virtualservice created

[root@k8s-master1 ~]# kubectl get gw,vs,dr -A|grep kiali
istio-system   gateway.networking.istio.io/kiali-gateway     24s
istio-system   virtualservice.networking.istio.io/kiali-virtualservice   ["kiali-gateway"]                  ["kiali.magedu.com"]     24s
istio-system   destinationrule.networking.istio.io/kiali     kiali        24s


[root@k8s-master1 kiali]# istioctl pc listener -n istio-system istio-ingressgateway-66867b46f4-6mdsn # 注意，因为我们gateway资源定义的端口就是80，所以查看istiogateway配置，不会额外显示，所有80请求都会通过istiogateway的8080端口进来
ADDRESS PORT  MATCH DESTINATION
0.0.0.0 8080  ALL   Route: http.8080
0.0.0.0 15021 ALL   Inline Route: /healthz/ready*
0.0.0.0 15090 ALL   Inline Route: /stats/prometheus*

3.3.6.3 调整hosts配置

把kiali.magedu.com 映射到任意一个k8s节点。过程略

3.3.6.4 访问测试

3.3.7 暴露Grafana到集群外部

3.3.7.1 配置解读

# grafana-gateway.yaml 该配置的主要作用就是在istiogatway上创建一个listener和virtual_host（可回顾envoy）
[root@k8s-master1 ~]# cat istio-in-practise-main/Traffic-Management-Basics/grafana/grafana-gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: grafana-gateway
  namespace: istio-system # Gateway资源可以在istio-system下，也可以在pod所在的ns下
spec:
  selector: # 通过标签选择和istio-ingressgateway进行关联，然后在istio-ingressgateway生成一个入向Listener
    app: istio-ingressgateway
  servers: 
  - port: # 这一段表示生成侦听器端口
      number: 80
      name: http
      protocol: HTTP
    hosts: # 这一段配置，就相当于envoy中的virtual_host配置
    - "grafana.magedu.com"
---

# grafana-virtualservice.yaml 该配置的作用就是在上面生成的listener下创建相应的路由功能
[root@k8s-master1 ~]# cat istio-in-practise-main/Traffic-Management-Basics/grafana/grafana-virtualservice.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: grafana-virtualservice
  namespace: istio-system # 这里可以在istio-system，也可以在pod所在ns
spec:
  hosts: # 这里的hosts配置必须和Gateway中定义的hosts配置完全一致
  - "grafana.magedu.com" 
  gateways: # 注意：当vs和被引用的gw不在同一ns下时，要使用ns/gw的格式进行引用
  - grafana-gateway # 这个网关名称也要和Gateway中定义的name完全一致
  http: # 路由配置
  - match:
    - uri:
        prefix: / # 前缀匹配/
    route:
    - destination: # 请求包含hosts：grafana.magedu.com，且请求路径为/的，都路由到grafana这个svc的3000端口
        host: grafana # 这里是定义的svc名称，没有指明ns，就表示也在metadata.namespace下
        port:
          number: 3000
---

# grafana-destinationrule.yaml 这个配置主要就是定义一个高级的流量治理功能
[root@k8s-master1 ~]# cat istio-in-practise-main/Traffic-Management-Basics/grafana/grafana-destinationrule.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: grafana
  namespace: istio-system
spec:
  host: grafana
  trafficPolicy:
    tls: # tls默认就是关闭的，所以这个加不加都行
      mode: DISABLE 
---

3.3.7.2 创建资源

略

3.3.8 流量治理总结

（1）Gatway
默认情况下，外部流量是没有办法通过istio-ingressgatway直接访问网格内部的，需要创建一个对应业务service的Gateway资源，这样istio-ingressgatway才能基于该Gateway自动生成一个Listener和Listener之中的Virtual_hosts，来接收外部请求。


（2）Virtual Service
但是光有Gatway也不够，因为此时的流量进来了，但是istiod并不知道该如何处理这些流量，所以还需要创建一个业务pod对应的vs，让vs来告诉请求去哪儿（路由功能）。
主要就是在Listener上，为某host或gatway，定制高级路由功能。


vs如何匹配Listener？
由关联的gateway CRD资源所定义。
由关联的service名称对应的端口所定义。


（3）DestinationRule
主要作用就是 为Cluster定义一些高级配置，如负载均衡策略、连接池等等。
默认配置：把service Name定义成Cluster，然后把该Service匹配到的pod，定义为cluster的endpoint。

3.3.9 Istio基本工作逻辑总结

首先Istiod会通过api server去watch etcd集群，从而发现我们整个集群所创建的service。
所有service都会被纳入网格的治理体系中，也就是配置到sidecar和gateway上。
然后自动生成对应的Listener、route、cluster、endpoint等。
没有接入sidecar的pod，只要在同一个k8s集群，也可以使用istio的流量治理功能，但前提是要客户端在网格内部。
因为客户端自身的sidecar上的listener发挥了作用。
但是有些不接入sidecar，有些功能还是没法实现，如双向TLS，因为控制平面没法向没有接入sidecar的pod分发证书。


如何区分网格内外？
网格内部：就是接入的sidecar的pdo。
网格外部：没有接入sidecar，但是在同一个k8s集群。

4. 流量治理和服务发现总结

（1）网格内服务发送和接受的流量（数据平面流量）都要经由Envoy代理进行，这也就是之前说到的Envoy流量拦截机制。


（2）Istio借助于服务注册表（Service Registry）完成服务发现。
Istio维护了一个内部服务注册表 (service registry)，它包含在服务网格中运行的Service及其相应的endpoints。
Service Registry所有的service和endpoint数据，都是由Isitod通过 api-server watch etcd中相关的数据得来。
Istio使用服务注册表（Service Registry）生成 Envoy 配置。


（3）K8s系统上，Istio会将网格中的每个Service的端口创建为Listener，而其匹配到的endpoint将组合成为一个Cluster。

• 这些Listener和Cluster将配置在网格内的每个SidecarEnvoy之上。
• 对于某个特定Sidecar Envoy来说，仅其自身所属的Service生成的Listener为Inbound Listener，而其他Service生成Listener都将配置为其上的OutboundListener。 # 访问自己属于入，访问其它属于出。
• Inbound Listener: 接收其所属Service的部分或全部流量。
• Outbound Listener: 代理本地应用访问集群内的其它服务。
  
  

（4）进出应用的所有流量都将被Sidecar Envoy拦截并基于重定向的方式进行处理。