你已經了解過Kubernetes了(或正在考慮探索一些Kubernetes部署)。了解它有很多很好的理由，你可能已經很清楚，Kubernetes是負責管理容器，將工作負載調度到集群上，處理可伸縮性和冗余，自動執行滾動(更新)和回滾。它是一個與基礎設施無關的系統，通過使用聲明式語句來描述系統和應用應處于的狀態，并驅動所托管的元素達到該狀態。這樣子使管理功能強大且可擴展的系統變得更加容易。當然，這里所說的“易于管理”有一定的學習曲線，但是為了獲得現代基于容器的軟件開發的好處，即提供可擴展性和基礎架構可移植性的基礎架構，這是非常值得的。

[[355372]]

雖然Kubernetes確實可以實現容器的操作可擴展性和管理，但它并不直接幫你管理Kubernetes本身所依賴的基礎設施。Kubernetes本身就是一個應用(或者說是一組應用)，這些應用需要在某處運行起來。盡管你可能聽過，Kubernetes它不是個操作系統，但仍依賴于要安裝在節點上的Linux或Windows系統。Kubernetes可以在例如AWS或GCE這類云服務商，或者是VMware這類虛擬化平臺上運行，但所有這些仍然需要首先安裝操作系統。(某些例如AWS EKS無需管理控制平面節點，但仍需要為工作節點設置Linux服務器。)

在操作上，重點是Kubernetes和它運行的工作負載，這本該如此，但這會導致一個在Kubernetes部署上常見的問題。雖然Kubernetes會定期打補丁和升級，但是關于底層操作系統的維護，更新，安全和操作往往被遺忘或忽視，至少在安全審計之前是這樣的。我經常聽SRE和系統管理員說，要同時管理Linux和Kubernetes，這導致額外的工作。就像一般的Linux操作系統一樣，Kubernetes也需要打補丁、更新、保護和控制用戶訪問等等。但是，僅僅因為這些任務是在Kubernetes級別上完成的，并不意味著它們在操作系統級別上可被忽略。不過，選擇合適的底層操作系統發行版，可以在很大程度上減少維護操作系統的工作量，減輕不及時更新的影響。

因此，考慮到你需要先安裝Linux才能在其上運行Kubernetes，這將涉及底層的操作系統，你應該選擇運行哪個Linux發行版呢?可選的方案有很多，但它們通常分為兩種，即容器優化的操作系統，或通用的操作系統。

通用Linux操作系統

這些是正常類型的Linux。

大部分人都熟悉運行通用類型Linux操作系統，例如Ubuntu、Debian、CentOS、RHEL或是Fedora。這是在Kubernetes集群中運行通用操作系統的主要優勢之一，你的系統管理員將熟悉如何安裝、更新和加固你的Linux發行版。可以使用現有的工具集來啟動服務器，安裝操作系統，并將其配置為基本的安全級別。現有的補丁管理和安全檢測工具應該可以在這些系統上正常運行，即使在其上運行Kubernetes。

然而……

使用通用類型Linux系統，隨之而來的是常見的Linux管理開銷。這意味著用戶賬號管理，補丁管理，內核更新，服務防火墻，SSH安全，禁止root登陸，禁用未使用的守護進程，內核調優等等，都需要完成并保持最新。如前所述，這些任務中的大部分可以使用現有的工具例如Ansible，Chef，Puppet來完成，然而，更新清單或控制文件，使服務器配置文件適合Kubernetes主節點和工作節點，可以說并非易事。

另一個問題是操作系統更改與Kubernetes維護的協調。經常會出現不協調的情況，以至于在安裝后操作系統仍保持原樣。隨著時間的推移，Kubernetes會(希望)升級，但底層的操作系統仍可能保持原樣，慢慢地在各種包和已安裝的內核中積累了已知的CVE(常見的漏洞和暴露)的負擔。

理想情況下，你希望自動化平臺(如Ansible或Puppet)與Kubernetes進行協調，以便可以在不影響Kubernetes操作的情況下升級節點的操作系統。這意味著操作系統需要：

• 設置節點為不可調度以便新工作負載不會調度到該節點上
• 驅逐該節點以讓所有運行的Pod移動到其他節點
• 更新并給節點打補丁
• 設置節點為可調度

當然，該系統需要保證在同一時刻不會有過多的節點在更新，以保證集群的工作負載能力不會受到負面影響(節點也不要太少，以免大型集群的更新速度慢于補丁和更新的發布速度)。你可能希望協調操作系統更新與Kubernetes更新，以減少重啟和中斷，但你仍然需要在短時間內支持更關鍵的操作系統更新。

通用類型Linux操作系統的最大優勢是工作人員對它的熟悉程度。這意味著他們將熟悉部署，同時也具備排障技術。他們可以安裝并使用常用的操作系統工具例如tcpdump、strace、lsof等等。配置可以很輕易地更改，以糾正錯誤和測試替代方案(這既是好事，同時也是壞事!)缺點是需要保持系統管理的開銷，以及需要與Kubernetes基礎設施和操作協調更新。

容器專用操作系統

美國國家標準與技術研究所(NIST)關于定義容器專用的操作系統有一個很好的總結，列出了一些優點。

“容器專用主機操作系統是一種明確設計為只運行容器的極簡主義操作系統，其禁用了所有其他服務和功能，并采用只讀文件系統和其他加固做法。當采用容器專用操作系統，攻擊面通常要比通用類型操作系統小得多，因此攻擊和破壞容器專用主機操作系統的機會較少。綜上，如果可以，各個組織都應盡可能使用容器專用主機操作系統。”引自“NIST Special Publication 800-190 Application Container Security Guide”

總結一下，顯而易見的一點就是，操作系統運行的軟件和包越少，攻擊面越小，漏洞也越少。這讓容器專用操作系統從一開始就明顯更安全，即使缺少頻繁打補丁。

容器專用操作系統也可以采用其他的安全方式，例如將根文件系統(最好是所有文件系統)設為只讀，減輕任何漏洞可能帶來的影響。

容器專用操作系統通常不運行(或不支持)包管理。這減少了安裝或更新包引起沖突導致節點或服務停止運行的機會。由于沒有Chef和Puppet等管理工具，運行不完整對系統運行穩定性造成不利影響的機會減少。取而代之的是，一個應用了所有更新和配置的完整的操作系統鏡像被安裝在一個備用的啟動機制中，并在下一次重啟時被啟動，或回退到之前已知的工作良好的鏡像。這意味著，節點的配置在任何時候都是完全已知的，任何版本都可以從使用的版本控制系統中還原。

一些容器專用的操作系統更像通用Linux發行版，例如VMware公司的PhotonOS與普通Linux發行版相比，安裝的包數量較少，但仍然包括包管理器、SSH訪問，并且不會將文件系統掛載為只讀。人們有時會困惑的一點是，通用Linux系統的“云優化”版本仍然是通用Linux系統，如Ubuntu發布的“云鏡像”，是“由Ubuntu工程部門定制的，可以在公共云上運行”。然而，這些仍然是完整的Linux發行版，安裝了所有的包，只是多了一個cloud-init包，這樣可以更容易地配置啟動，而無需人工干預。

CoreOS是第一個被普遍采用的容器專用操作系統，并普及了在容器中運行所有進程以提高安全性和隔離性的理念。CoreOS取消了軟件包管理器，并使用重啟到兩個只讀/usr分區中的一個，以確保更新是原子的，并可以回滾。不過自從CoreOS被RedHat收購后，該項目就被終結了。

當前的容器專用操作系統都采用最小的姿態(在操作系統中安裝的軟件包很少);鎖定(在一定程度上);在容器中運行進程(為了更好的安全性、穩定性和服務隔離)，并提供原子更新(通過啟動到一個可啟動分區，并更新另一個分區)。這樣的例子有：

• Google的Container-Optimized OS，支持只讀的根文件系統，但允許SSH，且只在GCP中運行。
• RancherOS，其運行SSH，不使用只讀文件系統來保護根分區
• K3OS，也是由Rancher開發的，但沒有運行完整的Kubernetes發行版。管理是通過kubectl，但支持SSH。
• AWS Bottlerocket是另一個具有不可改變的根文件系統和支持SSH的操作系統，也就是至少在初期，它專注于AWS的工作負載。

Talos是一個例外，它是容器專用操作系統中意見最大的一個。和其他系統一樣，Talos操作系統也是最小化的，沒有包管理器，只使用只讀文件系統(除了/var和/etc/kubernetes，以及一兩個短暫可寫(重啟時重置)的特殊文件，如/etc/resolv.conf)，并通過升級控制器與K8s集成升級。

然而，Talos操作系統比其他系統更進一步地提出了不可變基礎設施的理念，它取消了所有SSH和控制臺訪問，并使所有的OS訪問和管理通過API驅動。在運行Kubernetes的節點上，你想做的所有事情都有API調用，查看所有的容器，檢查網絡設置等。但在節點上你沒辦法做不該做的事情，比如卸載文件系統。Talos還選擇完全重寫Linux Init系統，它只做一件事，那就是啟動Kubernetes。

不能管理任何用戶定義的服務(這些都應該通過Kubernetes管理)，這進一步提高了安全性(沒有SSH，沒有控制臺)，減少了維護(沒有用戶，沒有補丁)，降低了任何CVE的影響(因為文件系統是不可變的，是短暫的)。你可能不同意放棄SSH訪問，限制SRE的動作，強迫節點完全不可變的觀點是可取的，但這也是不久前反對不可變容器的論點，這值得探究。擁有一個API管理的操作系統也非常適合大規模的操作和管理，如果你需要檢查一個節點、一類節點或者所有節點上的某個容器的日志，那就是使用不同參數的同一個API調用而已。

總結

如果你已經采用了容器管理是“牛而非寵物(即生產軟件基礎設施可隨時替換)”的觀點，即在部署更新或修復時，銷毀容器并啟用一個新版本，那么確保對支持容器的基礎設施采用同樣的方法是有意義的。采用類似于容器的管理模式，銷毀和重新配置節點以進行更新，而不是打補丁，這可能需要一些培訓，但是采用容器專用的操作系統有助于采用這種模式，減少管理開銷，并提高安全性。容器專用操作系統還有助于提高運行穩定性，系統管理員或開發人員無需更改配置以使其工作，從而消除了人為錯誤或錯誤配置導致下一次升級失敗的可能性。

鑒于許多企業仍處于Kubernetes采用生命周期的早期，現在是熟悉這個下一代操作系統的好時機。通過將操作系統與Kubernetes緊密結合在一起，可以將整個Kubernetes集群作為一臺計算機來對待，減少開銷，并促進增強安全性。這讓人們的注意力仍然集中在計算基礎設施所提供的工作負載和價值上，是向API驅動的數據中心邁出的又一步。