一、我們先要了解一下，為什么企業需要一個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提供應用服務引擎，將軟件研發測試和運維的平台作為一種服務提供，應用程序接口，開發人員基於這些服務構建業務應用。從運維和開發角度來說，這意味着無需運維搭建環境，開發也不會因為不同平台兼容性方面遇到困擾。
二、ofo for PaaS（kubernetes）平台介紹
2.1 平台簡介
- 提供多種應用發布方式和持續交付能力並支持微服務架構。
- 平台自身組件支持實時橫向擴展，一鍵式應用快速部署。
- PaaS簡化了集群管理，監控、日常運維操作簡化
- 整合了CI/CD/以及雲廠商的虛擬化、存儲、網絡和安全
- 業務高峰自動擴縮容，根據應用的負載情況，動態加載應用實例；
- kubernetes HPA pod根據配置閥值自動擴縮容，node節點cpu配置閥值，集成各個雲廠商api，自動擴容node節點。
- 保證公司業務1分鍾內自動恢復。全年故障率降低。
- 更高的資源利用率 node節點單機性能最大化
- 節省服務器成本百分之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：登錄容器，問題診斷

三、生產環境高並發線上業務容器化
我們在生產環境下運維kubernetes 已經有一段時間了，我們7*24 全天候 為每一個業務保駕護航ofo容器雲 （簡稱Ruly）我們底層基於某雲容器基礎服務，以及自建機房IDC、通過調用雲平台API以及RO模板快速創建管理docker實例。
- 我們team在高並發業務場景下做了哪些優化
- 容器化后比之前性能要好，同配置下延遲更低、故障恢復時間更快，服務成本降低
- 分享個線上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 進行驅逐。
四、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 運維、與備份
- 安裝就不在這里詳細介紹了。簡單介紹下日常運維以及備份
一、查看集群中的節點
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
二、添加節點
使用etcdctl member add node-name --peer-urls="https://xxx:2380"添加節點，生成變量。
1.准備新機器, 將上一步生成的配置文件變量，寫到新節點，尤其是集群狀態為existing。(目標節點的數據目錄要清空)
2.生成用於集群節點通信的SSL證書
3.生成用於客戶端和節點通信的證書
4.啟動並檢查
三、生產環境建議
建議采取多台etcd集群至5台，保證多個節點掛掉不會影響使用
四、etcd 備份

配合 cronjob nfs 或 雲共享儲存 建議分鍾級別保留
4.7. etcd 監控
推薦promtheus + grafana 可自定義promtheus etcd 報警規則，或grafana alert 插件報警 等等

參考 https://coreos.com/etcd/docs/latest/op-guide/monitoring.html
五、容器基礎監控、業務監控
監控是整個運維環節，乃⾄至整個產品⽣生命周期中最重要的⼀環、事前及時預警發現故障、事后提供數據追查定位問題，分析業務指標等等堅持業務指標采集是代碼的⼀部分原則不不動搖，提⾼高指標覆蓋率監控⽅方式和指標要標准化。
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 內存 監控 高峰期自動釘釘發送 無人值守
六、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
七、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