使用 Sysdig 监控 Kubernetes

今天，我们将分享 Sysdig 的 Chris Crane 关于他们将监控集成到 Kubernetes 中的客座文章。

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

与任何新的基础架构平台一样，如果您想在生产环境中运行 Kubernetes，您将需要能够对其进行监控和故障排除。我们是 Sysdig 的 Kubernetes 的忠实粉丝，而且，我们来这里是为了提供帮助。

Sysdig 在整个 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 Pod来查看此机器上运行的 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 集群由一组由主机器监管的minion机器组成。主机的任务包括跨 minion 编排容器，跟踪状态并通过 REST API 和 UI 公开集群控制。

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

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

所以要明确的是，多个服务甚至多个命名空间可以分散在同一个物理基础架构中。

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

考虑到这两个用例，Sysdig Cloud 对 Kubernetes 的支持如下所示：

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

Sysdig Cloud 的核心功能之一是组，它允许您定义应用程序和基础架构的元数据层次结构。通过应用适当的组，您可以根据其物理层次结构（例如，物理集群 > minion 机器 > pod > 容器）或根据其逻辑微服务层次结构（例如，命名空间 > 复制控制器 > pod > 容器 – 正如您在此示例中看到的）来浏览您的容器。

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

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

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

从此视图中，我现在可以轻松地为这些服务级指标创建警报，并且我可以深入到任何单个容器进行深度检查 - 直到进程级别 - 无论何时，包括及时回顾！

可视化您的 Kubernetes 服务

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

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

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

结论

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

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

要观看现场演示并与项目背后的一些人会面，请在本周四加入我们在旧金山的 Kubernetes 和 Sysdig 聚会。

• ←上一页
下一页→