2016-06-17 43 views
3

部署Kubernetes主節點的許多運行建議您使用--register-schedulable=false來阻止將用戶窗格安排到主節點(例如https://coreos.com/kubernetes/docs/latest/deploy-master.html)。在非常小的Kubernetes集羣中,除非絕對必要,否則有效地防止整個節點被用於pod調度看起來有點浪費計算資源。在Kubernetes主節點上運行用戶窗格有問題嗎?

對這個問題的回答(Will (can) Kubernetes run Docker containers on the master node(s)?)表明,確實有可能在主節點上運行用戶窗格 - 但並未解決是否存在與允許此問題相關的任何問題。

迄今爲止我所能找到的唯一信息表明可能存在與允許此問題相關的問題,那就是主節點上的pod看起來似乎不安全(請參閱http://kubernetes.io/docs/admin/master-node-communication/https://github.com/kubernetes/kubernetes/issues/13598)。我假設這可能會允許在主節點上運行的流氓pod訪問/劫持Kubernetes功能,這些功能通常無法在非主節點上的pod上訪問。如果只運行內部開發的pod /容器,可能不會有什麼大不了的 - 儘管我猜測總有人有可能盜取對容器/容器的訪問權限,從而獲得對主節點的訪問權限。

這聽起來像是一種與此場景相關的潛在風險(允許用戶在Kubernetes主節點上運行)?是否還有與此類設置相關的其他潛在問題?

回答

2

在主節點上運行pod肯定是可行的。

您提到的安全風險是一個問題,但是如果您配置服務帳戶,那麼所有已部署的pod對安全遠程訪問apiserver與不安全的本地訪問並沒有多大差別。

另一個問題是資源爭奪。如果在主節點上運行一個破壞主組件的流氓窗口,它可能會破壞整個集羣的穩定性。顯然,這是生產部署的一個關注點,但是如果您希望在開發/實驗環境中最大限度地利用少量節點,那麼在主服務器上運行一些額外的容器應該沒問題。

最後,您需要確保主節點有足夠大的pid cidr分配給它。在一些部署中,主人只會得到一個/ 30,這不會讓你運行很多的豆莢。

相關問題