摘要：不過目前主流的做法包括半自動部署方案都是讓主節(jié)點通過在容器中運行等東西。

轉載自筆者的博客

Docker 容器算是目前最火的云計算產(chǎn)品了，因為它解決了很多運維和開發(fā)上的痛點問題，比如抹平了開發(fā)和生產(chǎn)的環(huán)境區(qū)別，甚至可以做到在生產(chǎn)環(huán)境使用 RHEL，而開發(fā)使用 Ubuntu，也能平滑部署，但是想要真正的將其投放到生產(chǎn)環(huán)境中，實際上還有很多問題亟待解決。而 kubernetes 就是這樣一個 Best Practise

脫離了業(yè)務環(huán)境的架構都是耍流氓，想要將容器真正落地，就需要真正分析其需求，這里就整理了一下容器化平臺的需求

存儲

網(wǎng)絡

容器編排和服務發(fā)現(xiàn)

負載均衡

日志收集

認證授權

資源配額

分布式服務

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

容器都是無狀態(tài)的，很容易就被殺死，然后重新啟動，因此存儲是重中之重，Docker 自身提供了名為數(shù)據(jù)卷的存儲方案，但是實際上沒什么用，因為它支持的最好的就是本地存儲，掛在本地路徑，這樣的強依賴是不可能做到生產(chǎn)環(huán)境的分布式服務的，除非每一臺容器節(jié)點都持有一份同樣的文件存儲，但是這樣會大大的消耗存儲空間，而且 Docker 在文件權限管理等方面也有很多問題。kubernetes 提出的方案是通過持久化存儲鏈，實際上就是做了個抽象層插件，各方可以開發(fā)自己的插件用于支持各類存儲工具，目前已經(jīng)支持 ceph、glusterfs 等主流的分布式文件系統(tǒng)了，但是這些分布式文件系統(tǒng)在部署上都很麻煩，甚至有性能的損失，因此使用 nas 作為存儲是最便捷性能最好的。

網(wǎng)絡也是容器平臺的重點問題，因為不可能依靠一個容器提供所有的服務，比如一個容器提供了數(shù)據(jù)庫和 web 服務，而且這樣也不利于解耦，因此容器之間需要通過網(wǎng)絡通信，用過 Docker 自身網(wǎng)絡的都知道，Docker 實際上是通過網(wǎng)橋來實現(xiàn)容器之間網(wǎng)絡通信的，默認設置是無法做到跨節(jié)點網(wǎng)絡，但是可以通過設置 flannel 產(chǎn)生一個 SDN，然后 Docker 使用此網(wǎng)絡作為容器的網(wǎng)絡，這樣便能做到跨界點通信，kubernetes 則定義了一套 CNI 標準，只要符合這套標準就能讓 kubernetes 使用 SDN，而目前來說已經(jīng)有很多軟件定義網(wǎng)絡實現(xiàn)了這套協(xié)議，比如 flannel、weave，不過目前而言最好用的還是 flannel。

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

負載均衡實際上就是需要一個前端負載均衡器，將流量統(tǒng)一導入到不同的容器中，kubernetes 的方案是通過 ingress 定義規(guī)則，然后根據(jù)規(guī)則產(chǎn)生模板配置，就比如 nginx 作為負載均衡器，產(chǎn)生配置后 reload 就能生效，但是目前官方提供的 ingress controller 容器鏡像存在著一個問題，當 ingress 定義一個 TCP/UDP 四層負載均衡轉發(fā)的時候，nginx 容器則必須修改容器部署，因為需要綁定主機端口。因此目前最好的方案還是通過云服務器提供商的負載均衡器，比如 GCE、AWS 提供的負載均衡器。

日志收集實際上不光是收集容器通過標準輸出標準錯誤產(chǎn)生的日志，還需要收集容器運行時信息，比如內存、cpu 占用等信息，這里不細講了，因為無論是 Docker 還是 kubernetes 都提供了收集方案，不過 kubernetes 更加靈活好用，并且收集的信息更全面，連容器節(jié)點的信息都能收集

kuberentes 有幾大組件 apiserver、controller manager、scheduler、proxy、kubelet，所有的組件都通過 apiserver 通信和管理，因此需要通過認證和授權來防止非法操作，在這上面 kubernetes 提供了很多方案，比如 basic auth、bearar token、keystone 等，但是真正能投入生產(chǎn)環(huán)境使用的，只有 OpenID Connector，不知道這種認證授權的可以自行谷歌，更糟的是，官方甚至沒有提供部署方案，需要自行研發(fā) OpenID Connector 服務器并且部署下去。CoreOS 倒是開源了一套 dex 系統(tǒng)，但是這玩意實際上也不靠譜，照樣需要研發(fā)力量的支持，從這上面就決定了 kubernetes 高門檻的準入標準。

kubernetes 資源配額方案非常豐富，無論是存儲配額還是內存甚至是 cpu 限額，都可以通過 yaml 文件定義

分布式服務是大規(guī)模運行容器平臺的關鍵，因為容器平臺必然是部署在多節(jié)點上的，而 kubernetes 天生就是為分布式部署開發(fā)的，apiserver、controller manager、scheduler 實際上就是主節(jié)點，而 proxy 和 kubelet 則是每個 slave 節(jié)點都需要的。不過目前主流的做法包括 kubeadm 半自動部署方案都是讓主節(jié)點通過 kubelet 在容器中運行 apiserver 等東西。

想要在生產(chǎn)環(huán)境大規(guī)模應用容器化技術，看似開源了產(chǎn)品，但是 kubernetes 本質上是一個半成品，甚至連自動化部署方案都不成熟，并且需要研發(fā)力量的支持才能真正運行起來，以筆者個人的意見來說，kubernetes 實際上并非是一個面向企業(yè)終端用戶的產(chǎn)品，而是一個面向云計算廠商的半成品，它真正的用法應當是云計算公司提供自動化節(jié)點部署方案，云計算平臺提供 SDN 、負載均衡和分布式存儲，甚至可能的話，讓云計算廠商提供一套管理控制 web 界面，并且做好認證授權系統(tǒng)，kube-dashboard 這個官方提供的 web ui 界面實際上功能是全了，但是認證授權功能的缺失則導致普通用戶很難部署使用，或者說 kube-dashboard 本來就不是為了普通用戶部署而開發(fā)的，而是為了提供給廠商做二次開發(fā)準備。kube-dashboard 則是負責定義 web 管理界面應該有哪些功能。