本次内容根據2017年11月4日 K8S Geek Gathering 沙龍深圳站騰訊雲進階工程師王天夫的演講内容整理而成。
本次分享的主要内容涉及騰訊雲容器的頂層整體設計，包括産品功能，及提供的附加能力。同時會介紹我們現在Master叢集化部署的整體方案。通過這些内容的提前了解，可以更好了解後面和大家分享的關于容器監控的内容，所有監控的設計都是依賴于Master叢集化部署的。最後會和大家分享騰訊雲容器服務監控的Future Work。
大家可以看一下這個圖，這是騰訊雲容器服務PaaS平台頂層的設計，最上面是雲Portal，意義是使用者在使用我們容器服務的時候能夠從這幾個次元去掌控他們的叢集、建立他們的容器。第一個是MC，可以了解為是控制管理台，大家都知道Kubernetes本身的概念是比較複雜的，對一個剛剛接手Kubernetes的人來說了解成本是特别大的，我們在Kubernetes之上包裝了它的概念，對于剛剛接手的人來說是非常好的了解。同時可視化出來提供頁面給大家用。第二點是支援原生的K8S API，因為整個容器服務是基于K8S開發的，為了保證使用者使用不同的Kubernetes，是以我們在Kubernetes主幹上并不會去做很大的改動，因為一開始我們是做過這方面的東西，但是我們發現如果我們在K8S上做了特别大的改動，在第二次提供給使用者或者更新的時候，是一個非常困難的事情，因為大家知道K8S的疊代是非常快的，大概是半年到一年時間就會更新一個大版本，是以我們基本上都是原生基于K8S開發。最後我們還把我們自己包裝的概念通過一個雲API提供給使用者使用，因為現在很多的使用者都是有自己的營運系統的，他們會使用雲API去封裝一些自己的營運平台，是以我們這裡也支援了一下。
中間這塊是整個容器服務三個大部分，第一塊是整個CCS，這塊提供了如下的功能，像叢集管理、模闆應用管理，應用管理這裡指的是我們會把所有的服務包裝成一個大的應用，友善使用者去一鍵部署自己的應用。第三個是服務管理，我們把K8S裡面提到的概念，像deployment,service,pod封裝成服務的概念提供給使用者，後面還有日志、券和配額，這些都是我們這邊開發的。最底層，因為我們要支援原生的Kubernetes，是以不可避免的需要有些開發，比如和IaaS層、PaaS層的打通，就需要有日志、網絡、券、負載均衡的驅動開發。第二塊是CCR，是我剛才提到的鏡像服務。鏡像服務支援有多個hub源的鏡像，還有自建的Cloud的鏡像，還有第三方的也支援。同時我們做了一些比較重要的優化，我們在海外搭建了很多節點，幫助使用者能夠快速的拉取鏡像，并且做成mirror，同時我們的鏡像倉庫是分地域部署。同時我們還會定時拉去Docker Hub上的鏡像做緩存，進一步提升效率。最後一塊是CI/CD，CI/CD是去定義自動部署、自動建構的政策，例如送出代碼時自動觸發。
下面是我現在負責的CCS-Monitor Server，包括監控上面整套容器服務的體系。最底下是對我們自己騰訊雲的IaaS和PaaS層的集合，譬如說CVM、黑石，大家可以了解為公有雲和私有雲，同時我們內建塊存儲、對象存儲、CFS，我們還有日志中心，後面我會講一下。最後還有彈性伸縮和負載均衡，彈性伸縮主要可以了解為HPA和HNA，這是騰訊服務頂層的計。
接下來第二點，給大家講一下騰訊雲Master叢集化部署。下圖是現在騰訊容器服務Master叢集化部署的概覽，我給大家說一下大概的背景。當初騰訊雲的容器服務剛開始上線的時候，這個地方并不是這樣子的。
剛開始我們會為使用者的每個叢集建立一個Master，這個Master當初是一個虛拟機，為了做高可用，我們會為使用者再部署一個stand by的Master，當Master出現故障的時候，我們可以友善的切換。
最後就造成很多多的問題，一是成本的問題，如果每個叢集都部署一個Master，部署一台虛拟機，成本很大。二是運維成本，每台Master都是一台虛拟機，每個master的元件，是一個二進制檔案部署在Master上面。這種情況下，如果對某個Master進行更新，不可避免的就會出現很多問題。
基于這個考慮，我們重新優化了整個我們的Master部署，我們采用的方案是調研了社群裡面一些熱門的方案，這個方案就是kubernetes in kubernetes，不知道大家有沒有了解過這個東西。我們單獨部署一套K8S叢集，所有Master的元件，大家知道的三大元件都會以pod的形式運作在K8S叢集中。我們為Pod綁定雙網卡，一個網卡是彈性網卡，它會單獨與使用者的VPC做網絡通信，另外一個網卡是原生的，這個網卡會是Master叢集中使用的網卡。
每個API的元件都是一個Pod，好處是，一是Master叢集的部署，主要是以K8S管理，這樣HA、SLA都有很大的保證，包括後面運維的提升，可以使用K8S原生的rolling update去操作。其次是成本，有些使用者可能Master不需要那麼大的CPU Memory，我們可以共同調整CPU Memory的request，同時對于大型的客戶，譬如說在叢集中運作了上千個Pod情況下，通過動态調整擴充Master的配置，增大更多的Api server做一個負載調優。
這裡大概講了現在叢集化部署的方案，後面我監控的方案都會依賴于這個，給大家稍微先講一下這塊。
第三，基礎的名額監控。我們的基礎名額監控主要還是以IaaS層為主，就是大家所說的Cpu,Memory、DiSK和Network方面。這裡一共有四塊，Node、Deployment，Deployment，Pod，container，所有IaaS層的監控名額都會依照這四個子產品來做聚合。
上面的四塊是我講的IaaS層基礎名額，這裡我選取了幾個重要的名額，如果大家以後有自建容器監控，希望對大家有所幫助。CPU Memory有些名額是非常重要的，例如CPU Usage和Memory Usage，這裡的Cpu Usage和Memory Usage是占整個pod request或者 limit的整個比例，如果這兩個名額比較高，就必須警覺起來，可能會造成pod不可用的問題發生，另外我提一下，大家知道，在K8S中，有一個request 和limit的概念，如果request limit不配置，在一些測試環境，不知道大家有沒有試過，當一個Pod跑到很高的情況下，會出現雪崩的效應，比如跑挂一台機器，這時候挂了之後，節點異常，K8S會自動的把這台機器上所有的Pod踢走，Pod會自動建立到另外的機器上，繼續拖垮另外一台機器，這種可以稱之為“雪崩效應”。最後造成的結果是K8S叢集不可用。其次，CPU node和Memory node。目前你的K8S叢集中還有剩餘的CPU和Memory可配置設定的比例，當一個K8S pod配置的request limit不能滿足目前叢集中所剩餘的量，就會造成，新的Pod無法排程。Network比較基本，一個是進出帶寬、進出流量，還有進出包量。Disk有幾個比較重要的，traffic、iops，這些自己自建的時候也需要關注。
最後單獨提一下Inode，有一次使用者使用過程發現Pod建立不成功，經過多方面調查，發現Inode滿了，為什麼出現這種情況？我們看了K8S代碼，它對鏡像和日志都有回收機制，但是對Inode的回收和清理是沒有的，社群也有讨論，但是一直沒有解決。是以說Inode這塊是必須要監控起來的，它會造成你整個叢集中某個節點無法建立服務，是以說我單獨把它拎出來和大家提一下，我不知道現在的1.8版本有沒有解決這個問題。
最後是LB的監控，大家可以知道，servers有幾種提供的通路方式，騰訊雲容器服務的servers與騰訊雲的LB做了綁定，使用者建立servers的時候，如果指定的方式是LB，我們通過插件的方式幫他申請一個LB挂在上面，不管是内網還是外網。使用者對自己服務的監控，我們可以通過LB的Httpcode和目前的連接配接數、回包的時間等名額去做，就能準确的判斷出目前業務的健康狀态。
這是基礎監控名額大概的架構（見下圖）。我們主要使用開源的方式，大家在網上關注監控就知道，容器的監控大概有這麼幾種方案，當時我們做方案評估的時候也考慮過其他幾種，最後還是選擇了heapster的方式，還是業務驅動，因為調研的時候發現cadvisor對K8S中的聚合沒有做得特别好，它的資料都是原始的資料，如果我們在以Kubernetes的方式聚合，這是很複雜的。普羅米修斯，我們考慮它比較重，一個是集收集，告警和存儲一體的，我們需要的僅僅是收集這塊，是以說普羅米修斯并不适合我們這裡的業務，最後我們就選擇使用heapster。我們這裡的heapster也是以容器的方式部署在Master叢集化部署的叢集裡面，對使用者是無感覺的，也不消耗使用者的資源。其次heapster我們幫它綁定兩張網卡，一張是去使用者的叢集中拉取監控資料，因為大家知道heapster需要與Kubernetes通信，拉取一些監控資料，是以我們這裡必須綁定兩張網卡。其次我們會建構一個CCS Monitorserver，定時拉取一些叢集的監控資料，做一些彙總或計算。最後，我們會把這些收集到的資料Push到Barad server，這可以了解為騰訊雲整個監控的元件，這是平台級的元件。Barad server做了幾件事，一是聚合，會把我們所有上報的名額聚合成，比如我們加一些時間粒度的彙總，1分鐘、5分鐘、10分鐘這種，包括我們以Node的形式展示出整個Node下所有pod平均的監控名額。做這種聚合。最後我們會提供雲API的方式給接入層使用，接入層主要是使用者調取需要的監控名額，還有HPA和HNA，就是Pod和Node水準擴充，這個是我們直接拉取Barad API的資料做擴充工作。
第四，事件名額。其實在問題發生的時候，如果僅僅隻看基礎的監控名額是遠遠不夠的，因為你隻能發現你的服務出現了問題，但是你不能很好的去知道到底是哪個服務出現了問題，事件名額主要如下幾個問題：1、彙聚目前K8S所有資源事件的彙總，我們會根據這些事件做自己的提煉，同時push到事件中心。2、事件中心名額彌補名額監控資訊部直接的短闆，我剛才說到過。3、提高問題的定位效率。4、事件名額支援告警。事件名額主要分兩大塊：1、異常事件；2、狀态事件。異常事件大家可以了解為Pod建立失敗、重新開機、節點異常、記憶體不足、排程失敗的事件。狀态事件是一些正常事件，比如Pod啟動、銷毀、更新中、HPA觸發、HNA觸發。它對對于定位問題也有很大的幫助。
事件名額的整體方案，我們目前是從API server中拉取K8S所有的事件，會存儲在ES叢集中，我們會有内部的Cluster做資料的查詢和展示。ES中彙聚的都是每條基礎資料，也就是大家俗稱的源資料。其次CCS Monitor會把它合并成使用者能夠了解的彙總的資料，然後推到騰訊雲事件中心去。最後使用者可以在控制台上看到這個事件發生的原因、屬于哪個資源，最後還會告訴它如何解決這個問題，會有一個幫助文檔。
第五，整個監控中對騰訊最重要的是叢集穩定性的監控。這裡的圖會有點問題，叢集穩定性的監控分為四大塊，Kube-System和ETCD、Master相關元件監控，比如API server等，最重要的是運作時問題監控。
叢集穩定性監控采用三個開源的方案，一是Node Detector，主要是做運作時。Fluentd主要是采集每個Master叢集上每個容器的node，後面也用了普羅米修斯的方案，沒有再使用heapster，因為普羅米修斯，我們需要它做一些存儲，不需要做對外展示，這是内部使用，是以我們需要采用普羅米修斯去定制一些東西去采集更多的名額。大家可以看到整個Master叢集上，每個Master叢集上每個node部署的各個pod，Fluentd會拉取lod。普羅米修斯我們自己定制了一些插件，在每個pod上拉取一些我們基本的名額。同時Node Detector部署在每個使用者節點上，這是使用者可以自己選擇的。它主要采集一些Kernel和runtime的問題。Node Detector是K8S官方的項目，如果大家感興趣可以了解一下。
第六，最後一個監控元件，業務日志監控。大家知道業務日志對于一個問題定位幫助是非常大的，如果一個監控僅僅隻有事件和名額，其實很多問題都無法定位，因為容器在使用的時候，更多的會動态的增加和減少。是以我們這裡會采集容器日志，并且儲存在日志服務中，供使用者在後期能更友善的去追溯到原來的一些業務問題。業務日志分四個闆塊，容器日志的收集和節點日志的收集，還有日志存儲和日志處理，現在容器日志也是前面提到的stdout和stderr日志，并且附加相關的Kubernetes Metadata，主機特定目錄的日志并附加指定的label去收集使用者容器達到主機上固定的日志。存儲方面，我們支援把日志發送到使用者自己搭建的Kafka或者ES或者騰訊雲的日志服務中存儲起來做消費。最後一塊是日志處理，日志處理主要是友善使用者能夠去友善定位問題，同時我們支援能夠根據一定關鍵字配置一些關鍵字的告警，最後我們後續可能還會支援做一些大資料的處理工作。
整個業務日志的監控整體的方案（見PPT），我們讓使用者定義一個個不同的規則，不同的規則可以叫collector，所有的collector會并成一個Config Map，在啟動Fluentd的時候會收集Cluster指定的收集政策，最後發送到不同的後端源，當時做這套設計的時候我們考慮其他元件的方案，主要采集的agent，我們考慮了filebeat和fluentd,最後我們采用的還是fluentd，一是基于性能的考慮，fluentd是c和ruby寫的，消耗隻有在40M左右，filebeat會更大一些。最重要的一點是fluentd支援資料源推的路由，也就是說它能夠通過不同的規則、不同的lable去推到不同的終端上。例如我有一條規則A和規則B，它分别推到ES或者Ckafka，是以我們最後就選擇了fluentd的方案做業務日志的收集。
最後講一下我們後期調研的工作和待開發的工作：1、自定義監控。自定義希望讓使用者能夠自己去定義一些監控名額，自己Push一些監控名額到我們的監控平台。2、調用鍊追蹤和Real-time Monitor的部署，當一個應用起來之後，會有成千上百的容器在裡面傳輸，調用鍊就是非常直覺的監控方向,同時配合realtimemonitor，能夠很好的發現服務的健康狀态，其次我們還會提供一個應用市場，因為現在普遍上開源也有很多的監控方案，我們會把它打包成一個個應用提供給使用者使用，最後兩點就是告警的預測和叢集網絡的監控，告警預測我們希望通過我們收集的資料去分析可能發生的問題，例如說當一個時間點内某項名額與前段時間周期性比較的名額的發生很大差異的時候，我們需要能夠及時的通知使用者，這裡可能會出現了問題。叢集網絡的監控方面，我們發現使用者在部署的叢集的時候，經常有些iptables，ACL，或者timeout等網絡的問題，這塊的監控後期同樣會補上。