不同方式實現集羣的可行性 && 部分不建議踩的坑

路標

1.System has not been booted with systemd as init system (PID 1). Can't operate.
2.Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
3.Package virtualbox is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'virtualbox' has no installation candidate

  1. grep -E --color 'vmx|svm' /proc/cpuinfo 返回 0

結論

無論學習docker swarms還是minikubes,如果你碰到了以上的報錯信息,並且檢索到這篇文章,很遺憾的說,這是一條死路(有點深的坑),別(不建議)浪費時間了.........

背景

從docker swarms向k8s過渡時,我碰到了很多坑,最終被docker for mac撈出來。這期間我一共使用了以下模式來探索可行性:

  1. 直接放棄了windows系統.......
  2. windows內通過VirtualBox安裝ubuntu系統,失敗:不支持二次虛擬化
  3. windows內通過串聯主機搭建docker swarms集羣節點,成功:參見我另一篇blog

    Docker Swarms 跨主機集羣搭建
    只是針對docker swarms的解決方案,爲了學習minikube繼續探索

  4. 嘗試使用WSL搭建集羣,失敗:支持虛擬化,報(PID 1)的問題

    這一條有替代解決方案,後續會給出。

  5. 嘗試使用AliCloud的ECS搭建集羣,失敗:不支持二次虛擬化
  6. Mac for docker。docker swarms成功,k8s成功

中間碰到的問題大致歸結爲3類

  1. 衆所周知的網絡原因(tizi 或 換鏡像源)
  2. 不支持二次虛擬化
  3. WSL,非線程1 (PID 1)

分析

將以上情形,根據所使用宿主系統的結構方式差異,我大致將接觸docker swarms和minukube的方式大致分了2類:

  1. 常規模式
    • windows操作系統
    • linux操作系統
    • Mac的OS操作系統
  2. 非常規模式
    • windows的linux內核:WSL
    • 在宿主系統內安裝linux系統虛擬機
    • 使用雲服務商的ECS

逐條解釋:

  1. windows操作系統:......

  2. linux操作系統
    推薦,此處說的linux操作系統是指直接安裝在物理設備上、作爲宿主系統的linux系統,而不是在虛擬機安裝的linux系列系統。對於前者,建議安裝雙系統,對於後者,替代解決方案參見:Docker Swarms 跨主機集羣搭建

  3. Mac的OS操作系統
    推薦,docker for mac還是很方便的,尤其在裝k8s的時候,由於某些衆所周知的原因,我被卡了一個星期也跑不起來minikube,但是使用docker for mac和內置k8s安裝器,非常輕鬆的完成了k8s的安裝。

下面開始幾乎都是死路

  1. WSL:windows subsystem for linux
    不想裝虛擬機的用戶win用戶可能會想到這條路,但是會報出以下錯誤:
    System has not been booted with systemd as init system (PID 1). Can't operate.

    大致意思就是WSL並非系統id爲1的線程,無法完成你想要進行的操作。這是一條“死路",但並非完全不可解,國外有位大佬想到一條替代解決方案:將docker安裝在win系統,連接windows的docker與WSL。Running Docker containers on Bash on Windows,如果有感興趣的可以嘗試。

  1. 在宿主系統內安裝linux系統虛擬機
  2. 使用雲服務商的ECS
    以上兩個情形的問題一樣,都是不支持"二次虛擬化",也即不能在虛擬機裏再裝虛擬機。

    無論是docker swarms還是minikube,仔細觀察會發現他們都是在宿主系統的虛擬軟件中創建了新的虛擬機(通過命令行)

不同方式實現集羣的可行性 && 部分不建議踩的坑

其中,myvm1、myvm2爲docker swarms節點
minikube爲minikbe主節點

是否支持二次虛擬化的判斷標準很簡單,在當前系統(linux爲例)命令行中執行以下指令即可:(其他系統參見kubernetes document

grep -E --color 'vmx|svm' /proc/cpuinfo

如果無返回或返回0,則不支持虛擬化
若返回具體數字如4 or 8,則表示可虛擬化

以上

後記

對於雲服務商的ECS不可二次虛擬這點我初始是有些驚訝的,因爲如果使用ECS的用戶想要搭建集羣該怎麼辦呢?在我和其中一個雲服務商的工程師聯繫後,得到了的回覆是:CES和雲虛擬主機都不支持二次虛擬化,裸金屬主機支持。雲服務商也有單獨的集羣相關產品,但是實現方式無法透露,他們只在使用中提供技術支持。

最後貼上最低配的彈性裸金屬服務器的性能和價格截圖:
彈性裸金屬服務器

####
要獲取更多Haytham原創文章,請關注公衆號"許聚龍":
我的微信公衆號

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章