Knative = Kubernetes網路++

banq發表於2019-11-13

通常將Knative專案解釋為“ Kubernetes上的無伺服器”的構建基塊。因此，大多數Kubernetes使用者都不知道Knative可以為他們的非無伺服器工作負載做什麼：它可以 為Kubernetes上的無狀態微服務提供更好的自動縮放和聯網功能。

讓我們暫時不談“無伺服器”。大多數Kubernetes使用者遵循十二項應用程式宣告編寫微服務：服務應該是無狀態的，並且可以通過request / RPC相互通訊。但是Kubernetes不能真正滿足微服務：

  • 需要為一個應用編寫兩個清單（部署，服務）
  • 沒有針對HTTP / gRPC按請求/按RPC的負載平衡
  • 沒有流量分配，因此無法輕鬆進行藍色/綠色部署
  • 基於CPU /記憶體的自動縮放（通常很慢，而不是您所需要的）
  • 沒有併發控制（即每個Pod最多N個正在進行中的請求）

安裝在Kubernetes叢集上的Knative Serving直接解決了Kubernetes的這些缺點：

  • Kubernetes Service + Deployment組合而成的«Service»物件
  • HTTP / gRPC的每個請求的負載平衡
  • 基於請求的快速自動縮放，反應迅速
  • 使用服務修訂版進行流量拆分（藍色/綠色部署）
  • 開箱即用的快速自動縮放功能，高度可配置

    • 比例縮放到零（掛起）和0到N（啟用），也可配置
    • 併發控制（限制每個Pod的執行中請求）
  • （可選）對HTTP指標（延遲，請求等）的自動監視支援
  • （可選）自動TLS證書和外部端點的終止

在堆疊的關鍵路徑上採用像Knative這樣的新元件可能是一個艱難的決定。Knative專案的多個方面可能會改變您的想法：

  • Knative即將達到v1.0並變得“穩定”，擁有一個堅實的社群.
  • Knative是模組化的：您只能安裝其服務元件。
  • Knative不再依賴Istio：Knative需要用於路由和流量拆分的負載平衡器，但是您可以使用Gloo或 Ambassador之類的替代方案，或專為Knative構建的閘道器代理（例如 Kourier）。

Knative«Service»API

Knative將Kubernetes Deployment + Service組合為一種Service型別。

Deployment通過更改apiVersion/ kind修剪一些不必要的部分，可以非常輕鬆地將大多數無狀態Kubernetes 清單遷移到Knative ： 

# modify this:
apiVersion: apps/v1
kind: Deployment

# to this:
apiVersion: serving.knative.dev/v1
kind: Service

每次更新Knative時Service，Revision都會建立一個新物件。 Revision物件是不可變的，迫使您擁有部署的快照。然後，您可以使用Revision物件在首次釋出或直接回滾期間拆分流量。

Knative Serving提供了開發人員日常可能不會遇到的其他API，例如Configuration鼓勵將您的程式碼和配置分開的（另一種12要素應用程式規範）。

自動縮放

作為開發人員，如果您在解決如何在Kubernetes中自動擴充套件微服務方面遇到問題，則有充分的理由。

Kubernetes自動縮放主要是使用Horizo​​ntal Pod Autoscaler完成的。HPA控制器會檢視CPU /記憶體使用情況（或自定義指標），預設情況下會在很長時間內執行。因此， 對突發流量高峰的反應速度較慢。

另一方面，Knative自動縮放是由“進行中的請求”（併發）驅動的：如果您的服務突然收到超出其處理能力的請求，Knative將在較短的時間範圍內迅速新增更多Pod。因此，反應更快。

Knative知道Pod的所有請求。使用Knative，您可以將應用程式配置為具有“目標併發性”級別，這是一個軟性目標，或者是一個嚴格的“併發性”限制，以確保傳送到每個Pod的最大執行中請求。考慮到併發設定，Knative自動縮放器會密切監視傳入的請求並快速確定要新增的Pod數。

在擴大您的應用程式時，Knative會保留傳入的請求，並將它們代理到新的Pod，而不會刪除請求，這是Kubernetes不可能做到的。

作為一名開發人員，我更喜歡說“我的應用程式可以在一行配置中一次處理20個請求”，而不是在較長的Horizo​​ntalPodAutoscaling 清單中配置： “目標是平均70％CPU使用率並在1至30個容器之間縮放我的應用程式” 。

此外，Knative為一段時間內未收到流量的服務提供“從零擴充套件”（Kubernetes本身無法做到這一點4）。這可以通過使用Knative activator 元件來實現。預設情況下，此功能以無伺服器方式開啟，因此會導致“冷啟動”。但是，可以輕鬆關閉它。

您可以參考此部落格文章，此文件和本示例，以瞭解有關Knative自動縮放器的更多資訊。

Knative仍然是Kubernetes

用Knative部署的應用程式仍然是Kubernetes服務，他們可以連線其他Kubernetes服務，也可以使用本機Kubernetes服務發現進行連線。

Knative Services部署為Kubernetes Deployments，仍然可以通過Knative Service物件（示例）來指定PodSpec值（環境變數，卷安裝和其他詳細資訊）。

對於Kubernetes開發人員而言，Knative的進入門檻非常低。藉助諸如Anthos上的Cloud Run之類的託管服務，您可以在群集中的雲端或本地群集中擁有託管Knative設定。

點選標題見原文。

相關文章