基於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 kubernetes 實用 api list 所示，訪問就是經過認證&https請求api（固然了其中的信息都是假的，可是格式不變）；

• 設置相關的訪問權限，如，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來對整個集羣進行監控、報警、自動化操做。

1. 對於kubernetes master，監控項有：

   • kuber-apiserver的狀態；

   • kube-controller-manager的狀態；

   • kube-scheduler的狀態；

   • kubernetes中namespace、replicationcontroller、service、pods等主要資源的數量&狀態變化；

2. 對於kubernetes slave（即container節點），監控項有：

   • kubelet健康狀態；

   • kube-proxy健康狀態；

   • docker 的dataspace、metadataspace 使用狀況；

   • 當前節點運行容器的信息，包括了所有數量、正在運行的數量、版本等；

3. 對於docker容器自己，可參考blog Docker 監控的一點想法 ，監控項有：

   • 建立時間 & 信息參數；

   • 容器運行狀態；

   • 容器內存、cpu、流量狀況；

4. 還有一個重點是對router及其rule作重點監控：

   • 檢查全部router的運行狀態；

   • 監控全部node狀態，若是非健康，及時刪除router中因此指向此node的rules；

   • 檢查全部的pods及對應的rule，若是pods中的app服務失效 或者 沒有對應的rule指向pods（好比node節點損壞，其原有的pod移動到新node節點），此時爲pod更新router中的rule；

log

對於日誌這塊，業界一直沒有一項統一的作法，在這裏咱們的作法是經過透傳的方式，將容器中的日誌彙總到宿主機，在進行進一步的處理：

1. 統一了全部接入系統的app的日誌規範，包括了日誌格式、日誌路徑；

2. 將容器中應用的日誌根據app的不一樣映射到宿主機中指定的路徑；

3. 結合 flume， kafka， influxDB 還有其餘一些組件（ 日誌系統經典的 ELK組合），將應用的日誌進行彙總，方便RD同窗對日誌進行處理。

目前先簡單介紹到這裏，稍後若有可能再將具體實現細節放出。