使用Netsil監控Kubernetes上的微服務_Kubernetes中文社群
Kubernetes是容器編排和排程領域的王者，它擊敗了競爭對手Docker Swarm和Apache Mesos，開啟了閃耀的未來，微服務可以自修復，可以自動擴充套件，可以跨zone，region甚至跨雲供應商進行federate。在這樣的雲原生應用程式的新紀元裡，能夠以簡單的方式洞察服務之間是如何互動的變得日益重要——這可和大海撈針般大範圍尋找導致效能問題的某個特定的原因是不一樣的。
我們花了些時間研究Netsil並且將其解決方案打包成原生的Kubernetes Deployment。Netsil的應用程式，Application Operations Center (AOC，應用運維中心)，幫助使用者觀察並且收集跨Kubernetes叢集執行的微服務應用程式的分析資料。服務本身是不可知的，因為它在網路上才能決定其實際上如何執行。隨著時間的推移，並且實時地，它學習並且發現使用者的環境，幫助使用者逐漸搭建出SLA指標器，警報器等等。
開始吧
首先你需要一個Kubernetes叢集。我使用Stackpoint.io快速建立一個叢集。在任意主流供應商，比如AWS，GCE或者Azure上建立一個叢集。需要確保為你的主節點選擇足夠大的配置——這是所有收集器會將資料傳送這裡，在網路，處理器和記憶體上都可能消耗比較大。worker節點可以是任何配置，只要能夠滿足微服務應用程式的需求。在我的示例裡，使用了較大的例項配置，因為我會將多種服務都推送到這個環境裡。
在我們的示例裡，使用3個N1標準4的例項構建了一個叢集，這些例項通過HAProxy Ingress Controller暴露出去，它是自發現的，並且在部署它們時註冊了AOC服務。我們能夠使用叢集的公開VIP訪問AOC儀表盤。
開始前
在僅僅運行了Kubernetes服務的空空的叢集上再安裝一些服務，這裡使用Sock Shop，這是由Weaveworks開發的微服務參考程式。這樣有助於模擬一個真實的環境。Sock Shop使用了14個不同的服務，這是很多企業的應用程式會達到的複雜度。現在將AOC新增到我們的環境裡。
這裡有關於Sock Shop的詳細資訊。將其推送到環境裡很簡單，僅僅需要在克隆了repo後執行如下命令即可：
kubectl apply -f deploy/kubernetes/manifests
然後檢查Pod是否已經線上了：
$ kubectl get pods --namespace=default NAME READY STATUS RESTARTS AGE cart-3694116665-eccpp 1/1 Running 0 55m cart-db-2305146297-u30g8 1/1 Running 0 55m catalogue-11453786-lkslj 1/1 Running 0 55m catalogue-db-393939662-bn7uc 1/1 Running 0 55m front-end-3820830240–01e6t 1/1 Running 0 55m orders-3498886496-z8jun 1/1 Running 0 55m orders-db-1775353731-u7dmf 1/1 Running 0 55m payment-3012088042-vbfhw 1/1 Running 0 55m queue-master-936560853-ocmxi 1/1 Running 0 55m rabbitmq-1897447621–2ij04 1/1 Running 0 55m shipping-1232389217-b278a 1/1 Running 0 55m spc-balancer-biilo 1/1 Running 0 1h user-3090014237–196pv 1/1 Running 0 55m user-db-1338754314-exyou 1/1 Running 0 55m
開始觀察吧
我們已經有了執行著的Kubernetes 1.4叢集，並且安裝了Sock Shop應用程式，那麼開始學習環境裡是什麼吧。當股票購買者遇到問題時我們是否能知道呢？
在部署AOC之前需要在所有主機上執行如下命令。該命令幫助避免一個已知的Flannel和kube-proxy的競爭問題。
iptables -t nat -I POSTROUTING -o flannel.1 -s host-private-ip -j MASQUERADE
使用每臺主機的私有IP替換host-private-ip。完成後，從GitHub克隆AOC Kubernetes repo：
git clone https://github.com/netsil/netsil-kube.git
並且使用如下單個命令將其推送到Kubernetes裡：
kubectl apply -f netsil.yml
確保Pod和Service已經線上了。AOC容器可能需要一些時間，但是收集器會被啟動並且佇列裡的資料會被推送進來，因為它們已經開始發現你的環境了。
$ kubectl get po,svc — namespace=netsil NAME READY STATUS RESTARTS AGE collector-7wpaa 1/1 Running 0 1h collector-9o6k4 1/1 Running 0 1h collector-rzekv 1/1 Running 0 4m netsil-vjf5f 1/1 Running 0 1h NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE netsil 10.200.126.143 <nodes> 443/TCP,2001/TCP,2003/TCP,2003/UDP 1h
AOC拓撲有兩個主要元件。第一個是作為帶有單個副本的Replication Controller的一部分執行的Pod。它執行AOC儀表盤和資料收集的平臺。第二個元件是AOC收集器的DaemonSet。它告訴Kubernetes在環境的所有節點上執行一個帶有收集器容器的Pod。這些收集器配置為向AOC Pod傳送資訊。
生成流量
我們將使用Sock Shop的更多工具來模擬網站上的購物行為。這讓我們能看到AOC是如何學習流量模式以及我們的通用拓撲的。
你需要知道Sock Shop監聽以及執行的前端IP地址和埠：
docker run weaveworksdemos/load-test -h $frontend-ip[:$port] -r 100 -c 2
隨著load-test的執行，可以開始看到AOC隨著資料的獲得被點亮了：
因為AOC作為DaemonSet部署，如果任意Pod銷燬了並且在其他地方重新排程，AOC能夠繼續觀測到拓撲，隨著Kubernetes的變化而變化。
我很喜歡AOC的一個原因是部署通過服務來組織，並且我能夠實時地觀察到環境，並且開始深入不同的度量，為了那些可能影響到客戶的事情搭建服務級別的警報。因此，當環境像下圖一樣變紅時，我能夠獲得警報，知道某個服務處在緊急狀態，比如Sock Shop裡的信用卡和地址端點。
我甚至還可以深入儀表盤，知道承受最大壓力的Pod和容器是什麼。在本示例裡，網路壓力最大的容器是flannel Pod。這讓我們能夠了解最繁忙的服務是哪個，能夠幫助我們重新思考配置或者Kubernetes裡分發部署的方式。
總結
Netsil的AOC是非常棒的工具，可以幫助使用者實時觀察環境，隨著使用模式的變化而更新。使用者可以挖掘歷史資料並且新增警報。應用程式隨著新增更多的節點會自動擴充套件，新節點上線後就會在上面啟動一個收集器，這樣使用者能夠得到節點從上線到銷燬的所有資料。
如果想在自己的Kubernetes環境裡使用Application Operations Center，只需要下載這裡的manifests就可以了。可以在http://netsil.com學習Netsil和Application Operations Center。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
崔婧雯，現就職於IBM，高階軟體工程師，負責IBM WebSphere業務流程管理軟體的系統測試工作。曾就職於VMware從事桌面虛擬化產品的質量保證工作。對虛擬化，中介軟體技術，業務流程管理有濃厚的興趣。