深入浅出Istio:Service mesh快速入门与实践-读书笔记(By GisonWin)

01 服务网格历史

(以后补充)

02 服务网格的基本特性

连接
- 微服务错综复杂,要完成其业务目标,连接问题是首要问题.连接存在于所有服务的整个lifcecycle中,用于维持服务的运行.
安全
- 保障网格间安全,需要具备服务间通信加密,服务身体认证和服务访问控制(授权和鉴权)等功能
- 认证失败后如何处理,外部证书(统一CA)接入,签发,传播和更新等
策略
- 对调用频率的限制,对服务互访的控制以及针对流量的限制和变更
- Mixer作为Istio中执行者,Envoy每次调用,逻辑上都会通过Mixer进行事先预检和事后报告
观察
- 随着服务数量增多,监控和跟踪的需求水涨船高.因此可观察的保障就成为系统功能的重要组成部分,也是系统运维功能的重要保障
- 将服务器视为无个性,可替换的基础设施.如果机器发生故障,直接替换其即可.
- 服务的健康状况是一系列的连续状态,如我们关注服务的调用成功率,响应时间,调用量,传输量
- 网格还应提供分布式跟踪(Distributed Tracing)能力,对服务的调用链路进行跟踪

03 Istio基本介绍

Istio核心组件及功能
- 数据面:Sidecar.通过注入方式和业务容器共存于一个Pod,会支持业务应用容器的流量,并接受控制面组件的控制,同时会向控制面输出日志,跟踪及监控数据
- 控制面:Istio核心,管理Istio的所有功能
1. Pilot
  
  Pilot是Istio主要控制点,Istio流量由Pilot管理由Sidecar执行完成.
  - 从k8s或其他平台的注册中心获取服务信息,完成服务发现过程
  - 读取Istio各项控制配置,在进行转换后将其发给sidecar进行执行
  - sidecar根据pilot指令,将路由,服务,监听,集群等定义信息转换为本地配置,完成控制行为本地化.
2. Mixer
  
  主要功能:
  - 预检
  - 汇报
  Mixer中包含多个adapter来处理预检和报告.
3. Citadel
  
  早期版本称之为istio-CA,所以它就是用于管理证书的.在集群中启用了服务之间加密后,负责为集群中各个服务在统一CA条件下生成证书,并下发给各个服务中的Sidecar.
4. SideCar(Envoy)
  - 是Istio中的数据面,负责控制面对网格控制的实际执行者角色
  - Istio默认的Sidecar是由Envoy派生的,理论上只支持Envoy的xDS协议,其他类似反向代理软件都可以代替Envoy的角色.
  - Istio默认实现中,Istio通过istio-init初始化容器中的iptables指令,对所有的Pod流量进行支持,从而接管Pod中的应用通信过程,获得通信控制器,得以实现控制目标.
  - 同一个Pod内多个container间,网络栈共享,所以sidecar得以实现,sidecar加入后,原来containe间直接通信方式,通过container1-->sidecar1-->sidecar2-->container2的模式,所以通信过程中的控制和观察被Pilot所控制.
核心配置对象

Istio安装过程中会进行CRD初始化,在k8s集群中注册一系列的CRD.用户利用istio控制微服务间通信就是通过向k8s提交CRD资源方式完成的.

istio中的资源:
1. networking.istio.io
  
  流量管理功能的执行者.
  
  以下为最常用的对象:
  - Gateway
  - 访问服务时,不论是网格内部的服务互访还是通过Ingress进入网格的外部流量,都要经过Gateway.
  - 它描述了边缘接入对象设备:包含对外开放端口,主机名及可能存在的TLS证书的定义.
  - Ingress流量通过对应的istio Ingress Gateway Controler进入
  - 网格内部服务互访通过虚拟mesh( sidecar)进行
  - Polit根据Gateway和主机名检索,如果存在对应的VirtualService,则交由其处理,如果是Mesh gateway且不存在对应的主机名的VirtualService,则尝试调用k8s Service,如果还不存在则报404 error
  - VirtualService
  - Host:该对象负责的主机名称,在k8s集群中,可以是服务名
  - Gateway:流量来源网状,也被称为mesh
  - 路由对象:网格中的流量.如果符合前面host,gateway条件,就需要根据实际协议对流量的处理方式进行区别,原因是Http是一种透明协议,可以经过对报文解析,完成更细致的控制.而对于TCP流来说就不能完成过于复杂的任务.
  - TCP/TLS/HTTP Route
  - 路由对象可以是http,tcp,tls中的一个,分别针对不同的协议进行工作.
  - 每个路由对象至少包含两部分:匹配条件和目的路由
  - httproute对象中包含匹配httpmatchrequest对象数组,以及描述目标服务的destinationweight对象,且httpmatchrequest匹配条件较为丰富,可以超时控制,重试,错误注入等.
  - Tcproute简单很多,它的匹配借助L4MatchAttributes对象完成,包含源标签,gateway,地址和端口
  - DestinationWeight
  - 各协议路由的目标定义是一致的,都是destinationweight对象数组完成.它指到某个目标destination对象的流量权重,这意味着,多个目标可以同时为该virtualservice提供服务,并按照相权重进行流量分配
  - Destination
  - Subset:服务的一个子集,它在k8s中代表使用标签选择器区分的不同Pod.
  - Port:服务端口
2. config.istio.io
  
  该对象用于为mixer组件提供配置.Mixer对数据的处理过程如下
  - Rule:Mixer入口,包含一个match成员和一个逻辑表达式,只有符合表达式判断的数据才会交给action处理.逻辑表达式中变更称为attribute,其中内容来自Envoy提交的数据
  - Action:将符合入口标准的数据,在用什么方式加工之后,交给哪个适配器进行处理.
  - Instance:使用Template对接收到数据进行处理
  - Handler:代表一个适配器实例,用于接收处理后的数据
  - Instance:用于为进入的数据选择一个模板,并在数据中抽取某些字段作为模板的参数,传输给模板进行处理.
  - Adapter:Istio中定义的一个行为规范,而一些必要的实例化数据是需要再次进行初始化的.只有数据得到正式初始化后Adapter才能被投入使用.
  经过Handler实例化之后的Adapter,就具备了工作功能,有自身实现(listcheck,memquota)也有第三方实现(prometheus,datadog).Envoy传出数据将会通过具体的Adapter处理,得到预检结果,或者输出各种监控,日志及跟踪数据.
  - Template:用于对接收到的数据进行再加工.用户编制模板对象后,经过模板处理原始数据会被转换成符合适配器输入要求的数据格式,就可以在Instance字段中引用.
  - Handler:用于对Adapter进行实例化.
  Mixer管理了所有第三方资源接入,大大扩展了Istio的作用范围,但应用难度系统增高.
3. authentication.istio.io
  
  用于定义认证策略.在网格级别,命名空间级别以及服务级别都提供了认证策略的要求.要求在内容中包含服务间通信认证,及基于JWT的终端认证.
  - Policy:用于指定服务一级的认证策略,如将其命令为default,则该对象所在命名空间会默认采用这一认证策略
  - 策略目标:服务名称(主机名称)及服务端口号
  - 认证方法:设置服务间认证的perrs子对象,用于设置终端认证的origins子对象.
  - MeshPolicy:只能被命名为default,它代表所有网格内部应用默认认证策略,其他部分和Policy一致.
4. rbac.istio.io
  
  用于基于RBAC(基于角色)访问控制系统
  - ServiceRole:一系列规则rules组成,每条规则对应一条权限,其中描述了权限所对应的服务,服务路径及方法,还可以进行下定义的约束
  - ServiceRoleBinding:类似于k8s的RBAC,用于将用户主体(用户或服务)和ServiceRole绑定.
小结

04 Istio快速入门

环境介绍

对kubernets的环境要求如下:
- Kubernets1.9+
- 具备管理权限的kubectl及其配置文件,能够操作测试集群
- Kubernetes集群要有获取互联网镜像的能力
- 支持istio的自动注入功能,需要检查kubernetes API Server启动参数,保证其中admission control 部分按顺序启用MutatingAdmissionWebhook ,ValidatingAdmissionWebhook
快速部署Istio

下载过程略

下载安装包解压后,进入安装目录,将bin目录中的istioctl复制到PATH路径中,然后开始部署istio
```
kubectl apply -f install/kubernetes/istio-demo.yaml
```
运行如下命令,查看istio-system namespace中pod启动状况 ,-w 用于持续查询Pod状态的变化
```
kubectl get pods -n istio-system -w
```

部署两个版本的服务

#!/usr/bin/env python3
from flask import Flask,request
import os
import urllib.requestapp = Flask( name )@app.route('/env/<env>')
def show_env(env) :
return os.environ . get(env)@app.route('/fetch')
def fetch_env() :
url = request.args.get('url','')
with urllib.request.urlopen(url) as response:return response.read()
if __name__ =="__main__":app.run(host="0.0.0.0",port=80,debug=True)

我们为这个App创建两个Deployment,将其分别命名为flaskapp-v1,flaskapp-v2,同时创建一个service,命名为flaskapp.

创建flaskapp.istio.yaml

apiVersion: v1
kind: Service
metadata: name: flaskapplables: app: flaskapp
spec:selector:  app:flaskappports:-name: httpport: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:name: flaskapp-v1
spec:replicas: 1template:metadata:lables:app: flaskappversion: v1spec:containers:name: flaskappimage: distise/flashappimagePullPolicy: IfNotPresentenv:name: versionvalue: v1
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:name: flaskapp-v2
spec:replicas: 1template:metadata:lables:app: flaskappversion: v2spec:containers:name: flaskappimage: distise/flashappimagePullPolicy: IfNotPresentenv:name: versionvalue: v2

接下来使用istio进行注入.istioctl,基本作用是修改kubernetes Deployment.在Pod中注入前面提到的Sidecar 容器,并使用管道命令,将yaml文件通过istioctl处理之后通过管道输出给kubectl.最终提交到Kuernetes集群

istioctl kube-inject -f flask.istio.yaml |kuberctl apply -f -service/flaskapp created
#创建之后可看创建出来的Pod
kubectl get po -w
#也可以使用kubectl describe po查看Pod容器
kubectl describe po flaskapp-v1-6647dd84b9-2ndf4

部署客户端服务
验证服务
创建目标规则和默认路由
小结

本章实践了一个较为典型的Istio服务上线流程:注入-->部署-->创建目标规则-->创建默认路由.绝大多数istio网格应用都会遵循这一流程进行上线.

05 用Helm部署Istio

通过前面知识我们了解到,Istio由多个组件构成,并且可以通过kubectl命令在Kubernetes集群上进行部署,部署时会在Kubernetes集群上创建大量对象,Istio与Kubernetes进行了深度集成,构成Istio的组件都以Deployment形式在Kubernetes中运行,并在运行过程中所需的配置数据也需要依赖各种CRD及ConfigMap,Secret来进行存储.

这种包含复杂依赖关系的应用部署过程,需要由功能足够强大的模板系统来提供支持,Istio官方推荐使用Helm对istio进行部署.

Istio Chart概述

Istio Chart是一个总分结构,其分级结构和设计结构是一致的.
1. Chart.yml:chart基础信息文件,包含版本号,名称,关键字等元数据信息.
2. values-*.yml:
  - 提供Istio在各种场景下关键配置范本.可以作为Heml的输入文件,来对Istio进行典型定制.
  - 可对这些输入文件进行改写,改写完成后使用helm template命令生成最终部署文件.就能用Kubectl完成部署了.
  - values-istio-auth-galley.yaml:启用控制面mTLS,默认打开网格内部的mTLS,启用Galley
  - values-istio-multicluster.yaml:多集群配置
  - values-istio-auth-multiclusterm.yaml:
  - values-istio-auth.yaml:
  - values-istio-demo-auth.yaml
  - values-istio-demo.yaml
  - values-istio-galley.yaml
  - values-istio-gateways.yaml
  - values-istio-one-namespace.yaml
  - values-istio-one-namespace-auth.yaml
  - values.yaml:罗列了绝大多数常用变量,也是我们定制的基础参考.
3. requirements.yaml
  
  该文件用于管理对子Chart的依赖关系,并定义了一系列形状变量.
4. templates/_affinity.yaml:
  
  生成一组节点新和或互斥元素,供各个组件在渲染yaml时使用,定义一系列变量用于控制Istio组件节点亲和性.
  - nodeAffinityRequiredDuringScheduling:
  - nodeAffinityPreferredDuringScheduling:
5. templates/sidecar-injector-configmap.yaml
  
  用于生成一个Configmap对象,在该对象中保存的配置数据被用于进行Sidecar注入.
6. templates/configmap.yaml:
  
  也生成一个ConfigMap,名称为istio,用于为Pilot提供启动配置数据.
7. templates.crds.yaml:
  
  包含Istio所需CRD定义,部署方式如下:
  - 如果使用Helm2.10之前版本,需要先使用kubectl提交该文件到Kubernetes集群中
  - 如果使用Helm2.10之后版本,则Helm hook会自动提交安装,无须关注
8. charts:
  
  这个目录中的子目录就是Istio的组件:
  - certmanager:一个基于Jestack Cert-manager项目的ACME证书客户端,用于自动进行证书申请,获取及分发
  - galley:Istio利用galley进行配置管理工作
  - gateways:对Gateways Chart进行配置,可发安装多个Gateway Controller
  - grafana:图形化的Istio Dashboard
  - ingress:一个遗留设计,默认关闭,在流量控制协议升级到network.istio.io.v1alpha3之后,已建议弃用
  - kiali:带有分布式跟踪,配置校验等多项功能的Dashboard
  - mixer:Istio策略实施组件
  - pilot:Istio流量管理组件
  - prometheus:监牢软件,包含Istio特定的指标抓取设置
  - security:Citadel组件,用于证书的自动管理
  - serviegraph:分布式跟踪组件,用于获取和展示服务调用关系图,即将被弃用
  - sidecarInjectorWebhook:自动注入webhook的相关配置
  - tracing:分布式跟踪组件,使用Jaeger实现,替代原有的ServiceGraph组件
全局变量介绍

我们使用Chart时,通常不会修改Chart本体,仅通过对变量的控制来实现对部署过程的定制.Istio Helm Chart提供了大量变量来帮助用户对Istio进行定制.
1. hub&tag
  - 对内网部署非常有必要,将Istio镜像Pull并推送到私库后,只要在values.yaml修改就可以将Istio所需镜像的引用指向内网私库.
  - 多数情况下这两个变量代表所有镜像地址,具体名称一般{{.Values.global.hub}}/[component]/:{{.Values.global.tag}}拼接而成.
  - 在proxy_init,mixer,grafana,polit的Deployment模板中,一量在其image变量中包含路径符/,则会弃用global.hub,直接采用image的定义
  - ```
  {{- if contains "/".Values.image}}image: "{{.Values.image}}"
  {{- else}}image: "{{.Values.global.hub}}/{{.Values.image}}:{{.Values.global.tag}}"
  {{- end}}
```
2. ingress.enabled:
  
  用来控制是否启用Istio的Ingress Controller,如果设置为True,就会启用Kubernetes Ingress资源的支持,Istio并不推荐Ingress方式,建议使用Ingress Gateway取代它．
3. Proxy relation args：
  
  在values.yaml定义了一级proxy变量,用于对Sidecar进行控制
  - proxy.resources
  - proxy.concurrency
  - proxy.accessLogFile
  - proxy.privileged
  - proxy.enableCoreDump
  - proxy.includeIPRanges
  - proxy.excludeIPRanges
  - proxy.includeInboundPort
  - proxy.autoInject
  - proxy.envoyStatsd
4. proxy_init.image
  
  网格中的服务Pod在启前,首先会运行一个初始化镜像来完成流量工作,这个变量可以用于指定初始化容器镜像
5. imagePullPolicy:
  
  镜像摘取策略,default is IfNotPresent
6. controlPlaneSecurityEnabled
  
  指定是否在Istio控制面组件上启用mTLS通信.启用后哦组件包括Ingress,Mixer,Pilot,Sidecar
7. disablePolicyChecks:
  
  设置为True,会禁用Mixer的预检功能.预检功能是一个同步过程,有可能因为预检缓慢造成业务应用的阻塞.
8. enableTracing:
  
  是否启用分布式跟踪,default is True
9. mtls.enabled:
  
  服务之间是否默认启用mTLS,如果设置为True,则网格内服务间的通信都会使用mTLS进行安全加固.这一设置是全局的,对每个服务还可以单独使用目标规则或服务注解的方式,自行决定是否采用mTLS加固
10. imagPullSecrets:
  
  用于为ServiceAccount分配镜像拉取过程中的所需的认证凭据.默认为空
11. arch:
  
  在设置Istio组件的节点亲和性过程中,会使用这个变量的列表内容来确定可用于部署的节点范围 ,并按照不同的服务器架构设置了优先顺序,它默认的列表内容如下:
```
amd64: 2
s390x: 2
ppc64ie: 2
```
12. oneNamespace:
  
  默认为false.如果设置为true,则会在Polit的服务发现参数中加入-a,此时Pilot只会对Istio组件所在的命名空间进行监控.
13. configValidation:
  
  用于配置是否开启服务端的配置验证,默认为true.该选项开启后,会生成一个ValidatingWebhookConfiguration对象,并被包含到Galley配置中,从而启用校验功能.
14. meshExpansion:
  
  要将服务网格扩展到物理或虚拟机上,会使用到,默认为false.如果设置为true,则会在Ingress Gateway上公开Pilot,Citadel的服务
15. meshExpansionILB:
  
  是否在内部网状中公开Pilot和Citadel端口,默认为false.
16. defaultResources:
  
  为所有istio组件都提供一个最小资源限制.默认情况下只设置一个请求10mCPU资源的值,可以在各个Chart局部变量中分别设置资源需求
17. hyperkube:
18. priotyClassname
  
  默认为空,可选值包括system-cluster-critical,system-node-critical
19. crds
  
  该变量用于决定是否包含CRD定义.如果使用helm template,或2.10后的版本helm install ,就将其设置为true.否则在安装之前首先要执行kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml.并将该变量设置为false.
Istio安装清单的生成和部署
- 编辑values.yaml
  1. 镜像地址
  如果是内网部署,首先要解决镜像地址问题,一般在具备外网连接的服务器上拉取所需镜像,然后导出镜像,将其推送到本地私有镜像库,
  
  如果我们想获取其中使用的镜像名称,就可以用grep方便过滤出来
```
grep -r image:istio-demo.yaml|egrep -o -e "image:."| sort |uniq
```
  得到这些镜像名称之后,就进行镜像的拉取和推送.根据入私库地址,修改values.yaml中各个镜像地址,生成新的安装清单文件,然后重新用上述命令进行检查.
  1. 系统资源
  根据实际情况调整各个组件的资源分配.默认设置是非常保守的.
  1. 服务类型
  Istio的istio-ingressgateway服务的默认类型是Loadbalncer,如果在部署的Kubernetes集群中没有lb支持,就需要对服务类型进行修改.
  1. 可视化组件的服务开放
  在Istio中包含的Prometheus,Grafana,Kiali等可视化组件,在默认状态下都是ClusterIP类型,要顺利使用,则可能需要为其分配Ingress或者修改服务类型
- 生成部署清单
  
  使用helm template 生成最终部署清单.
```
helm template install/kubernetes/helm/listio --name istio --namespace istio-system -f my-values.yaml > my-istio.yaml
```
  命令完成后打开my-istio.yaml文件,检查其中内容是否符合预期.
- 部署Istio
  
  上面生成的my-istio.yaml是要求部署到istio-system命名空间的,使用命令如下
```
kubectl create ns istio-system
```
```
kubectl apply -f my-istio.yaml
```
  命令运行完成后可用使用命令来查看Pod运行情况,直至全部Pod成功进入Running或Completed状态,Istio安装部署工作就完成了
```
kubectl get po -n istio-system -w
```
小结

06 Istio常用功能

在网格中部署应用
```
istioctl kube-inject -f flash.istio.yaml -o flask.istio.injected.yaml
```
打开文件后发现Deployment对象有很大改变,多出了一个sidecar容器,并出现了一个初始化容器istio-init.
1. 对工作负载的要求
  - 要正确命令服务端口
  - 工作负载的Pod必须有关联的Service
2. 使用自动注入
  - 如果将sidecarInjectorWebhook.enabled设置为true,就会开启Sidecar自动注入特性
  - enableNamespacesByDefault为true,则会为所有命名空间开启自动注入功能.
  - autoInject,它设置的并不是自动注入功能,而是在启用自动注入功能之后,对于指定的命名空间内新建的Pod是否进行自动注入,如果取值为enabled,则该命名空间内的Pod只要没有被注解为sidecar.istio.io/inject:false就会完成自动注入,如果取值为disabled,则需要为Pod设置注解为sidecar.istio.io/niject:true才会进行注入.
3. 准备测试应用
  
  略
修改Istio配置

略
使用Istio Dashboard

提供了条形图,饼图,表格,拆线图等丰富的可视化组件.且对其中的数据源和可视化组件都可以二次开发.
1. 启用Grafana
  
  默认未启用grafana.启动命令如下
```
helm template istio --name istio --set grafana.enabled=true --namespace istio-system > default-grafana.yaml
######
kubectl apply -f default-grafana.yaml
```
2. 访问Grafana
```
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath-'{.items[0].metadata.name}') 3000:3000 &
```
  接下来打开 browser,type http://localhost:3000/ ,单击左上角Home链接.打开Istio内置的Dashboard.
3. 开放Grafana服务
  
  kubectl端口转发方式不是很稳定,要长期使用的话,对grafana进行定制.
  
  security.enabled=true并设置用户名和密码.
4. 学习和定制略
使用Prometheus
1. 访问prometheus
  
  默认是开启的.
  
  http://localhost:9090
2. 开放prometheus服务
  
  prometheus的Service通过values.yaml定制对服务开放方式
3. 学习和定制
  
  略

使用Jaeger

用于分布式跟踪的开源软件.提供了原生的OpenTracing支持,向下兼容Zipkin,同时支持多种存储后端.

启用Jaeger

默认未启用

helm template istio --name istio --set tracing.enabled=true --namespace istio-system > default-tracing.yaml
#########
kubectl apply -f default-tracing.yaml
#########
kubectl get po -w istio-system

访问Jaeger:

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686:16686

browser,type

http://127.0.0.1:16686

跟踪参数的传递:

(以后有时间再补充)
开放Jaeger服务
- 修改服务类型方式
- 使用Ingress Controller

使用Kiali

是用于Istio可视化软件,它除了提供监控,可视化及跟踪外还提供了Iistio配置验证,健康评估等高级功能
1. 启用kiali
  - 将kiali.enabled:true即可
  - 设置Ingress 出口
2. 访问kiali
```
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=kiali -o jsonpath='{.items[0].metadata.name}') 20001:20001
```
  browser,type http://localhost:20001
  
  tips:default username,password is admin:admin.
3. 开放kiali服务
  
  参考jaeger.
小结

07 HTTP流量管理

定义目标规则

当Kubernetes访问一个服务时,需要指定其协议,服务名和端口,Istio的服务网格中对服务进行了进一步抽象
- 可以使用Pod标签对具体服务进程进行分组
- 可以定义服务的负载均衡策略
- 可以为服务指定TLS要求
- 可以为服务设置连接池大小
Kubernetes中,Service和Deployment或其他工作负载关系是一对一.如下图所示:

而在Istio中,Service经常会对应不同的Deployment,如下图所示:
定义默认路由

Istio建议为每个服务都创建一个默认路由,在访问某一服务时如果没有特定的路由规则,则使用默认路由规则来访问指定的子集,以此来确保服务在默认情况下的行为稳定性.
流量的拆分和迁移

通过设置权重来拆分流量

如果不声明权重,其默认为100

流量分配是有权重的,且权重总和必须是100
金丝雀部署

定义:
- 就是在发布新版本时,部署的新版本并不对外开放,而是选择一小部分用户作为测试目标,这部分用户对服务的访问会指向特定版本,通过对这些金丝雀用户的使用情况观察,来确定新版本服务的发布效果,在确定结果之前,所有其他用户都继续使用原有版本
- 在金丝雀用户访问时产生的流量http header中会有一行lab:canary.我们用它区别用户,其他用户全都访问旧版本.
根据来源服务进行路由

根据不同版本的服务访问不同版本的目标服务.

在上面的VirtualService定义里,用sourceLabels对来源路由进行了匹配.
对URI进行重定向

根据URL进行重定向对目标路由进行分流 .
通信超时控制
- 微服务间进行相互调用时,由于服务问题或网络故障影响发生超时在所难免,对这种情况不加控制,通常需要等待默认的超时时间,会导致业务处理时间大幅度处长.如果故障继续存在,往往会造成业务积压,到了一定程序后会导致故障扩散,造成大面积故障.
- 即使全部加以控制(对于某一服务的调用,一旦超过一定时间则自动终止该调用),但由于服务和业务情况多变,需要不断调整控制过程来进行调整和优化.如有哪些调用点需要控制,每个调用节的超时应该设置多少,修改其中一点之后,会对其他调用点的超时设置产生什么样的影响.而且这种调整意味着很多重复工作,往往需要非常多的人力和时间投入才能达到较好效果.
- 通过 Istio的流量控制可以对服务间的超时进行控制,在应用无感知情况下,根据VirtualService配置,动态调整调用过程中的超时上限,从而达到控制故障范围的目的.相对于代码修改,这种非***调整方式能够节省大量成本.
故障重试控制
- 服务间调用过程中,有时会发生闪断情况,目标服务在短时间内不可用,此时如果进行重试,则可能会继续顺利完成调用.
- 和通信超时控制一样,都是用于应对故障的常用手段.无须开发介入,直接在运行环境中对故障重试行为进行调整,能够极大增强系统弹性和健壮性.
- 问题复杂了,重试有超时设置,服务调用本身也有超时设置,两者如何协调?
- 对于重试的超时设置和总体的超时设置,可以将重试超时和重试次数的乘积与总体的超时进行比较,哪个小,哪个设置就会优先生效.
入口流量管理

Kubernetes为第三方厂商提供了Ingress Controler规范,用于入站流量管理.而Istio推出了Gateway,用于在网络边缘进行入站和出站的流量管理.

Ingress Gateway在逻辑上是相当于网络边缘上的一个负载均衡器,用于接收和处理网格边缘出站和入门的网络连接.

在前面流量管理中使用VirtualService对象,都默认包含gateways字段,如果没有指定,则默认值为:mesh.所有网格内部服务间互相通信,都是通过这个网关进行的.如果要对外提供服务,需要定义Gateway对象,并在gateways字段中进行赋值.一量在gateways中填写了mesh之外的对象名称,就要继续对内部通信进行流量控制,并必须显式地将内置的mesh对象名称也加入列表中.
1. 使用Gateway开放服务
```
apiVersion:networking.istio.io/v1alpha3
kind:Gateway
metadata:
name: example-gateway
spec:
selector:istio: ingressgateway
servers:port: number: 80name: httpprotocol: HTTPhosts:"*.microservice.rocks""*.microservice.xyz"
```
  selector实际上是一个标签选择器,用于指定哪些Gateway Pod负责这个Gateway对象的运行
  
  hosts字段用了一个通配符来指明这个gateway可能要负责的主机名.可以使用kubectl get svc -n istio-system istio-ingressgateway 查看该服务的IP,并将测试域名映射这个IP
  
  将配置文件提交给Kubernetes集群
```
kubectl apply -f example.gateway.yaml
############
http flaskapp.microservice.rocks
```
  访问结果是404.回来发现并没有指定负责响应请求的服务.我们需要对路由规则进行修改
2. 为Gateway添加证书支持
  
  使用过程中可以直接查如何使用,此处略
3. 为Gateway添加多个证书支持
  
  使用过程中可以直接查如何使用,此处略
4. 配置入口流量的路由
  
  使用过程中可以直接查如何使用,此处略
出口流量管理

默认情况下网格内部无法对外网网络请求,但Istio提供了以下几种方式用于网格外部通信
- 设置Sidecar流量劫持范围:根据IP地址告知Sidecar哪些外部资源可以放开访问
- 注册ServiceEntry:把网格外部的服务使用ServiceEntry的方式注册到网格内部
1. 设置Sidecar的流量劫持范围
  
  流量支持由istio-init容器完成.
  - 设置values.yaml中的proxy.includeIPRanges变量
  - 使用Pod注解.traffic.sidecar.istio.io/includeOutboundIpRanges,表明劫持范围
2. 设置ServiceEntry
  
  可以为外部服务设置ServiceEntry,相当于外部服务在网格内部进行了注册,相对于使用CIDR白名单方式,这种方式让Istio对外部访问有了更大的管理能力.
新建Gateway控制器

略
设置服务熔断
- 服务熔思是种保护性措施,即在服务实例无法正常提供服务情况下将其多Lb池中移除,不再为其分配任务,避免在故障实例上积压更多任务,并且可以在等待服务能力恢复后,重新将发生故障的Pod加入LB池.这是常见的服务降级方法.
- Istio中提供了非***式的服务熔断功能.只需要设置DestinationRule对象即可完成.
故障注入测试

微服务测试过程中,往往需要对网络故障场景进行模拟,Istio提供了以下两种故障注入能力:
1. 注入延迟
  - percent:百分比,用于指定注入延迟的比率,默认为100
  - fixedDelay:表明延迟的时间长度,必须大于1毫秒
2. 注入中断
流量复制
- 另一个强大的测试功能,它可以把指向一个服务版本的流量复制一份出来发发送给另一个服务版本.这一功能能够将生产流量导入测试应用.在复制出来的镜像流量发出之后不会等待响应,因此对正常应用的性能影响较小,又能在不影响代码的情况下,用更实际的数据对应用进行测试.

08 Mixer适配器的应用

Mixer适配器简介
基于Denier适配器的访问控制
基于Listchecker适配器的访问控制
使用memQuota适配器进行服务限流
1. Mixer对象的定义
2. 客户端对象的定义
3. 测试限流功能
4. 注意事项
使用RedisQuota适配器进行服务限流
1. 启动Redis服务
2. 定义限流相关对象
3. 测试限流功能
为Prometheus定义监控指标
1. 默认监控指标
2. 自定义监控指标
使用stdio输出自定义日志
1. 默认的访问日志
2. 定义日志对象
3. 测试输出
使用Fluentd输出日志
1. 部署Fluentd
2. 定义日志对象
3. 测试输出
小结

09 Istio的安全加固

Istio安全加固概念
启用mTLS
设置RBAC
RBAC的除错过程

10 Istio的试用建议

Istio自身的突出问题
确定功能范围
选择试用业务
试用过程
1. 制定目标
2. 方案部署
3. 测试验证
4. 切换演练
5. 试点上线

导入markdown文件时,图片丢失,请下载附件PDF文件查看.

http://down.51cto.com/data/2459723

转载于:https://blog.51cto.com/8745668/2366184