基於kubernetes的docker叢集實踐
在公司內部,基於kubernetes實現了簡單的docker應用集群系統,拿出來和大家分享下,在這個系統中,實現了應用的自動部署、動態擴容、節點切換、健康檢查、AB式版本更新等功能,也歡迎大家將各自的實現也分享給我。
整體架構
整體架構如下圖:
其中分為分為這幾個塊:
-
APPBuilder: 應用構建模組,負責將app打包成dockerimage,併入image版本庫;
-
container: 容器執行,docker容器實際執行的地方;
-
thirdPart: 應用依賴的第三方資源,如redis、mysql等;
-
scheduler: 排程系統,核心部分,負責各個子模組的智慧排程;
-
router: 基於7層的請求分發,根據url將請求分發到對應的app容器;
-
nats: 基於4層的負載均衡,,將流量負載均衡到router叢集;
-
healthManage: 健康檢查系統,包括了對router rules、容器狀態、物理機狀態等各個子模組健康的檢查,並做相應補救action;
-
log模組: 統一處理app所產生的日誌;
scheduler
首先先介紹下最重要的部分,使用kubernetes作為技術實現,關於介紹和部署可以參考之前的 blog:kubernetes 0.18.1 安裝 & 部署 & 初試,不過這個文件中只有單機的master-slave,不太符合線上使用,我們在此基礎上做了以下升級:
-
部署etcd叢集,具體過程可以參考etcd官方:Clustering Guide
-
部署kubernetes master cluster,分別部署有 kube-apiserver,kube-scheduler,kube-controller-manager;
-
增加對kubernetes訪問的 認證 & 授權, 具體可參考我之前的blog,| 72fb2910302a12da3b6c7d219f31484c3 |, | 72fb2910302a12da3b6c7d219f31484c4 | , kubernetes中的Admission Controllers
-
關閉kube master的非安全埠訪問,關閉 insecure-port,開啟secure-port,並對kubernetes secure api訪問增加前端負載均衡,如在blog
-
設定相關的訪問許可權,如,kube slave節點只允許來自kube-master節點的iP訪問,kube-master只允許具有操作許可權的機器節點的ip訪問等等;
-
對kubernetes master子模組的引數做符合我們要求的調整等;
附上製作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時,輸入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
產生三個檔案: ca-key.pem,server-key.pem,server-cert.pem
設定kube-apiserver引數:
--tls-cert-file=./server-cert.pem \
--tls-private-key-file=./server-key.pem
在client訪問時,通過ca-key.pem來進行訪問
container
對於container節點,沒什麼好說的,其實就是kubernetes slave節點,部署有:kube-proxy, kubelet,docker。
沒有什麼好說的,主要是對個別引數做了調整等等。
Router
我們選用gorouter作為七層路由轉發工具,並將其搭建起cluster,部署見blog gorouter 安裝部署, 不過在設定rules的生命週期時,我們將週期設定為永久,如果發生rules失效,通過healthCheck來刪掉已失效的rule。
nats
四層負載均衡,就很統一了,開源的可以使用LVS,土豪的可以使用F5,我們是土豪,我們使用的是F5.
ThirdPart
為app應用所依賴的mysql、redis等,有專門的童鞋負責維護,短期內不考慮和kubernetes、docker結合。
APP Builder
負責應用的映象打包,我們這裡選用 jekins 作為使用的工具,每次app上線前,首先要先構建此app 版本的dockerimage,push 到私有的docker-registry。之後的升級操作流程如下:
執行AB上線
如果是回滾也十分方便,將上一個版本在走一次這個流程即可,對應用使用者來說,沒有任何終端感知,當AB兩個版本都生效後,將AB兩個版本的rule都加入router,在將A版本的router下掉,就完成了上線/回滾的操作。
程式碼地址稍後放出。
health Manage
健康監控檢查,可以說是叢集中最重要的一部分了。
我們在這裡沒有使用kubernetes推薦的方式,我們自己將其與內部的zabbix系統做了結合,通過zabbix來對整個叢集進行監控、報警、自動化操作。
-
對於kubernetes master,監控項有:
-
kuber-apiserver的狀態;
-
kube-controller-manager的狀態;
-
kube-scheduler的狀態;
-
kubernetes中namespace、replicationcontroller、service、pods等主要資源的數量&狀態變化;
-
-
對於kubernetes slave(即container節點),監控項有:
-
kubelet健康狀態;
-
kube-proxy健康狀態;
-
docker 的dataspace、metadataspace 使用情況;
-
當前節點執行容器的資訊,包括了全部數量、正在執行的數量、版本等;
-
-
對於docker容器本身,可參考blog Docker 監控的一點想法 ,監控項有:
-
建立時間 & 資訊引數;
-
容器執行狀態;
-
容器記憶體、cpu、流量情況;
-
-
還有一個重點是對router及其rule做重點監控:
-
檢查所有router的執行狀態;
-
監控所有node狀態,如果非健康,及時刪除router中所以指向此node的rules;
-
檢查所有的pods及對應的rule,如果pods中的app服務失效 或者 沒有對應的rule指向pods(比如node節點損壞,其原有的pod移動到新node節點),此時為pod更新router中的rule;
-
log
對於日誌這塊,業界一直沒有一項統一的做法,在這裡我們的做法是通過透傳的方式,將容器中的日誌彙總到宿主機,在進行進一步的處理:
-
統一了所有接入系統的app的日誌規範,包括了日誌格式、日誌路徑;
-
將容器中應用的日誌根據app的不同對映到宿主機中指定的路徑;
-
結合 flume, kafka, influxDB 還有其他一些元件( 日誌系統經典的 ELK組合),將應用的日誌進行彙總,方便RD同學對日誌進行處理。
目前先簡單介紹到這裡,稍後如有可能再將具體實現細節放出。