istio的代理配置参考文档:api
详细介绍: https://istio.io/blog/2018/v1alpha3-routing/服务器
在一个典型的网格中,一般有一个或多个用于终结外部 TLS 连接,将流量引入网格的负载均衡器(咱们称之为 gateway). 而后流量经过边车网关(sidecar gateway)流经内部服务.应用程序使用外部服务的状况也很常见(例如访问 Google Maps API),一些状况下,这些外部服务可能被直接调用;但在某些部署中,网格中全部访问外部服务的流量可能被要求强制经过专用的出口网关(Egress gateway).下图描绘了网关在网格中的使用状况.cookie
考虑到上述因素,v1alpha3引入了如下这些新的配置资源来控制进入网格,网格内部和离开网格的流量路由。网络
1.Gateway架构
2.VirtualService负载均衡
3.DestionRuleide
4.ServiceEntry微服务
下图描述了跨多个配置资源的控制流程spa
Gateway 用于为 HTTP / TCP 流量配置负载均衡器,并无论该负载均衡器将在哪里运行。 网格中能够存在任意数量的 Gateway,而且多个不一样的 Gateway 实现能够共存。 实际上,经过在配置中指定一组工做负载(Pod)标签,能够将 Gateway 配置绑定到特定的工做负载,从而容许用户经过编写简单的 Gateway Controller 来重用现成的网络设备。.net
对于入口流量管理,您可能会问: 为何不直接使用 Kubernetes Ingress API ? 缘由是 Ingress API 没法表达 Istio 的路由需求。 Ingress 试图在不一样的 HTTP 代理之间取一个公共的交集,所以只能支持最基本的 HTTP 路由,最终致使须要将代理的其余高级功能放入到注解(annotation)中,而注解的方式在多个代理之间是不兼容的,没法移植。
Istio Gateway 经过将L4-L6配置与L7配置分离的方式克服了 Ingress 的这些缺点。 Gateway 只用于配置L4-L6功能(例如,对外公开的端口,TLS 配置),全部主流的L7代理均以统一的方式实现了这些功能。 而后,经过在 Gateway 上绑定 VirtualService 的方式,可使用标准的 Istio 规则来控制进入 Gateway 的 HTTP 和 TCP 流量。
例如,下面这个简单的 Gateway 配置了一个 Load Balancer,以容许访问 host bookinfo.com 的 https 外部流量进入网格中:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: servers: - port: number: 443 name: https protocol: HTTPS hosts: - bookinfo.com tls: mode: SIMPLE serverCertificate: /tmp/tls.crt privateKey: /tmp/tls.key
要为进入上面的 Gateway 的流量配置相应的路由,必须为同一个 host 定义一个 VirtualService(在下一节中描述),并使用配置中的 gateways 字段绑定到前面定义的 Gateway 上:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - bookinfo.com gateways: - bookinfo-gateway # <---- bind to gateway http: - match: - uri: prefix: /reviews route: ...
Gateway 能够用于建模边缘代理或纯粹的内部代理,如第一张图所示。 不管在哪一个位置,全部网关均可以用相同的方式进行配置和控制。
用一种叫作 “Virtual services” 的东西代替路由规则可能看起来有点奇怪,但对于它配置的内容而言,这事实上是一个更好的名称,特别是在从新设计 API 以解决先前模型的可扩展性问题以后。
实际上,发生的变化是:在以前的模型中,须要用一组相互独立的配置规则来为特定的目的服务设置路由规则,并经过 precedence 字段来控制这些规则的顺序;在新的 API 中,则直接对(虚拟)服务进行配置,该虚拟服务的全部规则以一个有序列表的方式配置在对应的 VirtualService 资源中。
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1
VirtualService描述了一个或多个用户可寻址目标到网格内实际工做负载之间的映射。在上面的示例中,这两个地址是相同的,但实际上用户可寻址目标能够是任何用于定位服务的,具备可选通配符前缀或 CIDR 前缀的 DNS 名称。 这对于应用从单体架构到微服务架构的迁移过程特别有用,单体应用被拆分为多个独立的微服务后,采用 VirtualService 能够继续把多个微服务对外暴露为同一个目标地址,而不须要服务消费者进行修改以适应该变化。
DestinationRule 配置将流量转发到服务时应用的策略集。 这些策略应由服务提供者撰写,用于描述断路器,负载均衡设置,TLS 设置等.
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN - name: v3 labels: version: v3
ServiceEntry 用于将附加条目添加到 Istio 内部维护的服务注册表中。 它最经常使用于对访问网格外部依赖的流量进行建模,例如访问 Web 上的 API 或遗留基础设施中的服务。
全部之前使用 EgressRule 进行配置的内容均可以经过 ServiceEntry 轻松完成。 例如,可使用相似这样的配置来容许从网格内部访问一个简单的外部服务:
apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: foo-ext spec: hosts: - foo.com ports: - number: 80 name: http protocol: HTTP
也就是说,ServiceEntry 比它的前身具备更多的功能。首先,ServiceEntry 不限于外部服务配置,它能够有两种类型:网格内部或网格外部。网格内部条目只是用于向网格显式添加服务,添加的服务与其余内部服务同样。采用网格内部条目,能够把本来未被网格管理的基础设施也归入到网格中(例如,把虚机中的服务添加到基于 Kubernetes 的服务网格中)。网格外部条目则表明了网格外部的服务。对于这些外部服务来讲,双向 TLS 身份验证是禁用的,而且策略是在客户端执行的,而不是在像内部服务请求同样在服务器端执行策略。
因为 ServiceEntry 配置只是将服务添加到网格内部的服务注册表中,所以它能够像注册表中的任何其余服务同样,与 VirtualService 和/或 DestinationRule 一块儿使用。例如,如下 DestinationRule 可用于启动外部服务的 双向 TLS 链接:
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: foo-ext spec: name: foo.com trafficPolicy: tls: mode: MUTUAL clientCertificate: /etc/certs/myclientcert.pem privateKey: /etc/certs/client_private_key.pem caCertificates: /etc/certs/rootcacerts.pem
全部服务都是经过一个边缘代理(istio本身提供ingressgateway),根据不一样的域名转发到不一样的服务.如今给出两个例子.
服务service-dev的配置:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: service-dev-gateway namespace: im spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - service-dev.com --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service-dev-vs namespace: im spec: hosts: - service-dev.com gateways: - service-dev-gateway http: - route: - destination: host: service-dev.im.svc.cluster.local subset: v1 retries: attempts: 3 perTryTimeout: 100ms --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: service-dev-dr namespace: im spec: host: service-dev.im.svc.cluster.local subsets: - name: v1 labels: version: v1 trafficPolicy: outlierDetection: consecutiveErrors: 6 interval: 1m baseEjectionTime: 30s maxEjectionPercent: 80
服务service-deny的配置:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: service-deny-gateway namespace: im spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - service-deny.com --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service-deny-vs namespace: im spec: hosts: - service-deny.com gateways: - service-deny-gateway http: - route: - destination: host: service-deny.im.svc.cluster.local subset: v1 retries: attempts: 3 perTryTimeout: 100ms --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: service-deny-dr namespace: im spec: host: service-deny.im.svc.cluster.local subsets: - name: v1 labels: version: v1 trafficPolicy: outlierDetection: consecutiveErrors: 6 interval: 1m baseEjectionTime: 30s maxEjectionPercent: 80
上面两配置中: 都是配置各自一个gateway,定义特定的hosts.而后配置一个virtualservice绑定特定的gateway,指定的host根据指定的路由规则,路由到desinationrule.desinationrule查找host为service-dev(service-deny)而且标签为version: v1的服务.trafficPolicy是熔断处理,间隔1分钟内出现6次错误,把上游服务下线30S.下线的服务不能超过总的80%.