Kubernetes排错:用容器的元数据提供新思路

标签: kubernetes云计算
10594人阅读 评论(0) 收藏 举报
分类:
在这篇文章中,让我们讨论一下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-Metadata-Blog-Image-1.png


每一个主机都运行着一些容器。点击主机,我们会看到相关的容器:

Kubernetes-Metadata-Blog-2.png


仅仅的看这个单个主机上的容器列表,我看不出这些对象的职责结构。我们只能大概地猜测,一些容器运行着Kubernetes的服务(比如:kube-ui),其他的容器与应用相关(如:javaapp.x)。

现在,让我们使用Kubernetes提供的元数据来从“以应用为中心”的视角观察这个系统。让我们基于“标签”对组件创建出一个层级结构,顺序如下:

“命名空间(Namespace)” -> “复制控制器(Replication Controller)” -> Pod -> “容器(Container)”

这将容器基于以上的“标签”在不同的层次进行了聚合。在下面的app UI中,这种聚合和层级关系以灰色的分组导航条表示。你可以看到,我们有一个名为prod的“命名空间”,其下有一组“服务”(“复制控制器”)。每一个“复制控制器”包含多个“Pod”,而一个“Pod”又由多个“容器”组成。

Kubernetes-Metadata-Blog-3.png


除了通过“标签”来组织容器之外,这个视图同时对相关容器的指标进行了聚合,可以让我们方便查看单个“命名空间”或者“复制控制器”的性能详情。

换句话说:有了这种基于元数据的聚合视图,你可以(在较高的层次)对服务进行监控或者排错,只有在必要的时候才深入到主机或者容器层。

让我们用这个环境来干另外一件事情 - 使用元数据来可视化呈现这些“服务”和它们之间的交互拓扑。这里你可以看到我们的容器是以“服务”来组织的,但同时其像映射一样的视图能让你看清这些“服务”彼此是如何关联的。

Kubernetes-Metadata-Blog-4.png


这些方框代表了由“容器”聚合而成的“服务”(右上方的数字显示了包含的容器的数量),这些箭头代表了“服务”之间的交互和它们的延迟。

这种视图提供另外一种逻辑的非物理的视图,可以让我们展示这些组件是如何一起工作的。有了它我可以清楚的知道“服务”的性能,交互关系,和底层资源消耗(如这个例子中的CPU)。

元数据:爱之,不释手

虽然这是一篇元数据很简短的介绍,但是我希望这能启发你花一点时间思考它与你自己系统的关系,并且思考可以如何利用它。这里我们用它做了一个非常简单的例子 - 主要是应用和服务 - 但是你可以想象一下收集跨应用、跨环境、跨软件组件和跨云提供商的元数据,在Kubernetes有效地进行调度资源的时候,你可以快速地评估你的基础设施中任何部分(slice)的性能差异。

今天就讲这些资源的可视化,在下面的一篇文章中,我们将会谈到基于元数据的的自适应报警(adaptive alerting

(原文链接:Troubleshooting Kubernetes: How container metadata changes your point of view,翻译:钟最龙)
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1804951次
    • 积分:12970
    • 等级:
    • 排名:第1114名
    • 原创:78篇
    • 转载:53篇
    • 译文:1篇
    • 评论:54条
    文章分类
    最新评论