邊車容器下的服務網格istio
Istio是一個用於鏈接、管理以及安全化微服務的開放平臺, 提供了一種簡單的方式用於建立微服務網絡,並提供負載均衡/服務間認證/監控等能力,關鍵的是並不須要修改服務自己. 主要提供如下功能: Traffic Management: 控制服務之間調用的流量和API調用; Observability:...
Istio是一個用於鏈接、管理以及安全化微服務的開放平臺, 提供了一種簡單的方式用於建立微服務網絡,並提供負載均衡/服務間認證/監控等能力,關鍵的是並不須要修改服務自己. 主要提供如下功能:html
- Traffic Management: 控制服務之間調用的流量和API調用;
- Observability: 獲取服務之間的依賴,以及服務調用的流量走向;
- Policy Enforcement: 控制服務的訪問策略,不須要改動服務自己;
- Service Identity and Security: 服務身份與安全相關的功能;
架構
智能代理Envoy
Envoy 是一個面向服務架構的L7代理和通訊總線而設計的，這個項目誕生是出於如下目標：nginx
- 外置進程架構：Envoy是一個獨立的進程，與應用程序一塊兒運行。
- 跨語言: Envoy能夠與任何語言開發的應用一塊兒工做。
- 基於新C++11編碼
- L3/L4過濾器：Envoy其核心是一個L3/L4網絡代理，可以做爲一個可編程過濾器實現不一樣TCP代理任務，插入到主服務當中。
- HTTP L7過濾器：在現代應用架構中，HTTP是很是關鍵的部件，Envoy支持一個額外的HTTP L7過濾層。HTTP過濾器做爲一個插件，插入到HTTP連接管理子系統中，從而執行不一樣的任務，如緩衝，速率限制，路由/轉發，嗅探Amazon的DynamoDB等等。
- 支持HTTP/2
- HTTP L7路由：在HTTP模式下運行時，Envoy支持根據content type、runtime values等，基於path的路由和重定向。當服務構建到服務網格時，Envoy爲前端/邊緣代理，這個功能是很是有用的。
- 支持gRPC：gRPC是一個來自谷歌的RPC框架，使用HTTP/2做爲底層的多路傳輸。HTTP/2承載的gRPC請求和應答，均可以使用Envoy的路由和LB能力。因此兩個系統很是互補。
- 支持MongoDB L7
- 支持DynamoDB L7：
- 服務發現：服務發現是面向服務體系架構的重要組成部分。Envoy支持多種服務發現方法，包括異步DNS解析和經過REST調用服務發現(Service discovery)服務。
- 健康檢查：構建Envoy網格的推薦方法，是將服務發現視爲一個最終一致的方法。Envoy含有一個健康檢查子系統，它能夠對上游服務集羣進行主動的健康檢查。而後，Envoy聯合服務發現、健康檢查信息來斷定健康的LB對象。Envoy做爲一個外置健康檢查子系統，也支持被動健康檢查。
- 高級LB：在分佈式系統中，不一樣組件之間LB也是一個複雜的問題。Envoy是一個獨立的代理進程，不是一個lib庫，因此他可以在一個地方實現高級LB，而且可以被任何應用程序訪問。目前，包括自動重試、斷路器，全侷限速，阻隔請求，異常檢測。未來還會支持按計劃進行請求速率控制。
- 前端代理：雖然Envoy做爲服務間的通訊系統而設計，可是（調試，管理、服務發現、LB算法等）一樣能夠適用於前端，Envoy提供足夠的特性，可以做爲絕大多數Web應用的前端代理，包括TLS、HTTP/1.一、HTTP/2，以及HTTP L7路由。
- 極好的可觀察性：如上所述，Envoy目標是使得網絡更加透明。而然，不管是網絡層仍是應用層，均可能會出現問題。Envoy包括對全部子系統，提供了可靠的統計能力。目前只支持statsd以及兼容的統計庫，雖然支持另外一種並不複雜。還能夠經過管理端口查看統計信息，Envoy還支持第三方的分佈式跟蹤機制。
- 動態配置：Envoy提供分層的動態配置API，用戶可使用這些API構建複雜的集中管理部署。
Envoy將做爲一個獨立的sidecar與相關微服務部署在同一個Kubernetes的pod上,並提供一系列的屬性給Mixer。Mixer以此做爲依據執行策略,併發送到監控系統.json
這種sidecar代理模型不須要改變任何服務自己的邏輯,並能增長一系列的功能.後端
Mixer
後端的基礎設施經常被設計用於提供創建服務支持的功能，包括訪問控制系統、遙測數據捕獲系統、配額執行系統以及計費系統等。傳統服務會直接和這些後端系統打交道，和後端緊密耦合，並集成其中的個性化語義以及用法。安全
Mixer的設計目的是改變層次之間的邊界，以此來下降整體的複雜性。從服務代碼中剔除策略邏輯，改由運維人員進行控制。
Mixer架構
- 前提條件檢查 容許服務在響應來自服務消費者的傳入請求以前驗證一些前提條件。前提條件能夠包括服務使用者是否被正確認證，是否在服務的白名單上，是否經過ACL檢查等等。
- 配額管理 使服務可以在分配和釋放多個維度上的配額，配額這一簡單的資源管理工具能夠在服務消費者對有限資源發生爭用時，提供相對公平的競爭手段。限流控制就是配額的一個實例。
- 遙測報告 使服務可以上報日誌和監控，以及還將啓用針對服務生產者以及服務消費者的跟蹤和計費流。
這些機制的應用是基於一組 屬性 的，每一個請求都會將這些屬性呈現給Mixer。在Istio中，這些屬性來自於Sidecar代理（Envoy）的每一次請求。
request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: 192.168.0.1
target.service: example複製代碼
基於適配器與模板的配置
- Handler：Handlers就是一個配置完成的適配器。適配器的構造器參數就是Handler的配置。
- 實例：一個（請求）實例就是請求屬性到一個模板的映射結果。這種映射來自於實例的配置。
- 規則：規則肯定了什麼時候使用一個特定的模板配置來調用一個Handler。
Handler
這裏的例子配置了一個類型爲 listchecker 的適配器。listchecker適配器使用一個列表來檢查輸入。若是配置的是白名單模式且輸入值存在於列表之中，就會返回成功的結果。
apiVersion: config.istio.io/v1alpha2
kind: listchecker
metadata:
name: staticversion
namespace: istio-system
spec:
providerUrl: http://white_list_registry/
blacklist: false複製代碼
實例
配置實例將請求中的屬性映射成爲適配器的輸入, 注意Handler配置中須要的全部維度都定義在這一映射之中。
apiVersion: config.istio.io/v1alpha2
kind: metric
metadata:
name: requestduration
namespace: istio-system
spec:
value: response.duration | "0ms"
dimensions:
destination_service: destination.service | "unknown"
destination_version: destination.labels["version"] | "unknown"
response_code: response.code | 200
monitored_resource_type: '"UNSPECIFIED"'複製代碼
規則
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: promhttp
namespace: istio-system
spec:
match: destination.service == "service1.ns.svc.cluster.local" && request.headers["xuser"] == "user1"
actions:
- handler: handler.prometheus
instances:
- requestduration.metric.istio-system複製代碼
Pilot (原Istio-Manager)
Service Model服務模型
例如，k8s中，一個服務foo就會有一個域名foo.default.svc.cluster.local hostname，虛擬IP10.0.1.1以及可能的監聽端口。
Configuration Model配置模型
Istio的規則配置提供了一個基於pb的模式定義。這些規則內容存儲在一個KVstore中，pilot訂閱了這些配置信息的變化，以便更新istio其餘組件的配置內容。
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: reviews-default
spec:
destination:
name: reviews
route:
- labels:
version: v1
weight: 100複製代碼
代理控制器
- proxy agent 一套用於從抽象服務模型和規則配置生成envoy配置信息的腳本命令，同時也會觸發proxy的重啓；
- discovery service 實現了envoy的服務發現API，從而能夠發佈信息到envoy代理；
GET /v1/registration/(string: service_name)
請求發現服務返回指定service_name的全部主機, 返回如下JSON格式的響應：
{
"hosts": []
}
const std::string Json::Schema::SDS_SCHEMA(R"EOF( { "$schema": "http://json-schema.org/schema#",
"definitions" : {
"host" : {
"type" : "object",
"properties" : {
"ip_address" : {"type" : "string"},
"port" : {"type" : "integer"},
"tags" : {
"type" : "object",
"properties" : {
"az" : {"type" : "string"},
"canary" : {"type" : "boolean"},
"load_balancing_weight": {
"type" : "integer",
"minimum" : 1,
"maximum" : 100
}
}
}
},
"required" : ["ip_address", "port"]
}
},
"type" : "object",
"properties" : {
"hosts" : {
"type" : "array",
"items" : {"$ref" : "#/definitions/host"}
}
},
"required" : ["hosts"]
}
)EOF");複製代碼
這兒不得不提的是pilot的 proxy injection 能力，你可能已經想到了它是基於iptable規則來實現的。這樣全部的服務交互都會被pilot捕獲並從新轉發。
Istio-Auth
提供服務間以及用戶之間的認證,確保不須要修改服務code的前提下加強服務之間的安全性. 主要包括如下3個組件:
分佈式跟蹤
Istio的分佈式跟蹤是基於Twitter開源的zipkin分佈式跟蹤系統,理論模型來自於Google Dapper 論文.
啓動zipkin
安裝Istio時會啓動zipkin addon,固然也可使用以下命令啓動:
kubectl apply -f install/kubernetes/addons/zipkin.yaml複製代碼
訪問zipkin
訪問zipkin dashboard: http://localhost:9411
kubectl port-forward $(kubectl get pod -l app=zipkin -o jsonpath='{.items[0].metadata.name}') 9411:9411複製代碼
在服務中enable trace
服務自己實現須要作必定的改動,即從最初始的HTTP請求中獲取如下header並傳遞給其餘的請求:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context複製代碼
啓用Ingress
在Kubernetes環境下, Istio使用了內置的Ingress來暴露服務,目前支持HTTP和HTTPS兩種方式. 具體的Ingress,參見Kubernetes Ingress.
配置HTTP服務
cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: simple-ingress
annotations:
kubernetes.io/ingress.class: istio
spec:
rules:
- http:
paths:
- path: /headers
backend:
serviceName: httpbin
servicePort: 8000
- path: /delay/.*
backend:
serviceName: httpbin
servicePort: 8000
EOF複製代碼
配置HTTPS服務
cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: secured-ingress
annotations:
kubernetes.io/ingress.class: istio
spec:
tls:
- secretName: ingress-secret
rules:
- http:
paths:
- path: /ip
backend:
serviceName: httpbin
servicePort: 8000
EOF複製代碼
啓用Egress
配置外部服務
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
name: externalbin
spec:
type: ExternalName
externalName: httpbin.org
ports:
- port: 80
# important to set protocol name
name: http
EOF複製代碼
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
name: securegoogle
spec:
type: ExternalName
externalName: www.google.com
ports:
- port: 443
# important to set protocol name
name: https
EOF複製代碼
其中, metadata.name 就是內部服務所須要訪問的外部服務的名稱, spec.externalName則是外部服務的DNS名稱.
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SOURCE_POD -c sleep bash
curl http://externalbin/headers
curl http://securegoogle:443複製代碼
直接訪問外部服務
kubectl apply -f <(istioctl kube-inject -f samples/apps/sleep/sleep.yaml --includeIPRanges=10.0.0.1/24)複製代碼
配置請求路由
默認配置下,Istio會將全部的請求路由到同一個服務的全部版本上.此外,Istio提供了根據請求內容的路由規則,以下規則描述了全部的請求都會指向服務的版本v1:
type: route-rule
name: ratings-default
namespace: default
spec:
destination: ratings.default.svc.cluster.local
precedence: 1
route:
- tags:
version: v1
weight: 100
---
type: route-rule
name: reviews-default
namespace: default
spec:
destination: reviews.default.svc.cluster.local
precedence: 1
route:
- tags:
version: v1
weight: 100
---
type: route-rule
name: details-default
namespace: default
spec:
destination: details.default.svc.cluster.local
precedence: 1
route:
- tags:
version: v1
weight: 100
---
type: route-rule
name: productpage-default
namespace: default
spec:
destination: productpage.default.svc.cluster.local
precedence: 1
route:
- tags:
version: v1
weight: 100
---複製代碼
若是須要將某些請求指向其餘版本的服務,如根據請求的cookie進行路由:
destination: reviews.default.svc.cluster.local
match:
httpHeaders:
cookie:
regex: ^(.*?;)?(user=jason)(;.*)?$
precedence: 2
route:
- tags:
version: v2複製代碼
其餘具體的規則,參見: https://istio.io/docs/reference/config/traffic-rules/routing-rules.html#routerule
錯誤注入
destination: ratings.default.svc.cluster.local
httpFault:
delay:
fixedDelay: 7s
percent: 100
match:
httpHeaders:
cookie:
regex: "^(.*?;)?(user=jason)(;.*)?$"
precedence: 2
route:
- tags:
version: v1複製代碼
設置請求超時
HTTP請求超時能夠經過在路由規則中設置字段httpReqTimeout實現.
具體例子以下:
cat <<EOF | istioctl replace
type: route-rule
name: reviews-default
spec:
destination: reviews.default.svc.cluster.local
route:
- tags:
version: v2
httpReqTimeout:
simpleTimeout:
timeout: 1s
EOF複製代碼
限流
在Istio的mixer中配置限流規則,以下ratelimit.yaml:
rules:
- selector: source.labels["app"]=="reviews" && source.labels["version"] == "v3"
- aspects:
- kind: quotas
params:
quotas:
- descriptorName: RequestCount
maxAmount: 5000
expiration: 5s
labels:
label1: target.service複製代碼
若是target.service=rating, 那麼計數器的key則爲:
$aspect_id;RequestCount;maxAmount=5000;expiration=5s;label1=ratings複製代碼
執行以下命令可使得rating服務的請求控制在每5秒5000次(限定在reviews v3服務在調用時生效):
istioctl mixer rule create global ratings.default.svc.cluster.local -f ratelimit.yaml複製代碼
簡單的訪問控制
使用denials屬性
rules:
- aspects:
- kind: denials
selector: source.labels["app"]=="reviews" && source.labels["version"] == "v3"複製代碼
執行以下命令可使rating服務拒絕來自reviews v3服務的任何請求.
使用黑白名單
- name: versionList
impl: genericListChecker
params:
listEntries: ["v1", "v2"]複製代碼
啓用白名單時blacklist設置爲false,反之爲true.
rules:
aspects:
- kind: lists
adapter: versionList
params:
blacklist: false
checkExpression: source.labels["version"]複製代碼
結論
相關文章
- 1. Istio服務網格
- 2. Istio旨在成爲容器化微服務的網格管道
- 3. Istio 服務網格中的網關
- 4. Istio服務網格的興起
- 5. Istio服務網格路由入門
- 6. Service Mesh服務網格新生代--Istio
- 7. 一文讀懂Istio服務網格
- 8. 服務網格Istio管理面板-Naftis
- 9. 阿里雲容器服務Istio初探
- 10. 如何使用Istio服務網格管理微服務
- 更多相關文章...
- • 服務器上的 XML - XML 教程
- • Git 服務器搭建 - Git 教程
- • Docker容器實戰(七) - 容器眼光下的文件系統
- • Docker容器實戰(六) - 容器的隔離與限制
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. Istio服務網格
- 2. Istio旨在成爲容器化微服務的網格管道
- 3. Istio 服務網格中的網關
- 4. Istio服務網格的興起
- 5. Istio服務網格路由入門
- 6. Service Mesh服務網格新生代--Istio
- 7. 一文讀懂Istio服務網格
- 8. 服務網格Istio管理面板-Naftis
- 9. 阿里雲容器服務Istio初探
- 10. 如何使用Istio服務網格管理微服務