Sloop - Kubernetes 历史可视化

Sloop 监控 Kubernetes，记录事件和资源状态变更的历史，并提供可视化功能以辅助调试过往事件。

主要特性：

允许您查找并检查不再存在的资源（例如：发现上一次部署的 Pod 使用的是哪个主机）。
提供时间线显示，展示 Deployment、ReplicaSet 和 StatefulSet 更新中相关资源的滚动过程。
帮助调试瞬时和间歇性错误。
允许您查看 Kubernetes 应用随时间推移的变化。
是一个自包含的服务，不依赖于分布式存储。

屏幕截图

Screenshot1

架构概览

Architecture

安装

Sloop 可以通过以下任意一种方式进行安装：

Helm Chart

用户现在可以通过使用 helm chart 来安装 sloop，具体说明请参阅 helm readme

预编译二进制文件

TODO: 参见 Releases。

从源码构建

从源码构建 Sloop 需要一个可用的 Go 环境，版本需为 go.mod 文件中定义的版本或更高版本。

参见：https://golang.org/doc/install

克隆 sloop 仓库并使用 make 进行构建：

mkdir -p $GOPATH/src/github.com/salesforce
cd $GOPATH/src/github.com/salesforce
git clone https://github.com/salesforce/sloop.git
cd sloop
make
$GOPATH/bin/sloop

完成后，您应拥有一个正在运行的 Sloop 版本，它从您的 kubeConfig 中访问当前上下文。只需将浏览器指向 http://localhost:8080/

其他 makefile 目标：

docker：构建 Docker 镜像。
cover：运行带有代码覆盖率的单元测试。
generate：更新用于类型化表类的 genny 模板。
protobuf：生成 protobuf 代码生成。

本地 Docker 运行

要从 Docker 运行，您需要主机挂载您的 kubeconfig：

make docker-snapshot
docker run --rm -it -p 8080:8080 -v ~/.kube/:/kube/ -e KUBECONFIG=/kube/config sloop

在此模式下，数据会被写入基于内存的卷，并在每次运行后丢弃。若要保留数据，你可以使用类似 -v /data/:/some_path_on_host/ 的方式挂载 /data。

更新 webfiles 文件夹

要反映对 webserver/webfiles 的任何更改，请在提交 pr 之前，在终端中进入 webserver 目录并运行以下命令：

go-bindata -pkg webserver -o bindata.go webfiles/

这将使用您对目录内任何 html、css 或 javascript 文件的更改来更新 bindata 文件夹。

本地 Docker 运行并连接到 EKS

这与上述内容非常相似，但抽象了使用 AWS 凭据运行 docker 以连接到 EKS 的过程

make docker
export AWS_ACCESS_KEY_ID=<access_key_id> AWS_SECRET_ACCESS_KEY=<secret_access_key> AWS_SESSION_TOKEN=<session_token>
./providers/aws/sloop_to_eks.sh <cluster name>

上述数据保留策略在此情况下仍然适用。

备份与恢复

这是一个高级功能。请谨慎使用。

要下载数据库的备份，请访问 http://localhost:8080/data/backup

要从备份中恢复，请启动 sloop，并将 -restore-database-file 标志设置为在上一步中下载的备份文件。在恢复时，您可能还希望设置 -disable-kube-watch=true 标志以停止新的写入操作，和/或设置 -context 标志以将数据库恢复到不同的上下文中。

内存消耗

Sloop 的内存使用量可以通过调整几个选项来管理：

badger-use-lsm-only-options 如果此标志设置为 true，值将与 LSM 树共存，值日志主要仅作为预写日志使用。内存受限环境下的推荐值：false
badger-keep-l0-in-memory 当此标志设置为 true 时，Level 0 表将保留在内存中。这可以提高写入和压缩的性能。内存受限环境下的推荐值：false
badger-sync-writes 当 SyncWrites 为 true 时，所有写入都会同步到磁盘。将其设置为 false 可以获得更好的性能，但在崩溃时可能会导致数据丢失。内存受限环境下的推荐值：false
badger-vlog-fileIO-mapping TableLoadingMode 指示应使用哪种文件加载模式用于 LSM 树数据文件。设置为 true 将不会在内存映射中加载值。内存受限环境下的推荐值：true

除了这些标志之外，还可以调整其他一些值以适应内存限制。以下是一些配置示例。

内存消耗最大限制：1GB

               // 0.5<<20 (524288 bytes = 0.5 Mb)
               "badger-max-table-size=524288",
               "badger-number-of-compactors=1",
               "badger-number-of-level-zero-tables=1",
               "badger-number-of-zero-tables-stall=2",

内存消耗最大限制：2GB

               // 16<<20 (16777216 bytes = 16 Mb)
               "badger-max-table-size=16777216",
               "badger-number-of-compactors=1",
               "badger-number-of-level-zero-tables=1",
               "badger-number-of-zero-tables-stall=2",

内存消耗最大限制：5GB

               // 32<<20 (33554432 bytes = 32 Mb)
               "badger-max-table-size=33554432",
               "badger-number-of-compactors=1",
               "badger-number-of-level-zero-tables=2",
               "badger-number-of-zero-tables-stall=3",

除了上述设置外，max-disk-mb 和 max-look-back 可以根据输入数据和内存约束进行调整。

Prometheus

Sloop 使用 Prometheus 库来输出指标，这对性能调试非常有帮助。

在仓库的根目录下有一个 Prometheus 配置文件 prometheus.yml.

在 OSX 上，你可以使用 brew install prometheus 安装 Prometheus。然后从 sloop 目录运行 prometheus 来启动它

在浏览器中打开 http://localhost:9090。

一个有用的查询示例是 rate(kubewatch_event_count[5m])

事件过滤

可以通过在配置文件中添加 exclusionRules 来将事件从 Sloop 中排除：

{
  "defaultNamespace": "default",
  "defaultKind": "Pod",
  "defaultLookback": "1h",
  [...]
  "exclusionRules": {
    "_all": [
      {"==": [ { "var": "metadata.namespace" }, "kube-system" ]}
    ],
    "Pod": [
      {"==": [ { "var": "metadata.name" }, "sloop-0" ]}
    ],
    "Job": [
      {"in": [ { "var": "metadata.name" }, [ "cron1", "cron3" ] ]}
    ]
  }
}`

添加规则有助于减少 Sloop 消耗的资源，并移除 UI 中那些不感兴趣的事件所产生的无用噪音。

将规则限制到特定类型

特殊键 _all 下的规则针对任意类型对象的事件进行评估
其他任何键下的规则仅针对类型与该键匹配的对象进行评估，例如 Pod 仅适用于 pods，Job 仅适用于 jobs 等。

规则格式和支持的操作

规则应遵循 JsonLogic 格式，并针对与事件相关的 Kubernetes API 对象的 json 表示进行评估（见下文）。

可用的操作符，如上文所示的 == 和 in，文档见此处。

可供规则逻辑使用的数据

Kubernetes API 关于对象的约定要求以下键存在于所有资源的 json 数据中，所有这些键都可以在规则中引用：

metadata
spec
status

metadata object 下一些常用且有用的字段是：

name
namespace
labels

类型特定数据

某些资源包含额外的类型特定字段，例如 PersistentVolumeClaimSpec 对象具有名为 selector 和 storageClassName 的字段。

每个对象的类型特定字段及其在对象 JSON 表示中对应的键，记录在核心 API 中，例如 PersistentVolumeClaimSpec 对象的文档见此处。

贡献

请参阅 CONTRIBUTING.md

许可证

BSD 3-Clause