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

时间  2019-11-05
标签 深刻 istio service mesh 快速 入门 实践 读书 笔记 gisonwin 繁體版
原文   原文链接
01 服务网格历史

(之后补充)node

02 服务网格的基本特性
  1. 链接
    • 微服务错综复杂,要完成其业务目标,链接问题是首要问题.链接存在于全部服务的整个lifcecycle中,用于维持服务的运行.
    • 深刻浅出Istio:Service mesh快速入门与实践-读书笔记(By GisonWin)
  2. 安全
    • 保障网格间安全,须要具有服务间通讯加密,服务身体认证和服务访问控制(受权和鉴权)等功能
    • 认证失败后如何处理,外部证书(统一CA)接入,签发,传播和更新等
  3. 策略
    • 对调用频率的限制,对服务互访的控制以及针对流量的限制和变动
    • Mixer做为Istio中执行者,Envoy每次调用,逻辑上都会经过Mixer进行事先预检和过后报告
  4. 观察
    • 随着服务数量增多,监控和跟踪的需求水涨船高.所以可观察的保障就成为系统功能的重要组成部分,也是系统运维功能的重要保障
    • 将服务器视为无个性,可替换的基础设施.若是机器发生故障,直接替换其便可.
    • 服务的健康情况是一系列的连续状态,如咱们关注服务的调用成功率,响应时间,调用量,传输量
    • 网格还应提供分布式跟踪(Distributed Tracing)能力,对服务的调用链路进行跟踪
03 Istio基本介绍

  1. Istio核心组件及功能python

    • 数据面:Sidecar.经过注入方式和业务容器共存于一个Pod,会支持业务应用容器的流量,并接受控制面组件的控制,同时会向控制面输出日志,跟踪及监控数据
    • 控制面:Istio核心,管理Istio的全部功能
    • 深刻浅出Istio:Service mesh快速入门与实践-读书笔记(By GisonWin)

    1. Pilotweb

      Pilot是Istio主要控制点,Istio流量由Pilot管理由Sidecar执行完成.shell

      • 从k8s或其余平台的注册中心获取服务信息,完成服务发现过程
      • 读取Istio各项控制配置,在进行转换后将其发给sidecar进行执行
      • sidecar根据pilot指令,将路由,服务,监听,集群等定义信息转换为本地配置,完成控制行为本地化.

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

    2. Mixerjson

      主要功能:flask

      • 预检
      • 汇报

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

      Mixer中包含多个adapter来处理预检和报告.后端

    3. Citadelapi

      早期版本称之为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:Service mesh快速入门与实践-读书笔记(By GisonWin)

  2. 核心配置对象

    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对数据的处理过程以下

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

      • 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绑定.
  3. 小结
04 Istio快速入门

  1. 环境介绍

    对kubernets的环境要求以下:

    • Kubernets1.9+
    • 具有管理权限的kubectl及其配置文件,可以操做测试集群
    • Kubernetes集群要有获取互联网镜像的能力
    • 支持istio的自动注入功能,须要检查kubernetes API Server启动参数,保证其中admission control 部分按顺序启用MutatingAdmissionWebhook ,ValidatingAdmissionWebhook

  2. 快速部署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

  3. 部署两个版本的服务

    #!/usr/bin/env python3
from flask import Flask,request
import os
import urllib.request

app = 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: flaskapp
  lables: 
     app: flaskapp
spec:
 selector:  
    app:flaskapp
  ports:
     -name: http
     port: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp-v1
spec:
  replicas: 1
  template:
    metadata:
      lables:
         app: flaskapp
         version: v1
    spec:
      containers:
        name: flaskapp
        image: distise/flashapp
        imagePullPolicy: IfNotPresent
        env:
          name: version
          value: v1
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp-v2
spec:
  replicas: 1
  template:
    metadata:
      lables:
         app: flaskapp
         version: v2
    spec:
      containers:
        name: flaskapp
        image: distise/flashapp
        imagePullPolicy: IfNotPresent
        env:
          name: version
          value: 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

  4. 部署客户端服务

  5. 验证服务

  6. 建立目标规则和默认路由

  7. 小结

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

05 用Helm部署Istio

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

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

  1. Istio Chart概述

    Istio Chart是一个总分结构,其分级结构和设计结构是一致的.

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

    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组件

  2. 全局变量介绍

    咱们使用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.

  3. 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
  4. 小结
06 Istio经常使用功能

  1. 在网格中部署应用

    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. 准备测试应用

      略

  2. 修改Istio配置

    略

  3. 使用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. 学习和定制 略

  4. 使用Prometheus

    1. 访问prometheus

      默认是开启的.

      http://localhost:9090

    2. 开放prometheus服务

      prometheus的Service经过values.yaml定制对服务开放方式

    3. 学习和定制

      略

  5. 使用Jaeger

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

    1. 启用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

    2. 访问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

    3. 跟踪参数的传递:

      (之后有时间再补充)

    4. 开放Jaeger服务

      • 修改服务类型方式
      • 使用Ingress Controller

  6. 使用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.

  7. 小结
07 HTTP流量管理

  1. 定义目标规则

    当Kubernetes访问一个服务时,须要指定其协议,服务名和端口,Istio的服务网格中对服务进行了进一步抽象

    • 可使用Pod标签对具体服务进程进行分组
    • 能够定义服务的负载均衡策略
    • 能够为服务指定TLS要求
    • 能够为服务设置链接池大小

    Kubernetes中,Service和Deployment或其余工做负载关系是一对一.以下图所示:

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

    而在Istio中,Service常常会对应不一样的Deployment,以下图所示:

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

  2. 定义默认路由

    Istio建议为每一个服务都建立一个默认路由,在访问某一服务时若是没有特定的路由规则,则使用默认路由规则来访问指定的子集,以此来确保服务在默认状况下的行为稳定性.

  3. 流量的拆分和迁移

    经过设置权重来拆分流量

    若是不声明权重,其默认为100

    流量分配是有权重的,且权重总和必须是100

  4. 金丝雀部署

    定义:

    • 就是在发布新版本时,部署的新版本并不对外开放,而是选择一小部分用户做为测试目标,这部分用户对服务的访问会指向特定版本,经过对这些金丝雀用户的使用状况观察,来肯定新版本服务的发布效果,在肯定结果以前,全部其余用户都继续使用原有版本
    • 在金丝雀用户访问时产生的流量http header中会有一行lab:canary.咱们用它区别用户,其余用户全都访问旧版本.

  5. 根据来源服务进行路由

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

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

  6. 对URI进行重定向

    根据URL进行重定向对目标路由进行分流 .

  7. 通讯超时控制

    • 微服务间进行相互调用时,因为服务问题或网络故障影响 发生超时在所不免,对这种状况 不加控制,一般须要等待默认的超时时间,会致使业务处理时间大幅度处长.若是故障继续存在,每每会形成业务积压,到了必定程序后会致使故障扩散,形成大面积故障.
    • 即便所有加以控制(对于某一服务的调用,一旦超过必定时间则自动终止该调用),但因为服务和业务状况多变,须要不断调整控制过程来进行调整和优化.若有哪些调用点须要控制,每一个调用节的超时应该设置多少,修改其中一点以后,会对其余调用点的超时设置产生什么样的影响.并且这种调整意味着不少重复工做,每每须要很是多的人力和时间投入才能达到较好效果.
    • 经过 Istio的流量控制能够对服务间的超时进行控制,在应用无感知状况下,根据VirtualService配置,动态调整调用过程当中的超时上限,从而达到控制故障范围的目的.相对于代码修改,这种非***调整方式可以节省大量成本.

  8. 故障重试控制

    • 服务间调用过程当中,有时会发生闪断状况,目标服务在短期内不可用,此时若是进行重试,则可能会继续顺利完成调用.
    • 和通讯超时控制同样,都是用于应对故障的经常使用手段.无须开发介入,直接在运行环境中对故障重试行为进行调整,可以极大加强系统弹性和健壮性.
    • 问题复杂了,重试有超时设置,服务调用自己也有超时设置,二者如何协调?
    • 对于重试的超时设置和整体的超时设置,能够将重试超时和重试次数的乘积与整体的超时进行比较,哪一个小,哪一个设置就会优先生效.

  9. 入口流量管理

    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: 80
     name: http
     protocol: HTTP
   hosts:
     "*.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. 配置入口流量的路由

      使用过程当中能够直接查如何使用,此处略

  10. 出口流量管理

    默认状况下网格内部没法对外网网络请求,但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对外部访问有了更大的管理能力.

  11. 新建Gateway控制器

    略

  12. 设置服务熔断

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

  13. 故障注入测试

    微服务测试过程当中,每每须要对网络故障场景进行模拟,Istio提供了如下两种故障注入能力:

    1. 注入延迟
      • percent:百分比,用于指定注入延迟的比率,默认为100
      • fixedDelay:代表延迟的时间长度,必须大于1毫秒
    2. 注入中断

  14. 流量复制

    • 另外一个强大的测试功能,它能够把指向一个服务版本的流量复制一份出来发发送给另外一个服务版本.这一功能可以将生产流量导入测试应用.在复制出来的镜像流量发出以后不会等待响应,所以对正常应用的性能影响较小,又能在不影响代码的状况下,用更实际的数据对应用进行测试.
08 Mixer适配器的应用
  1. Mixer适配器简介
  2. 基于Denier适配器的访问控制
  3. 基于Listchecker适配器的访问控制
  4. 使用memQuota适配器进行服务限流
    1. Mixer对象的定义
    2. 客户端对象的定义
    3. 测试限流功能
    4. 注意事项
  5. 使用RedisQuota适配器进行服务限流
    1. 启动Redis服务
    2. 定义限流相关对象
    3. 测试限流功能
  6. 为Prometheus定义监控指标
    1. 默认监控指标
    2. 自定义监控指标
  7. 使用stdio输出自定义日志
    1. 默认的访问日志
    2. 定义日志对象
    3. 测试输出
  8. 使用Fluentd输出日志
    1. 部署Fluentd
    2. 定义日志对象
    3. 测试输出
  9. 小结
09 Istio的安全加固
  1. Istio安全加固概念
  2. 启用mTLS
  3. 设置RBAC
  4. RBAC的除错过程
10 Istio的试用建议
  1. Istio自身的突出问题
  2. 肯定功能范围
  3. 选择试用业务
  4. 试用过程
    1. 制定目标
    2. 方案部署
    3. 测试验证
    4. 切换演练
    5. 试点上线

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

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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程