[TOC]
1 istio 原理介绍和部署
1.1 什么是 serviceMesh
提到Service Mesh，就不得不提微服务。 根据维基百科的定义：
微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块（Small Building Blocks）为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关（Language-Independent/Language agnostic）的API集相互通信。
Service Mesh作为下一代微服务技术的代名词，初出茅庐却深得人心一鸣惊人，大有一统微服务时代的趋势。
那么到底什么是Service Mesh？一言以蔽之：Service Mesh是微服务时代的TCP协议。
有了这样一个感性的初步认知，我们再来看到底什么是Service Mesh。
服务开发模式和Service Mesh技术的演化过程
下面就是微服务的历史演变过程
1.1.1 时代0：点对点通信
我们可以看到两个服务之间都是在同一台服务器上，并且是点对点的通信
1.1.2 时代1：基于 stack 通信
多个服务之间基于 stack 通信，从而实现了服务的垮台部署但是然而现实远比想象的复杂，在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。
1.1.3 时代2：基于 TCP
在TCP出现之后，机器之间的网络通信不再是一个难题，以
GFS/BigTable/MapReduce 为代表的分布式系统得以蓬勃发展。这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。
1.1.4 时代3：通过软件层面实现
为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。
1.1.5 时代4：第一代 service Mesh Spring Cloud
时代 3 的微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题：
- 其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；
- 其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到；
- 其三，框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级。
因此以 Linkerd，Envoy，Ngixmesh 为代表的代理模式（边车模式）应运而生，这就是第一代 Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。
如果我们从一个全局视角来看，就会得到如下部署图：
如果我们暂时略去服务，只看Service Mesh的单机组件组成的网络：
相信现在，大家已经理解何所谓 Service Mesh，也就是服务网格了。它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格。
1.1.6 时代5 第二代Service Mesh Istio
第一代 Service Mesh 由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以 Istio 为代表的第二代 Service Mesh 。
只看单机代理组件（数据面板）和控制面板的Service Mesh全局部署视图如下：
至此，见证了6个时代的变迁，大家一定清楚了
Service Mesh 技术到底是什么，以及是如何一步步演化到今天这样一个形态。
现在，我们再回过头来看 Buoyant 的 CEO William Morgan，也就是 Service Mesh 这个词的发明人，对 Service Mesh 的定义：
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
这个定义中，有四个关键词：
- 基础设施层 + 请求在这些拓扑中可靠穿梭：这两个词加起来描述了
Service Mesh的定位和功能，是不是似曾相识？没错，你一定想到了 TCP； - 网络代理：这描述了
Service Mesh的实现形态； - 对应用透明：这描述了
Service Mesh的关键特点，正是由于这个特点，Service Mesh 能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题。
1.1.7 总结
Service Mesh 具有如下优点：
- 屏蔽分布式系统通信的复杂性（负载均衡、服务发现、认证授权、监控追踪、流量控制等等），服务只用关注业务逻辑；
- 真正的语言无关，服务可以用任何语言编写，只需和 Service Mesh 通信即可；
- 对应用透明，Service Mesh 组件可以单独升级。
当然，Service Mesh 目前也面临一些挑战：
- Service Mesh 组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；
- Service Mesh 组件接管了网络流量，因此服务的整体稳定性依赖于 Service Mesh，同时额外引入的大量Service Mesh 服务实例的运维和管理也是一个挑战；
1.2 Service Mesh 有哪些开源实现
Service Mesh 的概念从2016年提出至今，已经发展到了第二代。第一代 service Mesh 以数据面为主、第二代 service Mesh 以控制面为主
第一代 service mesh 以 Linkerd 和 Envoy 为代表。
第二代 service mesh 主要改进集中在更加强大的控制面功能（与之对应的 sidecar proxy 被称之为数据面），典型代表有 Istio 和 Conduit。
Service Mesh 发展历程：
2 什么是 istio
istio 官网：https://istio.io/latest/zh/
官方对 Istio 的介绍浓缩成了一句话：
An open platform to connect, secure, control and observe services.
翻译过来，就是”连接、安全加固、控制和观察服务的开放平台“。开放平台就是指它本身是开源的，服务对应的是微服务，也可以粗略地理解为单个应用。
如上图我们先来介绍四个动词就是 Istio 的主要功能，官方也各有一句话的说明。这里再阐释一下：
连接（connect）：Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能。
安全（secure）：Istio 提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性。
控制（control）：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力。
观察（observe）：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状态，发现并解决问题。
2.1 istio 历史
- Google, IBM, and Lyft 创建，于2017年5月24发布0.1版本
- 2018年7月31日晚上 24 点，Istio 宣布推出 1.0 正式版本，并表示已可用于生产环境。这距离最初的 0.1 版本发布已过去一年多的时间。
- 2019年3月19日发布1.1版本
- 2019年6月18日发布1.2版本
- 2019年9月12日发布1.3版本
- 2019年12月14日发布1.4版本
- 2020年3月5日发布1.5版本，架构发生重大改变
- 2020年5月21日发布1.6版本
- 2020年8月21日发布1.7版本
- 2020年11月19日发布1.8版本
- 2021年2月9日发布1.9版本
- 2021年5月18日发布1.10版本
2.2 istio 组件介绍
2.2.1 istio 1.5 版本前架构组件介绍
可以看到上图有几个组件并且，Pilot、Galley、Citadel、Adapter、Mixer 这几个组件为控制组件
各个组件介绍：
- Pilot：用于将配置下发到数据端 proxy 中
- Galley：用于从环境中获取配置生产配置，并对配置进行校验
- Citadel：提供安全功能
- Mixer：提供策略和控制
- Adapter：用于对不同的 OS 进行对接
查看部署之后的 pod 信息
# 从上面的 pod 图片中我们可以看到有对应的几个 pod 组件，这里做以说明：
egressgateway：出站网关
ingressgateway：入站网关
policy：应用策略
telemetry：用于进行遥测
sidecar-injector：注入一些 sidecar 数据的容器
tracing：用于分部署跟踪
grafana、Prometheus、kiali：用于可视化
Istio-pilot
pilot 用于向 proxy 发送配置数据，如上图 pilot 组件有 Platform Adapter、Abstract Model、Envoy API、Rules API
- Platform Adapter：用于对接不同的系统部署 istio 环境
- Envoy API：负责和 Envoy 的通讯，主要是发送服务发现信息和流量控制规则给 Envoy，而 Envoy 提供服务发现，负载均衡池和路由表的动态更新的 API。这些 API 将 Istio 和 Envoy 的实现解耦。
- Abstract Model：是对服务网格中”服务”的规范表示，即定义在 istio 中什么是服务,这个规范独立于底层平
- Rules API：提供接口给外部调用以管理 Pilot , 包括命令行工具 Istiot 以及未来可能出现的第三方管理界面
如果把数据面的 envoy 也看作一种 agent， 则 Pilot 类似传统 C/S 架构中的服务端 Master，下发指令控制客户端完成业务功能。和传统的微服务架构对比， Pilot 至少涵盖服务注册中心和 Config Server 等管理组件的功能。
如上图所示：pilot 直接从运行平台 (kubernetes,consul) 提取数据并将其构造和转换成 istio 的服务发现模型， 因此 pilot 只有服务发现功能，无须进行服务注册。这种抽象模型解耦 Pilot 和底层平台的不同实现，可支持kubernetes，consul等平台 。
除了服务发现， Pilot 更重要的一个功能是向数据面下发规则，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理规则，也包括认证授权等安全规则。Pilot 负责将各种规则转换成 Envoy 可识别的格式，通过标准的 XDS 协议发送给Envoy,指导 Envoy 完成功作。在通信上， Envoy 通过 gRPC 流式订阅 Pilot 的配置资源。如下图所示， Pilot 将 VirtualService 表达的路由规则分发到 Evnoy 上， Envoy 根据该路由规则进行流量转发。
Pilot 流程图
Pilot 通过上图的配置生成配置数据将数据发送至 Envoy
mixer
Istio 控制面部署了两个 Mixer 组件： istio-telemetry 和 istio-policy ，分别处理遥测数据的收集和策略的执行。查看两个组件的Pod 镜像会发现，容器的镜像是相同的，都是”/istio/mixer”
Mixer 是 Istio 独有的一种设计,不同于 Pilot ，在其他平台上总能找到类似功能的服务组件。从调用时机上说,Pilot 管理的是配置数据，在配置改变时和数据面交互即可；然而，对于 Mixer 来说，在服务间交互时 Envoy 都会对Mixer 进行一次调用，因此这是一种实时管理。当然，在实现上通过在 Mixer 和 Proxy 上使用缓存机制，可保证不用每次进行数据面请求时都和 Mixer 交互。
istio-telemetry 遥测
istio-telemetry 是专门用于收集遥测数据的 Mixer 服务组件。如下图所示所示：
当网格中的两个服务间有调用发生时，服务的代理 Envoy 就会上报遥测数据给 istio-telemetry 服务组件，istio-telemetry 服务组件则根据配置将生成访问 Metric 等数据分发给后端的遥测服务。数据面代理通过 Report 接口上报数据时访问数据会被批量上报。
上图组件功能：
- Metric ：监控数据
- log：日志
- tracing：分部署追踪
访问流程：
mixer 和 envoy 连接，然后 envoy 上报数据到 mixer ，然后 mixer 再将这些数据发送至不同的应用中
istio-policy 策略控制
istio-policy 是另外一个Mixer 服务，和istio-telemetry 基本上是完全相同的机制和流程。
如图下图所示：
数据面在转发服务的请求前调用 istio-policy 的 Check 接口检查是否允许访问， Mixer 根据配置将请求转发到对应的 Adapter 做对应检查，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制。
istio-citadel 提供安全功能
服务列表中的 istio-citadel 是 Istio 的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel 一直监听 Kube-apiserver ，以 Secret 的形式为每个服务都生成证书密钥，并在 Pod 创建时挂载到 Pod 上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向 TLS 认证、通道加密、访问授权等安全功能，这样用户就不用在代码里面维护证书密钥了。如下图 所示，frontend 服务对 forecast 服务的访问用到了HTTP 方式，通过配置即可对服务增加认证功能， 双方的 Envoy 会建立双向认证的 TLS 通道，从而在服务间启用双向认证的 HTTPS 。
istio-galley 对 yaml 进行验证
istio-galley 并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley 作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的 Pilot 和 Mixer 服务使用，这样其他管理面组件只用和 Galley 打交道，从而与底层平台解耦。在新的版本中 Galley 的作用越来越核心。
istio-sidecar-injector
istio-sidecar-inj ector 是负责自动注入的组件，只要开启了自动注入，在 Pod 创建时就会自动调用 istio-sidecar-injector 向 Pod 中注入 Sidecar 容器。在 Kubernetes 环境下，根据自动注入配置， Kube-apiserver 在拦截到Pod 创建的请求时，会调用自动注入服务 istio-sidecar-injector 生成 Sidecar 容器的描述并将其插入原 Pod 的定义中，这样，在创建的 Pod 内除了包括业务容器，还包括 Sidecar 容器。这个注入过程对用户透明，用户使用原方式创建工作负载。
istio-ingressgateway
istio-ingressgateway 就是入口处的 Gateway ，从网格外访问网格内的服务就是通过这个 Gateway 进行的。istio-ingressgateway 比较特别， 是一个 Loadbalancer 类型的 Service,不同于其他服务组件只有一两个端口, istio-ingressgateway 开放了一组端口，这些就是网格内服务的外部访问端口.
如下图所示：
网格入口网关 istio-ingressgateway 的负载和网格内的 Sidecar 是同样的执行体，也和网格内的其他 Sidecar 一样从 Pilot 处接收流量规则并执行，Istio 通过一个特有的资源对象 Gateway 来配置对外的协议、端口等。
istio-egressgateway
istio-egressgateway 就是出口处的 Gateway ，从网格内访问网格外的服务就是通过这个 Gateway 进行的。
envoy proxy
istio 的 sidecar（istio-proxy）是开源项目 envoy 的扩展版，Envoy 是用 C++ 开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，是 istio 架构中唯一的数据面组件， Envoy 提供了动态服务发现、负载均衡、TLS , HTTP/2 及 gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。在istio-proxy容器中除了有 Envoy ，还有一个 pilot-agent 的守护进程。
2.2.2 istio 1.5 版本后架构调整
这部分主要分析 Istio 1.5 在架构上的调整，这也是该版本最核心的变化。主要包括重建了控制平面，将原有的多个组件整合为一个单体结构 istiod；同时废弃了被诟病已久的 Mixer 组件。还对是否向后兼容的部分也做了说明，如果你要从 1.4.x 版本升级到 1.5 必须知道这些变化。
将 pilot、citadel、galley 合并到
istiod 同时删除了 Mixer ，因为很多用户反馈 Mixer 会影响性能
3 部署 istio1.10.0
下载地址： https://github.com/istio/istio/releases
现在最新的版本已经发现到了 1.12.0 所以我这里部署 1.10.0
1.下载压缩包
[16:29:41 root@k8s-master ~]#wget https://github.com/istio/istio/releases/download/1.10.0/istio-1.10.0-linux-amd64.tar.gz
2.解压
[16:30:11 root@k8s-master ~]#tar xf istio-1.10.0-linux-amd64.tar.gz
3.进入到解压之后的目录中
[16:30:25 root@k8s-master ~]#cd istio-1.10.0/
[16:31:06 root@k8s-master istio-1.10.0]#ll
total 48
drwxr-x--- 6 root root 4096 May 15 2021 ./
drwx------ 30 root root 4096 Nov 22 16:30 ../
drwxr-x--- 2 root root 4096 May 15 2021 bin/ # istioctl 命令文件
-rw-r--r-- 1 root root 11348 May 15 2021 LICENSE
drwxr-xr-x 5 root root 4096 May 15 2021 manifests/ # 资源文件
-rw-r----- 1 root root 854 May 15 2021 manifest.yaml
-rw-r--r-- 1 root root 5866 May 15 2021 README.md
drwxr-xr-x 20 root root 4096 May 15 2021 samples/ # 例子
drwxr-xr-x 3 root root 4096 May 15 2021 tools/ # 一些工具脚本
4.设置环境变量，我们这里写入到 /etc/profile 文件中
[16:31:08 root@k8s-master istio-1.10.0]#vim /etc/profile
export PATH=/root/istio-1.10.0/bin:$PATH
[16:35:40 root@k8s-master istio-1.10.0]#. /etc/profile
5.通过 demo 包部署，demo 包提供的就是一键化部署的方式
[16:36:49 root@k8s-master ~]#istioctl install --set profile=demo
This will install the Istio 1.10.0 demo profile with ["Istio core" "Istiod" "Ingress gateways" "Egress gateways"] components into the cluster. Proceed? (y/N) y # 输入 y
✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete Thank you for installing Istio 1.10. Please take a few minutes to tell us about your install/upgrade experience! https://forms.gle/KjkrDnMPByq7akrYA
6.安装完成之后会生成对应的下面 3 个 pod
[16:45:04 root@k8s-master istio-1.10.0]#kubectl get pod -n istio-system
NAME READY STATUS RESTARTS AGE
istio-egressgateway-55d4df6c6b-w8xml 1/1 Running 0 3m21s # 出口网关
istio-ingressgateway-69dc4765b4-nxjvt 1/1 Running 0 3m21s # 入口网关
istiod-798c47d594-2mn9v 1/1 Running 0 4m2s # 控制中心
4 bookinfo 示例演示
Bookinfo 是 istio 官网示例，应用程序分为四个单独的微服务：
productpage。该productpage微服务调用details和reviews微服务来填充页面。details。该details微服务包含图书信息。reviews。该reviews微服务包含了书评。它们调用ratings微服务。ratings。该ratings微服务包含预定伴随书评排名信息。
reviews 微服务有3个版本：
- 版本v1不会调用该
ratings服务。 - 版本v2调用该
ratings服务，并将每个等级显示为1到5个黑星★。 - 版本v3调用该
ratings服务，并将每个等级显示为1到5个红色星号★。
details有两个版本：
- 版本v1可用服务
- 版本v2不可用服务
ratings服务有4个版本：
- 版本v1不会没有数据库
- 版本v2调用mongodb数据库
- 版本v2-mysql调用mysql数据库
- 版本v2-mysql-vm调用外部mysql数据库
4.1 部署 bookinfo
1创建名称空间
[16:42:47 root@k8s-master ~]#kubectl create ns istio
2.设置名称空间标签实现自动注入
[16:49:38 root@k8s-master ~]#kubectl label ns istio istio-injection=enables
# 这里我给 istio ns 打上了 istio-injection=enables 的标签
3.部署bookinfo
# 进入到该目录下，这个目录是 istio 官方下载之后就提供的示例目录
[16:50:12 root@k8s-master ~]#cd /root/istio-1.10.0/samples/bookinfo/platform/kube/
# 创建
[16:53:10 root@k8s-master kube]#kubectl apply -f bookinfo.yaml -n istio
# 创建成功
[16:59:29 root@k8s-master kube]#kubectl get pod -n istio -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
details-v1-79f774bdb9-bn495 1/1 Running 0 7m19s 10.10.169.166 k8s-node2 <none> <none>
productpage-v1-6b746f74dc-drf6h 1/1 Running 0 7m18s 10.10.113.153 k8s-node <none> <none>
ratings-v1-b6994bb9-dk4zd 1/1 Running 0 7m19s 10.10.113.155 k8s-node <none> <none>
reviews-v1-545db77b95-pfm5t 1/1 Running 0 7m19s 10.10.169.170 k8s-node2 <none> <none>
reviews-v2-7bf8c9648f-kbmbs 1/1 Running 0 7m18s 10.10.113.154 k8s-node <none> <none>
reviews-v3-84779c7bbc-wmxmp 1/1 Running 0 7m18s 10.10.169.165 k8s-node2 <none> <none>
4.第三步创建成功之后部署 gateway和 virtualservice，destinationrule
- gateway 入口网关
- virtualservice 用于路由
[17:04:14 root@k8s-master networking]#cd /root/istio-1.10.0/samples/bookinfo/networking
# 创建入口网关
[17:04:15 root@k8s-master networking]#kubectl apply -f bookinfo-gateway.yaml -n istio
4.2 访问 web 验证
- 查看 istio-system 的 svc
[17:06:08 root@k8s-master networking]#kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-egressgateway ClusterIP 172.30.55.11 <none> 80/TCP,443/TCP 24m
istio-ingressgateway LoadBalancer 172.30.126.129 <pending> 15021:42608/TCP,80:64334/TCP,443:21341/TCP,31400:53357/TCP,15443:49878/TCP 24m
istiod ClusterIP 172.30.193.20 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 25m
# 可以看到 istio-ingressgateway 入口网关是 LoadBalancer 类型，并且将 svc 的 80 映射到宿主机的 64334 端口
2.浏览器访问
一定要访他的 nodeport 端口加上 productpage URI
http://10.0.0.131:64334/productpage
就可以看到一个简单的微服务部署完成
v1 版本：
v2 版本：
v3 版本：
可以看到每当我们刷新一次的时候他的页面版本五角星都会发生变化
5 istio CRD
istio 的 CRD 是 istio 自己创建的配置文件
[root@master01 istio-teaching-1.9.2]# kubectl get crd
NAME CREATED AT
authorizationpolicies.security.istio.io 2021-05-17T03:35:13Z
destinationrules.networking.istio.io 2021-05-17T03:35:13Z
envoyfilters.networking.istio.io 2021-05-17T03:35:13Z
gateways.networking.istio.io 2021-05-17T03:35:14Z
istiooperators.install.istio.io 2021-05-17T03:35:14Z
peerauthentications.security.istio.io 2021-05-17T03:35:15Z
requestauthentications.security.istio.io 2021-05-17T03:35:15Z
serviceentries.networking.istio.io 2021-05-17T03:35:15Z
sidecars.networking.istio.io 2021-05-17T03:35:16Z
telemetries.telemetry.istio.io 2021-05-17T03:35:16Z
virtualservices.networking.istio.io 2021-05-17T03:35:16Z
workloadentries.networking.istio.io 2021-05-17T03:35:17Z
workloadgroups.networking.istio.io 2021-05-17T03:35:17Z
- authorizationpolicies:权限控制相关
- destinationrules：目标规则
- envoyfilters：envoy 过滤器，用于扩展 istio 功能
- gateways：网关，分为入口网关和出口网关
- istiooperators：安装相关，不介绍
- peerauthentications：用于配置tls
- requestauthentications：用于配置jwt
- serviceentries：服务入口，用于连接外部服务
- sidecars：控制 sidecar
- telemetries：新增的资源，暂不介绍
- virtualservices：虚拟服务，用于配置路由
- workloadentries：工作负载条目
- workloadgroups：工作负载组
后面的操作的话都是围绕着 istio 的每个 CRD 来进行的，讲解 CRD 中的每个配置字段，然后根据这些配置内容进行实战演练