Istio架构剖析
Istio 主要作用
从官网首页可以看到，Istio主要的四大作用就是连接、安全、控制和观察：
- 连接（Connect）
流量管理、负载均衡、灰度发布 - 安全（Secure）
认证、鉴权 - 控制（Control）
限流、ACL - 观察（Observe）
监控、调用链
Istio是一个开源的服务网格，可为分布式微服务架构提供所需的基础运行和管理要素。
随着各组织越来越多地采用云平台，开发者必须使用微服务设计架构以实现可移植性，而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。
Istio采用一种一致的方式来保护、连接和监控微服务，降低了管理微服务部署的复杂性。
Istio概念
在Service Mesh中，我们需要了解Data Plane和Control Plane两个概念：
- Data Plane：作用是处理网格内服务间的通信，并完成服务发现、负载均衡、流量管理、健康检查等功能；
- Control Plane：作用是管理和配置智能代理用于路由流量，同时配置Mixers来应用策略、收集指标。
Istio核心组件
- Envoy：Istio 使用 Envoy调解服务网格中所有服务的入站和出站流量。属于数据平面。
- Mixer：负责在服务网格上执行访问控制和使用策略，以及收集从Envoy和其他服务自动监控到的数据。
- Pilot：为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。属于控制平面。
- Citadel：提供访问控制和用户身份认证功能。
Istio可视化管理组件
- Vistio：用于近乎实时地监控应用程序和集群之间的网络流量。
- Kiali：提供可视化服务网格拓扑、断路器和请求率等功能。Kiali还包括 Jaeger Tracing，可以提供开箱即用的分布式跟踪功能。
- jaeger：用于展示istio微服务调用链关系，以及微服务工作状态监测。注意，在生产环境中，应使用Elasticsearch或cassandra持久化存储jaeger数据。
架构图：
从架构设计上来看，Istio服务网格在逻辑上分为控制平面和数据平面两部分。
Istio的控制平面主要负责：
- 接收用户配置
- 生成路由规则
- 分发路由规则到代理
- 分发策略
- 遥测数据收集
Istio的数据平面主要负责：
- 流量转发
- 策略实施
- 遥测数据上报
用户通过控制平面提供的API提交路由配置规则、策略配置规则与遥测数据收集的配置规则。
Pilot把用户提交的配置规则转换成智能代理需要的配置形式，推送给智能代理。
智能代理根据用户的配置来执行服务路由、遥测数据收集与服务访问策略。
智能代理拦截服务所有流量，并与其他智能代理通信。
控制平面
控制平面中主要包括Mixer、Pilot、Citadel部件。
1.1：Mixer
Mixer是一个与平台无关的组件。
Mixer负责在服务网络中实施访问控制和策略，并负责从Envoy代理和其他服务上收集遥测数据。
代理提取请求级别的属性并发送到Mixer用于评估，评估请求是否能放行。
Mixer有一个灵活的插件模型。这个模型使得Istio可以与多种主机环境和后端基础设施对接。因此，Istio从这些细节中抽象了Envoy代理和Istio管理的服务。
1.2: Mixer架构图
在每一个请求过程中，Envoy代理会在请求之前调用Mixer组件进行前置条件检查，在请求结束之后上报遥测数据给Mixer组件。
为了提高性能，每个Envoy代理都会提前缓存大量前置条件检查规则，当需要进行前置条件检查时，直接在缓存中检查规则。
如果本地缓存中没有需要的规则，再去调用Mixer组件获取规则。
Mixer组件也有自己的缓存，以加速前置条件检查。需要上报的遥测数据也会被Envoy代理暂时缓存起来，等待时机上报Mixer组件，从而减少上报数据的调用次数。
2.1: Pilot
Pilot为Envoy代理提供:
- 服务发现功能
- 智能路由功能（例如：A/B测试、金丝雀发布等）
- 弹性功能（例如：超时、重试、熔断器等）。
Pilot将高级别的控制流量行为的路由策略转换为Envoy格式的配置形式，并在运行时分发给Envoy代理。
Pilot抽象了平台相关的服务发现机制，并转换成Envoy数据平面支持的标准格式。
这种松耦合设计使得Istio能运行在多平台环境，并保持一致的流量管理接口。
2.2: Pilot架构图
Pilot抽象不同平台的服务发现机制，只需要为不同的平台实现统一的抽象模型接口，即可实现对接不同平台的服务发现机制。
用户通过规则配置API来提交配置规则，Pilot把用户配置的规则和服务发现收集到的服务转换成Envoy代理需要的配置格式，推送给每个Envoy代理。
3. Citadel
Citadel内置有身份和凭证管理，提供了强大的服务间和终端用户的认证。
Citadel可以把不加密的通信升级为加密的通信。
运维人员可以使用Citadel实施基于服务身份的策略而不用在网络层控制。
Istio还支持基于角色的访问控制，用于控制谁能够访问服务。
数据平面
Istio在数据平面中使用一个Envoy代理的扩展版本。
Envoy是使用C++语言开发的高性能代理，它能拦截服务网络中所有服务的入口和出口流量。
Istio利用了众多Envoy内置的功能特性，例如：
- 动态服务发现
- 负载均衡
- TLS终止
- HTTP/2和gRPC代理
- 熔断器
- 健康检查
- 基于百分比流量分隔的灰度发布
- 故障注入
- 丰富的度量指标
Envoy作为一个边车与对应的服务部署在同一个Kubernetes Pod中。
这种部署方式使得Istio能提取丰富的流量行为信号作为属性。
Istio又可以反过来使用这些数据在Mixer中进行策略决策，并发送这些数据到监控系统中，提供整个网络中的行为信息。
采用边车部署方式，可以把Istio的功能添加到一个已经存在的部署中，并且不需要重新构建或者重新编写代码。
Istio部署
官方中文文档：
https://preliminary.istio.io/zh/docs/setup/getting-started
下载 Istio
下载 Istio，下载内容将包含：安装文件、示例和 istioctl 命令行工具。
访问 Istio release 页面下载与您操作系统对应的安装文件。在 macOS 或 Linux 系统中，也可以通过以下命令下载最新版本的 Istio：
curl -L https://istio.io/downloadIstio | sh -
切换到 Istio 包所在目录下。例如：Istio 包名为 istio-1.6.7，则：
安装目录包含如下内容：
- install/kubernetes 目录下，有 Kubernetes 相关的 YAML 安装文件
- samples/ 目录下，有示例应用程序
- bin/ 目录下，包含 istioctl 的客户端文件。istioctl 工具用于手动注入 Envoy sidecar 代理。
将 istioctl 客户端命令复制到/usr/local/bin目录下：
cp istioctl /usr/local/bin/
查看istio可选的几种部署模式
[root@k8s-master profiles]# istioctl profile list
Istio configuration profiles:
default
demo
empty
minimal
preview
remote
profile开启的组件、插件的表格如下：
查看具体的profile开启了哪些组件可用如下命令：
istioctl profile dump [default|demo|minimal|remote|empty|preview]
安装 demo 配置
[root@k8s-master istio-1.6.7]# istioctl manifest apply --set profile=demo
Detected that your cluster does not support third party JWT authentication. Falling back to less secure first party JWT. See https://istio.io/docs/ops/best-practices/security/#configure-third-party-service-account-tokens for details.
✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Addons installed
✔ Installation complete
查看istio的pod
[root@k8s-master istio-1.6.7]# kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-5dc4b4676c-whdlw 1/1 Running 0 15m
istio-egressgateway-65d5579779-252kt 1/1 Running 0 16m
istio-ingressgateway-7895c9764d-6t2jt 1/1 Running 0 16m
istio-tracing-8584b4d7f9-494rb 1/1 Running 0 15m
istiod-7988b4d788-nzd9f 1/1 Running 0 17m
kiali-6f457f5964-65pl9 1/1 Running 0 15m
prometheus-67988db74f-zblbq 2/2 Running 0 15m
这里说一下，在之前1.5之后的版本，istio已经封装了pilot、citadel和Galley等组件为istiod，所以查看pod的时候会发现有一个istiod
sidecar注入
sidecar注入分为手动注入和自动注入，以httpbin为例：
[root@k8s-master httpbin]# pwd
/usr/local/src/istio-1.6.7/samples/httpbin
[root@k8s-master httpbin]# ls
httpbin-gateway.yaml httpbin-nodeport.yaml httpbin-vault.yaml httpbin.yaml policy README.md sample-client
手动注入
# 方法一
kubectl apply -f <(istioctl kube-inject -f httpbin-nodeport.yaml)
# 方法二
istioctl kube-inject -f httpbin-nodeport.yaml | kubectl apply -f -
自动注入
# 方法一:这种方法是指以后一旦在default名称空间中创建的pods会自动注入sidecar
kubectl label namesapce default istio-injection=enabled
部署httpbin-nodeport
[root@k8s-master httpbin]# kubectl apply -f httpbin-gateway.yaml
gateway.networking.istio.io/httpbin-gateway created
virtualservice.networking.istio.io/httpbin created
[root@k8s-master httpbin]# kubectl apply -f httpbin-nodeport.yaml
service/httpbin created
deployment.apps/httpbin created
[root@k8s-master httpbin]# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
httpbin-768b999cb5-rgs8l 1/1 Running 0 2m8s
[root@k8s-master httpbin]# kubectl get svc -n default
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
httpbin NodePort 10.1.252.74 <none> 8000:31521/TCP 3m
浏览器测试访问
httpbin注入sidecar
[root@k8s-master httpbin]# kubectl apply -f <(istioctl kube-inject -f httpbin-nodeport.yaml)
service/httpbin unchanged
deployment.apps/httpbin configured
稍等几分钟后会发现pod数量多了一个，sidecar已经注入成功
istio有自带的ingressgateway，所以我们可以使用istio的ingress来访问有sidecar的应用，默认情况下的一个流程如下：
有关服务网关的流量去向图
根据上图可以看出，IngressGateway可以接收外部访问，并将流量转发到网格内的服务；
EgressGateway可以将网格内服务访问外部应用，二者分别实现服务网格中流量的进出。
Gateway为网格内服务提供负载均衡器（Envoy），可以实现四层~七层的负载均衡，且支持双向TLS认证，而我们K8s集群上普通的Ingress网关只能单独实现4层或者七层的负载均衡，相比之下优势就显露出来。
参考：
https://blog.csdn.net/lswzw/article/details/104745617/
https://blog.csdn.net/Mr_rsq/article/details/107834698