基于kubernetes的docker集群實(shí)踐
在公司內(nèi)部，基于kubernetes實(shí)現(xiàn)了簡(jiǎn)單的docker應(yīng)用集群系統(tǒng)，拿出來和大家分享下，在這個(gè)系統(tǒng)中，實(shí)現(xiàn)了應(yīng)用的自動(dòng)部署、動(dòng)態(tài)擴(kuò)容、節(jié)點(diǎn)切換、健康檢查、AB式版本更新等功能，也歡迎大家將各自的實(shí)現(xiàn)也分享給我。
整體架構(gòu)
整體架構(gòu)如下圖：
其中分為分為這幾個(gè)塊：
- APPBuilder： 應(yīng)用構(gòu)建模塊，負(fù)責(zé)將app打包成dockerimage，并入image版本庫;
- container： 容器運(yùn)行，docker容器實(shí)際運(yùn)行的地方;
- thirdPart： 應(yīng)用依賴的第三方資源，如redis、mysql等;
- scheduler： 調(diào)度系統(tǒng)，核心部分，負(fù)責(zé)各個(gè)子模塊的智能調(diào)度;
- router： 基于7層的請(qǐng)求分發(fā)，根據(jù)url將請(qǐng)求分發(fā)到對(duì)應(yīng)的app容器;
- nats： 基于4層的負(fù)載均衡，，將流量負(fù)載均衡到router集群;
- healthManage： 健康檢查系統(tǒng)，包括了對(duì)router rules、容器狀態(tài)、物理機(jī)狀態(tài)等各個(gè)子模塊健康的檢查，并做相應(yīng)補(bǔ)救action;
- log模塊： 統(tǒng)一處理app所產(chǎn)生的日志;
scheduler
首先先介紹下最重要的部分，使用kubernetes作為技術(shù)實(shí)現(xiàn)，關(guān)于介紹和部署可以參考之前的 blog：kubernetes 0.18.1 安裝 & 部署 & 初試，不過這個(gè)文檔中只有單機(jī)的master-slave，不太符合線上使用，我們?cè)诖嘶A(chǔ)上做了以下升級(jí)：
部署etcd集群，具體過程可以參考etcd官方：Clustering Guide
部署kubernetes master cluster，分別部署有 kube-apiserver，kube-scheduler，kube-controller-manager;
增加對(duì)kubernetes訪問的 認(rèn)證 & 授權(quán)， 具體可參考我之前的blog，kubernetes Authorization， kubernetes Authentication ， kubernetes中的Admission Controllers
關(guān)閉kube master的非安全端口訪問，關(guān)閉 insecure-port,開啟secure-port，并對(duì)kubernetes secure api訪問增加前端負(fù)載均衡，如在blog kubernetes 實(shí)用 api list 所示，訪問就是通過認(rèn)證&https請(qǐng)求api(當(dāng)然了其中的信息都是假的，但是格式不變);
設(shè)置相關(guān)的訪問權(quán)限，如，kube slave節(jié)點(diǎn)只允許來自kube-master節(jié)點(diǎn)的iP訪問，kube-master只允許具有操作權(quán)限的機(jī)器節(jié)點(diǎn)的ip訪問等等;
對(duì)kubernetes master子模塊的參數(shù)做符合我們要求的調(diào)整等;
附上制作https私有key&證書的方法：
- openssl genrsa -aes256 -out ca-key.pem 2048
- openssl req -new -x509 -days 3650 -key ca-key.pem -sha256 -out ca.pem （在提示輸入Common Name時(shí)，輸入https訪問的host，如10.10.5.103）
- openssl genrsa -out server-key.pem 2048
- openssl req -subj "/CN=10.10.5.103" -new -key server-key.pem -out server.csr
- echo subjectAltName = IP:10.10.5.103,IP:127.0.0.1 > extfile.cnf
- openssl x509 -req -days 3650 -in server.csr -CA ca.pem -CAkey ca-key.pem \
- -CAcreateserial -out server-cert.pem -extfile extfile.cnf
產(chǎn)生三個(gè)文件： ca-key.pem，server-key.pem，server-cert.pem
設(shè)置kube-apiserver參數(shù)：
- --tls-cert-file=./server-cert.pem \
- --tls-private-key-file=./server-key.pem
在client訪問時(shí)，通過ca-key.pem來進(jìn)行訪問
#p#
container
對(duì)于container節(jié)點(diǎn)，沒什么好說的，其實(shí)就是kubernetes slave節(jié)點(diǎn)，部署有：kube-proxy， kubelet，docker。
沒有什么好說的，主要是對(duì)個(gè)別參數(shù)做了調(diào)整等等。
Router
我們選用gorouter作為七層路由轉(zhuǎn)發(fā)工具，并將其搭建起cluster，部署見blog gorouter 安裝部署, 不過在設(shè)置rules的生命周期時(shí)，我們將周期設(shè)定為***，如果發(fā)生rules失效，通過healthCheck來刪掉已失效的rule。
nats
四層負(fù)載均衡，就很統(tǒng)一了，開源的可以使用LVS，土豪的可以使用F5，我們是土豪，我們使用的是F5.
ThirdPart
為app應(yīng)用所依賴的mysql、redis等，有專門的童鞋負(fù)責(zé)維護(hù)，短期內(nèi)不考慮和kubernetes、docker結(jié)合。
APP Builder
負(fù)責(zé)應(yīng)用的鏡像打包，我們這里選用 jekins 作為使用的工具，每次app上線前，首先要先構(gòu)建此app 版本的dockerimage，push 到私有的docker-registry。之后的升級(jí)操作流程如下：
如果是回滾也十分方便，將上一個(gè)版本在走一次這個(gè)流程即可，對(duì)應(yīng)用使用者來說，沒有任何終端感知，當(dāng)AB兩個(gè)版本都生效后，將AB兩個(gè)版本的rule都加入router，在將A版本的router下掉，就完成了上線/回滾的操作。
代碼地址稍后放出。
health Manage
健康監(jiān)控檢查，可以說是集群中最重要的一部分了。
我們?cè)谶@里沒有使用kubernetes推薦的方式，我們自己將其與內(nèi)部的zabbix系統(tǒng)做了結(jié)合，通過zabbix來對(duì)整個(gè)集群進(jìn)行監(jiān)控、報(bào)警、自動(dòng)化操作。
1.對(duì)于kubernetes master，監(jiān)控項(xiàng)有：
- kuber-apiserver的狀態(tài);
- kube-controller-manager的狀態(tài);
- kube-scheduler的狀態(tài);
- kubernetes中namespace、replicationcontroller、service、pods等主要資源的數(shù)量&狀態(tài)變化;
2.對(duì)于kubernetes slave(即container節(jié)點(diǎn))，監(jiān)控項(xiàng)有：
- kubelet健康狀態(tài);
- kube-proxy健康狀態(tài);
- docker 的dataspace、metadataspace 使用情況;
- 當(dāng)前節(jié)點(diǎn)運(yùn)行容器的信息，包括了全部數(shù)量、正在運(yùn)行的數(shù)量、版本等;
3.對(duì)于docker容器本身，可參考blog Docker 監(jiān)控的一點(diǎn)想法 ，監(jiān)控項(xiàng)有：
- 創(chuàng)建時(shí)間 & 信息參數(shù);
- 容器運(yùn)行狀態(tài);
- 容器內(nèi)存、cpu、流量情況;
4.還有一個(gè)重點(diǎn)是對(duì)router及其rule做重點(diǎn)監(jiān)控：
- 檢查所有router的運(yùn)行狀態(tài);
- 監(jiān)控所有node狀態(tài)，如果非健康，及時(shí)刪除router中所以指向此node的rules;
- 檢查所有的pods及對(duì)應(yīng)的rule，如果pods中的app服務(wù)失效 或者 沒有對(duì)應(yīng)的rule指向pods(比如node節(jié)點(diǎn)損壞，其原有的pod移動(dòng)到新node節(jié)點(diǎn))，此時(shí)為pod更新router中的rule;
log
對(duì)于日志這塊，業(yè)界一直沒有一項(xiàng)統(tǒng)一的做法，在這里我們的做法是通過透?jìng)鞯姆绞?，將容器中的日志匯總到宿主機(jī)，在進(jìn)行進(jìn)一步的處理：
統(tǒng)一了所有接入系統(tǒng)的app的日志規(guī)范，包括了日志格式、日志路徑;
將容器中應(yīng)用的日志根據(jù)app的不同映射到宿主機(jī)中指定的路徑;
結(jié)合 flume， kafka， influxDB 還有其他一些組件( 日志系統(tǒng)經(jīng)典的 ELK組合)，將應(yīng)用的日志進(jìn)行匯總，方便RD同學(xué)對(duì)日志進(jìn)行處理。
目前先簡(jiǎn)單介紹到這里，稍后如有可能再將具體實(shí)現(xiàn)細(xì)節(jié)放出。
