Istio 持续更新...
Istio
Istio 是什么?(衣撕朵)
云平台令使用它们的公司受益匪浅。但不可否认的是,上云会给 DevOps 团队带来压力。为了可移植性,开发人员必须使用微服务来构建应用,同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。 Istio 允许您连接、保护、控制和观察服务。
从较高的层面来说,Istio 有助于降低这些部署的复杂性,并减轻开发团队的压力。它是一个完全开源的服务网格,作为透明的一层接入到现有的分布式应用程序里。它也是一个平台,拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使您能够成功且高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。
服务网格 又是什么?
服务网格
- 用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长,它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务网格通常还有更复杂的运维需求,比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。
Istio 架构
Istio 服务网格从逻辑上分为数据平面和控制平面。
数据平面
由一组智能代理(Envoy)组成,被部署为 sidecar。这些代理通过一个通用的策略和遥测中心(Mixer)传递和控制微服务之间的所有网络通信。控制平面
管理并配置代理来进行流量路由。此外,控制平面配置 Mixer 来执行策略和收集遥测数据。
Istio 组件
Envoy
Istio
使用Envoy
代理的扩展版本。Envoy
是用C++
开发的高性能代理,用于协调服务网格中所有服务的入站和出站流量。Envoy
代理是唯一与数据平面流量交互的Istio
组件。Envoy
代理被部署为服务的sidecar
,在逻辑上为服务增加了Envoy
的许多内置特性:- 动态服务发现
- 负载均衡
- TLS 终端
- HTTP/2 与 gRPC 代理
- 熔断器
- 健康检查
- 基于百分比流量分割的分阶段发布
- 故障注入
- 丰富的指标
sidecar
代理模型sidecar
允许Istio
提取大量关于流量行为的信号作为属性。反之,Istio
可以在Mixer
中使用这些属性来执行决策,并将它们发送到监控系统,以提供整个网格的行为信息。sidecar
还允许您向现有的部署添加Istio
功能,而不需要重新设计架构或重写代码。
Envoy
代理在istio
中可以实现- 流量控制功能: 通过丰富的 HTTP、gRPC、WebSocket 和 TCP 流量路由规则来执行细粒度的流量控制。
- 网络弹性特性: 重试设置、故障转移、熔断器和故障注入。
- 安全性和身份验证特性: 执行安全性策略以及通过配置 API 定义的访问控制和速率限制。
Mixer
Mixer
是一个平台无关的组件。Mixer
在整个服务网格中执行访问控制和策略使用,并从Envoy
代理和其他服务收集遥测数据。代理提取请求级别属性,并将其发送到Mixer
进行评估。您可以在我们的Mixer
配置文档中找到更多关于属性提取和策略评估的信息。Mixer
包括一个灵活的插件模型。该模型使Istio
能够与各种主机环境和后端基础设施进行交互。因此,Istio
从这些细节中抽象出Envoy
代理和Istio
管理的服务。
Pilot
Pilot
主要是为Envoy sidecar
提供服务发现、用于智能路由的流量管理功能(例如,A/B 测试、金丝雀发布等)以及弹性功能(超时、重试、熔断器等)。Pilot
将控制流量行为的高级路由规则转换为特定于环境的配置,并在运行时将它们传播到sidecar
。Pilot
将特定于平台的服务发现机制抽象出来,并将它们合成为任何符合Envoy API
的sidecar
都可以使用的标准格式。平台适配器
与Envoy
交互图 (平台
支持 kubernetes、Consul、gcp、Nomad等)- 平台启动一个服务的新实例,该实例通知其平台适配器。
- 平台适配器使用
Pilot
抽象模型注册实例。 Pilot
将流量规则和配置派发给Envoy
代理,来传达此次更改。- 可以使用
Istio
的流量管理 API
通过Pilot
优化Envoy
配置,以便对服务网格中的流量进行更细粒度地控制。
Citadel
Citadel
通过内置的身份和证书管理,可以支持强大的服务到服务以及最终用户的身份验证。Citadel
可以用来升级服务网格中的未加密流量。Citadel
、operator
结合使用可以执行基于服务身份的策略,而不是相对不稳定的 3 层或 4 层网络标识。Citadel
使用Istio
的授权特性来控制谁可以访问您的服务。
Galley
Galley
是Istio
的配置验证、提取、处理和分发组件。它负责将其余的Istio
组件与从底层平台(例如 Kubernetes)获取用户配置的细节隔离开来。
Istio Install
我这里 Kubernetes 版本为1.18 因为我目前只有这么一个集群
安装
Istio
环境准备搭建
Kubernetes
集群, ( 请按照官方提供的兼容测试版本安装 目前支持 1.14, 1.15, 1.16 )下载
Istio
项目包. 项目包内包括(安装文件、示例和 istioctl 命令行工具。)安装
Istio
. 通过istioctl
客户端工具直接安装istio
到Kubernetes 中
.
搭建 Kubernetes
这一部分这里就省略了, 如需这一部分 文档, 请参考其他的博文。
下载 Istio 项目包
- 在
macOS
或Linux
系统中, 也可以通过以下命令下载最新版本的 Istio
|
|
- 输出如下:
|
|
- 配置环境变量
|
|
- 验证安装
|
|
- 配置 istioctl 命令自动补全
|
|
目录结构说明
bin
目录包含 istioctl 的客户端文件。istioctl 工具用于手动注入 Envoy sidecar 代理。manifest.yaml
文件的 sha码。samples
目录包含 istio 的实例应用程序。tools
目录包含 一些脚本convert_RbacConfig_to_ClusterRbacConfig.sh
dump_kubernetes.sh
_istioctl
istioctl.bash
istio 命令tab自动补全的脚本
install
目录包含如下目录: (istio除了支持 kubernetes 之外还支持 consul 和 gcp)consul
目录gcp
目录kubernetes
目录包含kuebrnetes
服务相关的 YAML 文件。tools
目录
安装 istio
istio
包含两种安装方式通过 istioctl 客户端命令安装 (推荐)
通过 helm 进行安装
|
|
- 输出如下:
|
|
查看部署情况
- 如果集群运行在一个不支持外部负载均衡器的环境中(例如:minikube),istio-ingressgateway 的 EXTERNAL-IP 将显示为
<pending>
状态。请使用服务的 NodePort 或 端口转发来访问网关。
- 如果集群运行在一个不支持外部负载均衡器的环境中(例如:minikube),istio-ingressgateway 的 EXTERNAL-IP 将显示为
|
|
|
|
组件说明
tracing
全链路监控。istio-pilot
服务发现与服务配置。kiali
可视化服务网格展示。- 服务拓扑图
- 分布式跟踪
- 指标度量收集和图标
- 配置校验
- 健康检查和显示
- 服务发现
prometheus
大家都懂的监控。grafana
prometheus
监控的展示webui。istio-ingressgateway
出口网关。istio-egressgateway
入口网关。jaeger
jaeger-agent
jaeger client的一个代理程序,client将收集到的调用链数据发给agent,然后由agent发给collector;jaeger-collector
负责接收jaeger client或者jaeger agent上报上来的调用链数据,然后做一些校验,比如时间范围是否合法等,最终会经过内部的处理存储到后端存储;jaeger-query
专门负责调用链查询的一个服务。
修改
istio-ingressgateway
网络类型 为 NodePort
|
|
|
|
验证 istio
- 查看版本
|
|
Kiali 组件
Kiali 以 web ui 的方式可视化服务网格。
- 查看 kiali svc
|
|
- 配置访问(我这里的node节点为云主机,所以我配置了一个 ingress)
|
|
- 创建ingress服务
|
|
Istio Profile
Profile 相关的介绍以及具体的区别
istioctl profile list
命令可查看当前版本的 profile
|
|
profile
包含如下:remote
远程kubernetes
部署, 以及多kubernetes
集群separatei
独立部署,不建议使用,后续可能删除default
默认安装, 根据IstioControlPlaneAPI的默认设置启用组件, 建议用于生产部署demo
演示实例,展示istio
所有功能且资源需求适中的配置empty
不部署任何内容。用于导出空的配置文件。minimal
最小化安装。
istio组件 | default | demo | minimal | remote | empty |
---|---|---|---|---|---|
istio-egressgateway | ✔ | ||||
istio-ingressgateway | ✔ | ✔ | ✔ | ||
istio-pilot | ✔ | ✔ | ✔ | ✔ | |
grafana | ✔ | ||||
istio-tracing | ✔ | ||||
Kiali | ✔ | ||||
prometheus | ✔ | ✔ | ✔ | ||
jaeger | ✔ | ||||
zipkin | ✔ |
istioctl profile dump profileName
可以打印或者导出profile
配置这里导出的文件就是
kubernetes
的 YAML 编排文件。api 为 istio 的 api。这里可以导出
default
然后根据自己的环境自定义适合自己的 profile。
|
|
istio injection
injection
注入后的变化原生 pod –>
pods
包含程序
项目。注入以后 pod –>
pods
包含程序
项目、istio-init
、istio-proxy
。istio-init
用于初始化网络配置,iptables
路由配置。istio-proxy
用于当前pod
与集群内部其他资源进行交互。
可以被
injection
的服务Deployment
- 注入后会添加istio-init
、istio-proxy
。ReplicaSet
- 注入后会添加istio-init
、istio-proxy
。DeamonSet
- 注入后会添加istio-init
、istio-proxy
。Pod
- 注入后会添加istio-init
、istio-proxy
。Job
- 注入后会添加istio-init
、istio-proxy
。Service
- 注入后不会添加任何组件。Secrets
- 注入后不会添加任何组件。ConfigMap
- 注入后不会添加任何组件。
deployment yaml 编排文件注入
istioctl kube-inject -f nginx-test.yaml
对Deployment
编排文件进行注入(会修改yaml文件内容)kubectl apply -f <(istioctl kube-inject -f nginx-test.yaml)
注入并 创建 服务到kubernetes
中, 这样操作不会改变原有的编排文件。
|
|
|
|
- 导出注入后的编排文件
|
|
|
|
- 创建服务
|
|
|
|
|
|
Address | 端口 | 类型 | 进程 | 说明 |
---|---|---|---|---|
127.0.0.1 | 15000 | TCP | envoy | envoy 命令行管理端口,可以获取程序运行信息。 |
0.0.0.0 | 15001 | TCP | envoy | |
0.0.0.0 | 15006 | TCP | envoy | |
0.0.0.0 | 15020 | HTTP | pilot-agent | |
0.0.0.0 | 15090 | HTTP | envoy |
pilot-agent
- 生成
envoy
配置文件 - 启动
envoy
进程 - 监控和管理
envoy
进程的运行状态, 故障恢复,envoy
配置变更以及重新加载。
- 生成
envoy
轻量级的代理服务器。service yaml 编排文件注入
- 上面已经提到过
service
注入是不会添加任何其他的服务到service
中的。
- 上面已经提到过
|
|
|
|
|
|
|
|
injection
注入检测 (istioctl analyze -n namespace 命令)运行此命令会检测
namespace
是否有istio
的资源配置情况。如下提示
default
命令中间下,并没有 注入istio
,以及使用kubectl label
标签进行注入。
|
|
injection
自动注入- 对
namespces
设置labels
标签, 可以使在这个namespaces
生成的可注入的程序进行自动注入(injection
)
- 对
|
|
|
|
|
|
Istio 流量管理
Istio 的流量管理 就是配置 HTTP/TCP 路由功能。
Update Istio Version 1.9.9
Istio
流量data plane 数据面流量
是指 网格内服务之间业务互相调用所产生的流量。control plane 控制面流量
是指Istio
各组件之间配置和控制网格行为所产生的流量。
Istio
流量管理分为六个部分Destination Rule
Envoy Filter
Gateway
Service Entry
Sidecar
Virtual Service
Istio 流量模型
Istio
依赖与服务注入(inject)时所部署的Envoy
代理。网格内发送与接收的所有的流量, 都通过
Envoy
进行代理。Envoy
代理 可以轻松的引导和控制网格的流量, 而不需要对服务进行任何修改。
Virtual Service
在
Istio
所提供的基本连接和发现基础上, 通过虚拟服务(vitrual service), 能够将请求路由到Istio
网格中的特定服务。每个虚拟服务(vitrual service)由一组路由规则组成, 这些路由规则使Istio
能够将虚拟服务(vitrual service)的每个给定请求匹配到网格内特定的目标地址。虚拟服务(Virtual Service)
定义了一组寻址主机时要使用的流量路由规则,每个路由规则为特定协议的流量定义匹配了条件。如果流量匹配,则将其发送到注册表中定义的命名目标服务(或其子集/版本)。同时流量来源也可以在路由规则中匹配,从而能够允许针对特定的客户端上下文自定义路由。服务(Service)
: 应用绑定到服务注册表中的唯一名称。服务包含多个网络端点,这些端点由在Pod、容器和VM等上运行的工作负载实例进行实现。服务版本(Service versions)
或子集
: 在持续部署的场景中,对于给定的服务,可能存在不同的应用程序实例。它们可能是对同一服务的迭代更改,这些版本部署在不同的环境(产品,阶段和开发等)中。场景包括A / B测试
和金丝雀发布
等。可以根据各种标准(标头,网址等)和/或通过分配给每个版本的权重来确定特定版本的选择。每个服务都有一个包含其所有实例的默认版本。来源(Source)
: 调用服务的下游客户端。主机(Host)
: 下游客户端连接服务时所使用的地址。访问模式(Access model)
: 应用程序仅需要处理目标服务(主机),而无需了解各个服务版本(子集)。版本的实际选择由代理/sidecar决定,从而使应用程序代码能够与所依赖服务的脱钩。
一个例子
注
: 所有服务(deployment)、(service)、包括 client 都必须被istio
注入(injection)。
|
|
- 查看配置的三个
service
的endpoints
|
|
- 配置一个
Virtual Service
|
|
VirtualService
服务并非是kubernetes
中实际的service
服务。kubectl get virtualservices
使用这个命令查看Virtual Service
|
|
- 测试以及 kiali 中查看
|
|
- 客户端
istio
注入
|
|
|
|
|
|
|
|
- 查看 kiali
|
|
Istio Gateway
- 创建 一个基于 Nginx Web 服务的
Istio Gateway
|
|
配置
DestinationRule
目标规则:
https://istio.io/latest/zh/docs/reference/config/networking/destination-rule/
通过
svc labels
选择访问
|
|
基于 TLS 的 Gateway
- 创建一个 自签 的tls证书
|
|
- 利用 根证书与密钥 创建
nginx.jicki.cn
证书与私钥
|
|
创建 Gateway 中使用到的
Secret
- 需要将 Secret 创建于
istio-system
这个 namespaces 下.
- 需要将 Secret 创建于
|
|
|
|
|
|
- 测试访问
|
|
Fault Injection
故障注入
Istio 的故障注入规则可以帮助您识别微服务中有硬编码超时, 导致 服务失败等。此类异常, 而不会影响最终用户。
故障注入 - 延迟调用, 在使用条件匹配访问 vs-user 用户等于 jicki 的时候 延迟7s 后调用, 延迟比例为 100%
|
|
|
|
- 在 外部调用 中实现 故障注入
|
|
Traffic Shifting
流量转移
在项目服务中, 通常会有一些新旧版本的逐步迁移, 如流量从微服务的一个版本的逐渐迁移到另一个版本。流量转移适用于web服务以及TCP服务。
- 通过配置
destination.weight
来定义流量的百分比 (只用于网格内的服务)
- 通过配置
|
|
Request Timeouts
请求超时
- 通过设置 请求超时 来测试服务的一些特性.
|
|
- Nginx 服务会直接返回
upstream request timeout
, 这里不需要修改 Nginx 的配置文件设置超时, 通过 vs 配既可实现。
Circuit Breaking
熔断
熔断, 是创建弹性微服务应用程序的重要模式。熔断能够使您的应用程序具备应对来自故障、潜在峰值和其他未知网络因素影响的能力。
通过配置
DestinationRule
中的trafficPolicy
配置熔断策略- 可以配置
tcp
与http
协议的条件, 如下为最大连接数为1
, 超过1
的时候就会触发 熔断机制
- 可以配置
|
|
- 部署一个
fortio
客户端 https://github.com/fortio/fortio
|
|
- 触发一下熔断
|
|
- 当使用 2个 连接的时候 只会触发
Code 503 : 4 (20.0 %)
|
|
- 配置 5个 连接的时候
Code 503 : 11 (55.0 %)
Mirroring
镜像流量
- 创建一个 vs 将默认流量都到
nginx-svc-1
中去. - 通过
mirror
标签镜像nginx-svc-1
的流量 到nginx-svc-2
中. (mirrorPercent 为镜像流量的百分比)
|
|
查看
nginx-1
与nginx-2
的日志 - 可以看出各自的不同.- 重点注意这些被镜像的流量是
即发即弃
的, 就是说镜像请求的响应会被丢弃。
- 重点注意这些被镜像的流量是
|
|
|
|
FAQ
Istio Proxy Limit
默认 Istio-proxy 资源限制比较低 cpu = 500m memroy = 512Mi
- 修改 k8s 资源文件 添加:
spec.template.metadata.annotations
- 修改 k8s 资源文件 添加:
|
|
Istio Upgrade
注意事项
升级 Istio 之前, 请确认是否支持升级
istioctl manifest versions
查看支持版本。升级过程中可能发生流量中断。为了缩短流量中断时间, 请确保每个组件(Citadel 除外)至少运行有两个副本。同时, 确保
PodDistruptionBudgets
配置最小可用性为 1。确保 istio
profile
与 需要升级的版本所配置的profile
一致。
升级步骤
1. 下载需要升级的 istio 版本
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.5.1 sh -
2. 替换
istioctl
二进制文件, 或者 更改istio
的环境变量PATH路径到新版本的目录中。3. 如果配置了
istioctl
自动补全,还需要替换为 新的 自动补全脚本。4. 使用新的
istioctl
导出新版本的 profile 文件istioctl profile dump demo > demo.yaml
5. 修改
demo.yaml
文件, 将其中jwtPolicy
身份验证机构修改为first-party-jwt
。Istio 将默认使用第三方令牌。5.1 验证是否支持 第三方令牌。
kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceaccounts/token"))'
5.1.1 jwtPolicy =
third-party-jwt
使用第三方令牌 更安全 Istio 默认使用这个选项。5.1.2 jwtPolicy =
first-party-jwt
使用第一方令牌 属性比较不安全。
6.
istioctl upgrade -f demo.yaml
命令进行升级。7. 观察
kubernets
中istio-system
的服务更新完成。8. 重新注入环境中部署的服务, 用以更新注入数据。
8.1 对于自动注入的情况可使用如下命令:
8.1.1
kubectl rollout restart deployment
8.1.2
kubectl rollout restart statefulset
8.1.3
kubectl rollout restart daemonset
8.2 对于手动注入的情况( 需要重新 apply 一下服务) :
- 8.2.1
kubectl apply -f <(istioctl kube-inject -f nginx-test.yaml)
- 8.2.1
9. 检查升级, 执行
istioctl version
检查9.1
client version
版本是否为新版本。9.2
control plane version
版本是否为新版本。9.3
data plane version
中是否全部proxies
都为新版本。
Istio UnInstall
- 卸载 Istio 的话其实就是讲
kubernetes
所安装到的组件delete
掉就可以了
|
|