Kubernetes安全三步談：如何監(jiān)控與控制Kubernetes中的資源消耗問(wèn)題

本文是關(guān)于Kubernetes安全系列三篇文章中的最后一篇。在第一篇文章中，我們分享了如何確保企業(yè)的Kubernetes集群免受外部***；第二篇文章介紹了三種保護(hù)Kubernetes免受內(nèi)部威脅的方法。在本文中，我們將介紹如何處理資源消耗或noisy neighbor問(wèn)題。

對(duì)于那些設(shè)置了多租戶(hù)Kubernetes集群的集群管理員而言，他們十分關(guān)注和擔(dān)心的一個(gè)問(wèn)題是，如何防止共同租戶(hù)成為“noisy neighbor”，即一個(gè)壟斷了CPU、內(nèi)存、存儲(chǔ)和其他資源的人。Noisy neighbor會(huì)對(duì)共享基礎(chǔ)設(shè)施的其他用戶(hù)資源的性能產(chǎn)生極壞的影響。

如此一來(lái)，跟蹤Kubernetes容器和Pod的資源使用情況，對(duì)集群管理而言非常重要，因?yàn)樗粌H可以保持容器編排系統(tǒng)處于最佳運(yùn)行狀態(tài)，降低運(yùn)維成本，還可以加強(qiáng)Kubernetes的整體安全狀況。

一些運(yùn)維團(tuán)隊(duì)可能不認(rèn)為資源消耗是一種重要的安全問(wèn)題，至少?zèng)]有保護(hù)Kubernetes免受內(nèi)部和外部網(wǎng)絡(luò)***重要。但這種觀點(diǎn)是不正確的。因?yàn)閰柡Φ?**會(huì)利用功能不良的基礎(chǔ)設(shè)施，來(lái)找到***Kubernetes組件的方法。

“安全不僅僅是‘不要闖進(jìn)我的房子’，而是‘我怎么能讓我的房子一直保持良好的運(yùn)行狀態(tài)’，”Rancher Labs的高級(jí)解決方案架構(gòu)師Adrian Goins表示。

運(yùn)維團(tuán)隊(duì)需要最大限度地利用Kubernetes Pods（一組具有共享存儲(chǔ)和網(wǎng)絡(luò)資源的一個(gè)或多個(gè)容器）所消耗的資源，以確保每個(gè)用戶(hù)都能擁有最佳性能，并且能監(jiān)控成本分配的使用情況?！笆褂玫扔诔杀?，”Goins說(shuō)，“因?yàn)镵ubernetes資源都是運(yùn)行在AWS、谷歌云、阿里云等等云提供商的底層計(jì)算基礎(chǔ)設(shè)施上，一切資源消耗都以為著金錢(qián)成本。即使集群是在數(shù)據(jù)中心的裸機(jī)上運(yùn)行，過(guò)多的使用也會(huì)花費(fèi)硬件、電力和其他資源?！?/p>

默認(rèn)情況下，配置容器時(shí)，對(duì)其可以使用的資源量沒(méi)有任何限制。如果容器不能高效運(yùn)行，部署容器的組織必將支付超額費(fèi)用。值得慶幸的是，Kubernetes具有幫助運(yùn)維團(tuán)隊(duì)管理和優(yōu)化Kubernetes資源利用能力的功能。

管理Pods中的資源

當(dāng)管理員定義Pod時(shí)，他們可以選擇指定每個(gè)容器需要多少CPU和內(nèi)存（RAM）。當(dāng)容器指定了資源請(qǐng)求時(shí)，調(diào)度程序可以更好地決定將Pod放在哪個(gè)節(jié)點(diǎn)上。根據(jù)Kubernetes的文檔，當(dāng)容器指定了限制時(shí)，可以按指定的方式處理節(jié)點(diǎn)上的資源爭(zhēng)用。

默認(rèn)情況下，Kubernetes集群中的所有資源都是在默認(rèn)的命名空間中創(chuàng)建的。命名空間是一種邏輯地將集群資源進(jìn)行分組的方法，包括用于指定資源配額的選項(xiàng)。

管理員可以在命名空間上設(shè)置資源限制或配額，為在命名空間中運(yùn)行的工作負(fù)載或應(yīng)用程序分配一定量的CPU、RAM或存儲(chǔ)——Kubernetes集群中的三個(gè)資源?！叭绻诿臻g中啟動(dòng)另一個(gè)資源會(huì)超出預(yù)設(shè)的配額，那么任何新資源都無(wú)法啟動(dòng)，”Goins指出。

?“當(dāng)你應(yīng)用了資源配額時(shí)，意味著你強(qiáng)制在該命名空間中運(yùn)行的所有內(nèi)容為其自身設(shè)置資源限制。限制有兩種類(lèi)型：預(yù)留，和最大限制，”Goins解釋說(shuō)。例如，通過(guò)預(yù)留，管理員可以讓Kubernetes集群為WordPress站點(diǎn)分配128 MB的RAM。對(duì)于部署的每個(gè)WordPress Pod，服務(wù)器本身將保證128 MB的RAM。因此，如果管理員將資源請(qǐng)求與1GB的資源配額相結(jié)合，則用戶(hù)只能在超過(guò)其限制之前運(yùn)行八個(gè)WordPress Pod。在那之后，他們將無(wú)法再使用RAM了。

資源限制的第二部分是最大限度。管理員可以預(yù)留128 MB的資源請(qǐng)求和最多256 MB的RAM?！叭绻鸓od超過(guò)256 MB的RAM使用量，Kubernetes會(huì)殺死它并重新啟動(dòng)它，”Goins說(shuō)?！叭绱艘詠?lái)，用戶(hù)可以免受失控過(guò)程和noisy neighbor的影響?！?/p>

項(xiàng)目和資源配額

像Rancher這樣的平臺(tái)，旨在通過(guò)提供直觀的界面和集中管理任務(wù)（如全局層的角色描述）來(lái)簡(jiǎn)化Kubernetes的管理。

正如前一篇關(guān)于內(nèi)部威脅防護(hù)的文章所述，Rancher包含一個(gè)有助于減輕集群管理負(fù)擔(dān)的“項(xiàng)目（Project）”資源，來(lái)超越命名空間。在Rancher中，Project允許管理員將多個(gè)命名空間作為單個(gè)實(shí)體進(jìn)行管理。因此，Rancher可以將資源配額應(yīng)用于Projects。

在標(biāo)準(zhǔn)Kubernetes部署中，資源配額只能應(yīng)用于單獨(dú)的命名空間。但是，管理員無(wú)法通過(guò)單次操作，同時(shí)將配額應(yīng)用于命名空間。資源配額必須經(jīng)過(guò)多次操作。

然而在Rancher中，管理員可以將資源配額應(yīng)用于Project，然后將配額傳播到每個(gè)命名空間。然后，Kubernetes會(huì)使用本機(jī)版本的資源配額，來(lái)強(qiáng)制執(zhí)行管理員限制。如果管理員希望更改特定命名空間的配額，則可以覆蓋以前的配額。

強(qiáng)化和優(yōu)化Kubernetes

毋庸置疑，Kubernetes已成為容器編排的標(biāo)準(zhǔn)，這也促使大多數(shù)云和虛擬化供應(yīng)商將其作為標(biāo)準(zhǔn)基礎(chǔ)架構(gòu)來(lái)提供。但是，對(duì)與Kubernetes環(huán)境相關(guān)的安全問(wèn)題的普遍缺乏認(rèn)識(shí)，可能會(huì)使各種組件暴露于來(lái)自網(wǎng)絡(luò)集群內(nèi)外的***中。

本系列文章的上兩篇中提供了一些可行的步驟，來(lái)告訴大家如何通過(guò)使用Kubernetes功能和容器管理解決方案（如Rancher），來(lái)加強(qiáng)Kubernetes對(duì)外部和內(nèi)部網(wǎng)絡(luò)威脅的防范。企業(yè)應(yīng)通過(guò)基于角色的訪問(wèn)控制（RBAC）和強(qiáng)身份驗(yàn)證從外部保護(hù)Kubernetes API訪問(wèn)。對(duì)于內(nèi)部人員保護(hù)，由于Kubernetes集群是多用戶(hù)，因此組織需要通過(guò)RBAC、邏輯隔離和NetworkPolicies來(lái)保護(hù)交叉通信。

為了防止其他租戶(hù)壟斷CPU、內(nèi)存、存儲(chǔ)和其他資源從而拖累整個(gè)集群的性能，Kubernetes提供資源限制和配額等功能，以幫助運(yùn)維團(tuán)隊(duì)管理和優(yōu)化Kubernetes資源利用功能。最后，除了可用的默認(rèn)設(shè)置之外，業(yè)界還有一些非常有效的工具可以幫助用戶(hù)完成Kubernetes集群的管理和保護(hù)。例如像Rancher這樣的平臺(tái)就是一種高度優(yōu)化的容器管理解決方案，專(zhuān)為將多個(gè)集群部署到生產(chǎn)環(huán)境中的組織而構(gòu)建，企業(yè)用戶(hù)可以更輕松地管理和運(yùn)行各地的Kubernetes。它可以保護(hù)Kubernetes集群免受外部***威脅、內(nèi)部隱患甚至noisy neighbor。