本文讲的是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）。

原文链接：（翻译：钟最龙）

原文发布时间为：2016-08-30

本文作者：钟最龙

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：Kubernetes排错：用容器的元数据提供新思路