這篇文章主要講解了“怎么用Ansible部署Kubernetes集群到OpenStack”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么用Ansible部署Kubernetes集群到OpenStack”吧！

創新互聯是由多位在大型網絡公司、廣告設計公司的優秀設計人員和策劃人員組成的一個具有豐富經驗的團隊，其中包括網站策劃、網頁美工、網站程序員、網頁設計師、平面廣告設計師、網絡營銷人員及形象策劃。承接：成都網站制作、成都做網站、外貿營銷網站建設、網站改版、網頁設計制作、網站建設與維護、網絡推廣、數據庫開發,以高性價比制作企業網站、行業門戶平臺等全方位的服務。

首先要answer的問題就是kubernetes和ansible是什么，為什么要選擇他們？

Kubernetes（K8S）是一個通過調用API來編排和管理Docker容器的平臺。除了基本的編排功能，它還有持續驅動控制進程的功能，面向用戶指定所需的狀態。當使用這個平臺的時候，你能將你的應用程序容器分組到一個叫pod的組合單元。pod是一個分享網絡和存儲的容器組。當你創建Docker容器的時候，默認設置下，每個容器都會獲得自己的網絡命名空間也就是它自己的TCP／IP堆棧。Kubernetes用－net＝”|”設置到Docker里，以此將所有的pod容器的網絡空間結合到一起。這個設置令容器可以再次使用另一個容器的網絡堆棧。K8S通過創建一個pod層面保持容器和它自己的網絡堆棧來完成，所有的pod容器被配置來重新使用保持容器的網絡空間。

在pod層面，Kubernetes提供各種services，比如調度，副本，自我修復，監控，命名／發現，身份識別，驗證授權等等。Kubernetes也有可以讓開發者寫自己模塊的插件模版，然后在這個平臺上面創建services。就像這篇博客寫得，Kubernetes是最先進的、可編寫和管理Docker容器的開源平臺之一。

我們選擇Ansible是因為它是當下最火、最直接、最容易使用的自動化平臺之一。它運行代理較少，在基礎架構上使用ssh來登錄系統，執行你在playbook文件中描述的策略。這些策略被模式化為一個yaml格式的任務清單。在沒有自動化的時候，這些就是必須由管理員來執行部署基礎設施軟件的手動任務。

這篇博客帖描述了在OpenStack虛擬機上面運行的Kubernetes集群。一個K8S集群有一個master節點，這個節點運行API server和一套運行在pod容器上的worker節點。設置使用的是Ansible（>2.0），Ubuntu和Neutron網絡。測試后，使用OpenStack kilo來發布。Ansible部署K8S軟件組件，啟動虛擬機，將虛擬機分類到master和worker節點，然后部署Kubernetes密鑰清單。我們使用neutron來給OpenStack虛擬機和K8S pod容器提供網絡連接。所有在測試環境中的虛擬機都運行Ubuntu 14.04 服務器操作系統。

下圖展示的是運行中的各種軟件組件，以及他們是如何在集群中交互的。我會把這個圖表作為資料來闡述自動進程，當你瀏覽這篇博客的時候，看到這個框圖就會覺得說得通了。

設置

這個設置是假設你已經有一個OpenStack云運行核心services，比如Nova，Neutron，Glance和Keystone。你還需要>2.X的ansible版本在一個有憑證和網絡連通ssh到計算節點和虛擬機。這個ansible節點也需要能夠訪問openStack API。我在我的Macbook上面用這些命令安裝了ansible：

sudo easy_install pip

sudo pip install ansible

在你安裝了ansible之后，用命令行：“ansible－version”來驗證它的版本。它應該輸出一個2.X發布版本。

Kubernetes集群Deployment

自動化集群配置由三個ansible playbooks控制。你可以點擊這里拉取playbooks，模版和代碼：https://github.com/naveenjoy/microservices。這三個playbooks是：

·      launch-instances.yml — launches kubernetescluster instances

·      deploy-docker.yml  — deploys docker onall of the cluster instances

·      deploy-kubernetes.yml — deploys kubernetescontrol and worker software components and brings up the cluster

所有的playbooks 從一個叫做settings.yml的文件中獲取他們輸入變量，這是根據設置文件參考的。設置文件中的節點代碼字典和他們的原數據（也叫做標簽）在集群指定節點的名字，標簽在應用程序啟動的時候被注入到節點里面。這些標簽在運行playbooks的時候，被云庫存腳本（https://github.com/naveenjoy/microservices/blob/master/scripts/inventory.py）用來將節點分類為master和worker。比如，標簽為ansible-_host_groups的節點是k8s_master會被分類為master節點，而標簽值等于k8s_worker會被分類為workers。設置文件也包括名為os_cloud_profile的代碼字典，它給ansible提供nova虛擬機啟動設置。為了開啟實例，如下運行playbook：

ansible-playbook -i hosts launch-instances.yml.

如果一切進行順利，你會看到所有的Nova實例已經在OpenStack云上準確無誤地創建好了。這些實例會提供底層基礎設施來運行K8S集群。在增加實例之后，你可以運行剩下的playbooks來部署Docker和Kubernetes。在playbook運行的時候，使用名為‘inventory.py’庫存腳本來分類節點，這樣control和worker組件就會被部署到正確的虛擬機上。

按如下所示運行playbooks：

ansible-playbook -i scripts/inventory.py deploy-docker.yml

ansible-playbook -i scripts/inventory.py deploy-kubernetes.yml

K8S集群的控制面板包括了API服務器，調度器，etcd數據庫和kube controller manager通過一個master密鑰清單文件。這個文件名為master-manifest.j2可以在模版文件夾里面找到。K8S控制面板軟件的版本是由設置文件決的。這個名為deploy-kubernetes.yml的playbook是第一次下載和部署kubelet和kube－proxy二進制，并且在所有節點上開啟這兩個services。然后master-manifest模版文件就會在master節點上被部署到一個叫做／etc／kubernetes／manifest的config目錄。這個目錄被kubelet daemon進程監視，它開啟了所有的提供控制面板services的Docker容器。當你使用Docker ps命令的時候，你會看到kube－apiserver，kube－controller－manager，etcd和kube－schedules進程在master節點里運行在他們自己的容器上。

API服務器被配置來使用HTTPS服務API。SSL所需的證書是通過將make-ca-cert.sh腳本作為playbook任務之一來運行生成的。這個腳本在每個節點上的證書目錄中生成了以下證書。這個在每個節點上都有生成，因為Docker daemon也使用相同的服務器證書來配置TLS。cert文件目錄值在設置文件中也是可配置的。

ca.pem——自簽CA證書

Server.crt/server.key——簽署的kube服務器端證書和它的密鑰文件。這個cert文件也可以被Docker Daemon進程用來確保客戶端安全訪問。

cert.pem/key.pem——簽署的客戶端證書和它的密鑰文件。kubectl和docker客戶使用。

在客戶機上面，你可以在repo里面找到這些certs文件夾。在客戶機里用convention.env為每個節點都創建了Docker環境文件。你可以追蹤這個環境變量的來源，然后運行Docker客戶端而不是Docker主機。比如，為了在名為master1的master節點上運行Docker命令，第一步就是執行“source master1.env”，然后運行命令。同樣，對于kubectl客戶端來說，config文件是由必要的憑證和集群master IP地址來創建的。Config文件可以在$HOME/.kube/config中找。這樣你可以在集群上的終端窗口運行kubectl命令。

在這篇博客帖中，我會描述如何使用OpenStack neutron service來連接K8S pods。這跟GCE的設置有些相似。其實也可以選擇其他的，比如Flannel，使用UDP封裝在現有租戶neutron中為路由pod創建一個覆蓋網絡選項。使用neutron為pod網絡刪除這個為容器覆蓋又覆蓋的網絡構架。

要重點注意的是在K8S中每個pod（也就是一組容器）都有一個IP地址。這就區別于在Docker中的網絡模版，在這里每個容器有主機的私有IP地址。為了讓K8S網絡運行起來，pod的IP地址必須是不需要NAT的，可路由的。這也就意味著兩件事情：

a）當一個pod容器與其它pod中的容器交流的時候，通信必須是直接路由，不需要NAT的。

b）當一個pod容器與虛擬機的IP地址交流的時候，通信必須是直接路由，不需要NAT的。

為了完成以上目的，第一步就是，在每個節點中名為docker0的默認docker橋被一個名為cbr0的Linux橋所替代。跨過所有節點，一個IP模塊被分配給pod網絡，比如說／16。這個模塊被抽象化了，節點到pod的映射被創建在一個設置文件里。在以上圖表中，我把10.1.0.0/16分配給pod網絡，然后創建了以下映射：

node1 : 10.1.1.1/24

node2: 10.1.2.1/24

nodeN: 10.1.n.1/24

create－bridge.sh（create-bridge.sh）腳本創建cbr0，然后使用在設置文件中定義好的映射來配置pod子網絡的IP地址。

第二步就是配置租戶路由器到路由流量，再到pod子網絡。比如在以上的框圖中，租戶路由器肯定是被配置到路徑中，再配置流量到pod子網絡10.1.1.0/24，配置到位于private－subnet＃1上node＃1的以太網絡地址。同樣的，路徑必須添加在集群中指向每個節點的目的站來路由流量到pod網絡。使用add_neutron_routes.py腳本完成這個步驟。

第三步就是添加IP tables規則到冒充流量，從pod子網絡到為出站連接的網絡。這是因為neutron租戶路由器不知道它需要從pod子網絡SNAT流量。

最后一步就是打開在每個節點的Linux內核上的IP轉發，到路徑包，再到網橋容器網絡。這些任務都由playbook deploy－kubernetes.yml執行的。

運行這個playbook的最終結果就是，neutron網絡現在被編程來進行pods到網絡間的路由通信。

注意：默認狀態下，作為一個抗欺騙安全措施，neutron在超管理器上安裝iptables防火墻規則，來控制流量在虛擬機端口的來去。所以，當路由流量注入pod網絡到虛擬機的端口，它是被超管理器防火墻過濾過的。所幸，有一個叫做AllowedAddressPairs的neutron擴展，它允許如pod子網絡的Havana發布版本，來通過虛擬機監控程序防火墻。

暴露Pod Services

出于實用性目的，每個pod必須放在服務抽象的前面。這個服務使用可以連接到pod容器里面運行的應用程序，來提供穩定的IP地址。這是因為pod能夠在任意節點上被調度，而且可以從分配好的node_pod_cidr范圍獲取任意IP地址。同樣的，當你擴展／縮減這些pods來容納流量變化，或者當運行失敗的pods通過平臺再次創建，他們的IP地址就會改變。從客戶角度來看，服務抽象要確保pods的IP地址保持固定。要重點注意的是，對于服務來說，CIDR，也就是cluster_cidr，只在每個節點本地存活，并不需要被neutron租戶路由器路由。這個服務IP流量被K8S用proxy功能（kube－proxy）分布到備份pod，proxy功能通常用iptables在每個節點中實施。

這個穩定的service IP可以用Kubernetes的NodePort性能暴露到外面。節點端口所做的事情就是，它使用worker節點的IP地址和一個高TCP端口31000，來暴露服務IP地址和端口到外部。所以如果你分配一個浮動IP到節點，應用程序會在那個IP和它的節點IP提供流量。如果你使用一個neutron負載平衡器，那就添加worker節點成員，編寫vip分布流量到節點端口。這個方法在以上框圖中已經闡述。

服務發現

服務發現可以使用DNS集群add-on服務實現完全自動化。可以使用skydns-manifest和skydns-service來部署。K8S會自動給每個在集群中定義的服務分配一個DNS名字。所以運行在pod里面的程序可以查找集群DNS服務器來解決服務名稱和位置。集群DNS服務支持A和SRV記錄查找。

感謝各位的閱讀，以上就是“怎么用Ansible部署Kubernetes集群到OpenStack”的內容了，經過本文的學習后，相信大家對怎么用Ansible部署Kubernetes集群到OpenStack這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創新互聯，小編將為大家推送更多相關知識點的文章，歡迎關注！