使用 Sysdig 监控 Kubernetes

今天，我们分享 Sysdig 的 Chris Crane 撰写的客座文章，介绍了他们与 Kubernetes 的监控集成。 

Kubernetes 提供了一个完整的环境来编写可伸缩的基于服务的应用。它负责容器分组、服务发现、负载均衡和自愈等事项，因此您无需担心这些问题。其设计优雅、可伸缩，且 API 使用起来非常愉快。

与任何新的基础设施平台一样，如果您想在生产环境中运行 Kubernetes，您会需要能够监控和排除故障。我们在 Sysdig 非常喜欢 Kubernetes，而且，嗯：我们在这里提供帮助。

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

从较高的层面来看，Sysdig 产品了解整个 Kubernetes 集群的层级结构，包括 namespaces、services、replication controllers 和 labels。因此，收集到的所有丰富的系统和应用数据现在都可以在您的 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 Namespaces 视图可用于查看 namespace 列表，并观察每个 namespace 在这台机器上使用的 CPU、内存、网络和磁盘资源量

同样，您可以选择 k8s Services 按 service 查看相同信息

或选择 k8s Controllers 查看 replication controllers

或选择 k8s Pods 查看在此机器上运行的 pod 列表及其使用的资源

基于向下钻取的导航 

csysdig 中一个很酷的功能是向下钻取的能力：只需选择一个元素，按下回车键，然后——砰——你就能看到它内部的情况了。向下钻取也了解 Kubernetes 的层级结构，这意味着我可以从一个 service 开始，获取其 pod 列表，查看其中一个 pod 中运行的容器，然后进入其中一个容器以探索文件、网络连接、进程甚至线程。请观看下面的视频。

操作！ 

关于 csysdig 还有一件事。正如最近宣布的那样，csysdig 也提供“控制面板”功能，可以使用热键根据当前选择的元素执行命令行。因此，我们确保为 Kubernetes 视图添加了一系列有用的热键。例如，您可以按 "x" 删除一个 namespace 或 service，或者按 "d" 查看其详情 (describe)。

然而，我最喜欢的热键是 "f"，用于跟踪 pod 生成的日志，以及 "b"，它利用 kubectl exec 为您提供 pod 内部的 shell。能够进入您正在观察的 pod 的 bash 提示符非常有用，坦白地说，有点神奇。:-)

这就是 sysdig 中 Kubernetes 的快速预览。但请注意，所有这些功能仅适用于单台机器。如果您想监控分布式 Kubernetes 集群怎么办？那就请 Sysdig Cloud 登场。

使用 Sysdig Cloud 监控 Kubernetes 

让我们首先快速回顾一下 Kubernetes 的架构。从物理/基础设施的角度来看，Kubernetes 集群由一组 minion 机器组成，由一台 master 机器监督。master 的任务包括跨 minion 协调容器、跟踪状态以及通过 REST API 和 UI 公开集群控制。

另一方面，从逻辑/应用的角度来看，Kubernetes 集群按照图中所示的层级方式组织

• 所有容器都运行在 pod 内部。一个 pod 可以容纳单个容器，也可以容纳多个协同工作的容器；在后一种情况下，pod 中的容器保证位于同一台机器上并可以共享资源。 
• Pod 通常位于 service 后面，service 负责均衡流量，并将一组 pod 作为单个可发现的 IP 地址/端口暴露出来。 
• Service 通过 replication controller (“RC”) 进行水平扩缩，RC 根据需要为每个 service 创建/销毁 pod。 
• Namespace 是虚拟集群，可以包含一个或多个 service。 

因此，需要明确的是，多个 service 甚至多个 namespace 可以分布在同一个物理基础设施中。

在与数百名 Kubernetes 用户交流后发现，典型的集群管理员通常倾向于从物理角度看待问题，而 service/应用开发者则更倾向于从逻辑角度看待问题。 

考虑到这两种用例，Sysdig Cloud 对 Kubernetes 的支持是这样的： 

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

Sysdig Cloud 的核心功能之一是分组，它允许您为应用和基础设施定义元数据的层级结构。通过应用适当的分组，您可以根据容器的物理层级（例如，物理集群 > minion 机器 > pod > 容器）或逻辑微服务层级（例如，namespace > replication controller > pod > 容器——如本例所示）来探索您的容器。 

如果您对底层物理资源的利用率感兴趣——例如，识别“吵闹的邻居”——那么物理层级非常有用。但如果您希望探索应用和微服务的性能，那么逻辑层级通常是最好的起点。 

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

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

从这个视图，我现在可以轻松地为这些 service 级别的指标创建警报，并且可以向下钻取到任何单个容器进行深度检查——深入到进程级别  – 无论何时我想，包括回顾历史数据！ 

可视化您的 Kubernetes Service 

我们还在 Sysdig Cloud 著名的拓扑视图中包含了对 Kubernetes 的感知能力，支持物理和逻辑两个层面。 

下面两张图展示了完全相同的基础设施和 service。但第一张图描绘了物理层级，包括一个 master 节点和三个 minion 节点；而第二张图将容器分组到 namespace、service 和 pod 中，同时抽象了容器的物理位置。 

希望您能清楚地看到第二种（面向 service 的）视图是多么自然和直观。应用的结构和各种依赖关系一目了然。尽管这些微服务混杂在我们机器集群中，但它们之间的交互关系变得显而易见！ 

结论 

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

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

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

• ←上一篇
• 下一篇→