容器元数据如何改变你的视角

当然，元数据是一个花哨的词。它实际上意味着“描述其他数据的数据”。虽然这个定义不太有用，但元数据本身在容器环境中却特别有用。当你有任何复杂的系统时，元数据的可用性可以帮助你对来自系统的各种数据进行排序和处理，从而让你更轻松地抓住问题的核心。

在 Kubernetes 环境中，元数据可能是一个关键工具，用于组织和理解容器如何在你的众多服务、机器、可用区或（将来）多个云中编排。这些元数据也可以被运行在你 Kubernetes 系统之上的其他服务使用，并可以帮助你管理你的应用程序。

我们将在下面看一些例子，但首先...

Kubernetes 元数据快速介绍：Kubernetes 元数据以标签（Labels）和注解（Annotations）的形式大量存在。标签旨在作为基础设施的标识性元数据，而注解旨在作为非标识性元数据。对于两者，它们都只是简单的键值对（key:value pairs），看起来像这样

"labels": {
  "key1" : "value1",
  "key2" : "value2"
}

标签并非设计成唯一的；你可以预期环境中任何数量的对象都携带相同的标签，你也可以预期一个对象可以有多个标签。

你可以使用哪些标签示例？这里仅举几例。警告：一旦开始，你可能会发现不止几种使用此功能的方法！

• 环境：Dev, Prod, Test, UAT 
• 客户：Cust A, Cust B, Cust C 
• 层级：Frontend, Backend 
• 应用：Cache, Web, Database, Auth 

除了你可能定义的自定义标签外，Kubernetes 还会自动为你系统应用带有有用元数据的标签。默认标签提供关于你整个 Kubernetes 层级结构的关键标识信息：Pods、Services、Replication Controllers 和 Namespaces。

发挥元数据的作用 

一旦你在 Kubernetes 上花一些时间，你就会看到标签有一个特别强大的应用，这使其变得至关重要

Kubernetes 标签让你可以轻松地在主机和容器的“物理”视图与应用程序和微服务的“逻辑”视图之间切换。

其核心在于，像 Kubernetes 这样的平台旨在优化利用底层物理资源。这是一种非常高效地使用私有或公有云资源的方式，有时你需要可视化这些物理资源。然而，在实际中，大多数时候你首先关心的是服务的性能。

但在 Kubernetes 世界中，实现高利用率意味着服务的容器可能分散在各处！那么你如何实际衡量服务的性能呢？这就是元数据发挥作用的地方。借助 Kubernetes 元数据，无论底层容器的物理位置在哪里，你都可以深入了解服务的性能。

给我描绘一幅图景 

让我们看一个简单的例子，以便更具体：监控你的应用程序。让我们以一个运行在 GKE 上的小型 3 节点部署为例。我们将使用 Sysdig Cloud 来可视化环境。这是节点的列表 — 注意名称前面加了“gke”。我们看到了 CPU、内存和网络等基本性能详情。

这些主机中的每一个都运行着许多容器。深入查看主机，我们看到与每个主机关联的容器

仅仅通过扫描单个主机上的容器列表，我看不出这些对象的职责有什么组织性。例如，其中一些容器运行 Kubernetes 服务（如 kube-ui），我们推测其他容器与正在运行的应用程序（如 javaapp.x）有关。

现在让我们使用 Kubernetes 提供的部分元数据，从应用程序的角度来查看系统。首先，让我们基于标签创建组件的层级结构，顺序如下

Kubernetes namespace -> replication controller -> pod -> container

这将根据上述标签在相应级别聚合容器。在下面的应用程序 UI 中，此聚合和层级结构显示在数据上方关于我们主机的灰色“分组”栏中。如你所见，我们有一个“prod”命名空间，其下方是一组服务（replication controllers）。这些 replication controllers 中的每一个都可以由多个 Pod 组成，而 Pod 又由容器组成。

除了通过标签组织容器外，此视图还聚合相关容器的指标，提供了命名空间或 replication controller 性能的单一视图。

换句话说，有了这种基于元数据的聚合视图，你现在可以先从监控和故障排除服务开始，只在需要时才深入到主机和容器。

让我们再做一件事来处理这个环境——让我们使用元数据创建服务及其通信拓扑的可视化表示。在这里，你看到我们的容器按服务组织，但还有一个地图状的视图，显示了这些服务如何相互关联。

方框代表服务，它们是容器的聚合（每个方框右上角的数字告诉你容器的数量），线条代表服务之间的通信及其延迟。

这种视图提供了另一种逻辑视图，而不是物理视图，展示了这些应用程序组件如何协同工作。从这里，我可以了解服务的性能、关系以及底层资源消耗（本例中是 CPU）。

元数据：爱它，用它

这只是对元数据的一个快速浏览，但我希望它能启发你花点时间思考它与你自身系统的关联以及如何利用它。这里我们构建了一个相当简单的例子——应用程序和服务——但想象一下跨你的应用程序、环境、软件组件和云提供商收集元数据。你可以高效地快速评估跨任何基础设施切片的性能差异，同时 Kubernetes 正在高效地调度资源使用。

今天就开始使用元数据来可视化这些资源吧，在后续的文章中，我们将讨论基于元数据的自适应告警（adaptive alerting）的力量。

• ←上一篇
• 下一篇→