kubectl scale 是幫助我們管理 Kubernetes 部署的眾多工具之一。在本文中我們將了解如何使用此工具以及最佳使用實(shí)踐。

概述

kubectl scale命令通過調(diào)整正在運(yùn)行的容器的數(shù)量來立即縮放應(yīng)用程序。這是增加部署副本數(shù)量的最快、最簡(jiǎn)單的方法，可用于應(yīng)對(duì)服務(wù)高峰以及日常維護(hù)變更。

在本文中，我們將了解如何使用kubectl scale來?擴(kuò)展一個(gè)簡(jiǎn)單的Kubernetes Deployment?，同時(shí)，我們還將更深入的了解該命令相關(guān)的各種參數(shù)。最終形成kubectl scale的最佳實(shí)踐，以及一些用于調(diào)整 Kubernetes 副`本數(shù)的替代方法。

kubectl scale用例

kubectl scale用于更改Kubernetes deployment, replica set, replication controller和 statefulset 等對(duì)象的副本數(shù)碼。當(dāng)我們?cè)黾痈北緮?shù)時(shí)，Kubernetes將啟動(dòng)新的Pod來擴(kuò)我們的服務(wù)。降低副本數(shù)將導(dǎo)致 Kubernetes 優(yōu)雅地終止一些 pod，從而釋放集群資源。

我們可以運(yùn)行kubectl scale來手動(dòng)調(diào)整應(yīng)用程序的副本數(shù)，以響應(yīng)不斷變化的服務(wù)容量需求。增加的流量負(fù)載可以通過增加副本數(shù)來處理，提供更多的應(yīng)用程序?qū)嵗齺矸?wù)用戶流量。當(dāng)業(yè)務(wù)突發(fā)降低的時(shí)候，可以減少副本的數(shù)量。這有助于通過避免使用不需要的資源來降低成本。

使用 kubectl

kubectl scale最基本的用法是這樣的：

$ kubectl scale --replicas=3 deployment/demo-deployment

執(zhí)行此命令將調(diào)整名為demo-deployment 的部署，使其擁有三個(gè)正在運(yùn)行的副本。我們可以通過替換其名稱而不是部署來定位不同類型的資源：

# ReplicaSet
$ kubectl scale --replicas=3 rs/demo-replicaset


# ReplicationController
$ kubectl scale --replicas=3 rc/demo-replicationcontroller


# StatefulSet
$ kubectl scale --replicas=3 sts/demo-statefulset

基礎(chǔ)縮放

現(xiàn)在我們將看一個(gè)使用kubectl scale擴(kuò)展部署的完整示例。這是一個(gè)定義簡(jiǎn)單部署的 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

現(xiàn)在運(yùn)行kubectl get pods命令來查看已為部署創(chuàng)建的 pod：

$ kubectl get pods


NAME   READY   STATUS   RESTARTS   AGE
demo-deployment-86897ddbb-jl6r6    1/1   Running    0   33s

只有一個(gè) pod 正在運(yùn)行。這是意料之中的，因?yàn)椴渴鸬那鍐卧谄鋝pec.replicas字段中聲明了一個(gè)副本。

單個(gè)副本不足以用于生產(chǎn)應(yīng)用程序。如果托管 pod 的節(jié)點(diǎn)出于任何原因離線，我們可能會(huì)遇到停機(jī)時(shí)間。使用kubectl scale增加副本數(shù)以提供更多空間：

$ kubectl scale --replicas=5 deployment/demo-deployment
deployment.apps/demo-deployment scaled

重復(fù)kubectl get pods命令以確認(rèn)部署已成功擴(kuò)容：

$ 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

現(xiàn)在有五個(gè) Pod 正在運(yùn)行。從AGE列可以看到scale命令保留了原來的 pod 并新增了 4 個(gè)。

經(jīng)過進(jìn)一步思考，我們可能會(huì)決定此應(yīng)用程序不需要五個(gè)副本。它只運(yùn)行一個(gè)靜態(tài) NGINX Web 服務(wù)器，因此每個(gè)用戶請(qǐng)求的資源消耗應(yīng)該很低。再次使用scale命令來降低副本數(shù)并避免浪費(fèi)集群容量：

$ kubectl scale --replicas=3 deployment/demo-deployment
deployment.apps/demo-deployment created

重復(fù)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 已將兩個(gè)正在運(yùn)行的 pod 標(biāo)記為終止。這會(huì)將正在運(yùn)行的副本計(jì)數(shù)減少到請(qǐng)求的三個(gè) pod。選擇要驅(qū)逐的 pod 會(huì)被發(fā)送一個(gè)SIGTERM(https://www.containiq.com/post/sigterm-signal-15-linux-graceful-termination-exit-code-143) 信號(hào)并允許優(yōu)雅地終止(https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace)。停止后，它們將從 pod 列表中刪除。

條件縮放

有時(shí)我們可能想要擴(kuò)展資源，但前提是已經(jīng)有特定數(shù)量的副本在運(yùn)行。這可以避免意外覆蓋以前的副本，例如集群中其他用戶所做的更改。

在命令中包含--current-replicas標(biāo)志可以達(dá)到效果：

$ kubectl scale --current-replicas=3 --replicas=5 deployment/demo-deployment
deployment.apps/demo-deployment scaled

此示例將演示deployment擴(kuò)展到五個(gè)副本，但前提是當(dāng)前有三個(gè)副本正在運(yùn)行。--current -replicas值始終完全匹配；我們不能將條件表示為“小于”或“大于”特定計(jì)數(shù)。

擴(kuò)展多個(gè)資源

當(dāng)我們提供多個(gè)名稱作為參數(shù)時(shí)， kubectl scale?命令可以一次縮放多個(gè)資源。每個(gè)資源都將縮放到由--replicas標(biāo)志設(shè)置的相同副本計(jì)數(shù)。

$ kubectl scale --replicas=5 deployment/app deployment/database
deployment.apps/app scaled
deployment.apps/database scaled

此命令將應(yīng)用程序和數(shù)據(jù)庫(kù)deployment擴(kuò)展到每個(gè)五個(gè)副本。

我們可以通過提供--all標(biāo)志來擴(kuò)展特定類型的每個(gè)資源，例如此示例以擴(kuò)展默認(rèn)命名空間中的所有部署：

$ kubectl scale --all --replicas=5 --namespace=default deployment
deployment.apps/app scaled
deployment.apps/database scaled

這會(huì)選擇當(dāng)前活動(dòng)命名空間內(nèi)的每個(gè)匹配資源?？s放的對(duì)象顯示在命令的輸出中。

我們可以對(duì)使用--selector?標(biāo)志縮放的對(duì)象進(jìn)行精細(xì)控制。這我們可以使用標(biāo)準(zhǔn)選擇語(yǔ)法根據(jù)對(duì)象的標(biāo)簽(https://www.containiq.com/post/using-kubernetes-labels-selectors-annotations) 過濾對(duì)象。這是一個(gè)使用app-name=demo-app標(biāo)簽擴(kuò)展所有部署的示例：

$ kubectl scale --replicas=5 --selector=app-name=demo-app deployment
deployment.apps/app scaled
deployment.apps/database scaled

更改超時(shí)

--timeout標(biāo)志設(shè)置 Kubectl 在放棄縮放操作之前將等待的時(shí)間。默認(rèn)情況下，沒有等待期。該標(biāo)志接受可讀的時(shí)間值，例如5m或1h：

$ kubectl scale --replicas=5 --timeout=1m deployment/demo-deployment

如果無法立即完成縮放更改，這可以讓我們避免長(zhǎng)時(shí)間的終端掛起。盡管kubectl scale是一個(gè)命令式命令，但在將新 pod 調(diào)度到節(jié)點(diǎn)時(shí)，對(duì)縮放的更改有時(shí)可能需要幾分鐘才能完成。

最佳實(shí)踐

使用kubectl scale通常是擴(kuò)展工作負(fù)載的最快、最可靠的方法。但是，為了安全操作，需要記住一些最佳實(shí)踐。如下所示：

• 避免過于頻繁地縮放：對(duì)副本計(jì)數(shù)的更改應(yīng)響應(yīng)特定事件，例如導(dǎo)致請(qǐng)求運(yùn)行緩慢或丟包的擁塞。最好分析當(dāng)前的服務(wù)性能，估算一下當(dāng)前需要滿足性能的資源需求，同時(shí)也預(yù)估一下未來的增長(zhǎng)容量。避免過于頻繁地?cái)U(kuò)展應(yīng)用程序，因?yàn)樵趧?chuàng)建和終止POD時(shí)，每個(gè)操作都可能導(dǎo)致延遲。
• 副本縮小到零將會(huì)導(dǎo)致服務(wù)停止。您可以運(yùn)行kubectl scale--replicas=0?，這將刪除選定對(duì)象中的所有容器。通過使用該命令，調(diào)整replicas的參數(shù)，從而實(shí)現(xiàn)向上的擴(kuò)容。
• 確保我們選擇了正確的對(duì)象。沒有確認(rèn)提示，因此請(qǐng)務(wù)必注意正在選擇的對(duì)象。按名稱手動(dòng)選擇對(duì)象是最安全的方法，可以防止您意外地?cái)U(kuò)展應(yīng)用程序的其他部分，從而導(dǎo)致停機(jī)或資源浪費(fèi)。
• 使用 --current-replicas?來避免意外。使用--current replications?標(biāo)志可以確保僅當(dāng)當(dāng)前計(jì)數(shù)符合您的期望時(shí)，縮放才會(huì)更改，從而提高安全性。否則，您可能會(huì)無意中覆蓋其他用戶或Kubernetes autoscaler應(yīng)用的縮放更改。

kubectl Scale的替代方式

運(yùn)行kubectl scale?是一項(xiàng)必不可少的操作，它對(duì)集群有著直接的影響。您正在指示Kubernetes盡快提供特定數(shù)量的副本。如果使用命令式的kubectl create?命令創(chuàng)建對(duì)象，這是合乎邏輯的，但是如果最初使用聲明性的YAML文件運(yùn)行kubectl apply?，則這是不合適的，如上所示。運(yùn)行scale?命令后，集群中的副本數(shù)量將不同于YAML的spec.replications?字段中定義的副本數(shù)量。更好的做法是修改YAML文件，然后將其重新應(yīng)用于集群。

首先將spec.replicas字段更改為我們所需的新副本數(shù)：

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

現(xiàn)在對(duì)修改后的文件重復(fù)kubectl apply命令：

$ kubectl apply -f demo-deployment.yaml

kubectl? 將自動(dòng)區(qū)分更改并采取措施將集群的狀態(tài)演變?yōu)槲募新暶鞯臓顟B(tài)。這將導(dǎo)致 Pod 被自動(dòng)創(chuàng)建或終止，因此運(yùn)行實(shí)例的數(shù)量再次與spec.replicas字段匹配。

kubectl scale的另一個(gè)替代方案是 Kubernetes 對(duì)自動(dòng)縮放的支持。配置此機(jī)制允許 Kubernetes 根據(jù) CPU 使用率和網(wǎng)絡(luò)活動(dòng)等指標(biāo)在配置的最小值和最大值之間自動(dòng)調(diào)整副本計(jì)數(shù)。

最后的總結(jié)

kubectl scale命令是擴(kuò)展 Kubernetes deployments, replica sets, replication controllers以及stateful sets的通用方式。它在每次調(diào)用時(shí)以一個(gè)或多個(gè)對(duì)象為目標(biāo)，并對(duì)其進(jìn)行縮放，以便運(yùn)行指定數(shù)量的 pod。

我們可以選擇設(shè)置條件，因此只有在存在特定數(shù)量的現(xiàn)有副本時(shí)才會(huì)更改比例，從而避免在錯(cuò)誤方向上意外調(diào)整大小。

同時(shí)我們也希望能夠遵循一些本文所提到的最佳時(shí)實(shí)踐，從而平穩(wěn)，可靠的實(shí)現(xiàn)資源的擴(kuò)縮容。

*原文：https://www.containiq.com/post/kubectl-scale?