在本系列博客的第1部分中，我們介紹了這樣一種想法，即Kubernetes Operator（在大規模部署時）可以消耗大量資源，無論是實際資源消耗還是可調度容量的消耗。我們還介紹了一種想法，即無伺服器技術可以通過在活動控制器部署空閒時減少其規模來減少對Kubernetes集群的影響。

在第2部分中，我們僅基於在閒置時將Pod實例的數量縮放為零的想法，介紹了一種無需更改源即可減少現有控制器的資源開銷的技術。

在這個由三部分組成的系列文章的最後一篇文章中，我們將展示如何適應現有Operator，以利用Knative服務提供的內置的從零到零的功能。

Operator架構

在較低的級別上，典型操作員的主要任務是監視Kubernetes後備存儲（etcd）中發生的更改並對它們做出反應（例如，通過安裝和管理Kafka集群）。 Informer對象監視事件並將接收到的事件放入工作隊列中，以確保在給定時間對於給定對象只有一個協調器（下圖中的Handle Object）處於活動狀態。 Informer對象不斷監視事件，而協調器僅在將項目插入工作隊列中時才運行，這是在Knative服務中應用從零縮放的主要候選對象。

從0.6開始，Knative Eventing為Kubernetes API伺服器事件提供了Cloud Event導入器（或源）。 通過將此導入程序與Knative服務提供的「從零縮放」功能結合使用，我們可以實現調節器的「從零縮放」的目標。 在這種新的體系結構中，通知程序不會縮放到零，但是現在可以在多個Operator之間共享，從而大大降低了整體資源消耗。

無伺服器樣本控制器

讓我們展示如何使現有控制器適應在Knative中運行。 考慮Kubernetes示例控制器項目，該項目演示了如何直接在Go客戶端庫的頂部實現操作符。 該項目定義了一個稱為Foo的新CRD，並提供了一個控制器來為Foo對象創建部署。

apiVersion: samplecontroller.k8s.io/v1alpha1

kind: Foo

metadata:

name: example-foo

spec:

deploymentName: example-foo

replicas: 1

generates:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: example-foo

ownerReferences:

- apiVersion: samplecontroller.k8s.io/v1alpha1

blockOwnerDeletion: true

controller: true

kind: Foo

name: example-foo

spec:

...

修改示例代碼以使Foo運算符無伺服器

我們修改了原始示例代碼，以使Foo運算符變得無伺服器（新代碼可在GitHub上找到）。 這是我們所做的：

我們刪除了所有通知程序的創建和配置：通知程序監視Kubernetes後備存儲中發生的更改。 現在，這是由API伺服器事件源完成的（請參見下文）。

我們添加了一個通用通知程序，以偵聽傳入的雲事件並將它們排隊在工作隊列中：該通知程序將雲事件的消耗與處理分離，以進行垂直擴展，（最重要的是）確保在給定的時間僅協調一個給定的對象。

相反，對索引器（內部Informer組件）的所有調用都是針對API伺服器進行的：不言自明。

我們添加了一個配置文件來監視Foo和Deployment類型的事件：

apiVersion: sources.eventing.knative.dev/v1alpha1

kind: ApiServerSource

metadata:

name: example-foo

spec:

serviceAccountName: example-foo

resources:

- apiVersion: samplecontroller.knative.io/v1alpha1

kind: Foo

- apiVersion: apps/v1

kind: Deployment

controller: true

sink:

apiVersion: serving.knative.dev/v1alpha1

kind: Service

name: example-foo-reconcile

資源部分指定要監視的對象類型（Foo和Deployment）。 controller：true告訴API伺服器源控制器監視部署對象，並發送一個包含對控制它的對象的引用的雲事件。

我們添加了一個配置文件以將協調程序部署為Knative服務：

apiVersion: serving.knative.dev/v1alpha1

kind: Service

metadata:

name: example-foo-reconcile

spec:

runLatest:

configuration:

revisionTemplate:

metadata:

annotations:

autoscaling.knative.dev/maxScale: "1"

autoscaling.knative.dev/window: "30s"

spec:

container:

image: $DOCKER_USER/knative-sample-controller

serviceAccountName: example-foo-reconcile

我們添加了兩個注釋來控制Knative pod自動縮放器的行為。第一個將並發Pod的最大值設置為一個，這樣它們就不會互相干擾。第二個調整穩定窗口，以便給協調器足夠的時間來完成。

您可以按照以下說明嘗試自己運行它，以觀察調節器縮小到零的情況。

與原始樣本控制器示例相比，Knative變量確實有一些限制：

• 由於Knative事件0.6中的事件篩選有限，因此它不監視部署。
• 如果協調器容器崩潰，事件導入器將不重播事件，從而可能使系統處於不一致狀態
• 沒有定期的事件同步

所有這些限制將在以後的Knative事件發行版中解決。

無伺服器的未來

這篇文章結束了我們有關無伺服器操作員的系列文章。我們已經展示了兩種方法來將操作員縮減到零，第一種適合現有的操作員部署，第二種利用Knative內置的無伺服器功能。你選！

原文：https://www.ibm.com/cloud/blog/new-builders/being-frugal-with-kubernetes-operators-part-3

本文：http://jiagoushi.pro/node/875

討論：請加入知識星球【首席架構師圈】或者微信圈子【首席架構師圈】