云和安全管理服務(wù)專家新鈦云服 祝祥翻譯
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/v1kind: Deploymentmetadata:name: demo-deploymentspec:replicas: 1selector: matchLabels: app: demo-apptemplate: metadata: labels: app: demo-app spec: containers: – name: nginx image: nginx:latest
將此 YAML 保存到工作目錄中的demo-deployment.yaml 。接下來,使用kubectl將部署添加到我們的集群:
$ kubectl apply -f demo-deployment.yamldeployment.apps/demo-deployment created
現(xiàn)在運(yùn)行kubectl get pods命令來查看已為部署創(chuàng)建的 pod:
$ kubectl get podsNAME READY STATUS RESTARTS AGEdemo-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-deploymentdeployment.apps/demo-deployment scaled
重復(fù)kubectl get pods命令以確認(rèn)部署已成功擴(kuò)容:
$ kubectl get podsNAME READY STATUS RESTARTS AGEdemo-deployment-86897ddbb-66lzc 1/1 Running 0 46sdemo-deployment-86897ddbb-66s9d 1/1 Running 0 46sdemo-deployment-86897ddbb-jl6r6 1/1 Running 0 3m33sdemo-deployment-86897ddbb-sgcjb 1/1 Running 0 46sdemo-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-deploymentdeployment.apps/demo-deployment created
重復(fù)kubectl get pods命令:
$ kubectl get podsNAME READY STATUS RESTARTS AGEdemo-deployment-86897ddbb-66lzc 1/1 Terminating 0 3m21sdemo-deployment-86897ddbb-66s9d 1/1 Terminating 0 3m21sdemo-deployment-86897ddbb-jl6r6 1/1 Running 0 6m8sdemo-deployment-86897ddbb-sgcjb 1/1 Running 0 3m21sdemo-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-deploymentdeployment.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/databasedeployment.apps/app scaleddeployment.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 deploymentdeployment.apps/app scaleddeployment.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)選擇語法根據(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 deploymentdeployment.apps/app scaleddeployment.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/v1kind: Deploymentmetadata:name: demo-deploymentspec:replicas: 5selector: matchLabels: app: demo-apptemplate: 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