主持人 > 博客 > 管理 > Knative - 基於 k8s 的平台即服務，具有無伺服器支援

Knative - 基於 k8s 的平台即服務，具有無伺服器支援

Knative - 基於 k8s 的平台即服務，具有無伺服器支援

Kubernetes 無疑已成為容器部署的主導平台。它提供了使用其 API 和自訂控制器控制幾乎所有事物的能力，這些控制器透過自訂資源擴展其 API。

然而，用戶仍然必須就如何部署、配置、管理和擴展應用程式做出詳細的決定。應用程式擴充、保護和流量問題仍由用戶自行決定。這使得 Kubernetes 有別於傳統的平台即服務 (PaaS)，例如 Cloud Foundry 和 Heroku。

這些平台具有簡化的使用者介面，面向最常參與設定個人應用程式的應用程式開發人員。路由、部署和指標由底層 PaaS 系統對使用者透明地進行管理。

從來源到出貨的工作流程由 PaaS 處理，方法是建立自訂容器映像、部署它、為傳入流量設定新的路由和 DNS 子網域。所有這一切都是根據命令啟動的 git push.

Kubernetes（有意）只為此類平台提供核心構建塊，讓社區可以自由地自行完成工作。如何 凱爾西海塔爾說:

Kubernetes 是一個建構平台的平台。這是開始的最佳位置，但不是結束的位置。

因此，我們看到了許多 Kubernetes 構建，以及嘗試為 Kubernetes 創建 PaaS 的託管公司，例如 OpenShift 和 Rancher。在不斷成長的 Kube-PaaS 市場中，由 Google 和 Pivotal 於 2018 年 XNUMX 月創立的 Knative 正在進入這一領域。

Knative 是 Google 和 Pivotal 之間的合作成果，並得到了 IBM、RedHat 和 Solo.im 等其他公司的協助。它提供與 Kubernetes 類似的 PaaS 功能，為基於無伺服器運算的應用程式提供一流的支援。與 Kubernetes 建置不同，Knative 作為附加元件安裝在任何相容的 Kubernetes 叢集上，並透過使用者資源進行設定。

什麼是 Knative？

Knative 被描述為“一個基於 Kubernetes 的平台，用於使用現代無伺服器運算交付和管理工作負載。” Knative 在標榜自己是這樣一個平台的同時，也根據並發 HTTP 請求的比例主動自動縮放容器。未使用的服務最終會縮減到零，從而提供無伺服器式的按需擴充。

Knative 由一組安裝在任何 Kubernetes 叢集中的控制器組成，並提供以下功能：

  • 從原始碼建立容器化應用程式（由元件提供） 建立),
  • 提供對應用程式傳入流量的存取（由元件提供） 正在服務),
  • 按需交付和自動擴展應用程式（也由元件提供） 正在服務),
  • 識別導致應用程式啟動的事件來源（由元件提供） 三項賽).

一個關鍵元件是服務，它為託管應用程式提供配置、自動擴展和流量管理。安裝 Knative 後，您仍然擁有對 Kubernetes API 的完全存取權限，允許使用者管理應用程式 普通 方式，也用於調試 Knative 服務，使用這些服務使用的相同 API 原語（模組、服務等）。

在Serving的幫助下，藍綠色流量路由也實現了自動化，確保當用戶交付更新版本的應用程式時，新舊版本應用程式之間的流量分離。

Knative 本身依賴於安裝相容的入口控制器。在撰寫本文時，支持 Gloo API 網關 и Istio 服務網格。它將配置可用的入口以將流量路由到 Knative 管理的應用程式。

對於想要在不安裝 Istio 控制面板的情況下嘗試的 Knative 用戶來說，Istio Service Mesh 可能是一個很大的依賴項，因為 Knative 僅依賴網關。

因此，大多數用戶更喜歡將 Gloo 作為 Knative 的網關，提供與 Istio 類似的功能集（為了僅使用 Knative），同時使用的資源也少得多，營運成本也更低。

讓我們在展台上實際測試 Knative。我將使用在 GKE 中運行的新安裝的叢集：

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

讓我們開始安裝 Knative 和 Gloo。這可以按任何順序完成：

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

我們檢查所有 Pod 是否都處於「Running」狀態：

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo 已準備好進行路由，讓我們建立一個自動擴展的 Knative 服務（我們稱之為 kservice）並將流量路由到它。

與傳統的 Deployment+Service+Ingress 模型相比，Knative 服務提供了一種更簡單的方式將應用程式交付到 Kubernetes。我們將使用這個範例：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

我將其複製到一個文件中，然後透過以下方式將其套用到我的 Kubernetes 叢集：

kubectl apply -f ksvc.yaml -n default

交付「helloworld-go」後，我們可以在叢集中查看 Knative 創建的資源 服務:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

部署 kservice 時，會啟動具有「helloworld-go」映像的 pod。如果沒有流量，Pod 數量將減少到零。反之亦然，如果同時請求的數量超過某個可設定的閾值，Pod 的數量就會增加。

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative 使用內部 Knative API 中的特殊「入口」資源來配置其入口。 Gloo 使用此 API 作為其配置來提供類似 PaaS 的功能，包括藍綠部署模型、自動 TLS 實作、逾時和其他進階路由功能。

一段時間後，我們看到我們的 Pod 消失了（因為沒有傳入流量）：

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

最後我們將嘗試聯繫他們。您可以使用以下方式輕鬆輕鬆地取得 Knative Proxy 的 URL glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

未安裝 glooctl 在kube服務中可以看到位址和連接埠：

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

讓我們使用 cURL 來運行一些資料：

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative 使用 Gloo 的高效能、全端 API 網關，在開箱即用的 Kubernetes 之上為開發人員提供了一個近乎 PaaS 的平台。這篇文章僅觸及 Knative 廣泛的自訂選項和附加功能的表面。格魯也一樣！

儘管 Knative 仍然是一個年輕的項目，但其團隊每六週就會發布新版本，高級功能的實現已經開始，例如自動 TLS 部署、控制面板自動縮放等。多個雲端公司之間合作的結果，並且作為 Google 新 Cloud Run 產品的基礎，Knative 很有可能成為 Kubernetes 上無伺服器運算和 PaaS 的主要選擇。關注新聞！

來自南橋編輯
讀者的意見對我們很重要，因此我們邀請您參與一項與未來有關 Knative、Kubernetes、無伺服器運算的文章相關的簡短調查：

只有註冊用戶才能參與調查。 登入， 請。

繼續撰寫有關 Knative 和無伺服器運算的文章和指南嗎？

  • 是的，請。

  • 不，謝謝。

28 位用戶投票。 4 名用戶棄權。

來源： www.habr.com

添加評論