istio路由配置
istio路由配置##
istio的代理配置参考文档:
- 中文文档: https://istio.io/zh/docs/reference/config/istio.networking.v1alpha3/
- 英文文档: https://istio.io/docs/reference/config/istio.networking.v1alpha3/
1.Istio v1aplha3路由API介绍###
详细介绍: https://istio.io/blog/2018/v1alpha3-routing/
在一个典型的网格中,通常有一个或多个用于终结外部 TLS 链接,将流量引入网格的负载均衡器(我们称之为 gateway). 然后流量通过边车网关(sidecar gateway)流经内部服务.应用程序使用外部服务的情况也很常见(例如访问 Google Maps API),一些情况下,这些外部服务可能被直接调用;但在某些部署中,网格中所有访问外部服务的流量可能被要求强制通过专用的出口网关(Egress gateway).下图描绘了网关在网格中的使用情况.
考虑到上述因素,v1alpha3引入了以下这些新的配置资源来控制进入网格,网格内部和离开网格的流量路由。
1.Gateway
2.VirtualService
3.DestionRule
4.ServiceEntry
下图描述了跨多个配置资源的控制流程
GateWay####
Gateway 用于为 HTTP / TCP 流量配置负载均衡器,并不管该负载均衡器将在哪里运行。 网格中可以存在任意数量的 Gateway,并且多个不同的 Gateway 实现可以共存。 实际上,通过在配置中指定一组工作负载(Pod)标签,可以将 Gateway 配置绑定到特定的工作负载,从而允许用户通过编写简单的 Gateway Controller 来重用现成的网络设备。
对于入口流量管理,您可能会问: 为什么不直接使用 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 Service####
用一种叫做 “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####
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###
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例子###
所有服务都是通过一个边缘代理(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%.