基于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， kubernetes Authorization ， kubernetes Authentication ， 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，部署見bloggorouter 安裝部署, 不過在設置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兩個版本的rule都加入router，在將A版本的router下掉，就完成了上線/回滾的操作。代碼地址稍后放出。
health Manage
健康監控檢查，可以說是集群中最重要的一部分了。我們在這里沒有使用kubernetes推薦的方式，我們自己將其與內部的zabbix系統做了結合，通過zabbix來對整個集群進行監控、報警、自動化操作。
-
對于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同學對日志進行處理。