怎么用Ansible部署Kubernetes集群到OpenStack

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

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

Kubernetes（K8S）是一個通過調用API來編排和管理Docker容器的平臺。除了基本的編排功能，它還有持續驅動控制進程的功能，面向用戶指定所需的狀態。當使用這個平臺的時候，你能將你的應用程序容器分組到一個叫pod的組合單元。pod是一個分享網絡和存儲的容器組。當你創建Docker容器的時候，默認設置下，每個容器都會獲得自己的網絡命名空間也就是它自己的TCP／IP堆棧。Kubernetes用－net＝”<container-name>|<container-id>”設置到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<nodename>.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這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！