AWS App Mesh和Istio怎么配置

本篇內容介紹了“AWS App Mesh和Istio怎么配置”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

概念

產品定位

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

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

核心術語

和AWS里很多產品一樣，App Mesh也不是獨創，而是基于Envoy開發的。AWS這樣的閉環生態必然要對其進行改進和整合。同時，也為了把它封裝成一個對外的服務，提供適當的API接口，在App Mesh這個產品中提出了下面幾個重要的技術術語，我們來一一介紹一下。

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

• 虛擬服務（Virtual services）：是真實服務的抽象。真實服務可以是部署于抽象節點的服務，也可以是間接的通過路由指向的服務。

• 虛擬節點（Virtual nodes）：虛擬節點是指向特殊工作組（task group）的邏輯指針。例如AWS的ECS服務，或者Kubernetes的Deployment。可以簡單的把它理解為是物理節點或邏輯節點的抽象。

• Envoy：AWS改造后的Envoy（未來會合并到Envoy的官方版本），作為App Mesh里的數據平面，Sidecar代理。

• 虛擬路由器（Virtual routers）：用來處理來自虛擬服務的流量。可以理解為它是一組路由規則的封裝。

• 路由（Routes）：就是路由規則，用來根據這個規則分發請求。

上面的圖展示了這幾個概念的關系：當用戶請求一個虛擬服務時，服務配置的路由器根據路由策略將請求指向對應的虛擬節點，這些節點本質上是AWS里的EKS或者ECS的節點。

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

從上面的對比看出，App Mesh目前基本上實現了最主要的流量控制（路由）的功能，但像超時重試、熔斷、流量復制等高級一些的功能還沒有提供，有待進一步完善。

架構

AWS App Mesh是一個商業產品，目前還沒有找到架構上的技術細節，不過我們依然可以從現有的、公開的文檔或介紹中發現一些有用的信息。

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

控制平面用來把邏輯意圖轉換成代理配置，并進行分發。

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

那么在平臺的支持方面呢？下面這張圖展示了App Mesh可以被運行在如下的基礎設施中，包括EKS、ECS、EC2等等。當然，這些都必須存在于AWS這個閉環生態中。

而Istio這方面就相對弱一些。盡管Istio宣稱是支持多平臺的，但目前來看和Kubernetes還是強依賴。不過它并不受限于單一的云平臺，這一點有較大的優勢。

從可觀測性來看，App Mesh依然發揮了自家生態的優勢，可以方便的接入CloudWatch、X-Ray對服務進行觀測。另外，App Mesh也提供了更大的靈活性，可以在虛擬節點里配置服務后端（可以是虛擬服務或者ARN），流量可以出站到這些配置的服務。這一點來說，和Istio的Mixer又有了異曲同工之妙。Mixer通過插件方式為Istio提供了極大的可擴展性，App Mesh在這一點上也不算落下風。

Istio的架構大家都非常熟悉了，這里就不再贅述了，感興趣的同學可以直接去官網查看。

功能與實現方式

部署

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

流量控制

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

Istio的匹配策略更加完善，除了上面提到的，還包括HTTP Authority，端口匹配，請求參數匹配等，具體信息可以從官方文檔的虛擬服務設置查看。下面兩段yaml分別展示了兩個產品在虛擬服務配置上的差異。

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需要你對不同版本的服務分開定義（即定義成不同的虛擬服務），而Istio是通過目標規則 DestinationRule 里的子集 subsets 和路由配置做的關聯。本質上它們沒有太大區別。

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

安全

在安全方面，兩者的實現方式具有較大區別。默認情況下，一個用戶不能直接訪問App Mesh的資源，需要通過AWS的IAM策略給用戶授權。比如下面的配置是容許用戶用任意行為去操作網格內的任意資源：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "appmesh:*"
            ],
            "Resource": "*"
        }
    ]
}

而虛擬節點間的授權方面，App Mesh目前只有TLS訪問的支持，且僅僅是預覽版（Preview）并未正式發布。下面的配置展示了一個虛擬節點只容許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中端到端的認證是支持mTLS的，同時還支持JWT的用戶身份認證。下面的配置分別展示了這兩種認證方式：

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的授權是通過RBAC實現的，可以提供基于命名空間、服務和HTTP方法級別的訪問控制。這里就不具體展示了，大家可以通過官網文檔來查看。

可觀察性

一般來說，可以通過三種方式來觀察你的應用：指標數據、分布式追蹤、日志。Istio在這三個方面都有比較完整的支持。指標方面，可以通過Envoy獲取請求相關的數據，同時還提供了服務級別的指標，以及控制平面的指標來檢測各個組件的運行情況。通過內置的Prometheus來收集指標，并使用Grafana展示出來。分布式追蹤也支持各種主流的OpenTracing工具，如Jaeger、Zipkin等。訪問日志一般都通過ELK去完成收集、分析和展示。另外，Istio還擁有Kiali這樣的可視化工具，給你提供整個網格以及微服務應用的拓撲視圖。總體來說，Istio在可觀察方面的能力是非常強大的，這主要是因為Mixer組件的插件特性帶來了巨大的靈活性。

App Mesh在這方面做的也不錯。在如下圖虛擬節點的配置中可以看到，你可以配置服務的后端基礎設施，這樣流量就可以出站到這些服務。同時，在日志收集方面，也可以配置到本地日志，或者是其他的日志系統。

另一方面，AWS又一次發揮了自己閉環生態的優勢，提供了App Mesh與自家的CloudWatch、X-Ray這兩個監控工具的整合。總的來說，App Mesh在可觀察性上也不落下風。

“AWS App Mesh和Istio怎么配置”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！