AWSAppMesh和Istio怎么配置

本篇內(nèi)容介紹了“AWS App Mesh和Istio怎么配置”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

10年積累的成都網(wǎng)站設(shè)計、網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有港閘免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

概念

產(chǎn)品定位

從官方的介紹來看，Istio和App Mesh都比較明確的表示自己是一種服務(wù)網(wǎng)格產(chǎn)品。Istio強(qiáng)調(diào)了自己在連接、安全、控制和可視化4個方面的能力；而App Mesh主要強(qiáng)調(diào)了一致的可見性和流量控制這兩方面能力，當(dāng)然也少不了強(qiáng)調(diào)作為云平臺下的產(chǎn)品的好處：托管服務(wù)，無需自己維護(hù)。

從某種程度上講，Istio是一個相對重一點(diǎn)的解決方案，提供了不限于流量管理的各個方面的能力；而App Mesh是更加純粹的服務(wù)于運(yùn)行在AWS之上的應(yīng)用并提供流控功能。筆者認(rèn)為這和它目前的產(chǎn)品形態(tài)還不完善有關(guān)（后面會具體提到）。從與AWS內(nèi)部開發(fā)人員的溝通中可以感覺到，App Mesh應(yīng)該是一盤很大的棋，目前只是初期階段而已。

核心術(shù)語

和AWS里很多產(chǎn)品一樣，App Mesh也不是獨(dú)創(chuàng)，而是基于Envoy開發(fā)的。AWS這樣的閉環(huán)生態(tài)必然要對其進(jìn)行改進(jìn)和整合。同時，也為了把它封裝成一個對外的服務(wù)，提供適當(dāng)?shù)腁PI接口，在App Mesh這個產(chǎn)品中提出了下面幾個重要的技術(shù)術(shù)語，我們來一一介紹一下。

• 服務(wù)網(wǎng)格（Service mesh）：服務(wù)間網(wǎng)絡(luò)流量的邏輯邊界。這個概念比較好理解，就是為使用App mesh的服務(wù)圈一個虛擬的邊界。

• 虛擬服務(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（未來會合并到Envoy的官方版本），作為App Mesh里的數(shù)據(jù)平面，Sidecar代理。

• 虛擬路由器（Virtual routers）：用來處理來自虛擬服務(wù)的流量?？梢岳斫鉃樗且唤M路由規(guī)則的封裝。

• 路由（Routes）：就是路由規(guī)則，用來根據(jù)這個規(guī)則分發(fā)請求。

上面的圖展示了這幾個概念的關(guān)系：當(dāng)用戶請求一個虛擬服務(wù)時，服務(wù)配置的路由器根據(jù)路由策略將請求指向?qū)?yīng)的虛擬節(jié)點(diǎn)，這些節(jié)點(diǎn)本質(zhì)上是AWS里的EKS或者ECS的節(jié)點(diǎn)。

那么這些App Mesh自創(chuàng)的術(shù)語是否能在Istio中找到相似甚至相同的對象呢？我歸納了下面的表格來做一個對比：

App Mesh	Istio
服務(wù)網(wǎng)格（Service mesh）	Istio并未顯示的定義這一概念，我們可以認(rèn)為在一個集群中，由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)了最主要的流量控制（路由）的功能，但像超時重試、熔斷、流量復(fù)制等高級一些的功能還沒有提供，有待進(jìn)一步完善。

架構(gòu)

AWS App Mesh是一個商業(yè)產(chǎn)品，目前還沒有找到架構(gòu)上的技術(shù)細(xì)節(jié)，不過我們依然可以從現(xiàn)有的、公開的文檔或介紹中發(fā)現(xiàn)一些有用的信息。

從這張官網(wǎng)的結(jié)構(gòu)圖中可以看出，每個服務(wù)的橙色部分就是Sidecar代理：Envoy。而中間的AWS App Mesh其實(shí)就是控制平面，用來控制服務(wù)間的交互。那么這個控制平面具體的功能是什么呢？我們可以從今年的AWS Summit的一篇PPT中看到這樣的字樣：

控制平面用來把邏輯意圖轉(zhuǎn)換成代理配置，并進(jìn)行分發(fā)。

熟悉Istio架構(gòu)的朋友有沒有覺得似曾相識？沒錯，這個控制平面的職責(zé)和Pilot基本一致。由此可見，不管什么產(chǎn)品的控制平面，也必須具備這些核心的功能。

那么在平臺的支持方面呢？下面這張圖展示了App Mesh可以被運(yùn)行在如下的基礎(chǔ)設(shè)施中，包括EKS、ECS、EC2等等。當(dāng)然，這些都必須存在于AWS這個閉環(huán)生態(tài)中。

而Istio這方面就相對弱一些。盡管Istio宣稱是支持多平臺的，但目前來看和Kubernetes還是強(qiáng)依賴。不過它并不受限于單一的云平臺，這一點(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)查看。

功能與實(shí)現(xiàn)方式

部署

Istio部署后類似一個網(wǎng)一樣附著在你的Kubernetes集群上， 控制平面會使用你設(shè)置的資源；而App Mesh是一種托管方式，只會使用Envoy代理。完整安裝后的Istio需要添加50個左右的CRD，而App Mesh只添加了3個CRD：meshes.appmesh.k8s.aws，virtualnodes.appmesh.k8s.aws和virtualservices.appmesh.k8s.aws。這一點(diǎn)也反映出了功能上的區(qū)別。

流量控制

盡管兩者的數(shù)據(jù)平面都是基于Envoy，但它們提供的流量控制能力目前還是有比較大的差距的。在路由的設(shè)置方面，App Mesh提供了相對比較豐富的匹配策略，基本能滿足大部分使用場景。下面是App Mesh控制臺里的路由配置截圖，可以看出，除了基本的URI前綴、HTTP Method和Scheme外，也支持請求頭的匹配。

Istio的匹配策略更加完善，除了上面提到的，還包括HTTP Authority，端口匹配，請求參數(shù)匹配等，具體信息可以從官方文檔的虛擬服務(wù)設(shè)置查看。下面兩段yaml分別展示了兩個產(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

另外一個比較大的不同是，App Mesh需要你對不同版本的服務(wù)分開定義（即定義成不同的虛擬服務(wù)），而Istio是通過目標(biāo)規(guī)則 DestinationRule 里的子集 subsets 和路由配置做的關(guān)聯(lián)。本質(zhì)上它們沒有太大區(qū)別。

除了路由功能外，App Mesh就顯得捉襟見肘了。就在筆者撰寫本文時，AWS剛剛添加了重試功能。而Istio借助于強(qiáng)大的Envoy，提供了全面的流量控制能力，如超時重試、故障注入、熔斷、流量鏡像等。

安全

在安全方面，兩者的實(shí)現(xiàn)方式具有較大區(qū)別。默認(rèn)情況下，一個用戶不能直接訪問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ā)布。下面的配置展示了一個虛擬節(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的，同時還支持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在這三個方面都有比較完整的支持。指標(biāo)方面，可以通過Envoy獲取請求相關(guān)的數(shù)據(jù)，同時還提供了服務(wù)級別的指標(biāo)，以及控制平面的指標(biāo)來檢測各個組件的運(yùn)行情況。通過內(nèi)置的Prometheus來收集指標(biāo)，并使用Grafana展示出來。分布式追蹤也支持各種主流的OpenTracing工具，如Jaeger、Zipkin等。訪問日志一般都通過ELK去完成收集、分析和展示。另外，Istio還擁有Kiali這樣的可視化工具，給你提供整個網(wǎng)格以及微服務(wù)應(yīng)用的拓?fù)湟晥D?？傮w來說，Istio在可觀察方面的能力是非常強(qiáng)大的，這主要是因為Mixer組件的插件特性帶來了巨大的靈活性。

App Mesh在這方面做的也不錯。在如下圖虛擬節(jié)點(diǎn)的配置中可以看到，你可以配置服務(wù)的后端基礎(chǔ)設(shè)施，這樣流量就可以出站到這些服務(wù)。同時，在日志收集方面，也可以配置到本地日志，或者是其他的日志系統(tǒng)。

另一方面，AWS又一次發(fā)揮了自己閉環(huán)生態(tài)的優(yōu)勢，提供了App Mesh與自家的CloudWatch、X-Ray這兩個監(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://muchs.cn/article6/ipggig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、企業(yè)建站、外貿(mào)網(wǎng)站建設(shè)、ChatGPT、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)