ofo容器pass架構分享

1、咱們先要了解一下，爲何企業須要一個paas平臺？或者能夠說paas到底能作什麼？

1.1 咱們先來了解一下paas究竟是什麼？

PaaS是Platform-as-a-Service的縮寫，意思是平臺即服務，
首先，在瞭解Paas以前須要知道什麼是雲計算，雲計算是指基於互聯網網絡，經過虛擬化（xen OpenStack）統一管理和調度計算，國內廠商如：阿里雲/aws/ucloud/等等
目前雲計算三大類：

1.基礎設施即服務（IaaS）
2.平臺即服務（PaaS）
3.軟件即服務（SaaS）

1.2企業爲何須要一個PaaS？

平臺即服務（PaaS）
PaaS提供應用服務引擎，將軟件研發測試和運維的平臺做爲一種服務提供，應用程序接口，開發人員基於這些服務構建業務應用。從運維和開發角度來講，這意味着無需運維搭建環境，開發也不會由於不一樣平臺兼容性方面遇到困擾。

 

2、ofo for PaaS（kubernetes）平臺介紹

2.1 平臺簡介

1. 提供多種應用發佈方式和持續交付能力並支持微服務架構。
2. 平臺自身組件支持實時橫向擴展，一鍵式應用快速部署。
3. PaaS簡化了集羣管理，監控、平常運維操做簡化
4. 整合了CI/CD/以及雲廠商的虛擬化、存儲、網絡和安全
5. 業務高峯自動擴縮容，根據應用的負載狀況，動態加載應用實例；
6. kubernetes HPA pod根據配置閥值自動擴縮容，node節點cpu配置閥值，集成各個雲廠商api，自動擴容node節點。
7. 保證公司業務1分鐘內自動恢復。整年故障率下降。
8. 更高的資源利用率 node節點單機性能最大化
9. 節省服務器成本百分之40-60。

2.2 Dashboard

• 顯示當前集羣
• 節點狀態
• 節點監控
• 組件狀態
• POD、namespace等等

2.3 應用服務

• pod管理
• service管理

2.4 定時任務

• kubernetes 、cronjob管理

2.5 配置中心

• configmap管理

2.6 CI/CD

• DevOps 持續交付
• 配合 Jenkins 自動完成從代碼提交到應用部署的 DevOps
• 實現從代碼變動到代碼構建，鏡像構建和應用部署的全流程自動化，持續反饋
• 每次集成或交付，都會第一時間將結果實時反饋

2.7 資源審計監控

• PAAS平臺操做審計
• Webshell操做審計
• 資源利用率Dashboard
• 容器資源使用報表

2.8 高級功能

• 特權容器：容器性能優化，問題診斷strace
• 主機網絡：使用宿主機網絡環境
• 初始化容器：性能優化，容器內最小權限
• 建立網絡服務：對集羣內（外）提供網絡服務
• 容器Webshell：登陸容器，問題診斷

 



3、生產環境高併發線上業務容器化

咱們在生產環境下運維kubernetes 已經有一段時間了，咱們7*24 全天候 爲每個業務保駕護航ofo容器雲 （簡稱Ruly）咱們底層基於某雲容器基礎服務，以及自建機房IDC、經過調用雲平臺API以及RO模板快速建立管理docker實例。

1. 咱們team在高併發業務場景下作了哪些優化
2. 容器化後比以前性能要好，同配置下延遲更低、故障恢復時間更快，服務成本下降
3. 分享個線上case 咱們team在高併發業務場景下作了哪些優化 3.1 優化：基礎篇性能測試 



咱們team在高併發業務場景下作了哪些優化

  3.1 優化：基礎篇性能測試

選擇比較適合的實例規格或機器型號. 雲服務器需支持多隊列網卡

 

 

 

3.2 系統層面優化

操做系統優化：支持大併發，單集羣2000節點
K8s&容器層面優化：支持大併發，基礎鏡像製做優化等等
Principle：最小權限，優先跑滿容器資源限制
docker宿主目錄直接跑在默認/var/lib/docker下 長期跑下來會致使系統盤異常。致使down機等。所以咱們作了一下調整，自定義鏡像（lvm) 增長可擴展性

3.3 內核參優化
docker進程異常Dead狀態 at centos 7.4 
* 增長fs.may_detach_mounts

 



總結：咱們作了大量業務壓測，以及雲平臺slb 、ecs idc 機器作了大量的性能調優，對業務的優化，配合開發同窗作了大量的debug 才使得咱們業務能在容器穩定的運行

3.4 容器化後比以前性能要好，同配置下延遲更低、故障恢復時間更快，服務成本下降
容器vs傳統部署模式 （最後兩個0.98ms 和0.96ms 爲容器



 

3.5 分享個線上case

在某某天一個凌晨4點，忽然接到短信報警，此時你們都在深睡，早上八點起牀後發現收到了兩條報警，一條是磁盤80%的告警，一條是磁盤恢復的報警，咱們能夠想象一下哈，若是你業務部署到了服務器，將會發生什麼，4-8點徹底能夠吧機器磁盤空間寫滿，致使業務異常。機器oom 爲何容器會自動恢復呢。緣由和簡單，kubernetes自帶有異常的pod自動驅逐，當磁盤空間大於百分之80 他會斷定這個pod是有問題的。

解釋：
本地磁盤是一個 BestEffort 資源，kubelet 會在 DiskPressure 的狀況下，kubelet 會按照 QoS 進行評估。若是 Kubelet 斷定缺少 inode 資源，就會經過驅逐最低 QoS 的 Pod 的方式來回收 inodes。若是 kubelet 斷定缺少磁盤空間，就會經過在相同 QoS 的 Pods 中，選擇消耗最多磁盤空間的 Pod 進行驅逐。

4、kubernetes之生產環境etcd高可用、備份、監控等

 

4.1 要說到kubernetes，就必定要聊聊etcd ，他存儲了於整個kubernetes的信息

etcd是一個高可用的鍵值存儲系統，主要用於共享配置和服務發現。etcd是由CoreOS開發並維護的，靈感來自於 ZooKeeper 和 Doozer，它使用Go語言編寫，並經過Raft一致性算法處理日誌複製以保證強一致性。
etcd能夠用於配置共享和服務發現。

 



4.2 etcd主要分爲四個部分：

HTTP Server：用於處理用戶發送的API請求以及其餘etcd節點的同步與心跳信息請求

Store：存儲，用於處理etcd支持的各種功能的事務，包括數據索引，節點狀態變動，事件處理與執行等。它是etcd對用於提供的大多數API功能的具體實現

Raft： Raft強一致算法的具體實現，是etcd的核心

WAL： Write Ahead Log(日誌先行)，WAL是一種實現事務日誌的標準方法。etcd經過WAL進行持久化存儲，全部的數據在提交以前都會事先記錄日誌 a. Snapshot: 防止數據過多而進行的狀態快照 b. Entry: 存儲的具體的日誌內容

 



4.3 etcd中的術語：

• Raft: etcd所採用的保證分佈式系統強一致的算法
• Node: 一個Raft狀態機實例
• Member: 一個etcd實例,管理一個Node，能夠爲客戶端請求提供服務
• Cluster: 多個Member構成的能夠協同工做的etcd集羣
• Peer: 同一個集羣中，其餘Member的稱呼
• Client: 向etcd集羣發送HTTP請求的客戶端
• WAL: 預寫日誌，是etcd用於持久化存儲的日誌格式
• Snapshot: etcd防止WAL文件過多而設置的快照，存儲etcd數據狀態
• Proxy: etcd的一種模式，能夠爲etcd提供反向代理服務
• Leader: Raft算法中經過競選而產生的處理全部數據提交的節點
• Follower: Raft算法中競選失敗的節點，做爲從屬節點，爲算法提供強一致性保證
• Candidate: Follower超過必定時間接收不到Leader節點的心跳的時候，會轉變爲Candidate(候選者)開始Leader競選
• Term: 某個節點稱爲Leader到下一次競選開始的時間週期,稱爲Term(任界，任期)
• Index: 數據項編號, Raft中經過Term和Index來定位數據

4.4 Raft 狀態機

Raft集羣中的每一個節點都處於一種基於角色的狀態機中。具體來講，Raft定義了節點的三種角色： Follower、Candidate和Leader。

• Leader(領導者): Leader節點在集羣中有且僅能有一個，它負責向全部的Follower節點同步日誌數據
• Follower(跟隨者): Follower節點從Leader節點獲取日誌，提供數據查詢功能，並將全部修改請求轉發給Leader節點
• Candidate(候選者): 當集羣中的Leader節點不存在或者失聯以後，其餘Follower節點轉換爲Candidate，而後開始新的Leader節點選舉

這三種角色狀態之間的轉換，以下圖：



 

一個 Raft 集羣包含若干個服務器節點；一般是 5 個，這容許整個系統容忍 2 個節點的失效。在任什麼時候刻，每個服務器節點都處於這三個狀態之一：領導人、跟隨者或者候選人。在一般狀況下，系統中只有一個領導人而且其餘的節點所有都是跟隨者。跟隨者都是被動的：他們不會發送任何請求，只是簡單的響應來自領導者或者候選人的請求。領導人處理全部的客戶端請求（若是一個客戶端和跟隨者聯繫，那麼跟隨者會把請求重定向給領導人）

每次成功選舉，新的Leader的Term(任屆)值都會比以前的Leader增長1。當集羣中因爲網絡或者其餘緣由出現分裂後又從新合併的時候，集羣中可能會出現多於一個的Leader節點。此時，Term值更高的節點纔會成爲真正的Leader。

4.5 etcd client

主要包含如下幾個功能：

• Cluster：向集羣裏增長etcd服務端節點之類，屬於管理員操做。
• KV：咱們主要使用的功能，即操做K-V。
• Lease：租約相關操做，好比申請一個TTL=10秒的租約。
• Watcher：觀察訂閱，從而監聽最新的數據變化。
• Auth：管理etcd的用戶和權限，屬於管理員操做。
• Maintenance：維護etcd，好比主動遷移etcd的leader節點，屬於管理員操做

4.6.etcd 運維、與備份

 

• 安裝就不在這裏詳細介紹了。簡單介紹下平常運維以及備份

1、查看集羣中的節點
ETCDCTL_API=3 etcdctl --endpoints=https://xxx.xx.xx.xx --cacert=ca.pem --cert=etcd-client.pem --key=etcd-client-key.pem --write-out=table member list

2、添加節點

使用etcdctl member add node-name --peer-urls="https://xxx:2380"添加節點，生成變量。

1.準備新機器, 將上一步生成的配置文件變量，寫到新節點，尤爲是集羣狀態爲existing。(目標節點的數據目錄要清空)

2.生成用於集羣節點通訊的SSL證書

3.生成用於客戶端和節點通訊的證書

4.啓動並檢查

3、生產環境建議

建議採起多臺etcd集羣至5臺，保證多個節點掛掉不會影響使用

4、etcd 備份



配合 cronjob nfs 或 雲共享儲存 建議分鐘級別保留

4.7. etcd 監控

推薦promtheus + grafana 可自定義promtheus etcd 報警規則，或grafana alert 插件報警 等等



 



參考 https://coreos.com/etcd/docs/latest/op-guide/monitoring.html

5、容器基礎監控、業務監控

監控是整個運維環節，乃⾄至整個產品⽣生命週期中最重要的⼀環、事前及時預警發現故障、過後提供數據追查定位問題，分析業務指標等等堅持業務指標採集是代碼的⼀部分原則不不動搖，提⾼高指標覆蓋率監控⽅方式和指標要標準化。

5.1. 定製容器基礎監控規則、規範。好比cpu閥值、內存閥值、磁盤閥值等等、高峯期 robot自動巡檢 報告
5.2. 監控選型：promtheus 、zabbix 等等

• Promtheus 負責監控整個集羣 配合grafana
• 業務監控：監控pod cpu mem 使用率 等等
• zabbix：負責文本類監控，如message 監控 kubernetes pod list 是否 running狀態、以及pod擴縮容監控

5.3.報警規則，怎麼才能讓避免垃圾報警。避免狼來了的故事
全部報警規則promtheus 或 zabbix 需根據kubernetes Kubelet 監控資源消耗規則匹配，特別注意要和kubernetes一些自動恢復規則最好匹配，儘可能低於kubernetes規則，要比kubernetes早發現,自研告警信息管理平臺，
在一個平臺中接收全部監控系統的告警，讓運維人員集中處理系統異常事件，避免多平臺切換，提高運維效率。 promtheus、Zabbix等主流監控平臺的告警自動整合進來 ，使用時間序列規則，將大量重複的告警事件壓縮爲一條有真正意義的告警。然後經過屬性關聯、 機器學習等算法把相關的告警合併起來，安排一線運維負責7x24小時應急值守， 快速接收告警進行初步預判，二線研發團隊負責告警升級的分析和根源定位，建議使用釘釘，短信報警

一個kubernetes 集羣的 dashborad 基本信息



 

指定pod cpu mem 監控



 

5.4 pod自動擴容提醒 和異常pod（crashloopbackoff）報警（釘釘報警）



 

5.5 業務監控 、pod cpu 內存 監控 高峯期自動釘釘發送 無人值守



 

6、kubernetes趟過的坑

6.1 案例一

異常：
authentication.k8s.io:0xc820374f50] is already registered
kubectl throwing group is already registered error
緣由：
kubectl版本與Kubernetes版本不一致致使的
解決：
選擇相應的kubectl版本從新安裝

 

6.2 案例二
異常：
kubelet: E0529 17:40:11.741095 14358 fs.go:418] Stat fs failed. Error: no such file or directory

緣由：因爲安裝docker時宿主目錄被軟鏈 overlayfs清理container不完整致使的

解決：
安裝kubernetes集羣時 docker須要配置好宿主目錄 不要軟鏈

 

6.3案例三

異常：svc ip 變化 致使沒法訪問，1.9.4以前的驚天大BUG

緣由：一個或者多個 Kubernetes service 對應的 Kubernetes endpoints 消失幾分鐘或者更長時間，kubectl get ep --all-namespaces」 不斷查詢，能夠觀察到一些 AGE 在分鐘級別的 endpoints 老是突然消失，endpoints不穩定，致使service沒法變化

解決：升級kubernetes至1.9.3或更高 1.9.2的bug

 

6.4 案例四
異常：作線上cordon節點的時候 服務不能夠用，致使某雲slb 沒法轉發到節點的容器業務服務

緣由：通常設置cordon的以後就會drain作排水調度，在ServiceController裏面確實會將unschedulable的節點從service上移除，這個是目前kubernetes的機制

解決：作cordon操做時選擇在業務低峯期，好比凌晨操做，分批操做不要一會兒所有cordon

7、trouble shooting for linux

經常使用技巧

• 經過系統級別的方法先查看總體系統負載狀況，再快速定位具體模塊問題
• top / iotop / iftop等查看CPU負載，io負載，網卡負載整體狀況
• ps / lsof查看（鏈接句柄）進程當前關聯的句柄（進程）
• strace抓一段時間可疑進程的系統調用狀況
lsof
• 枚舉進程打開的句柄（文件、sockets）
• 查看某一文件或鏈接（TCP/UDP端口）所關聯的進程
• 查看flock文件鎖&線程鎖交叉致使的死鎖(W)
• lsof
• lsof -nPp 
• lsof -nPI@192.168.xx.x:22
• lsof /var/lib/mysql/mysql.sock
ss

• 查看TCP/UDP sockets狀態• ss -an | grep LISTEN• netstat -s• EST, CLOSE-WAIT, TIME-WAIT, SYN_RECV• 發送TCP RST能夠避免進入TIME-WAIT狀態Tcpdump• 網絡抓包，網絡故障分析• tcpdump -vv -i eth0 port xx -X -s 0• tcpdump -vv -s 0 -i eth0 port xx -w /tmp/xx.pcap