Satellite是矽谷初創公司Gravitational公司旗下一個用Go寫的開源專案，可用來收集Kubernetes叢集的健康資訊，它既是一個library，也是一個應用。作為library，可以用做監控方案。在這篇文章裡，Satellite專案成員為我們分享了在一些場景下在底層（包括AWS 和裸機上）部署Kubernetes叢集時遇到的問題和他們在開發過程中用來解決其中一些問題的解決方案。

監測Kubernetes元件

監測Kubernetes叢集不是一個簡單的事情。為了闡述可能會發生的錯誤的型別，這裡是我們在AWS配置上的一個例子。
我們叢集中的一個例子完美展示了用SkyDNS執行以及所有pods啟動的健康狀態，然而，在幾分鐘之後，SkyDNS就進入“CrashLoopBackoff”狀態了。應用程式容器已經是啟動的，但是還在功能失調階段，因為他們在第一次重新啟動的時候無法到達資料庫。
結果原來是叢集宕機，但是我們只能盯著事件和pods狀態，對於發生了什麼無法得到一個清晰的理解。

在聯絡到主節點，看了SkyDNS pod的日誌之後，他們用etcd揭露一個問題。SkyDNS無法連線，或者連線在它建立之後立刻變得不穩定了。etcd它本身就是在執行的，那麼問題是出在哪裡呢？
在做了相當一部分的調查之後，我們找到了答案。高延遲網路連線磁碟導致讀寫錯誤，這就導致了etcd無法寫到檔案系統。雖然它是正確配置而且也在執行工作，但是它並不是一直可為Kubernetes服務所用。
吸取教訓——即使你已經成功地建立起叢集，但也不能保證它就可以像預期的那樣繼續工作。

那麼在配置期間哪些問題比較容易出錯呢？問題主要有以下這些：

• 主機之間沒有聯絡
• etcd宕機或者不穩定／錯誤配置導致滯後
• 主機間的覆蓋網路層損壞
• 單個節點中的任意一個都會宕機
• Kubernetes API伺服器或者控制器管理者宕機
• Docker無法啟動容器
• 網路分割會影響節點子集

我們在跟第一屆KubeCon的參加者交流了一些意見，頭腦風暴出以下可能的解決辦法：
“你怎樣評估Kubernetes叢集的健康？@klizhenas建議建立一個能夠給pods進行排程以及取消排程的app；有沒有人建立一下這個？
——Brandon Philips（@Brandon Philips）2015年11月11日

我們評估一下來監控Kubernetes的方法：

• 典型監測
• 面向應用的冒煙測試

典型監測解決辦法

傳統的監控監測方法還沒有出現短缺。這個種類之中最好的選擇之一就是monit。
這是一個極其輕便精簡（單個執行檔案），而且久經戰場的後臺程式執行在成千上萬臺機器上面——為小的起步但是是限制到監測單個系統。這是它最大的缺點。
使用monit過程中發現的問題之一就是一組測試執行有限和拓展性的缺乏。雖然可配置，但是我們還是不得不通過寫指令碼來拓展它的功能，或者通過微弱的介面來使特殊目的程式得到控制。
更加重要的是，我們發現，連線幾個monit例項到一個高可用系統和彈性網路是非常難的，而且系統和網路還要代理收集自己分享的資訊，然後協同工作來另這些資訊保持更新。

冒煙型別測試

“冒煙測試”這個術語的定義：
“一系列初步的測試來揭示一些簡單的故障的嚴重性，以此來拒絕預期中軟體的釋出。它通常包含一個子集的測試，測試覆蓋了大多數重要的作用來確定重要作用在按照預期執行。冒煙測試最頻繁的特點就是它執行的很快，通常是秒級的。”
以我們已有的Kubernetes知識，我們堅信我們可以使用冒煙測試用以下特點來建立一個監視系統：

• 輕量級定期測試
• 高可用性和彈性網路分割槽
• 零故障操作環境
• 時間序列作為健康資料的歷史

不管故障容易發生的抽象層次，就算是應用程式故障，或者是低層次網路錯誤，這個系統都能夠追蹤他們以查到實際的原因。

Serf啟動的監測Agents

我們的高層次解決方案是一系列程式Agent，一個叢集中的一個節點駐留在另一個節點上。他們互相之間通過一個Serf提供的gossip協議來交流：

Kubernetes關鍵元件的Agents監控狀態——etcd，scheduler，API伺服器和另外一些東西，還有一些執行冒煙程式——建立可以互相交流的輕量級容器。

Agent定期同步資料，這樣每個節點都是隨時更新關於叢集作為一個整體的資訊。由於Serf提供的一致性保證比較弱，導致更新資訊也不是很嚴格。定期測試結果儲存到後端——這可以很簡單，就如同一個SQLite資料庫或者InfluxDB等一系列實時資料庫。

擁有一個對等系統對偵測故障和監測資訊十分有幫助，即使系統中的關鍵部分部分宕機也沒有關係。在下面的例子中，主要節點以及大部分的節點都已經宕機，這就導致etcd也出了故障。然而，我們仍然可以得到關於叢集連線到以下任意一個節點的診斷資訊：

這裡是在部分損壞的系統截圖：

限制

由於它的簡易，目前的模型就有了一定的限制。如果是為更小一些的叢集（比如8個節點）就可以執行，然而，在一個再大一點的叢集，你就不想每個節點都可以互相交流了。這個解決方式就是我們計劃採取的方案是建立一個特殊的聚合器，從Skype的超級節點那裡或者是從Consul的“anti－entropy catelogs上面借鑑一些想法。

結語

監測Kubernetes叢集的狀態不是直接使用傳統監測工具就可以了的。手動故障排除有一定的複雜性，在叢集裡有一個自動反饋迴圈的話，就可以消除很大部分的複雜性。Satellite專案已經證明當操作叢集的時候對我們是有用的，所以我們決定對它進行開源，希望它可以成為一個幫助提升kubernetes發現錯誤系統。