摘要:健康監控檢查,可以說是集群中最重要的一部分了。我們在這里沒有使用推薦的方式,我們自己將其與內部的系統做了結合,通過來對整個集群進行監控報警自動化操作。
在公司內部,基于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。
沒有什么好說的,主要是對個別參數做了調整等等。
我們選用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下掉,就完成了上線/回滾的操作。
代碼地址稍后放出。
健康監控檢查,可以說是集群中最重要的一部分了。
我們在這里沒有使用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同學對日志進行處理。
目前先簡單介紹到這里,稍后如有可能再將具體實現細節放出。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32434.html
摘要:健康監控檢查,可以說是集群中最重要的一部分了。我們在這里沒有使用推薦的方式,我們自己將其與內部的系統做了結合,通過來對整個集群進行監控報警自動化操作。 在公司內部,基于kubernetes實現了簡單的docker應用集群系統,拿出來和大家分享下,在這個系統中,實現了應用的自動部署、動態擴容、節點切換、健康檢查、AB式版本更新等功能,也歡迎大家將各自的實現也分享給我。 整體架構 整體架構...
摘要:容器云的背景伴隨著微服務的架構的普及,結合開源的和等微服務框架,宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。 容器云的背景 伴隨著微服務的架構的普及,結合開源的Dubbo和Spring Cloud等微服務框架,宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態到無狀態,具體來說將業務狀態數據如:會話、用戶數據等存儲到中間件中服務中。 showI...
摘要:容器云的背景伴隨著微服務的架構的普及,結合開源的和等微服務框架,宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。 容器云的背景 伴隨著微服務的架構的普及,結合開源的Dubbo和Spring Cloud等微服務框架,宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態到無狀態,具體來說將業務狀態數據如:會話、用戶數據等存儲到中間件中服務中。 showI...
摘要:個推針對服務場景,基于和搭建了微服務框架,提高了開發效率。三容器化在微服務落地實踐時我們選擇了,下面將詳細介紹個推基于的實踐。 2016年伊始Docker無比興盛,如今Kubernetes萬人矚目。在這個無比需要創新與速度的時代,由容器、微服務、DevOps構成的云原生席卷整個IT界。個推針對Web服務場景,基于OpenResty和Node.js搭建了微服務框架,提高了開發效率。在微服...
摘要:個推針對服務場景,基于和搭建了微服務框架,提高了開發效率。三容器化在微服務落地實踐時我們選擇了,下面將詳細介紹個推基于的實踐。 2016年伊始Docker無比興盛,如今Kubernetes萬人矚目。在這個無比需要創新與速度的時代,由容器、微服務、DevOps構成的云原生席卷整個IT界。個推針對Web服務場景,基于OpenResty和Node.js搭建了微服務框架,提高了開發效率。在微服...
閱讀 1668·2021-11-12 10:35
閱讀 1614·2021-08-03 14:02
閱讀 2682·2019-08-30 15:55
閱讀 2027·2019-08-30 15:54
閱讀 756·2019-08-30 14:01
閱讀 2427·2019-08-29 17:07
閱讀 2252·2019-08-26 18:37
閱讀 3031·2019-08-26 16:51