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

然而，Kubernetes也在不斷地進行升級，并不總是能開箱即用地用于生產環境。

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

1、始終保持與最新穩定版同步

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

2、對清單進行檢查

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

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

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

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

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

4、采用基于 Git 的工作流

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

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

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

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

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

6、表明資源需求和上限

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

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

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

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

Deployment 用于創建 ReplicaSet 來保持所需的 Pod 數量，并定義 Pod 替換策略，如 RollingUPdate。

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

8、使用 Label 清楚地標記資源

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

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

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

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

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

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

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

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

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

11、保持無狀態

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

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

無狀態應用也使得按需遷移和擴展變得更為容易。

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

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

12、建立自己的網絡策略

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

在創建網絡策略之前，必須定義經過授權的連接并制定策略應該應用在哪些 Pod，由此過濾掉不符合標準的流量。

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

根據 Redhat 在2022年對300多名DevOps專業人士的調查，幾乎所有被調查人（94%）在前一年至少發生過一次 Kubernetes 安全事件。

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

RBAC 權限可以通過兩種方式配置：

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

14、為 Kubernetes 集群設置防火墻

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

除了要控制集群內部流量的網絡策略之外，還要在集群前面設置一道防火墻，以限制訪問 API 服務的外部請求。這可以使用常規或端口防火墻規則來實現。

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

15、小鏡像更好

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

怎么做到？

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