[延續上一篇：運用容器化架構及微服務架構，升級企業 IT 環境(1) ]
Proxy 的用處
根據上述，proxy 是此服務的核心所在。從 1990 年開始，各種形式的分離扮演著關鍵的角色，對於我們的政策執行是重要的控制點。
最初的 proxy 案例使用是負載平衡：將輸入的需求平均分散到活動的 pods 集合。服務 IP 除了有高度可用性外，他也可以支援跨多個版本分散流量，做金絲雀先期測試和 A/B 普遍測試。它也適用於應用程式服務逐步推出新版本上。
如上所述，proxy 相關運行作業在第四層 TCP/IP 一同運作。這已經足夠應用於基本服務，並搭配 DNS、IP 位址、port 號碼能夠讓舊版應用程式 (legacy applications) 正常運作。在第七層的服務多數為 HTTP 的需求，因這些服務供更多資訊，因此需要更複雜的處理程序。長遠來看，我們希望第四層適用粗略的存取控制 (對叢集或叢集內同網域名稱)，第七層適用於現代化企業和動態應用程式，搭配更複雜的政策控管。第七層政策可以使用較新的來源控管機制，包括明確的審查和來源程式碼的變更 (例如：GitOps)。
Proxy 在遠端測量應用也十分重要：它可以檢測服務的級別指標 (SLIs)，像是需求延遲和網路吞吐量，且無需了解相關服務 (decoupling 的特色)。它能夠透過遠端測量檢查 pod 的健康狀態，自動新增或縮減來調整 pod 的工作量。
我們在接下來的兩節當中會討論兩種不同的 proxy 用法。第一種是應用程式服務之間的流量管理，有時稱為「東-西」流量的結構，典型的架構圖，使用者位於頂部 (北邊)，服務從左到右(由西向東)。第二種為更傳統的使用者介面 proxy，它負責管理應用程式的流量 (由北到南)，並提供身份驗證、存取權限控制、多種 API 管理工具和調解服務等功能。
Istio 的微型服務和生命週期管理
Kubernetes 的 proxy 提供抽象的服務機制，但功能有限。近代的 proxy (例如：Envoy) 已經普及邊車 proxy 的概念，增加了強大的功能和彈性。因獨立 proxy 配置的效率不佳，所以需要無縫注入系統化管理跨域 proxy。Istio 是 Google 用來解決 Lyft 和 IBM8 微型化服務的開源項目。
流量管理
Istio 負責管理一組服務網格 (service mesh) 的 proxy 組件。網格是一組使用者面向的應用服務軟體。Istio 管理流量服務 (東西方) 和每個服務前的 proxy。這樣可以實現客戶端跨服務負載平衡的實例和入口功能，像是 A/B 測試以及使用者服務導向的金絲雀釋放 (canary releases) 服務。網格 proxy 同時也支援出口功能，例如超時、重試和斷路器等功能，並且在路由器連到外部網站時提高容錯值。重要的是，Istio 對 proxy 提供了集中管理的系統和政策。這可以說是最重要的分離 (decoupling) 方式：分離 (decoupling) 運行政策和服務。特別的是，它避免開發人員在服務中修改政策，也就是說開發人員可以在不重新部署的情況下更改政策。相反來說，開發人員只需更新應用的 proxy 就可以更改政策。因為是集中管理，所以可以在服務間保持一致，並且可以在安全的情況下控制版本更新。
再更高層來說，這個模型將操作和開發解離。在 IT 中有一個典型的問題為，操作人員希望將作業強制統一執行政策，但這需要密切地和開發人員討論，以確保每項服務都在做正確的事。這會導致在協調上花費龐大的成本，例如阻止政策審查的建立。在 Istio 模型中，由於政策程序在服務以外執行，所以協調的部分較少。相反來說，開發團隊有較高的發布速度 (可以每天或更多)，需要有更高的自主性和精力。廣義上來說，我們希望服務開發人員可以負責可用性和推出新版本的作業，同時將廣泛的政策制定和執行交由集中控管的團隊。
Istio 採用這些 proxy 並對其管理有許多好處，如圖 2 所示，它能將基本服務轉變為具有一致屬性和政策的進階服務。
安全性
除了流量管理之外，Istio 還相互驗證服務，加密服務間流量 (mutual TLS)，為呼叫服務提供存取控制，並產生稽核線索。這些功能可以透明地添加，無需更改應用程式或進行繁瑣的管理。 Istio 身份驗證可自動執行服務識別和授權，以啟用精細的應用程式層控制。例如，如果對抗制訴訟程序過程可以調用信用卡服務，導致意外付款，則會很糟糕。(有關詳細資訊，請參閱 Istio Security。)
可觀察性
服務的可見性是非常重要的，才能安全地達成正式環境上線的目標，並且瞭解即時遙測技術是建構安全平臺的基礎。Istio 通過自動產生和收集服務的監視資料和日誌提供自動化檢測服務。通過這種方式進行檢測，Istio 可以跨多種服務和後端收集一致性的資料。這樣可以輕鬆產生儀表板並提供常見的 SLI，例如延遲分佈、輸送量和錯誤率。反過來，一致性的指標能夠簡化自動化的工作，例如自動縮放和運行狀況檢查 (請參閱 Istio 遙測示例)。
有狀態的服務和資料庫
雖然目前大多數 Kubernetes 工作負載都是無狀態的，但 Kubernetes 可以使用 StatefulSets 的概念來容納有狀態的服務，其中每個 pod 都有一個穩定的識別和專用磁碟，可以在重新啟動時進行維護。這將容器編排擴展到分佈式資料庫，串流資料管道和其他有狀態服務。當 Kubernetes 專注於大規模的容器編排，新的程式化模型可以開發應用程式和執行時間，用來控管業務邏輯、資料一致性和日益分散的工作流程。
無伺服器跟事件
Knative 之類的開源框架編寫最佳做法，圍繞在雲端原生應用程式開發，經由來源驅動函數、動態、事件驅動的微服務等方式。生產者可以產生事件，消費者可以預先訂閱事件，依需求驅動的計算能力，只有活動中的使用量才需付費。 Knative 服務框架建構在 Kubernetes 和 Istio 的基礎上，具有中介軟體，可以快速部署無伺服器容器、自動擴展到零、智慧路由和快照已部署的代碼和配置。
零信任安全和雲端保證現代化
Google 首創零信任存取安全模型，以北到南 proxy 來執行更精細的控制，同時保持一致的使用者體驗 (請參閱 BeyondCorp：企業安全的新方法和 BeyondCorp – 存取代理）。作為整體 Google 安全架構的關鍵組成部分 (詳情請看這裏)，此上下文感知存取模式會強制執行服務和使用者身份驗證，並套用動態存取控制到所有的應用程式中。
通過在使用者/瀏覽器和後端服務端點之間插入應用層閘道器，這種方法解決了傳統企業模型面臨的主要挑戰，傳統企業模型仍然依賴具有堅固防火牆和 VPN 的網路層級邊界。由於雲端/SaaS 服務和行動化應用程式代表了大多數企業工作負載，因此可信賴的存取使用「即時real-time」前後文適當地執行雲端點的存取政策，並以最少代價來防止資料外洩露。
圖 3：跨使用者，資源和應用程式/服務的零信任模型
除了保障交易安全之外，這種基於代理的閘道器方法還有助於確保服務提供者可以有效地開發，部署和管理對於任何雲的後端 API 提供服務。
關於細微的遙測，開放式雲架構能控制平面自動化和技術/操作的一致性，讓企業能以更好的方式評估其資產/服務/使用者，展現雲端安全控管與稽核的最佳做法。它還允許企業發展其雲的「共用責任」模型，其中定制的安全控制 (垂直、區域、角色定義、託管服務等) 被定義在管理基礎架構政策的上游 (計算、儲存、網路)，平臺 (自動化 CI / CD 和 GitOps 管道，安全運行時，服務認證和生命週期管理、使用者身份和存取權限) 和應用程式層級 (商業邏輯，使用者體驗)。
現代化的點對點安全軟體供應鏈和具有零信任原則的雲商務加速了服務的開發和建構、交付和消費，並實現了以下關鍵原則和優勢：
所有使用者或服務都進行驗證，授予最低權限的存取政策：
- 根據以角色為基礎的明確政策，對使用者存取資料進行身份驗證、授權和記錄
- 針對雲端資源以及使用者和服務，進行集中化政策/配置和管理
- 將服務強制隔離，使得任何攻擊傷害對其他領域變成有限度的影響
用於保護敏感數據的應用程式和使用者上下文感知存取政策 (不可重現的身份)：
- 多重因素 (在 RBAC 控制之上、權杖 token) 用於授權使用者，資源和服務
- 預設情況下，資料在靜止時被加密，並透過加密連線來傳輸資料
- 二進制授權能確保提供適當的簽署和驗證，給可攜式的工作負載 (虛擬主機、容器)
對資源、使用者和服務的安全狀況進行中央監測和持續管理：
- 遙測一致性用於細微的服務存取控制，而不僅僅是 IP 和基礎設施日誌記錄和監控
- 持續地探索定位並做資料索引，控制分析、分類和保護資料
- 所有機密和證書都使用有效的根證書進行簽名，但需要持續進行證書管理
- 由可信賴的業界專家，做自動化修補程序和安全性更新維護
跟過往相比，在既有的企業/IT 環境內，許多企業正在迅速地改用開放式的軟件框架 (Kubernetes、Istio、Knative)。這種體系結構演變使工作負載的可移植性、與供應商無關的雲服務抽象化以及跨異質環境的集中化管理策略，提昇了安全性/成本治理方式，並明顯地簡化未來往雲端遷移的程序。
聲明性配置模型和 Kubernetes
到目前為止，我們已經討論了容器和 pod 的使用，以及使用託管代理產生良好分離的高級服務。我們的雲服務平台的最後一個基礎是配置模型。
配置結果是現代應用程式中最難的部分之一，多年來 Google 已經建構並拋棄了各種各樣的配置系統，從非常簡單的到過於複雜的。
由於應用程式和基礎架構的幾乎所有方面都需要配置，因此我們需要一個具備一致性還可以擴展的模型，但同時又能與自動化互相搭配。理想情況下，配置工具也應與正在配置的系統分離。
第一個問題是配置語言的內容用來做什麼。對 Google 來說，使用 Python 或 bash 腳本等通用語言非常誘人。通用語言非常強大，因為它們幾乎可以解決任何問題，但它們會導致系統變得複雜，也很容易失去清晰度，而且它們執行時進行直譯會導致正式環境發生意外狀況。
另一個挑戰，將執行代碼作為配置的一部分會使自動化變得更加困難。例如，配置區塊在執行時偶爾會失敗。一個人類可能能夠解釋該故障為何並手動修復它，但自動系統通常不能，因為很難知道系統在故障後處於什麼狀態。例如，可以簡單地重新執行配置塊嗎？或者它已經部分完成，留下副作用需要先被撤消？
作為替代，我們使用受限語言 YAML 來表示所需的資源狀態，但不直接計算它。目標是聲明性的，也就是說，YAML 應該表示 (「declare」) 系統的期望狀態。 YAML 可以直接使用，也可以通過工具輕鬆產生，當配置中涉及多個參與者時，我們可以提供聰明的工具來合併變更 (這在大型系統中很常見)。
我們仍然需要啟用自動化，但不是在配置中使用代碼，是使用後臺代理 (稱為 controller)，根據需要執行自動化。基本方法稱為協調，控制器的工作是調整正在運行的系統 (例如添加一個新的 pod)，使實際狀態與所需狀態一致 (「reconciled」)。這是一種穩健的最終一致性形式 – 完成協調可能需要一些時間，但是當失敗導致實際狀態偏離 (未改變的) 期望狀態時，相同的過程會使其恢復正常。
圖4：Kubernetes 配置模型
將所有這些結合在一起，YAML 文件是預期的狀態，並且使用 RESTful 介面來管理 apiserver (如下所示)。apiserver 可以由不同形式的 UI 或其他工具驅動，它將所需的狀態儲存在持久鍵/值儲存中 (當前基於etcd) 中。 控制器監視所需狀態的變化，然後採取相應的措施。
這種宣告模型的其中一個優點是，它可以跟流行的程式碼版本控制系統 (如git) 完美地搭配使用設定檔被視為原始碼，也應該使用相同的概念，做版本控制、測試和推出新版本。 該系統非常通用且非常一致；例如：設定檔有共同的元數據，並且有更新，驗證和刪除資源的明確定義的語意。資源企業邏輯存在於控制器內部，其餘部分相當通用，因此可重新使用和可擴展。
例如，開發人員可以產生「自訂資源定義」，用來定義新資源配置模式 (custom resource definitions/CRD) 和實現資源行為的控制器。Kubernetes API 服務器機制可以將新資源作為服務端點進行管理，而無需進行任何修改。
政策即代碼
這種可擴展的宣告模型支援 Kubernetes 和雲端運行的服務進行自動配置管理。Istio 政策規範 (基於 YAML 的 CRD) 可以通過託管控制器實施，這些控制器可以自動對代理進行政策更新。 「政策即代碼」和自動化 CI / CD 管道，可確保逐步推出新版和改善治理，例如：稽核、合規性和成本控制。
聲明性政策有助於擴展各種雲環境並確保一致性。命名空間提供不受專有實現約束的邏輯服務隔離邊界。命名空間還允許政策管理員設置護欄並委託特定租用戶的 (本地) 政策。此外，它們可以按層次結構分組以進行政策繼承，並與元數據標籤一起使用以強制實施雲租戶政策。最後，命名空間可以為使用者/服務身份驗證和授權啟用「自帶 bring your own」和邦聯式身分。 由於企業為其雲環境採用零信任存取模型，因此命名空間有助於確保在現有和未來環境中，實現一致的程式存取控制，和動態實施使用者和服務身分識別。政策即代碼 Policy as Code，強制執行專有資料管理政策是服務定義和啟動的必需組件。
結論
現代發展的關鍵是將團隊分離，以便提高工作效率。分離以多種形式出現，它們共同成就更快的進化和更好的系統，花費更短的時間內和更少的辛勞。我們介紹了幾種形式的分離：
- 容器能夠將應用程式和程式庫，與底層作業系統和主機分離。
- Kubernetes 中的基本服務，將服務與 pod 分離，允許每個服務獨立發展
- Istio 代理以統一的方式提供跨所有服務的功能，包括安全性和遙測，並與每個服務的原始碼分離。
- 啟用代理的政策部署和實施將政策管理與特定服務分離，以便政策可以在不中斷服務的情況下發展，並且可以在不更改基礎設施的情況下改進安全狀態 (通過政策即代碼)
- 使用服務作為部署單位，通常與特定團隊相對應，允許團隊更獨立地操作。 雖然這可能會為大規模應用程式帶來數百種服務，但 Kubernetes 和 Istio 服務基礎架構使其易於管理。
通過將基礎架構，服務和團隊分離，企業可以提高開發人員的敏捷性並加速創新，而不會影響運營效率，安全性和治理。
相關文章：運用容器化架構及微服務架構，升級企業 IT 環境(1)
(原文翻譯自 Google Cloud。)
