istio组件介绍和启动流程
Istio各个Deployment包含的容器组件
Deployment 名称 | Container和Port | Container和Port |
---|---|---|
istio-pilot | pilot: 8080,15010 | proxyv2: 15003,15005,15007 |
istio-galley | galley: 443,9093 | |
istio-egressgateway | proxyv2: 80,443,15090 | |
istio-ingressgateway | proxyv2: 80,443,31400,15011,8060,853,15030,15031,15090 | |
grafana | grafana: 3000 | |
istio-policy | mixer: 9093,42422 | proxyv2: 9091,15004,15090 |
istio-telemetry | mixer: 9093,42422 | proxyv2: 9091,15004,15090 |
prometheus | prometheus: 9090 | |
istio-citadel | citadel: 8086 | |
istio-sidecar-injector | sidecar-injector | |
istio-tracing | jaegertracing/all-in-one: 9411,16686 UDP:5775,6832,6831 | |
istio-ingress | proxyv2: 80,443 |
其中,流量的走向如下图所示:
创新互联公司主营咸宁网站建设的网络公司,主营网站建设方案,重庆APP开发公司,咸宁h5微信平台小程序开发搭建,咸宁网站营销推广欢迎咸宁等地区企业咨询
说明:红色线表示控制流,黑色线表示数据流,蓝色部分为Envoy和pilot相关组件
Istio核心组件与功能
istio主要有两部分组成: 控制面和数据面。
- 数据面被称为Sidecar: 会在业务Pod中注入一个容器,劫持业务应用容器的流量,并接受控制组件的控制,同时会向控制组件输出日志,跟踪及监控数据。
- 控制面是Istio的核心,管理Istio的所有功能。
Pilot:Istio的核心流量控制组件,主要负责流量管理。Pilot管理了所有Envoy的代理实例(Sidecar),主要有以下功能:
- 从K8S或者其它平台注册中心回去服务信息,完成服务发现
- 读取Istio的各项控制配置,在进行装换后将其发给数据组件进行实施。
- 数据组件Sidecar根据Pilot指令,完成 路由、服务、监听、集群等配置。
Mixer:主要是预检查和汇报工作,策略控制,监控,和日志收集等。主要工作流程如下:
- 用户将Mixer配置发送到Kubernetes集群中
- Mixer通过对集群资源的监听,获取配置的变化。
- 网格中的服务每次在调用前,都会向Mixer发出预检请求,查看是否允许执行。在服务完成调用后,会向Mixer发出报告信息,汇报在调用过程中产生的监控跟踪数据。
- Mixer 中包含多个Adapter的组件,这些组件来处理在Mixer中接收的预检报告数据,完成Mixer的各项功能。
Citadel:主要用于证书管理和身份认证。
Sidecar(Envoy):Istio中的数据面,负责控制对服务网格控制的实际执行。
- Istio中默认的Sidecar是由Envoy派生出的,实际理论上只要支持Envoy的xDS协议(x descovery service 各类服务发现的总称),其他类似的反向代理软件就能替代Envoy来担当此角色。
- Istio 利用istio-init初始化容器中的iptables指令,对所在Pod的流量进行劫持,从而接管Pod应用中的通信。
- Sidecar在注入到Pod之后,将原有的源容器 -> 目标容器的通信方式改变为 源容器 -> Sidecar -> Sidecar -> 目标容器。
数据面组件
Istio通过K8s的Admission webhook[9]机制实现了sidecar的自动注入,Mesh中的每个微服务pod会被加入Envoy相关的容器。
除了微服务自身的容器外,istio还在Pod中注入proxy_init
和proxyv2
两个容器。其中proxyv2容器中运行的两个进程是数据面的核心。
proxy_init
proxy_init是一个initContainer, 主要用于在启动Pod前做一些初始化的工作,只有当InitContainer执行成功之后,才会启动Pod中的其他container。
可以通过docker inspect
命令,来获取此容器镜像的元数据:
...
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh",
"-c",
"#(nop) COPY file:1e5fc95e10f8888f4cae33f7e0ea42b5aff9d18d36280ae288a0fee948dc18e1 in / "
],
"ArgsEscaped": true,
"Image": "sha256:e261e1418e2ed94d1de1742d80997cc58f96aa3c4bfc56cd50e7f2848bf5bcf6",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": [
"/usr/local/bin/istio-iptables.sh"
],
...
从上面的命令行输出可以看到,Proxy_init中执行的命令是istio-iptables.sh脚本,脚本具体内容可以直接从已存在的容器拷贝出来进行查看:
docker cp cbbaf5413d04:/usr/local/bin/istio-iptables.sh ./
这个脚本主要设置了Istio sidecar的iptables端口转发规则。
proxyv2
伴随着业务容器长久运行的注入容器是istio-proxy,这个容器负责截取POD中所有流入流出的流量。
通过如下命令,可以看到在此容器中运行的进程:
[root@k8s-node-1 ~]# kubectl exec reviews-v3-748456d47b-6jvsp -c istio-proxy -- ps -ef
UID PID PPID C STIME TTY TIME CMD
istio-p+ 1 0 0 02:26 ? 00:00:00 /usr/local/bin/pilot-agent proxy sidecar --configPath /etc/istio/proxy --binaryPath /usr/local/bin/envoy --serviceCluster reviews --drainDuration 45s --parentShutdownDuration 1m0s --discoveryAddress istio-pilot.istio-system:15007 --discoveryRefreshDelay 1s --zipkinAddress zipkin.istio-system:9411 --connectTimeout 10s --proxyAdminPort 15000 --controlPlaneAuthPolicy NONE
istio-p+ 16 1 0 02:26 ? 00:03:37 /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster reviews --service-node sidecar~10.2.53.61~reviews-v3-748456d47b-6jvsp.default~default.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only
istio-p+ 39 0 0 13:07 ? 00:00:00 ps -ef
这个容器中主要运行了两个进程:
- pilot-agent: 负责生成Envoy启动所需的配置文件,指定了连接istio控制面的服务和端口,并负责启动Envoy进程。
- envoy:其中指定的/etc/istio/proxy/envoy-rev0.json文件是当前pod的网络流量的核心配置,通过此文件获取pilot的地址,其中记录了当前的POD信息和流量的转发规则,pilot会与其建立长连接,并向其推送最新更新的网络策略。
通过对envoy-rev0.json文件进行分析,我们可以发现其主要包含了如下几个部分:
- node: 包含了当前Pod信息,包括ID,IP,servicename,namespace等。
- stats_config:定义了一些命名规则和对应的正则参数
- admin:给出了一组本地IP 127.0.0.1和15000管理端口,可以登录此容器执行
curl http://127.0.0.1:15000/help
获取当前POD的接口和状态信息 - dynamic_resources:定义了xDS的服务发现配置
- static_resources:定义了连接控制面的信息,包括连接pilot组件的服务地址,以及超时时间设置和连接数限制等配置信息。
- tracing:主要定义了zipkin的接口等信息,用于追踪业务流量的走向。
登录istio-proxy查看监听的端口,其中80端口为业务容器提供服务的端口:
$ netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:15001 0.0.0.0:* LISTEN 13/envoy
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:15090 0.0.0.0:* LISTEN 13/envoy
tcp 0 0 127.0.0.1:15000 0.0.0.0:* LISTEN 13/envoy
tcp6 0 0 :::15020 :::* LISTEN 1/pilot-agent
- 15001: Envoy的入口监听器,iptable会将pod的流量导入该端口中由Envoy进行处理
- 15000: Envoy管理端口,该端口绑定在本地环回地址上,只能在Pod内访问。
数据面组件启动流程
流程图示:
- initContainer执行初始化脚本,为Pod添加iptables规则
- Pilot-agent根据启动参数和K8S API Server中的配置信息生成Envoy的初始配置文件envoy-rev0.json,该文件告诉Envoy从xDS server中获取动态配置信息,并配置了xDS server的地址信息,即控制面的Pilot。
- Pilot-agent使用envoy-rev0.json启动Envoy进程。
- Envoy根据初始配置获得Pilot地址,采用xDS接口从Pilot获取到Listener,Cluster,Route等d动态配置信息。
- Envoy根据获取到的动态配置启动Listener,并根据Listener的配置,结合Route和Cluster对拦截到的流量进行处理。
Envoy配置文件结构
Envoy中实际生效的配置是由初始化配置文件中的静态配置和从Pilot获取的动态配置一起组成的。因此只对envoy-rev0 .json进行分析并不能看到Mesh中流量管理的全貌。那么有没有办法可以看到Envoy中实际生效的完整配置呢?答案是可以的,我们可以通过Envoy的管理接口来获取Envoy的完整配置:
kubectl -n yak exec yak-files-7d48cd48f-tf75f -c istio-proxy curl http://127.0.0.1:15000/config_dump > config_dump
查看此文件的结构:
{
"configs":[
{
"@type":"type.googleapis.com/envoy.admin.v2alpha.BootstrapConfigDump",
"bootstrap":Object{...},
"last_updated":"2019-05-08T08:07:28.221Z"
},
{
"@type":"type.googleapis.com/envoy.admin.v2alpha.ClustersConfigDump",
"version_info":"2019-05-09T08:36:01Z/4",
"static_clusters":Array[3],
"dynamic_active_clusters":Array[96]
},
{
"@type":"type.googleapis.com/envoy.admin.v2alpha.ListenersConfigDump",
"version_info":"2019-05-09T08:36:01Z/4",
"static_listeners":Array[1],
"dynamic_active_listeners":Array[57]
},
{
"@type":"type.googleapis.com/envoy.admin.v2alpha.RoutesConfigDump",
"static_route_configs":Array[3],
"dynamic_route_configs":Array[17]
}
]
}
配置中主要包含了如下几部分:
- bootstrap:文件中的内容和之前介绍的envoy-rev0.json是一致的
- clusters: 是一个服务集群,包含一个到多个endpoint,每个endpoint都可以提供服务,Envoy根据负载均衡算法将请求发送到这些endpoint中。
- static_clusters: 是来自于envoy-rev0.json的xDS server和zipkin server信息。
- dynamic_active_clusters : 是通过xDS接口从Istio控制面获取的动态服务信息。
- listeners: Envoy采用listener来接收并处理downstream发过来的请求,listener的处理逻辑是插件式的,可以通过配置不同的filter来插入不同的处理逻辑。
- static_listeners
- dynamic_active_listeners
- routes: 配置Envoy的路由规则。Istio下发的缺省路由规则中对每个端口设置了一个路由规则,根据host来对请求进行路由分发。
- static_route_configs
- dynamic_route_configs
官方bookinfo服务调用示意图:
参考链接:https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro/
分享文章:istio组件介绍和启动流程
文章网址:http://scyanting.com/article/gepjop.html