UDN-企业互联网技术人气社区

板块导航

浏览  : 1074
回复  : 0

[资源分享] Kubernetes排错:用容器的元数据提供新思路

[复制链接]
cat77的头像 楼主
发表于 2016-9-8 16:07:14 | 显示全部楼层 |阅读模式
  在这篇文章中,让我们讨论一下Kubernetes中的元数据(Metadata),以及如何利用它来监控系统的性能。

  元数据(Metadata) 是一个较为高大上的词。它的含义是“用来描述其他数据的数据”。尽管这个解释好像并没有解释到位,但实际上,元数据对容器环境来说特别的有用。当你面对一个复杂系统的时候,假如你能获取到它的元数据的话,并对加以归类并整理,能有助于直达问题核心、更快地解决问题。

  在Kubernetes环境中,元数据 不仅是一个在众多服务、机器、可用区和(在未来)云平台之间组织容器编排方式的重要工具,它同时也是一个让我们理解这些编排的关键工具。元数据可以被运行在Kubernetes系统之上的其他的服务使用,从而帮助你管理应用。

  下面我们将举一些例子,但在这之前,先让我们简单介绍一下Kubernetes的元数据。

  元数据简介

  Kubernetes中有很多元数据,它们以 “标签”(Label)或者 “注解”(Annotation)的形式存在。按照设计,“标签”是具有标识性的(identifying)元数据,而“注解”是那些没有标识性的(non-identifying)元数据。他们都是很简单的键值对,看起来就像这样:
  1. “labels”: {
  2. “key1” : “value1”,
  3. “key2” : “value2”
  4. }
复制代码

  “标签”不具有唯一性:你可能会看到你环境中的很多对象都有同样的“标签”,同时你也可能看到一个对象有很多的“标签”。

  我们在什么时候可能会用到“标签”呢?这里是一些例子。注意:一旦你开始使用“标签”,你会发现有很多用到这个功能的地方!

  环境(Environment):Dev、Prod,Test、UAT

  客户(Customer):Cust A、Cust B、Cust C

  层(Tier):Frontend、Backend

  应用(App):CacheWeb、Database、Auth

  除了自定义的“标签”,Kubernetes自己也会为系统添加包含有用原数据的“标签”。默认的标签提供了Kubernetes层级关系中关键的辨识信息:Pod、“服务(Service)”、“复制控制器(Replication Controller)”和“命名空间(Namespace)”。

  让元数据一展身手

  一旦你花了一点时间在Kubernetes之后,你会发现“标签”有一个特别强大的应用,正是这一点让它们必不可少:

  Kubernetes的“标签”能让你在一个关于你主机和容器的“物理”视图,和一个关于你应用和微服务的“逻辑”视图之间轻松地切换。

  从本质上,像Kubernetes这种平台的设计宗旨是编排,以让底层的物理资源得到最优的利用。这是一种强大的有效利用私有或者公有云资源的方式,并且有时候你需要将这些物理资源进行可视化。然而在现实中,绝大多数时候你首先关心,也最关心的是服务的性能。

  但是在Kubernetes的世界中,要获得这种高利用率意味着一个服务的容器可能会分散遍布各处。那么你该如何来衡量一个“服务”的性能呢?这里就是元数据可以一展身手的地方了。使用Kubernetes元数据,你能深入认识你服务的性能,不管底层的容器的物理位置处于何处。

  有图有真相

  让我们看一个能让你对这点有具体认识的例子:应用程序的监控。我这里在GKE部署了一个小型的环境,包含3个节点。我们这里将使用Sysdig Cloud来对这个环境进行可视化。下面是节点的列表 – 你可以看到每一个主机名前以“gke”开头。我们能看到一些基本的性能参数:如CPU、内存和网络等。
2.png

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

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

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

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

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

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

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

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

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

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

  元数据:爱之,不释手

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

原文作者:钟最龙 译  来源:Docker

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部