Serverless遇上ServiceMesh，是珠聯璧合還是流於形式？
作者：ANDRéS MARTíNEZ
翻譯：江水
原文：Serverless Service Mesh With Kubeless And Istio
在過去的幾個月中，你可能已經聽說過 service mesh。service mesh 簡單來說就是一個基礎設施組件，可以快速可靠的連接多個微服務。這種架構提出了一種非常有趣的方法，適用於在雲原生場景中設計新的應用程序。在本文中，我們將演示如何使用 Kubeless：一個跑在 Kubernetes 上的 serverless 框架，以及 Istio：一個提供網路連接，管理和安全控制的開源平台 Kubernetes 服務，你可以花幾分鐘輕鬆地部署你的第一個 service mesh。
在 Bitnami，我們開發了 Kubeless：一個 serverless 平台，可以讓你輕鬆在 Kubernetes 集群上運行微服務。如果這是你第一次聽說 Kubeless，你想了解更多的基本知識，可以看我之前的帖子, 或者訪問 Kubeless. io 官網。
除了 Kubeless，Istio 是一個為微服務提供網路資源的開源平台。Istio 允許你以一種簡單的方式管理、監控和安全控制你的微服務。
作為開發者，你可能知道，在群集中維護具有不同版本和授權策略的服務可能很困難，而且容易出錯。必須仔細管理所有服務之間的所有可能的路由。
結合 Kubeless 和 Istio 創建 service mesh 可以大大節約發布與網路管理的成本。Kubeless 只需要你輸入一個發布命令就可以讓 Istio 用過配置文件管理你的請求路由和策略。在本文中，我將通過如下命令演示：
1. 目標架構
為了演示 Kubeless 和 Istio，我將部署一個應用程序，將模擬管理一個cold room。請參見建議架構的示意圖：
應用將由三組不同的服務組形成：
2. 準備環境
對於本練習，我將使用 Google 雲平台 (GCP) 中的 Kubernetes 集群，使用谷歌 Kubernetes 引擎 (GKE)。如果你沒有 GCP 帳戶，或者你更喜歡在本地部署，則可以使用 Minikube 完成此練習。
在 GKE 上部署集群，我會用 Google Cloud SDK 的 gcloud 工具。如果你要用 GKE 完成此操作，請確保安裝如下工具：
我將啟用 alpha 功能（30天後將群集標記為刪除），因為這是使用 autoinjection 功能所必需的。Autoinjection 可以是我們不必在部署服務的時候手動插入 Istio 詳細信息。除此之外，為了確保我不會耗盡資源，我將使用5節點。
我現在將部署 Istio。我使用的是最新版本的。下面是要執行的命令：
注意:如果你在 Linux 或 Windows 系統中遵循本指南，請使用不同的壓縮。如果你在創建 ClusterRoleBinding 時遇到問題，可以按照本指南進行。
讓我們在這個新的集群中部署 Kubeless。如果你遵循本指南，則必須執行在 GKE 中部署 Kubeless 並安裝 Kubeless CLI 工具的步驟。
此時需要在群集中部署 Kubeless 和 Istio：
3. 部署 service mesh
是部署應用程序服務的時候了。本指南中使用的所有文件都可在此 Github 倉庫中獲得。你可以克隆存儲庫，以使這些文件在本地可用：
讓我們部署兩個版本的溫度計服務，將返回 room 的溫度：
請注意，我設置 labelversion=v1和version=v2，所以我可以區分他們的版本。我也設置 labelapp=temp，使這兩個函數有一個共同的 label。
除了這些部署之外，我還將創建一個服務，用於使用單個端點訪問這兩個函數：
最後，我將創建恆溫器服務和控制功能：
幾秒鐘後，就可使用 kubeless CLI 訪問這些服務:
請注意，有時當調用控制函數時，它會返回濕度，但其他的則不會。它取決於內部調用的 temp 服務（上文提到過 溫度計服務）的版本。
4. 使服務適應 Istio
Kubeless 自動創建訪問包含函數服務的函數所需的所有資源。但是，為了使用 Istio，服務埠的 name 屬性必須是一個眾所周知的值。因此，我必須更改在埠列表中的當前值。我可以通過編輯當前服務來更改它：
現在所有的服務都已更新，我需要重新啟動函數 pod。這是因為 pod 會在 initContainer 中註冊他們的信息。initContainer 只在啟動一個 pod 時執行，因此，要正確地註冊服務信息，我需要重新啟動所有的 pod：
幾分鐘後，pod 再次運行，並在 Istio 正確註冊。
5. 請求負載均衡
在這一步中，我將使用 Istio 提供的請求路由配置。這允許我管理不同版本的臨時服務的請求。我將部署一個非常簡單的規則，將90% 的請求重定向到 v1of 服務的版本，另外10% 個版本 v2。此功能在測試新功能或使用 a/b 測試時非常有用，因為它允許你在不影響所有用戶的功能的情況下運行同一服務的多個版本：
route-rule-10-v2.yaml:
現在，如果我多次執行 kubeless 函數調用控制命令，它將只列印幾次濕度。你可以更改這些數字（例如，將所有流量重定向到 v2 版本），並在調用 controlservice 時查看更改。
6. 基本訪問控制
對於本練習，我將限制對恆溫器服務的訪問。這只是一個例子，所以我將使用基本的訪問控制。請注意，如果我使用 TLS 身份驗證部署 Istio，我可以使用服務帳戶並配置安全訪問控制，但為了簡單起見，我不會在這裡做。
通常，恆溫器服務只能通過控制服務來訪問。為了確保這一點，我將部署以下清單:
deny-rule.yaml:
我所做的是阻止任何不是來自恆溫器服務的控制功能的請求（除非請求是 Kubernetes 使用的 /healthz 路徑, 以檢查服務是否活著）。
我們可以通過執行以下操作來確保規則的工作：
請注意，此規則不保護恆溫器服務不受群集用戶的控制，並具有創建 pod 的許可權。這些用戶中的任何一個都可以創建一個 label 是 function=control 的 pod，它將能夠訪問恆溫器服務。為了正確地保護此服務，我應該使用安全訪問控制，並指派一個 serviceAccountName（其他用戶不能使用）到 controldeployment。
7. 準備好了么？
我剛剛介紹了 Kubeless 和 Istio 的一些基本功能，但是現在你應該可以使用這兩種工具來啟動 service mesh 了。下一步是使用服務帳戶並設置具有安全訪問控制的群集。這樣我就可以為這些功能提供更嚴密的安全性。
除此之外，還有很多功能可以處理，例如，添加監控和指標，自定義路由，自動擴縮容...想瀏覽更多信息，請看 Istio 和 Kubeless 的網站和文檔。
原文地址：https://engineering.bitnami.com/articles/serverless-service-mesh-with-kubeless-and-istio.html
TAG:全球大搜羅 |