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

在這篇文章中，讓我們討論一下Kubernetes中的元數據（Metadata），以及如何利用它來監控系統的性能。

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

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

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

元數據簡介

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

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

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

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

讓元數據一展身手

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

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

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

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

有圖有真相

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

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

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

現在，讓我們使用Kubernetes提供的元數據來從“以應用為中心”的視角觀察這個系統。讓我們基于“標簽”對組件創建出一個層級結構，順序如下：

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

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

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

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

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

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

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

元數據：愛之，不釋手

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

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

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

原文發布時間為：2016-08-30

本文作者：鐘最龍

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。