作為一個久負盛名的容器編排平臺，Kubernetes具有很多優(yōu)勢，其自動化能力尤其突出，具體體現(xiàn)在工作負載的發(fā)現(xiàn)、自愈和應(yīng)用伸縮等方面。

然而，Kubernetes也在不斷地進行升級，并不總是能開箱即用地用于生產(chǎn)環(huán)境。

本文提供了一系列應(yīng)當(dāng)重點考慮的Kubernetes最佳實踐，用以提高您的 K8s 的安全性和性能，并控制成本。

1、始終保持與最新穩(wěn)定版同步

通常，應(yīng)該始終將 K8s 升級到最新穩(wěn)定版本，以應(yīng)用最新的安全或性能的修復(fù)與改進，也會獲得更多來自社區(qū)和供應(yīng)商提供的支持，從而避免可能危及服務(wù)交付的安全和性能問題，以及成本方面的異常。

2、對清單進行檢查

可能你覺得 YAML 很難使用，那么不妨用一下 yamllint，它可以在一個文件中處理多個文檔。

還有專門針對 Kubernetes 的 linter。比如，你可以使用 kube-score 來分析你的清單，從而遵循最佳實踐。 Kubeval 也能用來分析你的清單，但是它只是檢查有效性。Kubernetes 1.13 的 kubectl 提供的 dry-run 也可以用來檢測清單而不實際應(yīng)用它，所以，也可以使用這個特性來檢查你為 K8s 準備的 YAML 文件。

3、對各種配置文件做好版本控制

最好將 Deployment、Service 和 Ingress 等所有配置文件存儲在版本控制系統(tǒng)中。Github 是最流行的開源分布式版本控制平臺，也可以使用 Gitlab、BitBucket 和 SourceForge 等其它平臺。

要在將代碼推送到 Kubernetes 集群之前就對它們進行版本化管理，這樣就可以跟蹤代碼的變更內(nèi)容及變更人。這樣做，你就可以快速回滾更改、重建或恢復(fù)集群，來確保穩(wěn)定性和安全性。

4、采用基于 Git 的工作流

在 GitOps，或者是基于 Git 的工作流中，Git 是唯一的真實來源，因而是用于自動化包括 CI/CD 管道等所有任務(wù)的優(yōu)秀模型。

而除了可以提升生產(chǎn)力，GitOps 還有助于加快部署和增強錯誤跟蹤，并使 CI/CD 工作流程自動化，同時簡化集群管理，加快應(yīng)用開發(fā)。

5、充分利用 YAML 文件的聲明性

應(yīng)當(dāng)編寫聲明性的 YAML 文件加上 kubectl apply 命令來將對象添加到集群，而不是直接使用 kubectl run 的命令性方式。聲明式方法允許您指定所需達到的目標(biāo)狀態(tài)，剩下的交給 Kubernetes 自己來決定如何達到這個狀態(tài)。

這樣，所有的對象，就和代碼一樣，可以被保存在 YAML 文件中，并進行版本控制。一旦出現(xiàn)錯誤，就可以通過恢復(fù)之前的 YAML 文件并重新應(yīng)用它們來輕松地回滾部署。而且，采用這個模式，可以確保團隊能夠看到集群的當(dāng)前狀態(tài)，以及隨著時間的推移做出的所有更改。

6、表明資源需求和上限

在為資源定義需求或上限時，Millicores 作為 CPU 的單位，而 MB 可用作內(nèi)存的單位。如果資源需求超出了限制，那么容器將不會在吊艙中運行。

當(dāng)資源稀缺時，如果沒有配置資源需求和限制，生產(chǎn)集群就可能會失敗。而資源充足時，多余的資源會被沒有配置資源限制的 Pod 消耗掉，從而增加 Kubernetes 的使用成本。另外，如果 Pod 消耗了太多的 CPU 或內(nèi)存，并且調(diào)度程序無法添加新的 Pod，則可能出現(xiàn)節(jié)點崩潰的情況。

7、將 Pod 連接到 Deployments、ReplicaSets 和 Jobs

要盡可能避免使用裸露的豆莢，否則，在節(jié)點失敗的情況下，將無法重新調(diào)度它們，僅僅因為它們沒有被綁定到 Deployment 或 ReplicaSet。

Deployment 用于創(chuàng)建 ReplicaSet 來保持所需的 Pod 數(shù)量，并定義 Pod 替換策略，如 RollingUPdate。

除非有嚴格的重新啟動策略，否則 Deployment 幾乎總是比直接創(chuàng)建 Pod 更為有效。

8、使用 Label 清楚地標(biāo)記資源

Label 是可以幫助您識別 Kubernetes 集群中特定資源的鍵值對，還可以用在 kubectl 命令上來過濾和選取對象，允許根據(jù)特定特征快速識別對象。

即使你覺得暫時不會用到它們，但用 Label 為你的對象打上標(biāo)簽絕對是個好主意。另外，要使用盡可能多的描述性標(biāo)簽來區(qū)分團隊要使用的資源。比如可以按所有者、版本、實例、組件、管理者、項目、團隊、機密級別等等來進行標(biāo)記。

9、在啟動探測器之后運行活性探測器

活性探測器（Liveness probes）會定期檢查長期存活 Pod 的健康狀況，避免 Kubernetes 將流量導(dǎo)向不健康的 Pod。在默認情況下，Kubernetes 會重新啟動未通過健康檢查的 Pod，來確保應(yīng)用程序的可用性。

探測器會向 Pod 發(fā)送一個 ping 信號，然后看是否可以接收到響應(yīng)。如果沒有響應(yīng)，則表明應(yīng)用程序沒有在那個 Pod 中運行，導(dǎo)致探測器啟動一個新 Pod，并在那里運行應(yīng)用程序。

另外，必須首先運行啟動探測器（startup probe），這是第三種探測器，當(dāng) Pod 的啟動過程完成時，它會通知 Kubernetes。如果 Pod 的啟動探測器不完整，活性探測器（Liveness probes）和就緒探測器（readiness probes）就不會起作用。

10、使用命名空間簡化資源管理

命名空間可以在邏輯上將集群劃分為子集群。當(dāng)希望同時在多個項目或團隊之間共享 Kubernetes 集群時，命名空間就非常有用。有了命名空間，開發(fā)、測試和生產(chǎn)團隊就可以在同一個集群內(nèi)協(xié)作，而不會覆蓋或干擾彼此。

Kubernetes 自身提供了 default、kube-system 和 kube-public 三個命名空間。一個集群支持邏輯上獨立但彼此可以通信的多個命名空間。

11、保持無狀態(tài)

無狀態(tài)應(yīng)用通常比有狀態(tài)應(yīng)用更容易管理，盡管這種情況正在隨著 Kubernetes Operators 越來越受歡迎而改變。

無狀態(tài)后端可以不再需要剛開始使用 Kubernetes 的團隊來維護對伸縮性有限制的長連接。

無狀態(tài)應(yīng)用也使得按需遷移和擴展變得更為容易。

另外，保持工作負載的無狀態(tài)還允許使用 Spot Instance（AWS、Azure 等云提供商的一種優(yōu)惠計價方式）。

Spot Instance 的缺點在于，像 AWS 和 Azure 這樣的提供商經(jīng)常需要在短時間內(nèi)回收廉價的計算資源，這樣就會干擾工作負載，而使應(yīng)用成為無狀態(tài)，就可以避免這個問題。

12、建立自己的網(wǎng)絡(luò)策略

Kubernetes 的網(wǎng)絡(luò)策略規(guī)定了哪些流量是允許的，哪些是不允許的。這類似于在 Kubernetes 集群的 Pod 之間設(shè)置防火墻。無論流量在 Pod 之間如何移動，只有在網(wǎng)絡(luò)策略準許的情況下才被允許。

在創(chuàng)建網(wǎng)絡(luò)策略之前，必須定義經(jīng)過授權(quán)的連接并制定策略應(yīng)該應(yīng)用在哪些 Pod，由此過濾掉不符合標(biāo)準的流量。

13、設(shè)置基于角色的訪問控制（RBAC）

根據(jù) Redhat 在2022年對300多名DevOps專業(yè)人士的調(diào)查，幾乎所有被調(diào)查人（94%）在前一年至少發(fā)生過一次 Kubernetes 安全事件。

可以使用 RBAC 來制定哪些用戶可以訪問哪些 Kubernetes 資源，比如他們可以訪問哪些集群，誰可以進行更改，以及可以在多大程度上進行更改。

RBAC 權(quán)限可以通過兩種方式配置：

1. 對于非命名空間下的資源，使用 ClusterRole
2. 對于命名空間下的資源，使用 Role

14、為 Kubernetes 集群設(shè)置防火墻

這是另一個重要的 Kubernetes 最佳安全實踐。

除了要控制集群內(nèi)部流量的網(wǎng)絡(luò)策略之外，還要在集群前面設(shè)置一道防火墻，以限制訪問 API 服務(wù)的外部請求。這可以使用常規(guī)或端口防火墻規(guī)則來實現(xiàn)。

另外，確保訪問者 IP 地址在白名單中，并且服務(wù)器開放端口是受限的。

15、小鏡像更好

鏡像需要是小而且分層的。鏡像越小，其構(gòu)建速度越快，所需的存儲空間越少。鏡像尺寸可以通過有效的分層來顯著減小。

怎么做到？

如果需要許多不同的組件，可以在一個 Dockerfile 中使用多個 FROM 語句。安裝程序?qū)⒒?FROM 命令從已部署的容器提取每一層。由此產(chǎn)生的 Docker 容器更小，因為它不再包含以前的層，而只包含需要的組件。