本篇內(nèi)容介紹了“AWS App Mesh和Istio怎么配置”的有關(guān)知識,在實(shí)際案例的操作過程中,不少人都會(huì)遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
10年積累的成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作經(jīng)驗(yàn),可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你,你也不認(rèn)識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程,更有港閘免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
從官方的介紹來看,Istio和App Mesh都比較明確的表示自己是一種服務(wù)網(wǎng)格產(chǎn)品。Istio強(qiáng)調(diào)了自己在連接、安全、控制和可視化4個(gè)方面的能力;而App Mesh主要強(qiáng)調(diào)了一致的可見性和流量控制這兩方面能力,當(dāng)然也少不了強(qiáng)調(diào)作為云平臺(tái)下的產(chǎn)品的好處:托管服務(wù),無需自己維護(hù)。
從某種程度上講,Istio是一個(gè)相對重一點(diǎn)的解決方案,提供了不限于流量管理的各個(gè)方面的能力;而App Mesh是更加純粹的服務(wù)于運(yùn)行在AWS之上的應(yīng)用并提供流控功能。筆者認(rèn)為這和它目前的產(chǎn)品形態(tài)還不完善有關(guān)(后面會(huì)具體提到)。從與AWS內(nèi)部開發(fā)人員的溝通中可以感覺到,App Mesh應(yīng)該是一盤很大的棋,目前只是初期階段而已。
和AWS里很多產(chǎn)品一樣,App Mesh也不是獨(dú)創(chuàng),而是基于Envoy開發(fā)的。AWS這樣的閉環(huán)生態(tài)必然要對其進(jìn)行改進(jìn)和整合。同時(shí),也為了把它封裝成一個(gè)對外的服務(wù),提供適當(dāng)?shù)腁PI接口,在App Mesh這個(gè)產(chǎn)品中提出了下面幾個(gè)重要的技術(shù)術(shù)語,我們來一一介紹一下。
服務(wù)網(wǎng)格(Service mesh):服務(wù)間網(wǎng)絡(luò)流量的邏輯邊界。這個(gè)概念比較好理解,就是為使用App mesh的服務(wù)圈一個(gè)虛擬的邊界。
虛擬服務(wù)(Virtual services):是真實(shí)服務(wù)的抽象。真實(shí)服務(wù)可以是部署于抽象節(jié)點(diǎn)的服務(wù),也可以是間接的通過路由指向的服務(wù)。
虛擬節(jié)點(diǎn)(Virtual nodes):虛擬節(jié)點(diǎn)是指向特殊工作組(task group)的邏輯指針。例如AWS的ECS服務(wù),或者Kubernetes的Deployment??梢院唵蔚陌阉斫鉃槭俏锢砉?jié)點(diǎn)或邏輯節(jié)點(diǎn)的抽象。
Envoy:AWS改造后的Envoy(未來會(huì)合并到Envoy的官方版本),作為App Mesh里的數(shù)據(jù)平面,Sidecar代理。
虛擬路由器(Virtual routers):用來處理來自虛擬服務(wù)的流量。可以理解為它是一組路由規(guī)則的封裝。
路由(Routes):就是路由規(guī)則,用來根據(jù)這個(gè)規(guī)則分發(fā)請求。
上面的圖展示了這幾個(gè)概念的關(guān)系:當(dāng)用戶請求一個(gè)虛擬服務(wù)時(shí),服務(wù)配置的路由器根據(jù)路由策略將請求指向?qū)?yīng)的虛擬節(jié)點(diǎn),這些節(jié)點(diǎn)本質(zhì)上是AWS里的EKS或者ECS的節(jié)點(diǎn)。
那么這些App Mesh自創(chuàng)的術(shù)語是否能在Istio中找到相似甚至相同的對象呢?我歸納了下面的表格來做一個(gè)對比:
App Mesh | Istio |
---|---|
服務(wù)網(wǎng)格(Service mesh) | Istio并未顯示的定義這一概念,我們可以認(rèn)為在一個(gè)集群中,由Istio管理的服務(wù)集合,它們組成的網(wǎng)絡(luò)拓?fù)浼词欠?wù)網(wǎng)格。 |
虛擬服務(wù)(Virtual services) | Istio中也存在虛擬服務(wù)的概念。它的主要功能是定義路由規(guī)則,使請求可以根據(jù)這些規(guī)則被分發(fā)到對應(yīng)的服務(wù)。從這一點(diǎn)來說,它和App Mesh的虛擬服務(wù)的概念基本上是一致的。 |
虛擬節(jié)點(diǎn)(Virtual nodes) | Istio沒有虛擬節(jié)點(diǎn)的概念,可以認(rèn)為類似Kubernetes里的Deployment。 |
虛擬路由器(Virtual routers) | Istio也沒有虛擬路由器的概念。 |
路由(Routes) | Istio中的目標(biāo)規(guī)則(DestinationRule)和路由的概念類似,為路由設(shè)置一些策略。從配置層面講,其中的子集(subset)和App Mesh路由里選擇的目標(biāo)即虛擬節(jié)點(diǎn)對應(yīng)。但I(xiàn)stio的目標(biāo)規(guī)則更加靈活,也支持更多的路由策略。 |
從上面的對比看出,App Mesh目前基本上實(shí)現(xiàn)了最主要的流量控制(路由)的功能,但像超時(shí)重試、熔斷、流量復(fù)制等高級一些的功能還沒有提供,有待進(jìn)一步完善。
AWS App Mesh是一個(gè)商業(yè)產(chǎn)品,目前還沒有找到架構(gòu)上的技術(shù)細(xì)節(jié),不過我們依然可以從現(xiàn)有的、公開的文檔或介紹中發(fā)現(xiàn)一些有用的信息。
從這張官網(wǎng)的結(jié)構(gòu)圖中可以看出,每個(gè)服務(wù)的橙色部分就是Sidecar代理:Envoy。而中間的AWS App Mesh其實(shí)就是控制平面,用來控制服務(wù)間的交互。那么這個(gè)控制平面具體的功能是什么呢?我們可以從今年的AWS Summit的一篇PPT中看到這樣的字樣:
控制平面用來把邏輯意圖轉(zhuǎn)換成代理配置,并進(jìn)行分發(fā)。
熟悉Istio架構(gòu)的朋友有沒有覺得似曾相識?沒錯(cuò),這個(gè)控制平面的職責(zé)和Pilot基本一致。由此可見,不管什么產(chǎn)品的控制平面,也必須具備這些核心的功能。
那么在平臺(tái)的支持方面呢?下面這張圖展示了App Mesh可以被運(yùn)行在如下的基礎(chǔ)設(shè)施中,包括EKS、ECS、EC2等等。當(dāng)然,這些都必須存在于AWS這個(gè)閉環(huán)生態(tài)中。
而Istio這方面就相對弱一些。盡管Istio宣稱是支持多平臺(tái)的,但目前來看和Kubernetes還是強(qiáng)依賴。不過它并不受限于單一的云平臺(tái),這一點(diǎn)有較大的優(yōu)勢。
從可觀測性來看,App Mesh依然發(fā)揮了自家生態(tài)的優(yōu)勢,可以方便的接入CloudWatch、X-Ray對服務(wù)進(jìn)行觀測。另外,App Mesh也提供了更大的靈活性,可以在虛擬節(jié)點(diǎn)里配置服務(wù)后端(可以是虛擬服務(wù)或者ARN),流量可以出站到這些配置的服務(wù)。這一點(diǎn)來說,和Istio的Mixer又有了異曲同工之妙。Mixer通過插件方式為Istio提供了極大的可擴(kuò)展性,App Mesh在這一點(diǎn)上也不算落下風(fēng)。
Istio的架構(gòu)大家都非常熟悉了,這里就不再贅述了,感興趣的同學(xué)可以直接去官網(wǎng)查看。
Istio部署后類似一個(gè)網(wǎng)一樣附著在你的Kubernetes集群上, 控制平面會(huì)使用你設(shè)置的資源;而App Mesh是一種托管方式,只會(huì)使用Envoy代理。完整安裝后的Istio需要添加50個(gè)左右的CRD,而App Mesh只添加了3個(gè)CRD:meshes.appmesh.k8s.aws
,virtualnodes.appmesh.k8s.aws
和virtualservices.appmesh.k8s.aws
。這一點(diǎn)也反映出了功能上的區(qū)別。
盡管兩者的數(shù)據(jù)平面都是基于Envoy,但它們提供的流量控制能力目前還是有比較大的差距的。在路由的設(shè)置方面,App Mesh提供了相對比較豐富的匹配策略,基本能滿足大部分使用場景。下面是App Mesh控制臺(tái)里的路由配置截圖,可以看出,除了基本的URI前綴、HTTP Method和Scheme外,也支持請求頭的匹配。
Istio的匹配策略更加完善,除了上面提到的,還包括HTTP Authority,端口匹配,請求參數(shù)匹配等,具體信息可以從官方文檔的虛擬服務(wù)設(shè)置查看。下面兩段yaml分別展示了兩個(gè)產(chǎn)品在虛擬服務(wù)配置上的差異。
App Mesh配置:
apiVersion: appmesh.k8s.aws/v1beta1 kind: VirtualService metadata: name: my-svc-a namespace: my-namespace spec: meshName: my-mesh routes: - name: route-to-svc-a http: match: prefix: / action: weightedTargets: - virtualNodeName: my-app-a weight: 1
Istio配置:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings-route spec: hosts: - ratings.prod.svc.cluster.local http: - match: - headers: end-user: exact: jason uri: prefix: "/ratings/v2/" ignoreUriCase: true route: - destination: host: ratings.prod.svc.cluster.local
另外一個(gè)比較大的不同是,App Mesh需要你對不同版本的服務(wù)分開定義(即定義成不同的虛擬服務(wù)),而Istio是通過目標(biāo)規(guī)則 DestinationRule
里的子集 subsets
和路由配置做的關(guān)聯(lián)。本質(zhì)上它們沒有太大區(qū)別。
除了路由功能外,App Mesh就顯得捉襟見肘了。就在筆者撰寫本文時(shí),AWS剛剛添加了重試功能。而Istio借助于強(qiáng)大的Envoy,提供了全面的流量控制能力,如超時(shí)重試、故障注入、熔斷、流量鏡像等。
在安全方面,兩者的實(shí)現(xiàn)方式具有較大區(qū)別。默認(rèn)情況下,一個(gè)用戶不能直接訪問App Mesh的資源,需要通過AWS的IAM策略給用戶授權(quán)。比如下面的配置是容許用戶用任意行為去操作網(wǎng)格內(nèi)的任意資源:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appmesh:*" ], "Resource": "*" } ] }
而虛擬節(jié)點(diǎn)間的授權(quán)方面,App Mesh目前只有TLS訪問的支持,且僅僅是預(yù)覽版(Preview)并未正式發(fā)布。下面的配置展示了一個(gè)虛擬節(jié)點(diǎn)只容許tls
方式的訪問:
{ "meshName" : "app1", "spec" : { "listeners" : [ { "portMapping" : { "port" : 80, "protocol" : "http" }, "tls" : { "mode" : "STRICT", "certificate" : { "acm" : { "certificateArn" : "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012" } } } } ], "serviceDiscovery" : { "DNS" : { "hostname" : "serviceBv1.mesh.local" } } }, "virtualNodeName" : "serviceBv1" }
而Istio中端到端的認(rèn)證是支持mTLS的,同時(shí)還支持JWT的用戶身份認(rèn)證。下面的配置分別展示了這兩種認(rèn)證方式:
apiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata: name: "reviews" spec: targets: - name: reviews peers: - mtls: {} origins: - jwt: issuer: "https://accounts.google.com" jwksUri: "https://www.googleapis.com/oauth3/v3/certs" trigger_rules: - excluded_paths: - exact: /health
Istio的授權(quán)是通過RBAC實(shí)現(xiàn)的,可以提供基于命名空間、服務(wù)和HTTP方法級別的訪問控制。這里就不具體展示了,大家可以通過官網(wǎng)文檔來查看。
一般來說,可以通過三種方式來觀察你的應(yīng)用:指標(biāo)數(shù)據(jù)、分布式追蹤、日志。Istio在這三個(gè)方面都有比較完整的支持。指標(biāo)方面,可以通過Envoy獲取請求相關(guān)的數(shù)據(jù),同時(shí)還提供了服務(wù)級別的指標(biāo),以及控制平面的指標(biāo)來檢測各個(gè)組件的運(yùn)行情況。通過內(nèi)置的Prometheus來收集指標(biāo),并使用Grafana展示出來。分布式追蹤也支持各種主流的OpenTracing工具,如Jaeger、Zipkin等。訪問日志一般都通過ELK去完成收集、分析和展示。另外,Istio還擁有Kiali這樣的可視化工具,給你提供整個(gè)網(wǎng)格以及微服務(wù)應(yīng)用的拓?fù)湟晥D??傮w來說,Istio在可觀察方面的能力是非常強(qiáng)大的,這主要是因?yàn)镸ixer組件的插件特性帶來了巨大的靈活性。
App Mesh在這方面做的也不錯(cuò)。在如下圖虛擬節(jié)點(diǎn)的配置中可以看到,你可以配置服務(wù)的后端基礎(chǔ)設(shè)施,這樣流量就可以出站到這些服務(wù)。同時(shí),在日志收集方面,也可以配置到本地日志,或者是其他的日志系統(tǒng)。
另一方面,AWS又一次發(fā)揮了自己閉環(huán)生態(tài)的優(yōu)勢,提供了App Mesh與自家的CloudWatch、X-Ray這兩個(gè)監(jiān)控工具的整合??偟膩碚f,App Mesh在可觀察性上也不落下風(fēng)。
“AWS App Mesh和Istio怎么配置”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
新聞名稱:AWSAppMesh和Istio怎么配置
當(dāng)前地址:http://jinyejixie.com/article6/ipggig.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、企業(yè)建站、外貿(mào)網(wǎng)站建設(shè)、ChatGPT、移動(dòng)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)