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

轉(zhuǎn)載自筆者的博客

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

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

存儲(chǔ)

網(wǎng)絡(luò)

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

負(fù)載均衡

日志收集

認(rèn)證授權(quán)

資源配額

分布式服務(wù)

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

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

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

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

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

日志收集實(shí)際上不光是收集容器通過(guò)標(biāo)準(zhǔn)輸出標(biāo)準(zhǔn)錯(cuò)誤產(chǎn)生的日志，還需要收集容器運(yùn)行時(shí)信息，比如內(nèi)存、cpu 占用等信息，這里不細(xì)講了，因?yàn)闊o(wú)論是 Docker 還是 kubernetes 都提供了收集方案，不過(guò) kubernetes 更加靈活好用，并且收集的信息更全面，連容器節(jié)點(diǎn)的信息都能收集

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

kubernetes 資源配額方案非常豐富，無(wú)論是存儲(chǔ)配額還是內(nèi)存甚至是 cpu 限額，都可以通過(guò) yaml 文件定義

分布式服務(wù)是大規(guī)模運(yùn)行容器平臺(tái)的關(guān)鍵，因?yàn)槿萜髌脚_(tái)必然是部署在多節(jié)點(diǎn)上的，而 kubernetes 天生就是為分布式部署開發(fā)的，apiserver、controller manager、scheduler 實(shí)際上就是主節(jié)點(diǎn)，而 proxy 和 kubelet 則是每個(gè) slave 節(jié)點(diǎn)都需要的。不過(guò)目前主流的做法包括 kubeadm 半自動(dòng)部署方案都是讓主節(jié)點(diǎn)通過(guò) kubelet 在容器中運(yùn)行 apiserver 等東西。

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