如何在裸機下自動安裝部署CoreOS + Kubernetes
本次分享的主題是：如何在裸機下自動安裝部署 CoreOS + Kubernetes。主要從背景、工作原理、具體過程、采過的坑四個方面來分享。
先介紹一下背景
隨著光音業務規模的上升，線上業務產品的數量及服務器的采購量也越來越大。當達到一定數量級后，就不能使用常規的維護方法來解決這些問題。以前，一旦業務量上去，我們就不得不停下手頭的開發工作，部署業務所需要的環境及線上調試，到最后，只有特別熟悉業務和代碼的同事才能勝任此工 作。為了解決這些問題，我們從前年開始就關注了LXC，并試著小規模地使用了一段時間，但是由于LXC本身存在一系列的問題，比如內核版本的限制及二次開 發困難，沒能大規模地推廣。
后來隨著Docker的發展及火熱，我們也接觸到了CoreOS，它的AB分區升級特性特別吸引人。使用后才發現，跟宣傳寫的不一樣，還是需要重 啟服務器才能升級內核的，但是總的來說，結合Fleet的使用，可以動態地把業務遷到其它服務器，來達到平滑升級的目的，因此還是非常不錯的。
我是從開發轉到基礎平臺維護崗位的，所以希望用開發的方式來解決運維的問題，并想通過改變運維的方式的來加快業務研發的速度。但是真正專職做平臺 開發后，才意識到搭建整個運維體系是多么困難的事。所以，為了更快地構建我們的平臺，業務的選型首選開源框架，然后再它的基礎上，根據業務的需要做二次開 發。借著Google的名氣以及相對完善的生態圈，我們最終選擇了Kubernetes + CoreOS + Docker，做為整個平臺編排調度的基礎。
我們每次采購機器，一般都是幾百個節點，所以整個平臺的部署就非常頭疼，特別是CoreOS和Kubernetes，必須借助梯子才能安裝和更新，讓人非常不爽。前期的大部分時間都浪費在這上面了！
于是，寫了一個簡單的Yoo-Installer工具來解決這些問題，現在分享給大家。
由于想呈現最簡單便捷的安裝方式，結果沒把握好時間，這次的分享準備不足，所以你們可以多提問，我多分享一些采過的坑。
項目代碼我放到 GitHub上了，代碼還在不斷完善中，如果有問題，可以直接在上面提Issue。另外，我們組的一個同事趙文來也貢獻Kubernetes-client 的Nodejs版本，一并分享給大家： https://github.com/Goyoo/node-Kubernetes-client，希望能跟大家一起打造美好的Docker生態圈。
下面介紹Yoo-Installer是如何工作的
它共分為DHCP Service、TFTP Service、HTTP Service，其中HTTP Service 里包括了CoreOS的引導，安裝到硬盤，Kubernetes的安裝及其它服務腳本的初始化。
PXE引導在這里需要分享幾個點：
收到DHCP廣播，獲取IP
使用TFTP進行通信，傳輸CoreOS的基礎IMGAGE
在內存啟動CoreOS系統
系統啟動成功后，下載腳本，執行安裝Kubernetes及其它相關服務。
服務器的IP。在安裝服務器前，應該確定好服務器的IP，因為IP在后面的安裝是一個非常重要的變量。比如etcd的service IP，Kubernetes的Master IP都需要寫入到配置里的。
我們是這樣做的：我們的服務器是高密度刀片服務器，都配有管理模塊。通過一些簡單的API調用，就可以得到所有的網卡mac信息，與KVM的IP保持一定 的邏輯關系，這樣就可以保證服務器的IP有序，便于日后的管理與維護。（可以參考Yoo-installer項目的app/utils/IPMI /dhcpMacList.js，通過這段代碼得到dhcpd所需要的配置格式，直接使用即可）。
CoreOS集群的安裝方式
我們專門做了一個菜單，以滿足各種場景部署的需要。
在Yoo-Installer里，我分了6個菜單，適合四種使用場景。
分別對應于官方的CoreOS集群架構
- Docker Dev Environment on Laptop
- Small Cluster
- Easy Development/Testing Cluster
- Production Cluster with Central Services </ul>
- 同步系統時間，新機器可能時鐘有問題，這樣會導致CoreOS不能正常安裝，
- 硬盤分區，這個要根據自己的機器情況進行處理。
- 系統的安裝。
- 離線下載已經準備好的Kubernetes，并放到相應的系統目錄里。
- 其它腳本。
- 通知Yoo-Installer已經安裝完成并重啟。 </ol>
- 使用國外的服務器下載好一個tar包，然后下過來，load進來。
- 修改tag，在hub.docker.com里Google好像有這個鏡像，下載好后，修改成gc.io的tag。
我在項目里放了一個tar包。
Q： CoreOS的pxe是什么？
A：PXE功能是由主板提供的吧。
Q：節點=服務器？梯子？
A：我們有幾個管理服務器，做為節點進行proxy。如果需要的話，就在特定的程序變量里加ALL_PROXY。這樣做，也不會影響正常的網絡。
Q：網絡模型怎么選?橋接，同網段大網？OpenvSwitch？
A： 我們目前用的是Flannel，這個是CoreOS自帶的。
Q：怎么考慮網絡？
A：網絡目前使用的就是Flannel，同上一個問題。
Q：yoo installer做為開發開發人員的開發環境有什么可以分享的嗎？
A： 我覺得如果僅僅開發使用，可能不太適合。因為這個是為批量安裝部署設計的。如果是開發后的壓測，倒是可以考慮使用啊，因為想安裝的話，放到安裝網絡環境里就可以了。
Q：請問有對K8S的API調用做限制類嗎？
A：你是指限制資源嗎？在配置文件里做就可以了啊。如果還有API的問題，可以與我的同事探討一下：@Moon@北京-Goyoo 。
Q：最小集群的話一般需要幾臺VM？
A： 這個要看你的業務場景。我不知道你是不是指Small Cluster，上面有圖，需要3~5個即可。
Q：關于K8S的使用，RC，Services是否做了權限分配？
A： 因為我們是自己的私有云，沒有權限的分配。
Q：從Docker容器、pod到service，的網絡是如何走的，有用DNS嗎？
A：首先我們自己有一個內網的DNS，Kubernetes也提供了DNS的功能。
Q： 我用虛擬機，里面跑了CoreOS，3臺機器組成一個小集群可以嗎？
A： 當然可以啊。集群組建有三種方式，如果你是自己玩玩，建議使用DiscoveryID的方法。
Q：今天說容器動態IP分配不好，那你們實際生產中如何做的呢？
A：直接寫Static IP. 在初始化安裝時，已經通過mac綁定上IP，然后通過IP這個變量寫到文件里，做成static IP。
Q：CoreOS 本身也是操作系統嗎？跟虛機有啥區別呢，是安裝更方便，還是本身比較簡單？
A： CoreOS比較輕，而且默認沒有包管理器，也就是不能隨便安裝東西。這樣最大的好處是底層沒有任何依賴。而且可以自動升級。當然還有其它優點，你可以看一下官方的介紹。
Q： 環境中存在其他dhcp服務，你們檢測么？
A：因為是自建機房，都是我們自己維護的，自己對拓撲很清楚。目前沒有檢測。
Q：我用Docker+etcd+confd+Nginx搭建過集群，沒有用于生產 kubernetes這種集群，不是很懂，CoreOS現在很流行么？我也沒有玩過。
A：我也只是抱著試試用的態度，有些特性很吸引人。我們公司的文化是這樣的，鼓勵試錯，不怕出錯。所以有什么問題，只有用了才知道。不過，確實有很多坑。
Q： 還有，按你之前提到的有使用dhcp.server，想問下你們部署完后的測試環境，IP地址還能更改嗎？
A：可以改啊，只要改IP的配置文件就可以了。一般安裝后就不改了。我們自己也做了指修改工具，如果好用的話，也可以分享出來給大家。
Q： 這個CoreOS系統是怎么實現的？
A：我直接放代碼了啊。有一個菜單庫，我直接拿來用了。
Q： 你們應該是實現了一個裸機安裝OS，然后部署Kubernetes點東西吧，為啥沒有用puppet或者installer這些來做Kubernetes？
A：因為整合成一套了啊，插上網線，上電，系統就安裝好了。
Q： 嘉賓，你之前提到你們使用DHCP出過事故，能詳細說一下嗎？
A： 因為硬件故障，導致DHCP不能廣播。
Q： 非CoreOS的系統有考慮支持嗎？
A：我先把這個完善了吧，完善好之后再說。歡迎PR啊，目前我們組嚴重缺人，沒有精力做太多，只能在自己的工作范圍內，順便把代碼開源了。
Q： 請問整個集群中網絡模式使用的是什么vxlan？網絡服務用的Flannel還是pipework？
A：Flannel
Q： 引導CoreOS 時使用HTTP service作用是？
A： 下載自動安裝腳本，下載Kubernetes的東西，并做一些統計，銜接整個自動安裝過程。
Q： 如果環境做成IPv6，現在這套軟件可以直接用嗎?
A：應該沒有問題啊
Q： 問個問題，那以后技術選型的話會繼續目前的kubernetes還是會有別的？后續有什么計劃或是目前有什么不足后續打算改進的地方？
A：我們暫時使用Kubernetes。目前沒有自動調度，也就是根據歷史監控數據進行學習，完成一些自動擴容及縮容。其于此，還可以繼續完善數據平臺。
Q: 想問下，部署玩之后DHCP服務器掛掉了的話，怎么處理不讓已部署的環境掉線？
A: DHCP可以做熱備方案，已經部署的，我們已經做成Static IP了，所以不會掉線
Q： 使用pod為啥對單獨的容器分配IP？Kubernetes最小調度單位不是pod嗎？對容器分配IP還有意義嗎？
A： Yoo-Installer的IP分配是物理機，pod里有自己的一套overlay
Q： Flannel方式下容器IP跟宿主機IP在一個網段嗎？
A：不在同一個網絡。各自管理自己的。
Q： 硬件故障可能是CoreOS硬件驅動問題吧，你們是重啟解決的還是重新部署？
A： 因為機器多了，故障也會顯得多一些。節點的掛機，不會影響正常的業務運轉，這就是使用Docker的好處啊。有些故障解決不了，我就直接關機。
Q： 我找到辦法了，先pull下來的同名的（國內可訪問的）image，然后用#docker tag 命令改成gcr.io的tag就可以了。
A：這種最方便了。
Q： 整個安裝過程是自動化的進度怎么掌握？
A： 在安裝完成后，會有一個成功的請求到Yoo-Cloud，通過這種方式來統計。
Q： 已經部署的改成靜態IP不是得一個容器一個容器的改啊？
A： 有一套自動的腳本，只需要取出當前機器應該分配的IP即可。
Q： Kubernetes自帶ui用到了嗎？如何？
A：不好用，功能簡單。
Q： 請問這個能部署在云主機里不？
A：云主機提供商，大部分都支持CoreOS了吧。具體的情況，我還真沒測試過。
Q： 他們沒有把os安裝和服務部署分開！現在應該很少自己公司產品用。
A：我們做的是私有混合云，服務的部署是另一套編排工具。
Q： 網絡規劃的時候沒有吧IP和端口綁定？還需要用yoo_install分配IP給物理機？
A：沒有。那樣做網絡更加復雜，在我們的應用場景下，偏向于大二層。
Q： Flannel 容器到 host 能不能通信？
A：可以通信啊，你需要用來做什么？
Q： 這套里面你們都跑哪些應用呢？
A:：我們公司里的大部分業務，目前正在努力推進Micro-services。
Q：Kubernetes對外發布服務時像端口規劃如何處理？
A：我們會規定一些port，因為我們業務還算單一，主要就是HTTP和部分TCP。
Q： 之前應用分布多臺云主機上，端口比較統一，放Kubernetes集群，如何處理？
A：他們在Flannel里，都是不同的IP了，所以不會出現端口重復的問題。
Q： 還有Kubernetes的集群的loadbanlce如何做？
A：本身不支持吧，需要自己完成相應功能。他們把這部分設計成了plugin的形式。
Q： 請問碰到過手機服務 TCP 長連接被中斷問題么？
A： 我們也有長連接，不過目前沒放到CoreOS里。對于移動端，中間很常見的吧。
Q： 應用部署用的是？Chef/Puppet？
A：目前盡量使用Docker，除了一些編排類的工具。因為CoreOS本身安裝東西就不方便，而且為了減少底層依賴。還有一個想法，熱備放到公有云上，這樣未來就不用考慮這些依賴了。一些簡單的，使用Fleet Global的形式，全局跑一個腳本的體驗也很爽。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年8月4日晚微信群分享內容整理。分享人 王鵬（Tad），光音網絡資深研發經理，云平臺負責人，專注于Docker的研究與推廣。目前負責云平臺的研發工作，積極打造基于Docker的資源自動調度，自動化構建和測試，推進產品的容器化及微服務化。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
來自： http://dockone.io/article/563
參考： CoreOS Cluster Architectures
第一種，就是開發環境的方式。我們在開發時，可以使用這種方式來開發。
小規模集群的方式。每個節點都安裝了etcd服務，任何一個節點故障都不會影響整體服務。
開發測試集群。這種方式的優點是不用額外部署etcd服務，需要幾個節點來測試，就加入幾個，非常靈活。但是不是高可用的架構。因為如果etcd死了，整體集群就不能工作了。所以，非常適合開發測試使用。
線上生產環境集群架構。這種基本上就可以做到高可用了。不同服務資源之間可以使用Meta信息進行標識。
這些代碼是如何實現的呢
主要是通過cloud-config-url參數的設置來改變不同的啟動腳本，如cloud-config-url= http://192.168.1.10/config/develop-etcd/pxe.yml
注意，這里面有一個技巧。默認的話，CoreOS是沒有密碼的。有時安裝時會出現一些問題，我會在啟動參數里加上coreos.autologin標記，這樣引導后，就可以直接進入系統，然后查找問題了。
詳見代碼： https://github.com/Goyoo/yoo-i ... fault
這樣，我們就能順利啟動系統了。
啟動后，我們需要安裝系統到硬盤，下載并安裝Kubernetes，并初始化一些系統環境等等。
這樣是怎么做的呢?
先看代碼
這里我們在cloud-config-url里自定義了一個服務，叫setup.service。等系統啟動后，會下載相應的腳本：pxe.sh。
詳見代碼。
腳本分為幾個部分：
那么，我們對于Kubernetes是如何自動處理的呢。
在CoreOS里，有一個Cloud-init文件，在每次系統啟動時，它便會自動執行。我們利用了這個文件，自動搭建了Kubernetes的服務。
比如這個Central的 YAML文件。
在這個配置文件里，有以下幾個部分
hostname: 配置后，方便識別。這些服務的配置會自動創建相應的service文件。
ssh_authorized_keys: 可以設置一個跳板機的key，方便管理。
update: CoreOS版本更新策略及更新版本設置。
Fleet: Fleet的服務。
units: 具體的systemd units文件配置，這里面包括了etcd、Fleet、Flannel、Docker、kube api server、kube controller manage、kube scheduler、kube-register等服務的配置。
我們也可以直接寫文件，比如DNS的配置，『search localhost』 ，我在coreos-init里就沒找到對應的功能配置key，只有寫文件了。
這里有幾個需要注意的地方
服務器不建議用DHCP動態分配IP，就算是MAC綁死的也不好。我們出過一次故障，DHCP服務異常，導致業務網絡中斷。關于cloud-init文件， CoreOS 提供了coreos-cloudinit的方法，可以做validate 。如果自己修改了init文件，最好檢驗一下，不然只有重啟后才能發現問題。
coreos-cloudinit不加validate參數，還可以執行，像寫文件之類的操作，直接就可以看到結果。
關于CoreOS自動下載更新。像我們這樣自建機房的，最郁悶了，不像一些國外的公有云那么方便，直接可以下載更新。怎么做呢？首先，你要有個梯子，然后通過專門設置update 的service，加上ALL_PROXY，就可以自動更新了！
為了更便捷的使用Yoo-Installer，我計劃做二個版本，一個是VM版本的，下載后，直接可以用，另一個是Docker版本的。由時準備不足，沒有做完，但是因為我自己也需用，所以我會繼續完善！
這里要吐個嘈。我在封裝DHCPD時，因為橋接的問題，Docker里面的廣播根本發不出來。如果您有高招，請告訴我，我會請你吃飯哦~
對于Yoo-Installer，為了便于使用，我們專門做了一個UI，功能還不豐富，希望大家能積極提意見，歡迎PR。
Q& A
Q：我有一個問題，剛好剛才問了一個Kubernetes創建pod，要從gcr.io下載image，被墻了，這個你們怎么解決呢？A： 這個有二個方法。
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！