本文講的是Kubernetes排錯：用容器的元數(shù)據(jù)提供新思路【編者的話】本文介紹了Kubernetes的元數(shù)據(jù)以及如何用于工作的，用好元數(shù)據(jù)有助于監(jiān)控和排查系統(tǒng)故障，并且只有在需要的時候才去深入到主機和容器中，最后建議大家在生成環(huán)境中使用元數(shù)據(jù)。

在這篇文章中，讓我們討論一下Kubernetes中的元數(shù)據(jù)（Metadata），以及如何利用它來監(jiān)控系統(tǒng)的性能。

元數(shù)據(jù)（Metadata）?是一個較為高大上的詞。它的含義是“用來描述其他數(shù)據(jù)的數(shù)據(jù)”。盡管這個解釋好像并沒有解釋到位，但實際上，元數(shù)據(jù)對容器環(huán)境來說特別的有用。當你面對一個復雜系統(tǒng)的時候，假如你能獲取到它的元數(shù)據(jù)的話，并對加以歸類并整理，能有助于直達問題核心、更快地解決問題。

在Kubernetes環(huán)境中，元數(shù)據(jù)?不僅是一個在眾多服務、機器、可用區(qū)和（在未來）云平臺之間組織容器編排方式的重要工具，它同時也是一個讓我們理解這些編排的關鍵工具。元數(shù)據(jù)可以被運行在Kubernetes系統(tǒng)之上的其他的服務使用，從而幫助你管理應用。

下面我們將舉一些例子，但在這之前，先讓我們簡單介紹一下Kubernetes的元數(shù)據(jù)。

元數(shù)據(jù)簡介

Kubernetes中有很多元數(shù)據(jù)，它們以 “標簽”（Label）或者 “注解”（Annotation）的形式存在。按照設計，“標簽”是具有標識性的（identifying）元數(shù)據(jù)，而“注解”是那些沒有標識性的（non-identifying）元數(shù)據(jù)。他們都是很簡單的鍵值對，看起來就像這樣：
“l(fā)abels”:?{ “key1”?:?“value1”, “key2”?:?“value2” }??
“標簽”不具有唯一性：你可能會看到你環(huán)境中的很多對象都有同樣的“標簽”，同時你也可能看到一個對象有很多的“標簽”。

我們在什么時候可能會用到“標簽”呢？這里是一些例子。注意：一旦你開始使用“標簽”，你會發(fā)現(xiàn)有很多用到這個功能的地方！

• 環(huán)境（Environment）：Dev，Prod，Test，UAT
• 客戶（Customer）：Cust A，Cust B, Cust C
• 層（Tier）：Frontend, Backend
• 應用（App）：Cache, Web, Database, Auth

除了自定義的“標簽”，Kubernetes自己也會為系統(tǒng)添加包含有用原數(shù)據(jù)的“標簽”。默認的標簽提供了Kubernetes層級關系中關鍵的辨識信息：Pod、“服務（Service）”、“復制控制器（Replication Controller）”和“命名空間（Namespace）”。

讓元數(shù)據(jù)一展身手

一旦你花了一點時間在Kubernetes之后，你會發(fā)現(xiàn)“標簽”有一個特別強大的應用，正是這一點讓它們必不可少：

Kubernetes的“標簽”能讓你在一個關于你主機和容器的“物理”視圖，和一個關于你應用和微服務的“邏輯”視圖之間輕松地切換。

從本質(zhì)上，像Kubernetes這種平臺的設計宗旨是編排，以讓底層的物理資源得到最優(yōu)的利用。這是一種強大的有效利用私有或者公有云資源的方式，并且有時候你需要將這些物理資源進行可視化。然而在現(xiàn)實中，絕大多數(shù)時候你首先關心，也最關心的是服務的性能。

但是在Kubernetes的世界中，要獲得這種高利用率意味著一個服務的容器可能會分散遍布各處。那么你該如何來衡量一個“服務”的性能呢？這里就是元數(shù)據(jù)可以一展身手的地方了。使用Kubernetes元數(shù)據(jù)，你能深入認識你服務的性能，不管底層的容器的物理位置處于何處。

有圖有真相

讓我們看一個能讓你對這點有具體認識的例子：應用程序的監(jiān)控。我這里在GKE部署了一個小型的環(huán)境，包含3個節(jié)點。我們這里將使用Sysdig Cloud來對這個環(huán)境進行可視化。下面是節(jié)點的列表 - 你可以看到每一個主機名前以“gke”開頭。我們能看到一些基本的性能參數(shù)：如CPU、內(nèi)存和網(wǎng)絡等。

每一個主機都運行著一些容器。點擊主機，我們會看到相關的容器：

僅僅的看這個單個主機上的容器列表，我看不出這些對象的職責結(jié)構(gòu)。我們只能大概地猜測，一些容器運行著Kubernetes的服務（比如：kube-ui），其他的容器與應用相關（如：javaapp.x）。

現(xiàn)在，讓我們使用Kubernetes提供的元數(shù)據(jù)來從“以應用為中心”的視角觀察這個系統(tǒng)。讓我們基于“標簽”對組件創(chuàng)建出一個層級結(jié)構(gòu)，順序如下：

“命名空間（Namespace）” -> “復制控制器（Replication Controller）” -> Pod -> “容器（Container）”

這將容器基于以上的“標簽”在不同的層次進行了聚合。在下面的app UI中，這種聚合和層級關系以灰色的分組導航條表示。你可以看到，我們有一個名為prod的“命名空間”，其下有一組“服務”（“復制控制器”）。每一個“復制控制器”包含多個“Pod”，而一個“Pod”又由多個“容器”組成。

除了通過“標簽”來組織容器之外，這個視圖同時對相關容器的指標進行了聚合，可以讓我們方便查看單個“命名空間”或者“復制控制器”的性能詳情。

換句話說：有了這種基于元數(shù)據(jù)的聚合視圖，你可以（在較高的層次）對服務進行監(jiān)控或者排錯，只有在必要的時候才深入到主機或者容器層。

讓我們用這個環(huán)境來干另外一件事情 - 使用元數(shù)據(jù)來可視化呈現(xiàn)這些“服務”和它們之間的交互拓撲。這里你可以看到我們的容器是以“服務”來組織的，但同時其像映射一樣的視圖能讓你看清這些“服務”彼此是如何關聯(lián)的。

這些方框代表了由“容器”聚合而成的“服務”（右上方的數(shù)字顯示了包含的容器的數(shù)量），這些箭頭代表了“服務”之間的交互和它們的延遲。

這種視圖提供另外一種邏輯的非物理的視圖，可以讓我們展示這些組件是如何一起工作的。有了它我可以清楚的知道“服務”的性能，交互關系，和底層資源消耗（如這個例子中的CPU）。

元數(shù)據(jù)：愛之，不釋手

雖然這是一篇元數(shù)據(jù)很簡短的介紹，但是我希望這能啟發(fā)你花一點時間思考它與你自己系統(tǒng)的關系，并且思考可以如何利用它。這里我們用它做了一個非常簡單的例子 - 主要是應用和服務 - 但是你可以想象一下收集跨應用、跨環(huán)境、跨軟件組件和跨云提供商的元數(shù)據(jù)，在Kubernetes有效地進行調(diào)度資源的時候，你可以快速地評估你的基礎設施中任何部分（slice）的性能差異。

今天就講這些資源的可視化，在下面的一篇文章中，我們將會談到基于元數(shù)據(jù)的的自適應報警（adaptive alerting）。

原文鏈接：Troubleshooting Kubernetes: How container metadata changes your point of view（翻譯：鐘最龍）

原文發(fā)布時間為：2016-08-30

本文作者：鐘最龍

本文來自云棲社區(qū)合作伙伴Dockerone.io，了解相關信息可以關注Dockerone.io。

原文標題：Kubernetes排錯：用容器的元數(shù)據(jù)提供新思路

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結(jié)

以上是生活随笔為你收集整理的Kubernetes排错：用容器的元数据提供新思路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。