上次在Kubernetes中安装好Istio之后, 忙了很长的时间在处理另一个事, 今天学习一下istio的架构及一些概念，后续分析整个数据的流向.
WhatFor
先来看看istio能做什么，从官网的首页很明确地指出了istio的作用
主要提供四个方面的能力, 简单总结一下:
- Connect: 主要用于工作负载之内的流量管理
- Secure: 主要用于工作负载之间的认证
- Control: 主要用于配置策略及遥测功能
- Observe: 主要用于监控、日志、调用链等可观察性功能
从实际来看, 虽然Istio支持了很多的平台, 但是与之最为紧密结合使用的还是Kubernetes.
Struct
istio的整体架构图
再细分, istio分为控制面及数据面, 如下:
从架构图可以看出几个很重要的信息
- istio在数据面的工作负载中使用了
sidecar(envoy)功能,这个是kubernets原生支持的- istio的原理借鉴了kubernetes的service设计理念, 在kubernetes中，kube-proxy劫持的是进出kubernetes节点的流量，而istio的sidecar则劫持的是进出pod的流量, Kubernetes 管理的对象是 Pod，那么 Service Mesh 中管理的对象就是一个个 Service
istio使用了Adapter来对接抽象各种平台能力, 这使得istio的拓展性更强.
具体sidecar是如何劫持流量并转发出去的，不在这篇说明.
再来简单说明一下各个组件的作用.
Components
数据面
envoy
数据面很简单, 就一个proxy(envoy)
envoy有如下的特点:
- HTTP 7层路由
- 支持gRPC、HTTP/2
- 服务发现和动态配置
- 健康检查
- 高级负载均衡
简单来说, istio通过注入(手工注入入自动注入)等方式将envoy加入到业务Pod中, 然后通过initContainer生成的iptables规则将所在进出业务容器的流量都进行劫持
控制面
pilot
Pilot 是Istio实现流量管理的核心组件，它主要的作用是配置和管理Envoy代理
- 从平台（如Kubernetes）获取服务信息，完成服务发现
- 获取Istio的各项配置，转换成Envoy代理可读的格式并分发, 使用XDS协议.
piolt架构图:
Mixer
Mixer的主要功能是提供策略控制，并从Envoy代理收集遥测数据。每次网络通信时Envoy代理都会向Mixer发出预检要求，用来检测调用者的合法性。调用之后Envoy代理会发送遥测数据供Mixer收集。一般情况下Sidecar代理可以缓存这些数据，不需要频繁地调用Mixer.
同时,Mixer彩用配器模式, 可以支持不同的后端，如日志后端，监控后端, 调用链后端.
Citadel
Citadel是与安全相关的组件，主要负责密钥和证书的管理。它可以提供服务间和终端用户的身份认证，还可以加密服务网格中的流量。
galley
在2019年3月份发布的1.1版本中，Gally作为一个独立的组件被添加到了架构当中（在此之前的版本中Gally并未独立出现），它现在是Istio主要的配置管理组件，负责配置的获取、处理和分发。Gally使用了一种叫作MCP（Mesh Configuration Protocol，网格配置协议）的协议与其他组件进行通信。
重点学习Pilot及Mix即可, citadel及galley一般都不会变动频繁, 知道怎么一回事就可以了.
上面主要学习了下istio整体的框架,没有说明地很详细, 至于istio如何注入sidecar, sidecar又是如何劫持流向转发, 又是如何找到对端的容器地址的，挺有意思, 后续再更.
