kubernetes 實戰[1]

轉載自筆者的博客

kubernetes 容器平臺分析

Docker 容器算是目前最火的雲計算產品了，由於它解決了不少運維和開發上的痛點問題，好比抹平了開發和生產的環境區別，甚至能夠作到在生產環境使用 RHEL，而開發使用 Ubuntu，也能平滑部署，可是想要真正的將其投放到生產環境中，實際上還有不少問題亟待解決。而 kubernetes 就是這樣一個 Best Practise

生產環境容器化的需求

脫離了業務環境的架構都是耍流氓，想要將容器真正落地，就須要真正分析其需求，這裏就整理了一下容器化平臺的需求

1. 存儲

2. 網絡

3. 容器編排和服務發現

4. 負載均衡

5. 日誌收集

6. 認證受權

7. 資源配額

8. 分佈式服務

能夠看到，真正想要部署一個容器平臺實際上須要解決的問題是十分繁多的，Docker 只是解決了最根本的容器分發和運行，可是 kubernetes 卻解決了上面的大部分問題，這裏就一一講述一下。

存儲

容器都是無狀態的，很容易就被殺死，而後從新啓動，所以存儲是重中之重，Docker 自身提供了名爲數據卷的存儲方案，可是實際上沒什麼用，由於它支持的最好的就是本地存儲，掛在本地路徑，這樣的強依賴是不可能作到生產環境的分佈式服務的，除非每一臺容器節點都持有一份一樣的文件存儲，可是這樣會大大的消耗存儲空間，並且 Docker 在文件權限管理等方面也有不少問題。kubernetes 提出的方案是經過持久化存儲鏈，實際上就是作了個抽象層插件，各方能夠開發本身的插件用於支持各種存儲工具，目前已經支持 ceph、glusterfs 等主流的分佈式文件系統了，可是這些分佈式文件系統在部署上都很麻煩，甚至有性能的損失，所以使用 nas 做爲存儲是最便捷性能最好的。

網絡

網絡也是容器平臺的重點問題，由於不可能依靠一個容器提供全部的服務，好比一個容器提供了數據庫和 web 服務，並且這樣也不利於解耦，所以容器之間須要經過網絡通訊，用過 Docker 自身網絡的都知道，Docker 其實是經過網橋來實現容器之間網絡通訊的，默認設置是沒法作到跨節點網絡，可是能夠經過設置 flannel 產生一個 SDN，而後 Docker 使用此網絡做爲容器的網絡，這樣便能作到跨界點通訊，kubernetes 則定義了一套 CNI 標準，只要符合這套標準就能讓 kubernetes 使用 SDN，而目前來講已經有不少軟件定義網絡實現了這套協議，好比 flannel、weave，不過目前而言最好用的仍是 flannel。

容器編排和服務發現

容器之間存在依賴必然須要編排功能，這也是 kubernetes 重點解決的問題，在容器編排上，kubernetes 有 pod、controller 概念，pod 能夠認爲是抽象的容器，它有可變的 ip，而且容易被殺死重啓。controller 則是控制 pod 運做的控制器，replication controller、deployment、statefulsets、daemon sets，各有各的用法，好比 deployment 可以作到水平伸縮。在服務發現上面，kubernetes 有 pod、service 概念，看到這裏相信你們都會有疑問，pod ip 可變總不能每次都要手動改程序或者配置才能訪問吧，實際上 kubernetes 提供的 service 就是用來解決這個問題的，service 是一套虛擬的 ip，service 經過 selector 選擇器挑選出本身身後的 pod，這樣就能作到提供穩固的 ip 接口，其餘容器無需關心數據庫的 ip，只須要關心數據庫這個 service 就能夠。service 自己的 ip 則不是經過 SDN 產生的，而是經過 iptables 導流，將其導入到實際的 pod 中，可是這樣子依舊存在一個問題，就是 service 的 ip 一樣須要提早知道，這時候就須要服務發現出馬了，kubernetes 自身提供了一套簡單好用的 DNS 發現機制，kube-dns 將 service 註冊到 dns 中，經過 dns 就能解析獲得 service 對應的 ip。

負載均衡

負載均衡實際上就是須要一個前端負載均衡器，將流量統一導入到不一樣的容器中，kubernetes 的方案是經過 ingress 定義規則，而後根據規則產生模板配置，就好比 nginx 做爲負載均衡器，產生配置後 reload 就能生效，可是目前官方提供的 ingress controller 容器鏡像存在着一個問題，當 ingress 定義一個 TCP/UDP 四層負載均衡轉發的時候，nginx 容器則必須修改容器部署，由於須要綁定主機端口。所以目前最好的方案仍是經過雲服務器提供商的負載均衡器，好比 GCE、AWS 提供的負載均衡器。

日誌收集

日誌收集實際上不光是收集容器經過標準輸出標準錯誤產生的日誌，還須要收集容器運行時信息，好比內存、cpu 佔用等信息，這裏不細講了，由於不管是 Docker 仍是 kubernetes 都提供了收集方案，不過 kubernetes 更加靈活好用，而且收集的信息更全面，連容器節點的信息都能收集

認證受權

kuberentes 有幾大組件 apiserver、controller manager、scheduler、proxy、kubelet，全部的組件都經過 apiserver 通訊和管理，所以須要經過認證和受權來防止非法操做，在這上面 kubernetes 提供了不少方案，好比 basic auth、bearar token、keystone 等，可是真正能投入生產環境使用的，只有 OpenID Connector，不知道這種認證受權的能夠自行谷歌，更糟的是，官方甚至沒有提供部署方案，須要自行研發 OpenID Connector 服務器而且部署下去。CoreOS 卻是開源了一套 dex 系統，可是這玩意實際上也不靠譜，照樣須要研發力量的支持，從這上面就決定了 kubernetes 高門檻的准入標準。

資源配額

kubernetes 資源配額方案很是豐富，不管是存儲配額仍是內存甚至是 cpu 限額，均可以經過 yaml 文件定義

分佈式服務

分佈式服務是大規模運行容器平臺的關鍵，由於容器平臺必然是部署在多節點上的，而 kubernetes 天生就是爲分佈式部署開發的，apiserver、controller manager、scheduler 實際上就是主節點，而 proxy 和 kubelet 則是每一個 slave 節點都須要的。不過目前主流的作法包括 kubeadm 半自動部署方案都是讓主節點經過 kubelet 在容器中運行 apiserver 等東西。

總結

想要在生產環境大規模應用容器化技術，看似開源了產品，可是 kubernetes 本質上是一個半成品，甚至連自動化部署方案都不成熟，而且須要研發力量的支持才能真正運行起來，以筆者我的的意見來講，kubernetes 實際上並不是是一個面向企業終端用戶的產品，而是一個面向雲計算廠商的半成品，它真正的用法應當是雲計算公司提供自動化節點部署方案，雲計算平臺提供 SDN 、負載均衡和分佈式存儲，甚至可能的話，讓雲計算廠商提供一套管理控制 web 界面，而且作好認證受權系統，kube-dashboard 這個官方提供的 web ui 界面實際上功能是全了，可是認證受權功能的缺失則致使普通用戶很難部署使用，或者說 kube-dashboard 原本就不是爲了普通用戶部署而開發的，而是爲了提供給廠商作二次開發準備。kube-dashboard 則是負責定義 web 管理界面應該有哪些功能。