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