什么是传感器 传感器 (Sensor) 是将外部系统和事件与 StackStorm 集成的一种方式。传感器是 Python 代码片段，它们要么定期轮询某些外部系统，要么被动等待入站事件，通常示例用于每隔一段时间去轮询某一个对象，然后他们将 Trigger 注入 StackStorm，可以通过规则进行匹配，以执行潜在的 Action。 Sensor 是用 Python 编写的，并且必须遵循 StackStorm 定义的传感器接口要求。 什么是触发器 触发器 (Trigger) 是 StackStorm 中用于识别 StackStorm 的传入事件。Trigger 是类型（字符串）和可选参数（对象）的元组。编写 Rule 是为了与 Trigger 一起使用。Sensor 通常会记录 Trigger，但这并不是严格要求的。例如，有一个向 StackStorm 注册的通用Webhooks触发器，它不需要自定义传感器。 Stackstorm内置触发器 默认情况下，StackStorm 会发出一些内部 Trigger，您可以在规则中利用它们。这些触发器可以与非系统触发器区分开来，因为它们的前缀为 “st2”。 下面包含每个资源的可用 Trigger 列表： Action Reference Description Properties core.st2.generic.actiontrigger 封装 Action 执行完成的触发器 execution_id, status, start_timestamp, action_name, action_ref, runner_ref, parameters, result core.st2.generic.notifytrigger 通知触发器 execution_id, status, start_timestamp, end_timestamp, action_ref, runner_ref, channel, route, message, data core....

什么是包 包 “pack” 是扩展 StackStorm 的集成和自动化的部署单元。通常， pack 是沿着服务或产品边界组织的，例如 AWS、Docker、Sensu 等。 pack 包含Actions、Workflows、Rules、 Sensors和Aliases。StackStorm 内容始终是 pack 的一部分，因此了解如何创建 pack 并使用它们非常重要。 一些 pack 扩展了 StackStorm 以将其与外部系统集成，例如 AWS，GitHub，JIRA。我们称它们为“集成 pack ”。有些 pack 捕获自动化模式：这类 pack 含特定自动化过程的 workflow, Rule 和 Action - 例如st2 演示 pack 。我们称它们为“自动化 pack ”。这种命名主要是一种约定：StackStorm 本身对两者没有区别。 任何使用该 pack 所针对的服务的人都可以共享和重用集成 pack 。您可以在StackStorm Exchange找到许多这样的示例。自动化 pack 通常是特定于站点的，并且在特定团队或公司之外几乎没有用处；它们通常在内部共享。 总结：Packs是StackStorm中组织工作流、动作和传感器的方式。它们是一组相关的动作、工作流和传感器的集合，通常用于实现特定的自动化任务或集成。 包管理 StackStorm pack 通过命令进行管理：将为您提供有用的概述。st2 pack <...> / st2 pack -h 有些（例如core 基本 StackStorm action）是随 StackStorm 预装的。所有其他 pack 都需要您安装。幸运的是，这很容易！ list和get是获取有关本地 pack 信息的主要命令：...

StackStorm 使用 Rules 和 Workflows 来捕获操作模式并进行自动化。rule将 Triggers 映射到 Actions（或 Workflow），应用匹配条件( Criteria)，并将 Triggers payloads 映射到 Actions 的 Input。 注意 rule不按预期工作吗？请查看rule故障排除文档。其中介绍了rule测试、检查执行、记录和故障排除等内容。 Rule 的配置结构 stackstorm 中的 Rule 是以 YAML 格式来定义。以下是 Rule 定义结构以及 “必需”和 “可选” rule 元素的列表： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --- name: "rule_name" # required pack: "examples" # optional description: "Rule description." # optional enabled: true # required trigger: # required type: "trigger_type_ref" criteria: # optional trigger....

在我们基于 Kubernetes 编写云原生 GoLang 代码时，通常在本地调试时，使用 kubeconfig 文件，以构建基于 clientSet 的客户端。而在将代码作为容器部署到集群时，则会使用集群 (in-cluster) 内的配置。 clientcmd 模块用于通过传递本地 kubeconfig 文件构建 clientSet。因此，在容器内使用相同模块构建 clientSet 将需要维护容器进程可访问的 kubeconfig 文件，并设置具有访问 Kubernetes 资源权限的 serviceaccount token。 下面是一个基于 kubeconfig 访问集群的代码模式 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 var ( k8sconfig *string //使用kubeconfig配置文件进行集群权限认证 restConfig *rest.Config err error ) if home := homedir.HomeDir(); home != "" { k8sconfig = flag.String("kubeconfig", fmt.Sprintf("./admin.conf"), "kubernetes auth config") } flag....

本文记录了在 kubernetes 环境中，使用 cephfs 时当启用了 fscache 时，由于网络问题，或者 ceph 集群问题导致的整个 k8s 集群规模的挂载故障问题。 结合fscache的kubernetes中使用cephfs造成的集群规模故障 在了解了上面的基础知识后，就可以引入故障了，下面是故障产生环境的配置 故障发生环境 软件 版本 Centos 7.9 Ceph nautilus (14.20) Kernel 4.18.16 故障现象 在 k8s 集群中挂在 cephfs 的场景下，新启动的 Pod 报错无法启动，报错信息如下 bash 1 ContainerCannotRun: error while creating mount source path /var/lib/kubelet/pods/5446c441-9162-45e8-0e93-b59be74d13b/volumes/kubernetesio-cephfs/{dir name} mkcir /var/lib/kubelet/pods/5446c441-9162-45e8-de93-b59bte74d13b/volumes/kubernetes.io~cephfs/ip-ib file existe 主要表现的现象大概为如下三个特征 对于该节点故障之前运行的 Pod 是正常运行，但是无法写入和读取数据 无法写入数据 permission denied 无法读取数据 kublet 的日志报错截图如下 彻底解决方法 需要驱逐该节点上所有挂在 cephfs 的 Pod，之后新调度来的 Pod 就可以正常启动了 故障的分析 当网络出现问题时，如果使用了 cephfs 的 Pod 就会出现大量故障，具体故障表现方式有下面几种 新部署的 Pod 处于 Waiting 状态...