要虛擬化或不虛擬化裸機部署的裸機服務器

Question

我想在大型物理服務器（24個內核）上部署kubernetes，但我對某些事情並不確定。

除了在裸機上運行，​​爲k8s集羣創建虛擬機有什麼優點和缺點。

我有以下幾點考慮：

• 創建VM將允許工作負載隔離。新的虛擬實驗可以創建並分配給開發者。
• 另一方面，在裸機上運行的k8s可以爲每個開發人員創建一個新的NAMESPACE進行實驗，他們可以在其中運行代碼。畢竟他們的代碼應該在Docker容器中運行。

安全：

• 擁有的虛擬機將限制給將來的維護訪問量，限制了可以做的傷害量。另一方面，對於任何未來的維護者來說，主要任務是添加/刪除節點，並且他們需要裸機訪問才能做到這一點。

認證：

• 目前開發者在他們的代碼貫穿CI管道及其運行部署的部署將只接觸服務器。但是查看日誌呢？我們可以設置分層kubectl身份驗證，以允許開發人員只訪問分配給他們的任何名稱空間（我相信這應該可以通過k8s名稱空間授權插件來實現）。

服務器上已存在多個vms。這會成爲一個問題嗎？

Answer 1

128核心和懷疑....這是一個單一的服務器很多核心。

對於kubernetes然而，這是不相關的： Kubernetes可以使用不同大小的服務器並將其利用到最大。但是，如果將主服務器進程和節點/輔助進程組合在一臺服務器上，則可能會產生不必要的資源問題。正如您已經提到的那樣，您可以使用名稱空間來管理它們。

我們所做的是在單個dev/qa kubernetes環境中使用與命名空間的持續集成，其中更改具有自己的命名空間（因此我們運行許多許多命名空間），並在這些命名空間中運行完整的環境部署。一堆shell腳本用於管理這個。這既適用於您的大型服務器，也適用於小型（或虛擬）盒子。虛擬化對你的好處主要在於將較大的盒子分成較小的盒子，這樣你就可以將它用於其他目的，然後只用kubernetes（是的，kubernetes除了MS Windows以外，沒有桌面，沒有用於VPN目的的內核模塊等等）。

Answer 2

我會以不同vms的形式分離dev和prod。我曾經在Docker中有過一個webapp，它使用了太多的線程，所以主機上的docker守護進程崩潰了。幸運的是它僅限於一個主機。你可以通過設定限制來保護這一點，但這是一個風險：開發中的一個錯誤也可能會降低產品質量。

Answer 3

我想答案是「這要看情況了！」這不是一個真正的答案。就我個人而言，我會使用虛擬機來分割機器並以這種方式進行部署。您擁有更多靈活性，您可以輕鬆創建新環境，然後輕鬆銷燬多少服務器資源。

即使這些虛擬磁盤真的很大，我認爲它還是更容易管理，同時考慮到您在機器上存在虛擬機。

也就是說，您不能運行單個節點服務器的技術原因，但是您可能遇到因升級而導致的停機時間問題（如果這是個問題），以及該服務器需要修補或重新啓動，那麼你的整個羣集就會關閉。

我會考慮您的環境需求以獲得高可用性和正常運行時間，以及您將如何部署虛擬機（如果走這條路），並決定哪種方法最適合您。