使用 Sysdig 监控 Kubernetes

今天我们分享一篇来自 Sysdig 的 Chris Crane 的客座文章，内容关于他们与 Kubernetes 的监控集成。

Kubernetes 提供了一个完整的环境来编写可扩展的、基于服务的应用程序。它负责容器分组、发现、负载均衡和修复等事务，因此您无需担心这些问题。其设计优雅、可扩展，API 使用起来也令人愉悦。

与任何新的基础设施平台一样，如果您想在生产环境中运行 Kubernetes，您会希望能够对其进行监控和故障排除。Sysdig 的我们是 Kubernetes 的忠实拥趸，嗯：我们来助您一臂之力。

Sysdig 在其全线产品中提供对 Kubernetes 的原生可见性。这包括我们的开源 CLI 系统探索工具 sysdig，以及第一个也是唯一一个从头开始设计以支持容器和微服务的监控平台 Sysdig Cloud。

从宏观角度来看，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 Pods**以查看在此机器上运行的 Pod 列表及其使用的资源

基于钻取的导航

csysdig 中的一个很酷的功能是钻取能力：只需选择一个元素，点击回车键——轰——现在您正在查看其内部。钻取还了解 Kubernetes 层次结构，这意味着我可以从一个服务开始，获取其 Pod 列表，查看在一个 Pod 中运行的容器，然后进入其中一个容器以探索文件、网络连接、进程甚至线程。请观看下面的视频。

操作！

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

然而，我最喜欢的热键是“f”，用于跟踪 Pod 生成的日志，以及“b”，它利用 `kubectl exec` 让您在 Pod 内部获得一个 shell。被带入您正在观察的 Pod 的 bash 提示符真的非常有用，坦率地说，有点神奇。:-)

这是对 sysdig 中 Kubernetes 的快速预览。请注意，所有这些功能仅适用于单台机器。如果您想监控一个分布式 Kubernetes 集群，会发生什么？Sysdig Cloud 应运而生。

使用 Sysdig Cloud 监控 Kubernetes

让我们快速回顾一下 Kubernetes 的架构。从物理/基础设施的角度来看，Kubernetes 集群由一组由**主节点**机器监督的**从节点**机器组成。主节点的任务包括在从节点之间编排容器、跟踪状态以及通过 REST API 和 UI 公开集群控制。

另一方面，从逻辑/应用程序的角度来看，Kubernetes 集群以这张图片所示的层次结构排列

• 所有容器都在**Pods**中运行。一个 Pod 可以托管一个单独的容器，也可以托管多个协作容器；在后一种情况下，Pod 中的容器保证位于同一台机器上，并且可以共享资源。
• Pod 通常位于**服务**之后，服务负责均衡流量，并以单个可发现的 IP 地址/端口公开一组 Pod。
• 服务通过**复制控制器**（“RC”）横向扩展，RC 会根据需要为每个服务创建/销毁 Pod。
• **命名空间**是虚拟集群，可以包含一个或多个服务。

因此，需要明确的是，多个服务甚至多个命名空间可以分散在同一物理基础设施中。

与数百名 Kubernetes 用户交流后，似乎典型的集群管理员通常对从物理角度查看事物感兴趣，而服务/应用程序开发人员则倾向于对从逻辑角度查看事物更感兴趣。

考虑到这两种用例，Sysdig Cloud 对 Kubernetes 的支持方式如下：

• 通过自动连接到 Kubernetes 的集群 API 服务器并查询 API（包括常规 API 和 watch API），Sysdig Cloud 能够推断出您的微服务应用程序的物理和逻辑结构。
• 此外，我们透明地提取重要的元数据，例如标签。
• 此信息与我们正在申请专利的 ContainerVision 技术相结合，该技术无需对容器或应用程序进行任何检测即可检查容器中运行的应用程序。基于此，Sysdig Cloud 可以从**以基础设施为中心**和**以应用程序为中心**的角度提供丰富的可见性和上下文。两全其美！让我们看看这实际上是什么样子。

Sysdig Cloud 的核心功能之一是组，它允许您为应用程序和基础设施定义元数据层次结构。通过应用适当的组，您可以根据容器的物理层次结构（例如，物理集群 > 从属机器 > pod > 容器）或根据其逻辑微服务层次结构（例如，命名空间 > 复制控制器 > pod > 容器 – 如本例所示）来探索容器。

如果您对底层物理资源的利用率（例如，识别嘈杂的邻居）感兴趣，那么物理层次结构非常有用。但如果您正在探索应用程序和微服务的性能，那么逻辑层次结构通常是最佳起点。

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

请记住，实现此服务的 Pod 分散在多台机器上，但我们仍然可以汇总此服务的请求计数、响应时间和 URL 统计信息。而且别忘了：这不需要对 WordPress、Apache 或底层容器进行任何配置或检测！

从这个视图中，我现在可以轻松地为这些服务级别指标创建警报，并且我可以随时深入到任何单个容器进行深度检查——一直到进程级别——包括追溯到过去！

可视化您的 Kubernetes 服务

我们还在 Sysdig Cloud 著名的拓扑视图中包含了 Kubernetes 感知，包括物理和逻辑级别。

下面的两张图片显示了完全相同的基础设施和服务。但第一张描述了物理层次结构，有一个主节点和三个从属节点；而第二张则将容器分组到命名空间、服务和 Pod 中，同时抽象了容器的物理位置。

希望不言而喻，第二种（面向服务的）视图是多么自然和直观。应用程序的结构和各种依赖关系一目了然。尽管这些微服务在我们的机器集群中交织在一起，但各种微服务之间的交互变得显而易见！

结论 

我非常有信心，我们在这里提供的功能代表了 Kubernetes 环境可见性的一次巨大飞跃，它不会让您失望。我也希望它能成为一个有用的工具，让您在生产中使用 Kubernetes 时更加安心。谢谢，祝您挖得开心！

您可以在 github 和 sysdig.org 上找到开源 sysdig，您可以在 sysdig.com 注册 Sysdig Cloud 的免费试用版。

要观看现场演示并结识项目背后的一些工作人员，请于本周四加入我们在旧金山举行的 Kubernetes 和 Sysdig 见面会。

• ←上一篇
• 下一篇→