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%.