在这篇文章中,让我们讨论一下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,翻译:钟最龙)

最新文章

  1. STM32之通用定时器
  2. cordova添加plugin
  3. php笔试题(3)--转载
  4. 一个短小的JS函数,用来得到仅仅包含不重复元素的数组
  5. NSDate & NSDateFormatter
  6. 《ASP.NET 本质论》HttpApplication的处理管道 ,HttpMoudle,HttpHandler
  7. android开发之——混淆编译
  8. Exploring TCP state machine by graphs
  9. Python丨Python 性能分析大全
  10. pip换源安装
  11. 微信小程序实际开发中学习
  12. Voltage Level-Shifter Output Waveform
  13. 初试GH-OST(转)
  14. Java 第二次实验20145104 张家明
  15. happybase(TSocket read 0 bytes)
  16. 全球数据库-->基金/管理产品-->基金分析/新闻/报告
  17. 记开发个人图书收藏清单小程序开发(九)Web开发——新增图书信息
  18. 【redis的搭建】centos6.4下搭建redis
  19. 通过EditText的setTransformationMethod()隐藏或显示密码
  20. Day16 Django深入讲解

热门文章

  1. java并发系列(二)-----线程之间的协作(wait、notify、join、CountDownLatch、CyclicBarrier)
  2. P1460 健康的荷斯坦奶牛 Healthy Holsteins
  3. 表格存储TableStore2.0重磅发布,提供更强大数据管理能力
  4. Laravel 精选资源大全
  5. LintCode_173 链表插入排序
  6. 从0开始学习 GitHub 系列之「05.Git 进阶」
  7. ASP.NET自定义控件组件开发 第一章 第三篇 第一章的完结篇
  8. spring boot 异常处理(转)
  9. golang之下载安装配置
  10. 海胜专访--MaxCompute 与大数据查询引擎的技术和故事