聊聊 Kubectl scale 命令的優秀實踐
kubectl scale 是幫助我們管理 Kubernetes 部署的眾多工具之一。在本文中我們將了解如何使用此工具以及最佳使用實踐。
概述
kubectl scale命令通過調整正在運行的容器的數量來立即縮放應用程序。這是增加部署副本數量的最快、最簡單的方法，可用于應對服務高峰以及日常維護變更。
在本文中，我們將了解如何使用kubectl scale來?擴展一個簡單的Kubernetes Deployment?，同時，我們還將更深入的了解該命令相關的各種參數。最終形成kubectl scale的最佳實踐，以及一些用于調整 Kubernetes 副`本數的替代方法。
kubectl scale用例
kubectl scale用于更改Kubernetes deployment, replica set, replication controller和 statefulset 等對象的副本數碼。當我們增加副本數時，Kubernetes將啟動新的Pod來擴我們的服務。降低副本數將導致 Kubernetes 優雅地終止一些 pod，從而釋放集群資源。
我們可以運行kubectl scale來手動調整應用程序的副本數，以響應不斷變化的服務容量需求。增加的流量負載可以通過增加副本數來處理，提供更多的應用程序實例來服務用戶流量。當業務突發降低的時候，可以減少副本的數量。這有助于通過避免使用不需要的資源來降低成本。
使用 kubectl
kubectl scale最基本的用法是這樣的：
$ kubectl scale --replicas=3 deployment/demo-deployment執行此命令將調整名為demo-deployment 的部署，使其擁有三個正在運行的副本。我們可以通過替換其名稱而不是部署來定位不同類型的資源：
# ReplicaSet
$ kubectl scale --replicas=3 rs/demo-replicaset
# ReplicationController
$ kubectl scale --replicas=3 rc/demo-replicationcontroller
# StatefulSet
$ kubectl scale --replicas=3 sts/demo-statefulset
基礎縮放
現在我們將看一個使用kubectl scale擴展部署的完整示例。這是一個定義簡單部署的 YAML 文件：
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-deployment
spec:
replicas: 1
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: nginx
image: nginx:latest
將此 YAML 保存到工作目錄中的demo-deployment.yaml 。接下來，使用kubectl將部署添加到我們的集群：
$ kubectl apply -f demo-deployment.yaml
deployment.apps/demo-deployment created
現在運行kubectl get pods命令來查看已為部署創建的 pod：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
demo-deployment-86897ddbb-jl6r6 1/1 Running 0 33s
只有一個 pod 正在運行。這是意料之中的，因為部署的清單在其spec.replicas字段中聲明了一個副本。
單個副本不足以用于生產應用程序。如果托管 pod 的節點出于任何原因離線，我們可能會遇到停機時間。使用kubectl scale增加副本數以提供更多空間：
$ kubectl scale --replicas=5 deployment/demo-deployment
deployment.apps/demo-deployment scaled
重復kubectl get pods命令以確認部署已成功擴容：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
demo-deployment-86897ddbb-66lzc 1/1 Running 0 46s
demo-deployment-86897ddbb-66s9d 1/1 Running 0 46s
demo-deployment-86897ddbb-jl6r6 1/1 Running 0 3m33s
demo-deployment-86897ddbb-sgcjb 1/1 Running 0 46s
demo-deployment-86897ddbb-tgvnw 1/1 Running 0 46s
現在有五個 Pod 正在運行。從AGE列可以看到scale命令保留了原來的 pod 并新增了 4 個。
經過進一步思考，我們可能會決定此應用程序不需要五個副本。它只運行一個靜態 NGINX Web 服務器，因此每個用戶請求的資源消耗應該很低。再次使用scale命令來降低副本數并避免浪費集群容量：
$ kubectl scale --replicas=3 deployment/demo-deployment
deployment.apps/demo-deployment created
重復kubectl get pods命令：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
demo-deployment-86897ddbb-66lzc 1/1 Terminating 0 3m21s
demo-deployment-86897ddbb-66s9d 1/1 Terminating 0 3m21s
demo-deployment-86897ddbb-jl6r6 1/1 Running 0 6m8s
demo-deployment-86897ddbb-sgcjb 1/1 Running 0 3m21s
demo-deployment-86897ddbb-tgvnw 1/1 Running 0 3m21s
Kubernetes 已將兩個正在運行的 pod 標記為終止。這會將正在運行的副本計數減少到請求的三個 pod。選擇要驅逐的 pod 會被發送一個SIGTERM(https://www.containiq.com/post/sigterm-signal-15-linux-graceful-termination-exit-code-143) 信號并允許優雅地終止(https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace)。停止后，它們將從 pod 列表中刪除。
條件縮放
有時我們可能想要擴展資源，但前提是已經有特定數量的副本在運行。這可以避免意外覆蓋以前的副本，例如集群中其他用戶所做的更改。
在命令中包含--current-replicas標志可以達到效果：
$ kubectl scale --current-replicas=3 --replicas=5 deployment/demo-deployment
deployment.apps/demo-deployment scaled
此示例將演示deployment擴展到五個副本，但前提是當前有三個副本正在運行。--current -replicas值始終完全匹配；我們不能將條件表示為“小于”或“大于”特定計數。
擴展多個資源
當我們提供多個名稱作為參數時， kubectl scale?命令可以一次縮放多個資源。每個資源都將縮放到由--replicas標志設置的相同副本計數。
$ kubectl scale --replicas=5 deployment/app deployment/database
deployment.apps/app scaled
deployment.apps/database scaled
此命令將應用程序和數據庫deployment擴展到每個五個副本。
我們可以通過提供--all標志來擴展特定類型的每個資源，例如此示例以擴展默認命名空間中的所有部署：
$ kubectl scale --all --replicas=5 --namespace=default deployment
deployment.apps/app scaled
deployment.apps/database scaled
這會選擇當前活動命名空間內的每個匹配資源?？s放的對象顯示在命令的輸出中。
我們可以對使用--selector?標志縮放的對象進行精細控制。這我們可以使用標準選擇語法根據對象的標簽(https://www.containiq.com/post/using-kubernetes-labels-selectors-annotations) 過濾對象。這是一個使用app-name=demo-app標簽擴展所有部署的示例：
$ kubectl scale --replicas=5 --selector=app-name=demo-app deployment
deployment.apps/app scaled
deployment.apps/database scaled
更改超時
--timeout標志設置 Kubectl 在放棄縮放操作之前將等待的時間。默認情況下，沒有等待期。該標志接受可讀的時間值，例如5m或1h：
$ kubectl scale --replicas=5 --timeout=1m deployment/demo-deployment如果無法立即完成縮放更改，這可以讓我們避免長時間的終端掛起。盡管kubectl scale是一個命令式命令，但在將新 pod 調度到節點時，對縮放的更改有時可能需要幾分鐘才能完成。
最佳實踐
使用kubectl scale通常是擴展工作負載的最快、最可靠的方法。但是，為了安全操作，需要記住一些最佳實踐。如下所示：
- 避免過于頻繁地縮放：對副本計數的更改應響應特定事件，例如導致請求運行緩慢或丟包的擁塞。最好分析當前的服務性能，估算一下當前需要滿足性能的資源需求，同時也預估一下未來的增長容量。避免過于頻繁地擴展應用程序，因為在創建和終止POD時，每個操作都可能導致延遲。
- 副本縮小到零將會導致服務停止。您可以運行kubectl scale--replicas=0?，這將刪除選定對象中的所有容器。通過使用該命令，調整replicas的參數，從而實現向上的擴容。
- 確保我們選擇了正確的對象。沒有確認提示，因此請務必注意正在選擇的對象。按名稱手動選擇對象是最安全的方法，可以防止您意外地擴展應用程序的其他部分，從而導致停機或資源浪費。
- 使用 --current-replicas?來避免意外。使用--current replications?標志可以確保僅當當前計數符合您的期望時，縮放才會更改，從而提高安全性。否則，您可能會無意中覆蓋其他用戶或Kubernetes autoscaler應用的縮放更改。
kubectl Scale的替代方式
運行kubectl scale?是一項必不可少的操作，它對集群有著直接的影響。您正在指示Kubernetes盡快提供特定數量的副本。如果使用命令式的kubectl create?命令創建對象，這是合乎邏輯的，但是如果最初使用聲明性的YAML文件運行kubectl apply?，則這是不合適的，如上所示。運行scale?命令后，集群中的副本數量將不同于YAML的spec.replications?字段中定義的副本數量。更好的做法是修改YAML文件，然后將其重新應用于集群。
首先將spec.replicas字段更改為我們所需的新副本數：
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-deployment
spec:
replicas: 5
selector:
matchLabels:
app: demo-app
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: nginx
image: nginx:latest
現在對修改后的文件重復kubectl apply命令：
$ kubectl apply -f demo-deployment.yaml
kubectl? 將自動區分更改并采取措施將集群的狀態演變為文件中聲明的狀態。這將導致 Pod 被自動創建或終止，因此運行實例的數量再次與spec.replicas字段匹配。
kubectl scale的另一個替代方案是 Kubernetes 對自動縮放的支持。配置此機制允許 Kubernetes 根據 CPU 使用率和網絡活動等指標在配置的最小值和最大值之間自動調整副本計數。
最后的總結
kubectl scale命令是擴展 Kubernetes deployments, replica sets, replication controllers以及stateful sets的通用方式。它在每次調用時以一個或多個對象為目標，并對其進行縮放，以便運行指定數量的 pod。
我們可以選擇設置條件，因此只有在存在特定數量的現有副本時才會更改比例，從而避免在錯誤方向上意外調整大小。
同時我們也希望能夠遵循一些本文所提到的最佳時實踐，從而平穩，可靠的實現資源的擴縮容。
*原文：https://www.containiq.com/post/kubectl-scale?
