建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
作為一個(gè)久負(fù)盛名的容器編排平臺(tái)，Kubernetes具有很多優(yōu)勢(shì)，其自動(dòng)化能力尤其突出，具體體現(xiàn)在工作負(fù)載的發(fā)現(xiàn)、自愈和應(yīng)用伸縮等方面。
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶(hù)創(chuàng)新互聯(lián)還提供了灤南免費(fèi)建站歡迎大家使用！
然而，Kubernetes也在不斷地進(jìn)行升級(jí)，并不總是能開(kāi)箱即用地用于生產(chǎn)環(huán)境。
本文提供了一系列應(yīng)當(dāng)重點(diǎn)考慮的Kubernetes最佳實(shí)踐，用以提高您的 K8s 的安全性和性能，并控制成本。
1、始終保持與最新穩(wěn)定版同步
通常，應(yīng)該始終將 K8s 升級(jí)到最新穩(wěn)定版本，以應(yīng)用最新的安全或性能的修復(fù)與改進(jìn)，也會(huì)獲得更多來(lái)自社區(qū)和供應(yīng)商提供的支持，從而避免可能危及服務(wù)交付的安全和性能問(wèn)題，以及成本方面的異常。
2、對(duì)清單進(jìn)行檢查
可能你覺(jué)得 YAML 很難使用，那么不妨用一下 yamllint，它可以在一個(gè)文件中處理多個(gè)文檔。
還有專(zhuān)門(mén)針對(duì) Kubernetes 的 linter。比如，你可以使用 kube-score 來(lái)分析你的清單，從而遵循最佳實(shí)踐。 Kubeval 也能用來(lái)分析你的清單，但是它只是檢查有效性。Kubernetes 1.13 的 kubectl 提供的 dry-run 也可以用來(lái)檢測(cè)清單而不實(shí)際應(yīng)用它，所以，也可以使用這個(gè)特性來(lái)檢查你為 K8s 準(zhǔn)備的 YAML 文件。
3、對(duì)各種配置文件做好版本控制
最好將 Deployment、Service 和 Ingress 等所有配置文件存儲(chǔ)在版本控制系統(tǒng)中。Github 是最流行的開(kāi)源分布式版本控制平臺(tái)，也可以使用 Gitlab、BitBucket 和 SourceForge 等其它平臺(tái)。
要在將代碼推送到 Kubernetes 集群之前就對(duì)它們進(jìn)行版本化管理，這樣就可以跟蹤代碼的變更內(nèi)容及變更人。這樣做，你就可以快速回滾更改、重建或恢復(fù)集群，來(lái)確保穩(wěn)定性和安全性。
4、采用基于 Git 的工作流
在 GitOps，或者是基于 Git 的工作流中，Git 是唯一的真實(shí)來(lái)源，因而是用于自動(dòng)化包括 CI/CD 管道等所有任務(wù)的優(yōu)秀模型。
而除了可以提升生產(chǎn)力，GitOps 還有助于加快部署和增強(qiáng)錯(cuò)誤跟蹤，并使 CI/CD 工作流程自動(dòng)化，同時(shí)簡(jiǎn)化集群管理，加快應(yīng)用開(kāi)發(fā)。
5、充分利用 YAML 文件的聲明性
應(yīng)當(dāng)編寫(xiě)聲明性的 YAML 文件加上 kubectl apply 命令來(lái)將對(duì)象添加到集群，而不是直接使用 kubectl run 的命令性方式。聲明式方法允許您指定所需達(dá)到的目標(biāo)狀態(tài)，剩下的交給 Kubernetes 自己來(lái)決定如何達(dá)到這個(gè)狀態(tài)。
這樣，所有的對(duì)象，就和代碼一樣，可以被保存在 YAML 文件中，并進(jìn)行版本控制。一旦出現(xiàn)錯(cuò)誤，就可以通過(guò)恢復(fù)之前的 YAML 文件并重新應(yīng)用它們來(lái)輕松地回滾部署。而且，采用這個(gè)模式，可以確保團(tuán)隊(duì)能夠看到集群的當(dāng)前狀態(tài)，以及隨著時(shí)間的推移做出的所有更改。
6、表明資源需求和上限
在為資源定義需求或上限時(shí)，Millicores 作為 CPU 的單位，而 MB 可用作內(nèi)存的單位。如果資源需求超出了限制，那么容器將不會(huì)在吊艙中運(yùn)行。
當(dāng)資源稀缺時(shí)，如果沒(méi)有配置資源需求和限制，生產(chǎn)集群就可能會(huì)失敗。而資源充足時(shí)，多余的資源會(huì)被沒(méi)有配置資源限制的 Pod 消耗掉，從而增加 Kubernetes 的使用成本。另外，如果 Pod 消耗了太多的 CPU 或內(nèi)存，并且調(diào)度程序無(wú)法添加新的 Pod，則可能出現(xiàn)節(jié)點(diǎn)崩潰的情況。
7、將 Pod 連接到 Deployments、ReplicaSets 和 Jobs
要盡可能避免使用裸露的豆莢，否則，在節(jié)點(diǎn)失敗的情況下，將無(wú)法重新調(diào)度它們，僅僅因?yàn)樗鼈儧](méi)有被綁定到 Deployment 或 ReplicaSet。
Deployment 用于創(chuàng)建 ReplicaSet 來(lái)保持所需的 Pod 數(shù)量，并定義 Pod 替換策略，如 RollingUPdate。
除非有嚴(yán)格的重新啟動(dòng)策略，否則 Deployment 幾乎總是比直接創(chuàng)建 Pod 更為有效。
8、使用 Label 清楚地標(biāo)記資源
Label 是可以幫助您識(shí)別 Kubernetes 集群中特定資源的鍵值對(duì)，還可以用在 kubectl 命令上來(lái)過(guò)濾和選取對(duì)象，允許根據(jù)特定特征快速識(shí)別對(duì)象。
即使你覺(jué)得暫時(shí)不會(huì)用到它們，但用 Label 為你的對(duì)象打上標(biāo)簽絕對(duì)是個(gè)好主意。另外，要使用盡可能多的描述性標(biāo)簽來(lái)區(qū)分團(tuán)隊(duì)要使用的資源。比如可以按所有者、版本、實(shí)例、組件、管理者、項(xiàng)目、團(tuán)隊(duì)、機(jī)密級(jí)別等等來(lái)進(jìn)行標(biāo)記。
9、在啟動(dòng)探測(cè)器之后運(yùn)行活性探測(cè)器
活性探測(cè)器（Liveness probes）會(huì)定期檢查長(zhǎng)期存活 Pod 的健康狀況，避免 Kubernetes 將流量導(dǎo)向不健康的 Pod。在默認(rèn)情況下，Kubernetes 會(huì)重新啟動(dòng)未通過(guò)健康檢查的 Pod，來(lái)確保應(yīng)用程序的可用性。
探測(cè)器會(huì)向 Pod 發(fā)送一個(gè) ping 信號(hào)，然后看是否可以接收到響應(yīng)。如果沒(méi)有響應(yīng)，則表明應(yīng)用程序沒(méi)有在那個(gè) Pod 中運(yùn)行，導(dǎo)致探測(cè)器啟動(dòng)一個(gè)新 Pod，并在那里運(yùn)行應(yīng)用程序。
另外，必須首先運(yùn)行啟動(dòng)探測(cè)器（startup probe），這是第三種探測(cè)器，當(dāng) Pod 的啟動(dòng)過(guò)程完成時(shí)，它會(huì)通知 Kubernetes。如果 Pod 的啟動(dòng)探測(cè)器不完整，活性探測(cè)器（Liveness probes）和就緒探測(cè)器（readiness probes）就不會(huì)起作用。
10、使用命名空間簡(jiǎn)化資源管理
命名空間可以在邏輯上將集群劃分為子集群。當(dāng)希望同時(shí)在多個(gè)項(xiàng)目或團(tuán)隊(duì)之間共享 Kubernetes 集群時(shí)，命名空間就非常有用。有了命名空間，開(kāi)發(fā)、測(cè)試和生產(chǎn)團(tuán)隊(duì)就可以在同一個(gè)集群內(nèi)協(xié)作，而不會(huì)覆蓋或干擾彼此。
Kubernetes 自身提供了 default、kube-system 和 kube-public 三個(gè)命名空間。一個(gè)集群支持邏輯上獨(dú)立但彼此可以通信的多個(gè)命名空間。
11、保持無(wú)狀態(tài)
無(wú)狀態(tài)應(yīng)用通常比有狀態(tài)應(yīng)用更容易管理，盡管這種情況正在隨著 Kubernetes Operators 越來(lái)越受歡迎而改變。
無(wú)狀態(tài)后端可以不再需要?jiǎng)傞_(kāi)始使用 Kubernetes 的團(tuán)隊(duì)來(lái)維護(hù)對(duì)伸縮性有限制的長(zhǎng)連接。
無(wú)狀態(tài)應(yīng)用也使得按需遷移和擴(kuò)展變得更為容易。
另外，保持工作負(fù)載的無(wú)狀態(tài)還允許使用 Spot Instance（AWS、Azure 等云提供商的一種優(yōu)惠計(jì)價(jià)方式）。
Spot Instance 的缺點(diǎn)在于，像 AWS 和 Azure 這樣的提供商經(jīng)常需要在短時(shí)間內(nèi)回收廉價(jià)的計(jì)算資源，這樣就會(huì)干擾工作負(fù)載，而使應(yīng)用成為無(wú)狀態(tài)，就可以避免這個(gè)問(wèn)題。
12、建立自己的網(wǎng)絡(luò)策略
Kubernetes 的網(wǎng)絡(luò)策略規(guī)定了哪些流量是允許的，哪些是不允許的。這類(lèi)似于在 Kubernetes 集群的 Pod 之間設(shè)置防火墻。無(wú)論流量在 Pod 之間如何移動(dòng)，只有在網(wǎng)絡(luò)策略準(zhǔn)許的情況下才被允許。
在創(chuàng)建網(wǎng)絡(luò)策略之前，必須定義經(jīng)過(guò)授權(quán)的連接并制定策略應(yīng)該應(yīng)用在哪些 Pod，由此過(guò)濾掉不符合標(biāo)準(zhǔn)的流量。
13、設(shè)置基于角色的訪問(wèn)控制（RBAC）
根據(jù) Redhat 在2022年對(duì)300多名DevOps專(zhuān)業(yè)人士的調(diào)查，幾乎所有被調(diào)查人（94%）在前一年至少發(fā)生過(guò)一次 Kubernetes 安全事件。
可以使用 RBAC 來(lái)制定哪些用戶(hù)可以訪問(wèn)哪些 Kubernetes 資源，比如他們可以訪問(wèn)哪些集群，誰(shuí)可以進(jìn)行更改，以及可以在多大程度上進(jìn)行更改。
RBAC 權(quán)限可以通過(guò)兩種方式配置：
- 對(duì)于非命名空間下的資源，使用 ClusterRole
- 對(duì)于命名空間下的資源，使用 Role
14、為 Kubernetes 集群設(shè)置防火墻
這是另一個(gè)重要的 Kubernetes 最佳安全實(shí)踐。
除了要控制集群內(nèi)部流量的網(wǎng)絡(luò)策略之外，還要在集群前面設(shè)置一道防火墻，以限制訪問(wèn) API 服務(wù)的外部請(qǐng)求。這可以使用常規(guī)或端口防火墻規(guī)則來(lái)實(shí)現(xiàn)。
另外，確保訪問(wèn)者 IP 地址在白名單中，并且服務(wù)器開(kāi)放端口是受限的。
15、小鏡像更好
鏡像需要是小而且分層的。鏡像越小，其構(gòu)建速度越快，所需的存儲(chǔ)空間越少。鏡像尺寸可以通過(guò)有效的分層來(lái)顯著減小。
怎么做到？
如果需要許多不同的組件，可以在一個(gè) Dockerfile 中使用多個(gè) FROM 語(yǔ)句。安裝程序?qū)⒒?FROM 命令從已部署的容器提取每一層。由此產(chǎn)生的 Docker 容器更小，因?yàn)樗辉侔郧暗膶?，而只包含需要的組件。
分享標(biāo)題：2023年15個(gè)Kubernetes優(yōu)秀實(shí)踐
新聞來(lái)源：http://fisionsoft.com.cn/article/dpjgigc.html
