1. istio架构
Istio 服务网格逻辑上分为数据平面和控制平面。
数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。
控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。
1 Envoy
Istio 使用 Envoy 代理的扩展版本，Envoy 是以 C++ 开发的高性能代理，用于调解服务网格中所有服务的所有入站和出站流量。Envoy 的许多内置功能被 istio 发扬光大，例如：
动态服务发现
负载均衡
TLS 终止
HTTP/2 & gRPC 代理
熔断器
健康检查、基于百分比流量拆分的灰度发布
故障注入
丰富的度量指标
Envoy 被部署为 sidecar，和对应服务在同一个 Kubernetes pod 中。这允许 Istio 将大量关于流量行为的信号作为属性提取出来，而这些属性又可以在 Mixer 中用于执行策略决策，并发送给监控系统，以提供整个网格行为的信息。
Sidecar 代理模型还可以将 Istio 的功能添加到现有部署中，而无需重新构建或重写代码。可以阅读更多来了解为什么我们在设计目标中选择这种方式。
1.1 手动注入
istioctl命令更改配置文件
$ istioctl kube-inject -f <your-app>.yaml -o <your-app-addEnvoy>.yaml
部署应用
$ kubectl create -f <your-app-addEnvoy>.yaml
1.2 注入后的文件
Annotation： 标注了这一部署和pod是否已经被注入，被什么版本注入
proxy container ：容器是envoy代理容器。容器两个进程，父进程为守护进程传入启动参数给子进程。子进程proxy负责转发流量
InitContainer: 容器初始化，对iptables做一些配置。使其跳过和proxy进程用户一致的用户进程的流量处理，跳过Loopback流量处理，其余所有流量转发到15001端口
Envoy 实现了过滤和路由，并在pilot,mixer协助下服务发现、健康检查，提供了具有弹性的负载均衡。
2. Mixer
Mixer 是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。有关属性提取和策略评估的更多信息，请参见 Mixer 配置。
Mixer 中包括一个灵活的插件模型，使其能够接入到各种主机环境和基础设施后端，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。
3. Pilot
控制面中负责流量管理的组件为Pilot
Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 sidecar。
Pilot 将平台特定的服务发现机制抽象化并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 都可以使用的标准格式。这种松散耦合使得 Istio 能够在多种环境下运行（例如，Kubernetes、Consul、Nomad），同时保持用于流量管理的相同操作界面。
Platform Adapter: 平台适配器。针对多种集群管理平台实现的控制器，得到API server的DNS服务注册信息（即service名与podIP的对应表）、入口资源以及存储流量管理规则的第三方资源
Abstract Model：维护了envoy中对service的规范表示。接收上层获取的service信息转化为规范模型
Envoy API：下发服务发现、流量规则到envoy上
Rules API：由运维人员管理。可通过API配置高级管理规则
Pilot Architecture（官网文档[1])
4. Citadel
Citadel 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持基于角色的访问控制，以控制谁可以访问您的服务。
5. Galley
- Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节隔离开来。
istio流量示意图：
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: nginx-gw
spec:
selector:
app: istio-ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- nginx.test.com
---
apiVersion: networking.istio.io/v1alpha3
kind: 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
通过命令访问 curl -H "Host: nginx.gateway.com" http://ingressgateway:nodeport/
istio-ingressgateway 就是小区的大门（唯一的大门），所有进入的流量都需要经过，
ingressgateway 相当于路标引导去到A B C D的一栋建筑里面，分开域名去导流，
virtualservice 就像到建筑里的电梯一样，按照不同的楼层进行管理路由的作用， destinationrule 到达具体的楼层后按照不同的门房号 1 2 3 4 进入到真正的屋里去。
确认istio-ingressgateway是否有对外的IP
kubectl get service istio-ingressgateway -n istio-system
如果 EXTERNAL-IP 有值（IP 地址或主机名），则说明您的环境具有可用于 Ingress 网关的外部负载均衡器。如果 EXTERNAL-IP 值是 <none>（或一直是 <pending> ），则说明可能您的环境并没有为 Ingress 网关提供外部负载均衡器的功能。
可以通过以下方法添加外部IP
kubectl edit service istio-ingressgateway -n istio-system
kubectl get service istio-ingressgateway -n istio-system
