Google Cloud 服務網格:Traffic Director 與 Anthos Service Mesh 的左右互搏

2021-02-15 ServiceMesher

作為開源 Service Mesh 明星項目 Istio 背後的主要廠商，Google 也在其公有雲上推出了 Service Mesh 管理服務。讓人迷惑的是 Google Cloud 上有兩個 Service Mesh 產品：Traffic Director 與 Anthos Service Mesh。Google Cloud 首先在 2019 年 3 月發布了其第一個 Service Mesh 產品 Traffic Director，隨後不久在 2019 年 9 月緊接著發布了另一個 Service Mesh 產品 Anthos Service Mesh，隨後兩個產品獨立並行發展，直到如今。

Google Cloud 同時推出兩個 Service Mesh 產品的原因是什麼？這兩個產品的定位有何不同？本文將分別分析這兩個產品的架構和功能，以試圖解答該疑問。

Traffic Director

Traffic Director 是 Google Cloud 專為服務網格打造的全託管式流量控制平面，用戶不需要對 Traffic Director 進行部署，維護和管理。我們可以把 Traffic Director 看作一個託管的 Pilot（備註：並不確定其內部是否使用的 Pilot），其只提供了流量管理能力，不提供 Istio 控制面的其他能力。用戶可以使用 Traffic Director 創建跨區域的、同時支持集群和虛擬機實例的服務網格，並對多個集群和虛擬機的工作負載進行統一的流量控制。Traffic Director 託管控制面 提供了跨地域容災能力，可以保證 99.99% 的 SLA。

總而言之，Traffic Director 的關鍵特性包括：

• 全託管控制面• 控制面高可用• 同時支持 K8s 集群和虛擬機• 跨地域的流量管理

Traffic Director 架構

Traffic Director 的總體架構和 Istio 類似，也採用了 「控制面 + 數據面」 的結構，控制面託管在 Google Cloud 中，對用戶不可見。用戶只需要在創建 project 時啟用 Traffic Director API，即可使用 Traffic Director 提供的網格服務。數據面則採用了和 Istio 相同的 Envoy 作為 proxy。控制面和數據面採用標準的 xDS v2 進行通信。控制面對外採用了一套自定義的 API 來實現流量管理，並不支持 Istio API。Traffic Director 也沒有採用 Istio/K8s 的服務發現，而是採用了一套 Google Cloud 自己的服務註冊發現機制，該服務註冊發現機制以統一的模型同時支持了容器和虛擬機上的服務，並為工作負載提供了健康檢測。

Traffic Director 架構

Traffic Director 架構服務註冊發現機制

Traffic Director 採用了 Google Cloud 的一種稱為 Backend Service 的服務註冊機制。通過 Backend Service 支持了 GKE 集群中容器工作負載和虛擬機工作負載兩種方式的服務註冊發現，不過和 Istio 不同的是，Traffic Director 並不支持 K8s 原生的服務註冊發現機制。

服務註冊發現資源模型

Traffic Director 的服務註冊發現資源模型如下圖所示，圖中藍色的圖形為 Traffic Director 中使用的資源，桔色的圖形為這些資源對應在 K8s 中的概念。Backend Service 是一個邏輯服務，可以看作 K8s 中的 Service，Backend Service 中可以包含 GKE 集群中的 NEG （Network Endpoint Group），GCE 虛擬機 的 MIG （Managed Instance Group），或者無服務的 NEG 。NEG 中則是具體的一個個工作負載，即服務實例。

Traffic Director 服務發現資源模型

img

Google Cloud 的這一套服務註冊的機制並不只是為 Traffic Director 而定製的，還可以和 Google Cloud 上的各種負載均衡服務一起使用，作為負載均衡的後端。熟悉 K8s 的同學應該清楚，進入 K8s 集群的流量經過 Load Balancer 後會被首先發送到一個 node 的 nodeport 上，然後再通過 DNAT 轉發到 Service 後端的一個 Pod IP 上。Google Cloud 在 cluster 上提供了一個 VPC native[1] 的網絡特性，可以在 VPC 中直接路由 Pod ，在打開 VPC native 特性的集群中，通過將 NEG 而不是 K8s service 放到 Load balancer 後端，可以跳過 Kubeproxy iptables 轉發這一跳，直接將流量發送到 Pod，降低轉發延遲，並可以應用更靈活的 LB 和路由算法。

雖然 Backend Service 已經支持了無服務 NEG，但目前 Traffic Director 還不支持，但從資源模型的角度來看，應該很容易擴展目前的功能，以將無服務工作負載加入到服務網格中。

下面舉例說明如何創建 Backend Service，並將 GKE 和 VM 中運行的服務實例加入到 Backend Service 中，以了解相關資源的內部結構。

註冊 GKE 集群中的容器服務

1、 創建 GKE NEG：在 K8s Service 的 yaml 定義中通過 annotation 創建 NEG

img

2、 創建防火牆規則：需要創建一條防火牆規則，以允許 gcloud 對 GKE NEG 中的服務實例進行健康檢查

gcloud compute firewall-rules create fw-allow-health-checks \    --action ALLOW \      --direction INGRESS \      --source-ranges 35.191.0.0/16,130.211.0.0/22 \      --rules tcp
3、創建健康檢查
gcloud compute health-checks create http td-gke-health-check \    --use-serving-port
4、創建 Backend Service，創建時需要指定上一步創建的健康檢查
gcloud compute backend-services create td-gke-service \   --global \   --health-checks td-gke-health-check \   --load-balancing-scheme INTERNAL_SELF_MANAGED
5、將 GKE NEG 加入到上一步創建的 Backend service 中
NEG_NAME=$(gcloud beta compute network-endpoint-groups list \| grep service-test | awk '{print $1}')gcloud compute backend-services add-backend td-gke-service \   --global \   --network-endpoint-group ${NEG_NAME} \   --network-endpoint-group-zone us-central1-a \   --balancing-mode RATE \   --max-rate-per-endpoint 5
註冊 GCE 虛擬機服務
1、 創建虛機模版：在創建模版時可以通過命令參數 –service-proxy=enabled 聲明使用該模版創建的虛擬機需要安裝 Envoy sidecar 代理
gcloud beta compute instance-templates create td-vm-template-auto \      --service-proxy=enabled
2、 創建 MIG：使用虛擬機模版創建一個 managed instance group，該 group 中的實例數為 2
gcloud compute instance-groups managed create td-vm-mig-us-central1 \      --zone us-central1-a   --size=2   --template=td-vm-template-auto
3、 創建防火牆規則
gcloud compute firewall-rules create fw-allow-health-checks \    --action ALLOW \    --direction INGRESS \    --source-ranges 35.191.0.0/16,130.211.0.0/22 \    --target-tags td-http-server \    --rules tcp:80
4、 創建健康檢查
gcloud compute health-checks create http td-vm-health-check
5、 創建 Backend Service，創建時需要指定上一步創建的健康檢查
gcloud compute backend-services create td-vm-service \   --global \   --load-balancing-scheme=INTERNAL_SELF_MANAGED \   --connection-draining-timeout=30s \   --health-checks td-vm-health-check
6、 將 MIG 加入到上一步創建的 Backend service 中
gcloud compute backend-services add-backend td-vm-service \    --instance-group td-demo-hello-world-mig \    --instance-group-zone us-central1-a \    --global
流量管理實現原理
Traffic Diretor 的主要功能就是跨地域的全局流量管理能力，該能力是建立在 Google Cloud 強大的 VPC 機制基礎上的， Google Cloud 的 VPC 可以跨越多個 Region，因此一個 VPC 中的服務網格中可以有來自多個 Region 的服務。另外 Traffic Director 並未直接採用 Istio 的 API，而是自定義了一套 API 來對網格中的流量進行管理。
控制面流量規則定義
Traffic Director 流量規則相關的控制面資源模型如下圖所示，圖中下半部分是 Istio 中和這些資源對應的 CRD。
•Forwarding Rule：定義服務的入口 VIP 和 Port。•Target Proxy：用於關聯 Forwarding Rule 和 URL Map，可以看作網格中代理的一個資源抽象。•URL Map：用於設置路由規則，包括規則匹配條件和規則動作兩部分。匹配條件支持按照 HTTP 的 Host、Path、Header 進行匹配。匹配後可以執行 Traffic Splitting、Redirects、URL Rewrites、Traffic Mirroring、Fault Injection、Header Transformation 等動作。•Backend Service：前面在服務發現中已經介紹了 Backend Service 用於服務發現，其實還可以在 Backen Service 上設置流量策略，包括 LB 策略，斷路器配置，實例離線檢測等。可以看到 Backend Service 在 Traffic Director 的流量管理模型中同時承擔了 Istio 中的 ServiceEntry 和 Destionation Rule 兩個資源等功能。
客戶端直接通過 VIP 訪問服務其實是一個不太友好的方式，因此我們還需要通過一個 DNS 服務將 Forwarding Rule 中的 VIP 和一個 DNS record 關聯起來，在 Google Cloud 中可以採用 Cloud DNS[2] 來將 Forwarding Rule 的 VIP 關聯到一個內部的全局 DNS 名稱上。
Traffic Director 流量管理資源模型
img
下面舉例說明這些資源的定義，以及它們是如何相互作用，以實現 Service Mesh 中的流量管理。
下圖中的 forwarding rule 定義了一個暴露在 10.0.0.1:80 上的服務，該服務對應的 url map 定義了兩條路由規則，對應的主機名分別為 * 和 hello-worold，請求將被路由到後端的 td-vm-service backend service 中的服務實例。
img
Forwarding Rule 定義
img
Target Proxy 定義
img
URL Map 定義
img
Backend Service 定義
img
Managed Instance Group 定義
img數據面 Sidecar 配置
Traffic Director 將服務發現信息和路由規則轉換為 Envoy 配置，通過 xDS 下發到 Envoy sidecar，控制面規則和數據面配置的對應關係下：
Forwarding Rule    ->    Envoy ListenerURL Map            ->    Envoy RouteBackend Service    ->    Envoy ClusterNEG/MIG            ->    Envoy endpoint
Listener 配置
Listener 中的 Http Connection Manager filter 配置定義了 IP+Port 層面的入口，這裡只接受 Forwarding Rule 中指定的 VIP 10.0.0.1。我們也可以在 Forwarding Rule 中將 VIP 設置為 0.0.0.0，這樣的話任何目的 IP 的請求都可以處理。
img
Route 配置
img
Cluster 配置
img高級流量規則
在 URL Map 中設置 Traffic Splitting
    hostRules:    - description: ''     hosts:      - '*'    pathMatcher: matcher1    pathMatchers:    - defaultService: global/backendServices/review1      name: matcher1      routeRules:      - priority: 2        matchRules:        - prefixMatch: ''        routeAction:         weightedBackendServices:         - backendService: global/backendServices/review1           weight: 95         - backendService: global/backendServices/review2           weight: 5
在 Backend Service 中設置 Circuit Breaker
 affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION   capacityScaler: 1.0    group:https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/zones/<var>ZONE</var>/instanceGroups/<var>INSTANCE_GROUP_NAME</var>   maxUtilization: 0.8 circuitBreakers:   maxConnections: 1000   maxPendingRequests: 200   maxRequests: 1000   maxRequestsPerConnection: 100   maxRetries: 3 connectionDraining:   drainingTimeoutSec: 300 healthChecks:   - https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/healthChecks/<var>HEALTH_CHECK_NAME</var> loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: <var>BACKEND_SERVICE_NAME</var> port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30
從這兩個規則的定義可以看出，雖然文件結構有所差異，但實際上 Traffic Director yaml 路由規則的定義和 Istio 非常相似。
與 Istio 相比，Traffic Director 的流量管理機制更為靈活，可以在 Mesh 中同時接入 K8s 集群和虛擬機中的工作負載。但 Traffic Director 需要手動進行較多的配置才能對服務進行管理，包括 backend service，forwarding rule，url map 和 DNS，而在 Istio 中，如果不需要進行特殊的路由和流量策略，這些配置都是不需要手動進行的，pilot 會自動創建默認配置。
Sidecar Proxy 部署機制
Traffic Director 數據面採用了和 Istio 相同的機制，通過 Iptables 規則將應用服務的出入流量重定向到 Envoy sidecar，由 Envoy 進行流量路由。Traffic Director 採用了下面的方式來在 K8s 集群的 Pod 或者虛擬機中安裝數據面組件。
VM 手動部署
通過腳本從 gcloud 上下載 envoy 二機制，並安裝 iptables 流量攔截規則，啟動 envoy。
# Add a system user to run Envoy binaries. Login is disabled for this usersudo adduser --system --disabled-login envoy# Download and extract the Traffic Director tar.gz file# 下載traffic director相關文件sudo wget -P /home/envoy https://storage.googleapis.com/traffic-director/traffic-director.tar.gzsudo tar -xzf /home/envoy/traffic-director.tar.gz -C /home/envoy#下載 Envoy 的初始化配置，配置中包含了控制面traffic director的地址sudo wget -O - https://storage.googleapis.com/traffic-director/demo/observability/envoy_stackdriver_trace_config.yaml >> /home/envoy/traffic-director/bootstrap_template.yaml# 設置iptables流量攔截規則的相關參數sudo cat << END > /home/envoy/traffic-director/sidecar.envENVOY_USER=envoy# Exclude the proxy user from redirection so that traffic doesn't loop back# to the proxyEXCLUDE_ENVOY_USER_FROM_INTERCEPT='true'# Intercept all traffic by defaultSERVICE_CIDR='10.10.10.0/24'GCP_PROJECT_NUMBER='${GCP_PROJECT_NUMBER}'VPC_NETWORK_NAME=''ENVOY_PORT='15001'ENVOY_ADMIN_PORT='15000'LOG_DIR='/var/log/envoy/'LOG_LEVEL='info'XDS_SERVER_CERT='/etc/ssl/certs/ca-certificates.crt'TRACING_ENABLED='true'ACCESSLOG_PATH='/var/log/envoy/access.log'ENDsudo apt-get update -ysudo apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common -ysudo curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -sudo add-apt-repository 'deb [arch=amd64] https://download.docker.com/linux/debian stretch stable' -ysudo apt-get update -ysudo apt-get install docker-ce -y#下載envoy二機制sudo /home/envoy/traffic-director/pull_envoy.sh#設置iptables規則，啟動envoysudo /home/envoy/traffic-director/run.sh start"
VM 自動部署
在創建虛擬機模版時添加注入 proxy 的參數，可以在 VM 中自動部署 Envoy sidecar。
gcloud beta compute instance-templates create td-vm-template-auto \    --service-proxy=enabledgcloud compute instance-groups managed create td-vm-mig-us-central1 \    --zone us-central1-a --size=2 --template=td-vm-template-auto
GKE 通過 deployment 部署
GKE 提供 yaml 模版，需要修改 deployment 文件，在 yaml 中增加 sidecar 相關的鏡像。未提供 webhook, 參見 Traffic Director 的示例文件 [3]。
VM 和 GKE 混合部署示例
下面我們創建一個示例程序，將 V 和 GKE 中的服務同時加入到 traffic director 管理的 service mesh 中，以展示 traffic director 的對 VM 和容器服務流量統一管理能力。該程序的組成如下圖所示。程序中部署了三個服務，在 us-central1-a 中部署了兩個 VM MIG 服務，在 us-west1-a 中部署了一個 GKE NEG 服務，這三個服務處於同一個 VPC 中，因此網絡是互通的。
img
通過 us-central1-a region 上的客戶端向三個服務分別發送請求。
echo Access service in VM managed instance group td-demo-hello-world-migecho for i in {1..4}do    curl http://10.0.0.1    sleep 1doneecho echo Access service in VM managed instance group td-observability-service-vm-mig echo for i in {1..4}do    curl http://10.10.10.10    sleep 1doneecho echo Access service in GKE network endpoint group k8s1-e403ff53-default-service-test-80-e849f707 echo for i in {1..4}do    curl http://10.0.0.2    echo    sleep 1done
服務端會在請求響應消息中列印自身的 host name。我們從客戶端循環訪問三個服務，從命令結果可見每次的輸出是不同的，這是因為 envoy 會通過預設 lb 算法將請求分發到不同的服務實例上。
Access service in VM managed instance group td-demo-hello-world-mig<!doctype html><html><body><h1>td-demo-hello-world-mig-ccx4</h1></body></html><!doctype html><html><body><h1>td-demo-hello-world-mig-658w</h1></body></html><!doctype html><html><body><h1>td-demo-hello-world-mig-ccx4</h1></body></html><!doctype html><html><body><h1>td-demo-hello-world-mig-658w</h1></body></html>Access service in VM managed instance group td-observability-service-vm-mig<!doctype html><html><body><h1>td-observability-service-vm-mig-50tq</h1></body></html><!doctype html><html><body><h1>td-observability-service-vm-mig-16pr</h1></body></html><!doctype html><html><body><h1>td-observability-service-vm-mig-50tq</h1></body></html><!doctype html><html><body><h1>td-observability-service-vm-mig-16pr</h1></body></html>Access service in GKE network endpoint group k8s1-e403ff53-default-service-test-80-e849f707app1-84996668df-dlccnapp1-84996668df-t4qmnapp1-84996668df-dlccnapp1-84996668df-t4qmn
Anthos Service Mesh
Anthos Service Mesh 是 Google 混合雲和多雲解決方案 Anthos 中負責服務管理的部分。和 Traffic Director 的主要區別是，Anthos Service Mesh 直接採用了開源 Istio， 並且未對控制面進行託管，而是將 Istio 控制面部署在了用戶集群中，只是將遙測信息接入了 Google Cloud，並在 Google cloud console 的 Anthos Service Mesh 界面中提供了服務網格的查看和監控界面。Anthos Service Mesh 關鍵特性包括：
• 原生 Istio 多集群方案• 支持多雲 / 混合雲（不支持虛機）• 集中的服務監控控制臺。
Anthos 的整體架構
Google Cloud Anthos 旨在提供一個跨越 Google Cloud、私有雲和其他公有雲的統一解決方案，為客戶在混合雲 / 多雲環境下的集群和應用管理提供一致的體驗。Anthos 包含了統一的 GKE 集群管理，服務管理和配置管理三大部分功能。其中 Anthos Service Mesh 負責其中統一的服務管理部分，可以將部署在多個不同雲環境中的 Istio 集群在 Anthos Service Mesh 控制臺中進行統一的管理和監控。
Anthos 架構
imgAnthos GKE 集群管理
Anthos 對 On-Perm 和多雲的 K8s 集群的管理採用了代理的方式，Anthos 會在每個加入 Anthos 的集群中安裝一個 agent，由 agent 主動建立一個到 Anthos 控制面的連接，以穿透 NAT，連接建立後，Anthos 控制面會連接集群的 API Server，對集群進查看和行管理。
Anthos 採用 agent 接入 K8s 集群
imgAnthos Service Mesh 的混合雲 / 多雲解決方案
由於採用了開源 Istio，因此 Anthos Service Mesh 的混合雲 / 多雲解決方案實際上採用的是 Istio 的多集群方案。Istio 自身的多集群方案是非常靈活的，根據網絡模式和控制面的安裝模式，可以有多種靈活的搭配組合。Anthos Service Mesh 中推薦使用的是多控制面方案。
多網絡多控制平面
該方案中多個集群在不同網絡中，不同集群中的 Pod IP 之間是不能通過路由互通的，只能通過網關進行訪問。即使在不同集群中部署相同的服務，對遠端集群中服務的訪問方式也和本地服務不同，即不能採用同一服務名來訪問不同集群中的相同服務，因此無法實現跨集群 / 地域的負載均衡或容災。
由於上訴特點，多網絡多控制平面的部署方案一般用於需要隔離不同服務的場景，如下圖所示，通常會在不同集群中部署不同的服務，跨集群進行服務調用時通過 Ingress Gateway 進行。
Anthos Service Mesh 多集群管理 - 多網絡多控制平面
img單網絡多控制平面
在該方案中，多個集群處於同一個扁平三層網絡之中，各個集群中的服務可以直接相互訪問。如下圖所示，兩個集群中的 Istio 控制面都通過訪問對方的 API server 拿到了對方的服務信息。在這種場景中，通常會在不同集群中部署相同的服務，以實現跨地域的負載均衡和容災。
如圖中箭頭所示，在正常情況下，每個 region 中的服務只會訪問自己 region 中的其他服務，以避免跨 region 調用導致時延較長，影響用戶體驗。當左邊 region 中的 ratings 服務由於故障不能訪問時，reviews 服務會通過 Istio 提供的 Locality Load Balancing 能力訪問右側 region 中的 ratings 服務，以實現跨 region 的容災，避免服務中斷。
Anthos Service Mesh 多集群管理 - 單網絡多控制平面
imgAnthos Service Mesh 多集群部署示例
對於 Istio 來講，其管理的 Mesh 中的多個集群是否跨雲 / 混合雲並不影響集群管理的部署方案，因為本質上都是同一網絡 / 多個網絡兩種情況下的多集群管理。本示例的兩個集群都使用了 GKE 的 Cluster。但只要把網絡打通，本示例也適用於跨雲 / 混合雲的情況。
本示例的部署如圖 「單網絡多控制面 「所示，在同一個 VPC 中的兩個 region 中部署了兩個 GKE cluster。部署時需要注意幾點：
• 需要將 cluster 的網絡方案設置為 vpc-native，這樣 pod ip 在 vpc 中就是可以路由的，以讓兩個 cluster 的網絡可以互通。• 需要為兩個 cluster 中部署的 Istio 控制面設置對方 api server 的 remote secret，以使 stio 獲取對方的 Service 信息。
具體的安裝步驟可以參見 Anthos Service Mesh 的幫助文檔 [4]。
從導出的 Envoy sidecar 配置可以看到，其連接的 xds server 為本地集群中的 istiod。
        "cluster_name": "xds-grpc",        "endpoints": [         {          "lb_endpoints": [           {            "endpoint": {             "address": {              "socket_address": {               "address": "istiod.istio-system.svc",               "port_value": 15012              }             }            }           }          ]         }        ] ````Metric，Access log和 tracing 過 Envoy stackdriver http filter 上報到 Google Cloud，以便通過 Anthos Service Mesh 控制臺統一查看。```json              "name": "istio.stackdriver",              "typed_config": {               "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",               "type_url": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",               "value": {                "config": {                 "root_id": "stackdriver_outbound",                 "vm_config": {                  "vm_id": "stackdriver_outbound",                  "runtime": "envoy.wasm.runtime.null",                  "code": {                   "local": {                    "inline_string": "envoy.wasm.null.stackdriver"                   }                  }                 },                 "configuration": "{\"enable_mesh_edges_reporting\": true, \"disable_server_access_logging\": false, \"meshEdgesReportingDuration\": \"600s\"}\n"                }               }              }
嘗試從位於 west1-a Region 集群的 sleep pod 中訪問 helloworld 服務，可以看到預設會訪問本集群中的 helloword v1 版本的服務實例，不會跨地域訪問。
g********@cloudshell:~ (huabingzhao-anthos)$ export CTX1=gke_huabingzhao-anthos_us-west1-a_anthos-mesh-cluster-1for i in {1..4}> do> kubectl exec --context=${CTX1} -it -n sample -c sleep  \>    $(kubectl get pod --context=${CTX1} -n sample -l    \>    app=sleep -o jsonpath='{.items[0].metadata.name}')  \>    -- curl helloworld.sample:5000/hello> doneHello version: v1, instance: helloworld-v1-578dd69f69-c2fmzHello version: v1, instance: helloworld-v1-578dd69f69-c2fmzHello version: v1, instance: helloworld-v1-578dd69f69-c2fmzHello version: v1, instance: helloworld-v1-578dd69f69-c2fmz
將 west1-a 集群中 helloworld deployment 的副本數設置為 0，再進行訪問，由於本地沒有可用實例，會訪問到部署在 east1-b region 的 helloworld v2，實現了跨地域的容災。這裡需要注意一點：雖然兩個集群的 IP 是可路由的，但 Google cloud 的防火牆預設並不允許集群之間相互訪問，需要先創建相應的防火牆規則，以允許跨集群的網格訪問流量。
kubectl edit deployment helloworld-v1 -nsample --context=${CTX1}apiVersion: apps/v1kind: Deploymentmetadata:  annotations:    deployment.kubernetes.io/revision: "1"  creationTimestamp: "2020-08-14T12:00:32Z"  generation: 2  labels:    version: v1  name: helloworld-v1  namespace: sample  resourceVersion: "54763"  selfLink: /apis/apps/v1/namespaces/sample/deployments/helloworld-v1  uid: d6c79e00-e62d-411a-8986-25513d805eebspec:  progressDeadlineSeconds: 600  replicas: 0  revisionHistoryLimit: 10  selector:    matchLabels:      app: helloworld      version: v1  strategy:    rollingUpdate:      maxSurge: 25%      maxUnavailable: 25%    type: RollingUpdate    .g********@cloudshell:~ (huabingzhao-anthos)$ for i in {1..4}> do> kubectl exec --context=${CTX1} -it -n sample -c sleep  \>    $(kubectl get pod --context=${CTX1} -n sample -l    \>    app=sleep -o jsonpath='{.items[0].metadata.name}')  \>    -- curl helloworld.sample:5000/hello> doneHello version: v2, instance: helloworld-v2-776f74c475-jws5rHello version: v2, instance: helloworld-v2-776f74c475-jws5rHello version: v2, instance: helloworld-v2-776f74c475-jws5rHello version: v2, instance: helloworld-v2-776f74c475-jws5r
相互競爭還是優勢互補？
從前面的分析可以看出， Google Cloud 推出的 Traffic Director 和 Anthos Service Mesh 這兩個服務網格的產品各有側重點：
•Traffic Director 關注重點為流量管理。依靠 Google Cloud 強大的網絡能力提供了跨區域的 Mesh 流量管理，支持本地服務出現問題時將流量導向另一個地域的相同服務，以避免用戶業務中斷；並且通過統一的服務發現機制實現了 K8s 集群和虛擬機的混合部署。•Anthos Service Mesh 關注重點為跨雲 / 多雲的統一管理。這是出於用戶業務部署的實際環境和業務向雲遷移的較長過程的實際考慮，但目前未支持虛擬機，並且其對於 Mesh 中全局流量的管理能力不如 Traffic Director 這樣強大。
由於目的不同，兩者在控制面也採用不同的實現方案。由於 Traffic Director 只需要支持 Google Cloud，處於一個可控的網絡環境中，因此採用託管的自定義控制面實現，並對接了 Google Cloud 上的服務發現機制；而 Anthos Service Mesh 考慮到多雲 / 混合雲場景下複雜的網絡環境和部署限制，採用了開源 Istio 的多控制面方案，在每個集群中都單獨安裝了一個 Istio，只是接入了 Google Cloud 的遙測數據，以對網格中的服務進行統一監控。
雖然 Traffic Director 和 Anthos Service Mesh 兩者都是 Google Cloud 上的 Service Mesh 產品，似乎存在競爭關係，但從兩者的功能和定位可以看出，這兩個產品其實是互補的，可以結合兩者以形成一個比較完善的 Service Mesh 託管解決方案。因此 Google Cloud 會對兩個產品持續進行整合。下圖為 Traffic Director Road Map 中 Anthos 和 Istio 的整合計劃。
img參考文檔
•Creating a VPC-native cluster[5]•Traffic Director[6]•Anthos Service Mesh[7]
引用連結
[1] VPC native: https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips
[2] Cloud DNS: https://cloud.google.com/dns/
[3] 示例文件: https://storage.googleapis.com/traffic-director/trafficdirector_istio_sidecar.yaml
[4] 幫助文檔: https://cloud.google.com/service-mesh/docs/gke-project-setup
[5] Creating a VPC-native cluster: https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips
[6] Traffic Director: https://cloud.google.com/traffic-director
[7] Anthos Service Mesh: https://cloud.google.com/anthos/service-mesh

相關焦點

  • Google Traffic Director 詳細介紹
    援引來自Traffic Director官方網站的介紹資料，Traffic Director的定位是：Enterprise-ready traffic management for open service mesh.適用於開放式服務網格的企業級流量管理工具。
  • 從侵入式服務治理到Service Mesh
    目前service mesh技術在網際網路公司中越來越流行，那麼之前分布式系統是如何服務治理的呢，又是如何一步步發展成service mesh的呢？Service Mesh的定義最早是由出品Linkerd的Buoyant公司的CEO William在他的經典博客文章What's a service mesh? And why do I need one？中給出的。
  • Traefik 團隊開源的輕量級 Service Mesh 工具 Maesh
    Containous（Traefik 團隊）推出了全新設計的輕量級 service mesh（服務網格）工具：Maesh，Maesh 允許對 Kubernetes
  • 微服務架構與服務網格Service Mesh
    作者：阿二 | 編輯：皮皮哥今天我們來聊一聊：服務網格（Service Mesh ）以及字節跳動的服務治理平臺MS。
  • Service Mesh 淺析:從概念、產品到實踐
    1 Service Mesh - 服務通信的濟世良方 Service Mesh（中文譯做服務網格）這一概念由 Buoyant 公司的 CEO，William Morg」n 首先提出。2017 年 4 月該公司發布了第一個 Service Mesh 產品 Linkerd，這篇同一時間發表的文章 What’s a service mesh？
  • service mesh - 微服務通信進化之路
    但是服務間通信的相關技術早在網格計算機系統時代就開始發展了。從計算機設備端到端通信的發展開始，經歷過以下階段:（1）框架、庫以 Spring Cloud 、Dubbo 為代表的框架，與語言強相關相關，必須框架支持的語言，或提供各語言庫函數，才可以進行微服務通信。
  • Google混合雲多雲平臺Anthos Config Mangement產品設計分析
    Anthos 需要為部署在不同數據中心、GCP 以及其它雲上的多種應用程式的組件建立服務網格，Istio 自然是首選。它會和 VMWare NSX、Cisco ACI 以及 Google 自己的 Andromeda 等 SDN 進行無縫集成。已經在網絡設施上（例如 F5） 進行投資的客戶，可以將 Istio 和負載均衡及防火牆集成起來。
  • 正確入門Service Mesh:起源、發展和現狀
    不得不說，起名真是門藝術，Micro-Services -> Service Mesh，多麼承前啟後和順其自然啊，光看名字就能很形象地理解這玩意兒所做的事情：把微服務的各個service（服務）節點，用一張mesh（網格）連接起來。
  • 服務網格比較:Istio vs Linkerd
    根據 CNCF[2] 的 最新年度調查 [3]，很明顯，很多人對在他們的項目中使用服務網格表現出了極大的興趣，並且許多人已經在他們的生產中使用它們。將近 69％ 的人正在評估 Istio，64％ 的人正在研究 Linkerd。Linkerd 是市場上第一個服務網格，但是 Istio 的服務網格更受歡迎。這兩個項目都是最前沿的，而且競爭非常激烈，因此選擇哪一個是一個艱難的選擇。
  • 使用Istio簡化微服務系列二:如何通過HTTPS與外部服務進行通信?
    作者：Nithin Mallya翻譯：狄衛華原文：Simplifying Microservices with Istio in Google Kubernetes Engine — Part II原文連結：https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-ii
  • Service Mesh 發展趨勢:雲原生中流砥柱
    （Google Traffic Director 的詳細介紹，請查看文章 Google Traffic Director詳細介紹 [6]）微軟則推出了Service Fabric Mesh。Azure Service Fabric 是 Microsoft 的微服務框架，設計用於公共雲，內部部署以及混合和多雲架構。
  • 測試Istio 1.6 Service Mesh引入虛擬機Workload (筆記與感悟)
    引起我注意的是Istio正式增強了對非容器形態加入網格的支持, 並聲明會做為重要的戰略持續優化. 做為VMwarer對這次更新有種被照顧到了的欣喜. 一方面VMware以All in的姿態投身於Kubernetes業態, 另一方面如Istio, AWS App Mseh, Kong Kuma等一眾服務網格產品都在向VM / BM延伸.
  • 詳細教程丨如何利用Rancher和Kong實現服務網格?
    掃描下方二維碼或點擊文末【閱讀原文】即可報名：服務網格（Service mesh）是當前新興的架構模式，越來越受到人們的青睞。與Kubernetes一起，服務網格可以形成一個強大的平臺，它可以解決在微服務集群或服務基礎設施上發現的高度分布式環境中出現的技術需求。服務網格是一個專門的基礎設施層，用於促進微服務之間的服務到服務通信。
  • 微服務進入2.0時代
    （https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one）上面這段話非常清晰的指明了服務網格的職責，即處理服務間通訊，這正是服務治理的核心所在。
  • ECCV 2018 | Pixel2Mesh:從單幀RGB圖像生成三維網格模型
    文章提出了一種端到端的深度學習框架，可從單張彩色圖片直接生成三維網格（3D Mesh）。受深度神經網絡特性的限制，以前的方法通常用 volume 或者 point cloud 表示三維形狀，將它們轉換為更易於使用的 mesh 並非易事。
  • 如何在Kubernetes上使用Istio Service Mesh設置Java微服務?
    對於那些關注不夠的人來說-Istio是用於分布式應用程式體系結構的service mesh，尤其是那些在雲上運行的Kubernetes。Istio與Kubernetes適配得非常好，以至於你可能認為它是Kubernetes平臺的一部分。如果你還想知道，到底什麼是service mesh或Istio？那麼，讓我們來看看Istio。
  • 服務網格在Cookpad網站中的實踐
    目前，我想介紹一下在 Cookpad 上構建和使用服務網格所獲得的知識。對於服務網格本身，我認為您將對以下文章，公告和教程有完整的了解：https://speakerdeck.com/taiki45/observability-service-mesh-and-microserviceshttps://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one
  • ​ABAQUS網格劃分之『Bottom-up mesh』
    ，介紹ABAQUS中的Bottom-up mesh網格劃分方法，並對該方法需要注意的問題進行闡述。由於前三中網格生成方法更為常用和簡單，本文僅對第四種方法進行介紹。以圖1所示模型為例我們使用bottom-up進行網格生成。首先進入mesh模塊，將mesh controls設置為bottom-up方法。之後進入劃分窗口，如圖2所示。
  • 經典遊戲《金庸群俠傳》到底哪些人才,可以學習左右互搏之術?
    在《射鵰英雄傳》和《神鵰俠侶》中，老頑童通過十幾年的無聊練習竟然練成了一招左右互搏之術，甚至打得黃老邪都措手不及。
  • 使用 SkyWalking 和 Envoy 訪問日誌服務對服務網格進行觀察
    不過自從 v1.5 版本，由於 Mixer 在大型集群中差強人意的表現，Istio 開始棄用 Mixer。Mixer 的功能現已遷至 Envoy 代理，並獲 Istio 1.7 版本支持。 代理傳入請求︰在此情況下，Envoy 會作為伺服器端的 Sidecar，以 inbound|portNumber|portName|Hostname[or]SidecarScopeID 格式設定 upstream_cluster。