本文分三部分，第一部分涉及istio的核心特性以及官方/KubeSphere运维部署相关第二部分是核心特性和多集群、多命名空间、多控制平台部署实践第三部分是Istio源码阅读和分析

一、总览

图片描述

二、核心特性

2.1 流量管理

包括服务的注册、发现，负载均衡策略，灰度/AB测试

2.1.1 虚拟服务和目标规则

负责实现服务发现和不同的负载均衡策略

引入虚拟服务支持不同的路由规则（不同版本、灰度用户等），否则默认采用轮询
引入目标规则支持不同的负载均衡策略

2.1.3 其它

网关。运行在网格边界的，负责入/出流量管理的，独立的Envoy代理
服务入口。将一个外部服务注册到注册中心，这样Envoy就能劫持发往外部服务的流量，进行管理
为了提升网格性能。 Envoy代理可以配置为只能感知特定命名空间，而不是整个集群
服务容错。支持超时，重试，熔断

2.2 可见性

2.2.1 Metrics

默认包括流量、错误率、响应时间，通过Grafama仪表盘展示

边车代理-Envoy
业务服务
istio控制组件

2.2.2 调用链追踪

支持Jaeger等
业务服务在数据包中待请求的上下文，其它的由Envoy完成

2.2.3 日志

日志收集采用EFK(Fluentd + Elasticsearch + Kibana)方案，使用 Fluentd 进行日志收集

2.3 扩展和定制–WASM

扩展开发有一定的门槛。一个实例全链路A/B测试

2.4 安全

内部服务间(mTLS)，外部服务访问(JWT, mTLS)

三、运维

3.1 部署模型

多集群、多网络、多控制平面
多网格。区分环境，测试、预发布、正式
租户模型。一个命名空间一个租户，或者一个集群对应一个租户（独立网格）
建议较少集群，通过命名空间来隔离租户；多地部署，提高可用性、降低延迟

3.2 性能

官方数据

Istio 负载测试网格包含了 1000 个服务和 2000 个 sidecar，全网格范围内，QPS 为 70,000。 在使用 Istio 1.10.2 运行测试后，我们得到了如下结果：

通过代理的 QPS 有 1000 时，Envoy 使用了 0.5 vCPU 和 50 MB 内存。
网格总的 QPS 为 1000 时，istio-telemetry 服务使用了 0.6 vCPU。
Pilot 使用了 1 vCPU 和 1.5 GB 内存。
90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟。

数据平面调优经验

3.3 配置

3.3.1 协议选择

http可自动识别，其它未手动选择的视为普通tcp流量
Service描述文件手动指定。通过端口命名规则： name: <protocol>[-<suffix>], 如name:grpc-demosvr； 1.18+的k8s，可通过appProtocol字段指定

3.3.2 KubeSphere

支持最基础的，参考KubeSphere灰度发布与熔断

四、实践

这里主要针对KubeSphere没有配置入口的特性，进行命令行的实践，如服务入口、服务容错配置等

4.1 Istio安装

4.1.1 单集群

安装Docker
安装Minikube。 minikube start --memory=16384 --cpus=4 --kubernetes-version=v1.14.2 --registry-mirror=https://docker.mirrors.ustc.edu.cn
安装Istio。利用helm进行安装。 MAC M1 不支持！-2021/7/8

// 阿里镜像库找不到coredns报错
docker pull coredns/coredns:1.8.0
docker tag coredns/coredns:1.8.0 registry.cn-hangzhou.aliyuncs.com/google_containers/coredns/coredns:v1.8.0

minikube delete
// start时的一些参数
minikube start --registry-mirror=https://docker.mirrors.ustc.edu.cn --image-mirror-country='cn' --memory=15000 --cpus=6 --kubernetes-version=v1.18.0   

4.1.2 多集群

4.1.3 虚拟机

4.2 Istio升级

4.2.1 Sidecar

4.2.2 控制平面

4.2.3 CNI

4.3 核心特性测试–KubeSphere

主要涉及流量管理和可见性，扩展和定制开发另外讨论自定义资源定义 (CRD) 是默认的 Kubernetes API 扩展。 Istio 使用 Kubernetes CRD API 来变更配置。

虚拟服务和目标规则（服务发现和负载均衡）灰度发布。页面支持
网关。页面支持
服务容错。 CRD API变更(kubectl apply -f)
Metrics。
调用链。页面支持
协议指定。页面支持
多集群部署。

// 查看已经安装的crd
kubectl get crds | grep 'istio.io'
//查看crd的配置
kubectl get virtualservices.networking.istio.io -o yaml -n test

//变更crd的配置

//故障注入
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percent: 100
        fixedDelay: 2s
    route:
    - destination:
        host: ratings
        subset: v1
EOF

// 超时时间设置
kubectl apply -n test -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
    timeout: 0.5s
EOF

4.4 开发、部署、运维闭环周期

部署。 gitlab的ci构建镜像->推到镜像仓库->KS拉取镜像进行服务部署
告警&问题定位–蓝鲸
发布更新。发布支持灰度、A\B

五、源码阅读和分析

TODO

Istio调研和实践