使用Sysdig监控Kubernetes

今天,我们分享了Sysdig的Chris Crane的来宾帖子,介绍了他们如何将监控集成到Kubernetes中。 

Kubernetes 提供了一个完整的环境来编写可扩展的,基于服务的应用程序。它负责诸如容器分组,发现,负载平衡和修复之类的事情,因此您不必担心它们。设计优雅,可扩展,API令人愉悦。

与任何新的基础架构平台一样,如果您想在生产环境中运行Kubernetes,您将希望能够对其进行监视和故障排除。我们是Sysdig的Kubernetes的忠实拥护者,而且,恩:我们在这里为您提供帮助。

Sysdig提供了整个Sysdig产品系列中Kubernetes的本机可见性。包括了 系统摘要 ,我们的开源,CLI系统探索工具以及 Sysdig云 ,这是第一个也是唯一一个从头开始设计以支持容器和微服务的监视平台。

Sysdig产品在较高级别上了解整个Kubernetes集群层次结构,包括 命名空间,服务,复制控制器 标签 。因此,现在可以在Kubernetes基础架构的上下文中使用收集的所有丰富系统和应用程序数据。这对您意味着什么?简而言之,我们相信Sysdig可以成为您使Kubernetes环境明显更易于监视和故障排除的首选工具!

在本文中,我将快速预览开源sysdig和Sysdig Cloud中的Kubernetes可见性,并展示一些有趣的用例。让我们从开源解决方案开始。

使用csysdig探索Kubernetes集群 

充分利用sysdig的Kubernetes支持的最简单方法是启动csysdig,即sysdig ncurses UI:

 > csysdig -k http://127.0.0.1:8080
*注意:使用-k命令指定Kubernetes API服务器的地址,sysdig将利用标准API和watch API轮询所有相关信息。

既然csysdig正在运行,请按F2键打开“视图”面板,您会注意到其中存在许多新视图。的 k8s命名空间 视图可用于查看名称空间列表,并观察它们在本机上正在使用的CPU,内存,网络和磁盘资源的数量:

同样,您可以选择 k8s服务 查看按服务细分的相同信息:

要么 k8s控制器 查看复制控制器:

要么 k8s豆荚 查看在此计算机上运行的Pod列表及其使用的资源:

基于向下钻取的导航 

csysdig的一项很酷的功能是向下钻取的能力:只需选择一个元素,然后单击enter和-繁荣-现在您就可以在其中查看它了。向下钻取还了解Kubernetes层次结构,这意味着我可以从服务开始,获取其Pod列表,查看哪些容器在其中一个Pod中运行,然后进入其中一个容器以探索文件,网络连接,进程甚至线程。看看下面的视频。

行动!  

关于csysdig的另一件事。如 最近宣布,csysdig还提供了“控制面板”功能,使得可以使用热键根据当前选定的元素执行命令行。因此,我们确保使用大量有用的热键来丰富Kubernetes的视图。例如,您可以按“ x”删除名称空间或服务,也可以按“ d”描述它们。

My favorite hotkeys, however, are "f," to follow the logs that a pod is generating, 和 "b," which leverages kubectl exec to give you a shell inside a pod. Being brought into a bash prompt for the pod you’re observing is really useful 和 , frankly, a bit magic. :-)

因此,这是sysdig中Kubernetes的快速预览。但是请注意,所有这些功能仅适用于一台计算机。如果要监视分布式Kubernetes集群会怎样?输入Sysdig Cloud。

使用Sysdig Cloud监控Kubernetes 

让我们首先快速回顾一下Kubernetes的架构。从物理/基础结构的角度来看,Kubernetes集群由一组 奴才 机器监督 机。管理员的任务包括跨多个小兵编排容器,跟踪状态并通过REST API和UI公开集群控制。

另一方面,从逻辑/应用程序的角度来看,Kubernetes集群以如下图所示的分层方式排列:

  • 所有容器都在内部运行 豆荚 。容器可以容纳一个容器,也可以容纳多个协作容器。在后一种情况下,可以确保将容器中的容器放置在同一台机器上,并且可以共享资源。 
  • 豆荚通常坐在后面 服务 ,它负责平衡流量,也将Pod集作为单个可发现的IP地址/端口公开。 
  • 服务水平扩展 复制控制器 (以下简称“ RC”),可根据需要为每种服务创建/销毁广告连播。 
  • 命名空间 是可以包括一项或多项服务的虚拟集群。  

因此,需要明确的是,多个服务甚至多个名称空间都可以分散在同一物理基础结构中。

与数百名Kubernetes用户交谈之后,似乎典型的集群管理员通常对从物理角度看事物感兴趣,而服务/应用程序开发人员往往对从逻辑观点看事物更感兴趣。 

考虑到这两个用例,Sysdig Cloud对Kubernetes的支持如下: 

  • 通过自动连接到Kubernetes的集群API服务器并查询API(常规API和Watch API),Sysdig Cloud能够推断微服务应用程序的物理和逻辑结构。 
  • 此外,我们透明地提取重要的元数据,例如标签。 
  • 该信息与我们正在申请专利的ContainerVision技术相结合,该技术使检查容器内部运行的应用程序成为可能,而无需对容器或应用程序进行任何检测。  基于此,Sysdig Cloud可以从 以基础架构为中心以应用为中心 观点看法。两全其美!让我们看看它的实际外观。

One of the core features of Sysdig云 is groups, which allow you to define the hierarchy of metadata for your applications 和 infrastructure. By applying the proper groups, you can explore your containers based on their physical hierarchy (for example, physical cluster > 奴才 machine > pod > container) 要么 based on their logical microservice hierarchy (for example, namespace > replication controller > pod > container – as you can see in this example). 

如果您对基础物理资源的利用感兴趣-例如,识别嘈杂的邻居-那么物理层次结构非常有用。但是,如果您希望探索应用程序和微服务的性能,那么逻辑层次结构通常是最好的起点。 

例如:在这里您可以看到我们WordPress服务的整体性能: 

请记住,实现此服务的Pod分散在多台计算机上,但是我们仍然可以总计该服务的请求计数,响应时间和URL统计信息。而且请不要忘记:这不需要对wordpress,apache或底层容器进行任何配置或配置! 

从这个角度来看,我现在可以轻松地为这些服务级别指标创建警报,并且可以深入挖掘任何单独的容器以进行深入检查-直到过程级别-随时随地,包括及时返回! 

可视化您的Kubernetes服务 

我们还在物理和逻辑级别上将kubernetes意识纳入了Sysdig Cloud著名的拓扑视图中。 

下面的两张图片显示了完全相同的基础架构和服务。但是第一个描述了物理层次结构,有一个主节点和三个小仆节点。第二个将容器分为命名空间,服务和Pod,同时抽象化容器的物理位置。 

希望第二个(面向服务的)视图更加自然和直观,这是不言而喻的。应用程序的结构和各种依赖关系立即清晰可见。尽管事实上,这些微服务在我们的机器集群中混合在一起,但各种微服务之间的交互变得很明显! 

结论  

我非常有信心,我们在这里提供的内容代表着对Kubernetes环境的可见性的巨大飞跃,并且不会让您失望。我也希望它可以成为有用的工具,使您更加安心地在生产中使用Kubernetes。谢谢,开开心心地挖! 

Sysdig产品副总裁Chris Crane 

您可以在以下位置找到开源sysdig 的github 系统摘要 .org ,您可以在以下位置注册Sysdig Cloud的免费试用版 系统摘要 .com

要观看现场演示并结识项目背后的一些人,请在本周四加入我们,参加 Kubernetes 和Sysdig Meetup在旧金山.