在本系列博客的第1部分中，我們介紹了這樣一種想法，即Kubernetes運營商（在大規模部署時）可以消耗大量資源，無論是實際資源消耗還是可調度容量的消耗。我們還介紹了一種想法，即無伺服器技術可以通過在活動控制器部署空閒時減少其規模來減少對Kubernetes集群的影響。在本文中，我們將基於閒置時將Pod實例的數量縮放為零的想法，介紹一種無需進行源修改即可減少現有控制器的資源開銷的技術。
將控制器縮放至零
除了核心的Kubernetes平台之外，大多數運營商和其他通用控制器都使用Deployments或StatefulSets進行部署。這兩種構造都具有將標度設置為特定值的能力。然後，Kubernetes平台添加或刪除吊艙以實現所需的價值。但是，將控制器擴展到一個以上的實例通常僅提供冗餘。這是由於內置的一致性檢查所致，該檢查可確保控制器容器不會相互干擾。以下是許多控制器和操作員所特有的部署：
如果將此類部署的規模設置為0，Kubernetes控制器管理器將終止任何正在運行的Pod，從而使我們沒有任何活動的控制器實例來處理資源事件。實際上，在更改比例時，我們將禁用當前控制器的事件處理。
在最簡單的情況下，控制器停止時不會發生資源修改，並且在修改監視的資源之前會恢復控制器規模。在這種情況下，只需將部署規模設置為大於零的標量值，即可將控制器恢復到之前的狀態。但是，當控制器停止時發生資源修改的情況又如何呢？
Kubernetes中的和解是基於稱為「級別觸發」的概念構建的。在級別觸發的系統中，對帳是針對整個狀態進行的，而不是依賴於單個事件或自上次對帳以來發生的那些事件的順序。當進行擴展時，我們的控制器將僅查看要監視的資源，並將其狀態與目標資源協調一致，而不管過渡期間發生了多少個人更改。要了解有關Kubernetes中的電平觸發的更多信息，請查看James Bowes的文章「 Kubernetes中的電平觸發和對帳」。
自動縮放到零
如果Kubernetes控制器部署可以容忍從零擴展到零並且可以再次備份，那麼這可以根據實際活動自動完成嗎？絕對是，這是控制器零縮放器的目標。
控制器零縮放器本身就是一個Kubernetes控制器，它監視Kubernetes API的活動，一旦它們變得空閒，就會自動按比例縮小控制器，稍後在發生相關資源修改後恢復縮放。由於它是由各個控制器部署上的注釋完全驅動的，因此可以在現有Kubernetes部署中啟用零標度控制器而無需進行原始碼修改。
圖2顯示了控制器零縮放器如何針對正在運行的控制器部署進行工作。
啟動時，控制器零縮放器開始監視具有一組批註的部署。這些注釋將部署標識為控制器零縮放器應對其執行操作的控制器。一旦確定部署正在管理中，控制器零縮放器便開始監視與該控制器相關的API伺服器活動。一旦在一段時間內沒有發生任何資源修改，就確定該單個控制器為空閒，並且其規模設置為零。
同時，控制器零縮放器會繼續監視控制器需要處理的任何Kubernetes API伺服器活動。如果確實發生資源更改，將恢復規模，這將對控制器吊艙做出反應。最終結果是，在發生諸如「 kubectl apply」之類的操作之後的幾分鐘內，下遊資源修改將完成。
讓我們來看一個使用Banzai Cloud中Istio Operator的示例。我們將執行以下順序：
- 安裝Istio操作員。
- 安裝控制器零縮放器。
- 以零比例標註並觀察Istio Operator。
- 創建一個Istio資源，並觀察Istio Operator擴大規模並處理資源修改。
首先，將通過克隆項目並利用makefile來安裝相關的「自定義資源定義」（CRD）和用於部署控制器容器的StatefulSet，來安裝Istio Operator：
git clone [email protected]:banzaicloud/istio-operator.git
cd istio-operator
make deploy
通過查看正在運行的實例數（應為1）來驗證此部署是否成功。 您可能需要等待片刻才能激活控制器，因為首先需要拉動圖像。
kubectl get statefulsets -n istio-system istio-operator-controller-manager
NAME DESIRED CURRENT AGE
istio-operator-controller-manager 1 1 8s
現在，讓我們部署控制器零縮放器。 由於Docker映像尚未公開可用，因此我們需要首先構建該映像。
再次，我們將驗證控制器部署實際上已經開始：
kubectl get deployments -n controller-zero-scaler controller-zero-scaler
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
controller-zero-scaler 1 1 1 1 21s
現在，讓我們來看看自動縮放的作用。 首先，我們需要在這個特定的控制器上啟用零縮放，我們將使用一組注釋來做到這一點。
kubectl annotate -n istio-system statefulset -l \\
controller-tools.k8s.io='1.0' \\
controller-zero-scaler/idleTimeout='30s' \\
controller-zero-scaler/watchedKinds='[{"apiVersion": "istio.banzaicloud.io/v1beta1", "Kind": "Istio"}]'
statefulset.apps/istio-operator-controller-manager annotated
這將添加兩個與零標度活動相關的注釋：
- idleTimeout：定義將控制器確定為空閒狀態的速度。 在這種情況下，我們需要至少等待30秒才能觀察Istio控制器的當前狀態
- watchedKinds：指示哪些API對象對該控制器有意義。 對於Istio運算符，它對名稱為「 Istio」的自定義資源定義感興趣。
等待至少30秒後，您應該看到Istio控制器容器已停止：
sleep 30 && kubectl get statefulsets --all-namespaces
NAMESPACE NAME DESIRED CURRENT AGE
istio-system istio-operator-controller-manager 0 0 2m36s
到目前為止，我們已成功將Istio控制器縮放為零。 現在，我們來看看更改Istio資源時會發生什麼。 讓我們使用istio-operator目錄中提供的示例：
kubectl apply -f config/samples/istio_v1beta1_istio.yaml
現在，我們可以通過查看Istio控制器的容器數量來驗證放大是否成功。 我們還可以檢查下游操作員動作是否發生。 對於Istio Operator，將安裝一些自定義資源定義（CRD）（以及多個部署）。
# Here we should see 1 available as long as we do not wait too long!
kubectl get deployments -n controller-zero-scaler controller-zero-scaler
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
controller-zero-scaler 1 1 1 1 7m33s
# There should be 55 CRDs as well as 8 deployments
kubectl get crd | grep -i istio.io | wc -l
55
kubectl get deployments --all-namespaces | grep istio | wc -l
博客系列的第3部分
控制器零標度解決方案非常適合現有的控制器實現，因為可以在單個集群上啟用它而無需進行任何源修改。 這意味著您可以直接購買操作員，並帶有正確的注釋，即可立即受益。
Knative是另一種在運營商和Kubernetes控制器之外具有廣泛吸引力的無伺服器技術。 在本系列的最後一篇博文中，我們將探討如何將Knative事件（使用Kubernetes API Server作為事件源）用作構建Kubernetes控制器和運算符的基礎。
原文：https://www.ibm.com/cloud/blog/new-builders/being-frugal-with-kubernetes-operators-part-2
本文：http://jiagoushi.pro/node/874/
討論：請加入知識星球【首席架構師圈】或者微信圈子【首席架構師圈】