在本文中，将探讨使用 k3s 的 kine 项目来替换掉 etcd，并通过实验使用 kubeadm 去 run 一个 k8s 集群，并用 k3s 的 kine 项目来替换掉 etcd。 为什么使用 kine etcd 在 Kubernetes 之外基本上没有应用的场景，并且 etcd 迭代也比较慢，由于没有人愿意维护因此一直在衰退 [1]，并且，Kubernetes 集群中，etcd 也是一个影响集群规模的重大因素。并且 K3S 存在一个项目 Kine 可以使用关系型数据库运行，这样对集群维护者来说可以不需要维护复杂的 etcd 集群，由于关系型数据库有很多高可用方案，这将使得 k8s 集群规模变成了无限可能。 Kine 介绍 前文提到，kubernetes (kube-apiserver) 与 etcd 是耦合的，如果我们要使用 RDBMS 去替换 etcd 就需要实现 etcd 的接口，那么这个项目就是 Kine [2]。 Kine 是一个 etcdshim，处于 kube-apiserver 和 RDBMS 的中间层，它实现了 etcdAPI的子集（不是etcd的全部功能），Kine 在 RDBMS 数据库之上实现了简单的多版本并发控制；将所有信息存储在一个表中；每行存储此 key 的修订, key, 当前值, 先前值, 先前修订，以及表示该 Key 是已创建还是已删除的标记，通过这种机制可以作为 shim 层来替换 etcd。...

Preparation debian12 几乎可以使用任何旧的计算机硬件，因为最小安装的要求非常低。以下是最低要求和推荐要求： 最低要求 推荐要求 存储：10 Gigabytes 内存：512 Megabytes CPU: 1 GigaHertz 存储：10 Gigabytes内存：2 GigabytesCPU: 1 GigaHertz or more 如何选择下载安装包 offical mirror aliyun mirror 官网提供了安装包的下载，其中CD是网络安装，DVD是离线安装 debian官方下载页面 Notes：CD安装包很小，下载下来是 debian-11.4.0-amd64-netinst.iso 如名所示，这是一个网络安装包，所以推荐下载DVD部分，可以达到离线安装的效果 截至文章编写日期，debian-12.5.0-amd64-DVD-1.iso 大小是 3.7G Debian12 EOL：June 30th, 2028 安装步骤 在界面中选择“Install”，安装将开始。如果图形化安装可以选择“Graphical install”，这里选择“Install”。 欢迎页面 完成后，系统将提示选择安装时的“语言”。选择喜欢的语言，然后按“Enter”。这里选择英文 选择语言页面 这将是接下来安装步骤 安装步骤概述 选择位置与键盘布局 选择地区，这里选择美国 选择区域 下面部署时选择键盘布局：中国大陆使用的键盘布局是美国-英语，不要选择英国-英语之类，布局是不一样的，会存在按键输出的结果会不同 选择键盘布局 完成上述操作后，将开始加载镜像。等待扫描完成。。。。 等待扫描组件 设置主机名和域名 这步骤中将配置一个“主机名”。与一个“域”名称。 配置主机名 “域” 可以选择留空确定 配置域 完成上述操作后，安装程序将提示需要设置 root 密码。输入您的 root 密码，然后在重新输入以进行验证后继续。 Tips: 这里建议设置密码，不设置密码会导致安装完成后无法进入 root 用户**，**这样就需要根据先登录普通用户，然后通过 sudo切换过去。 设置Root密码 设置Root密码 - 二次确认 设置非ROOT用户名、账户和密码 下一步创建一个非ROOT用户，这个步骤是必须的，并为这个新创建的帐户分配一个密码。以下截图将描述将如何完成此操作。...

设置一个网络接口 debian 中网络接口的配置文件是在 /etc/network/interfaces，可以设置 “静态地址” 或 “DHCP” text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces....

OpenAPI 什么是OpenAPI Swagger 是一套围绕 OpenAPI 规范构建的开源工具，可帮助我们设计，构建，记录和使用 REST API。 OpenAPI 规范（前名称为 Swagger 规范）是 REST API 的 API 描述格式。包括： 可用端点 ( 例如 /users) 以及每个 endpoint 上的操作 (例如 GET /users, POST /users) 操作参数，每个操作的输入和输出 认证方法 联系信息，许可证，使用条款等其他信息。 什么是 Swagger？ Swagger 是一组围绕 OpenAPI 规范构建的开源工具，有助于用户设计，构建，记录和使用 REST API，支持整个 API 生命周期的开发，从设计和文档到测试和部署。 使用 Swagger 的目的 标准化文档格式：Swagger (OpenAPI) 采用了准化 API 文档格式。通过使用 Swaggo（将注释转换为 Swagger2.0文档的包） 生成 Swagger 文档，Swagger 的结构化格式的文档，使开发人员更容易理解产品的 API 交互。 交互式文档体验：Swagger UI 与 Swaggo 集成，提供交互式且用户友好的界面，用于测试 API。Swaggo提供了一个自动生成的界面，允许开发人员浏览 Endpoint，查看请求/响应示例，甚至可以直接从文档执行 API 请求。这种交互式体验可提高开发人员的工作效率并加速 API 的采用。 自动且最新的文档：Swaggo 可自动从用户的 Go 代码生成 API 文档。这种自动化无需手动维护单独的文档文件。Swaggo 直接从用户的代码库中提取信息，包括 endpoint 详细信息，请求/响应模型和注释。使用这种方法可确保用户的 API 文档随着代码的更新而保持最新。 Swagger 与 Gin 的集成 拉取 Swaggo 使用如下命令下载swag...

创建服务账户 首先可以到「 IAM管理 -> 服务帐户」新增帐户。在新增完成后，会得到一把 key，将它下载后请妥善保管，因为所有相关的身份认证都会用到，这个 key 在下载后就无法继续下载了。 授权 接着到「IAM -> 新增」成员，并且选择角色，这里选择「Cloud Storage -> 储存空间物件检视者」，让此帐户具备有 read（读取） storage 的功能。 登录 bash 1 2 cat KEY-FILE | docker login -u KEY-TYPE --password-stdin \ https://LOCATION-docker.pkg.dev GCP 的 KEY-TYPE 通为 json_key，但这里包含两种类型 _json_key 和 _json_key_base64 KEY-FILE 就是下载的 Service account key 的文件 bash 1 2 cat KEY-FILE | docker login -u _json_key --password-stdin \ https://LOCATION-docker.pkg.dev 通常 Service account key 文件内容如下 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 { "type": "service_account", "project_id": "project2024-0101", "private_key_id": "bdfsd612779509406bb8452c3ek12d730ed547e722d", "private_key": "-----BEGIN PRIVATE KEY----....

Kubernetes监控架构设计 k8s监控设计背景说明 根据 Kubernetes监控架构 1，Kubernetes 集群中的 metrcis 可以分为 系统指标 (Core Metrics) 和 服务指标 (service metrics) ; 系统指标(System metrics) 是通用的指标，通常可以从每一个被监控的实体中获得（例如，容器和节点的CPU和内存使用情况）。服务指标(Service metrics) 是在应用程序代码中显式定义并暴露的 (例如，API Server 处理的 500 错误数量)。 Kubernetes将系统指标分为两部分： 核心指标 (core metrics) 是 Kubernetes 理解和用于其内部组件和核心工具操作的指标，例如：用于调度的指标 (包括资源估算算法的输入, 初始资源/VPA (vertical autoscaling)，集群自动扩缩 (cluster autoscaling)，水平Pod自动扩缩 (horizontal pod autoscaling ) 除自定义指标之外的指标)；Kube Dashboard 使用的指标，以及 “kubectl top” 命令使用的指标。 非核心指标 (non-core metrics) 是指不被 Kubernetes 解释的指标。我们一般假设这些指标包含核心指标 (但不一定是 Kubernetes 可理解的格式)，以及其他额外的指标。 所以，kubernetes monitoring 的架构被设计拥有如下特点： 通过标准的主 API (当前为主监控 API) 提供关于Node, Pod 和容器的核心系统指标，使得核心 Kubernetes 功能不依赖于非核心组件 kubelet 只导出有限的指标集，即核心 Kubernetes 组件正常运行所需的指标。 … 监控管道 Kubernetes 监控管道分为两个：...

工作流模型是指 Stackstorm 中 Orquesta 工作流的定义，包含工作流的执行方式，也可以理解为工作流模型就是 Workflow DSL 定义任务执行的有向图 工作流模型 下表是工作流模型 (Workflow Model) 的属性。工作流接受 Input，按预定义顺序执行一组任务 (Task)，并返回输出 (Output)。此处的工作流模型是一个有向图 (directed graph)，其中 Task 是节点，Taskt 之间的转换及其条件形成边。组成工作流的任务将在 DSL 中定义为名为 Task 的字典， 其中 Key 和 Value 分别是任务名称和任务模型。 Attribute Required Description version Yes The version of the spec being used in this workflow DSL. description No The description of the workflow. input No A list of input arguments for this workflow. vars No A list of variables defined for the scope of this workflow....

应用连接 nacos 时报错 403，用户密码均正确，用户存在，并且权限正确 text 1 2 2024-05-20 10:36:11,593 - [ERROR] - [ropertySourceBuilder][main][n.c.NacosPropertySourceBuilder: 101][]: get data from Nacos error,dataId:admin-server.yaml - com.alibaba.nacos.api.exception.NacosException: http error, code=403,msg=user not found!,dataId=admin-server.yaml,group=DEFAULT_GROUP,tenant=cced143f-5adb-4cb8-a580-28802ea8f203 at com.alibaba.nacos.client.config.impl.ClientWorker$ConfigRpcTransportClient.queryConfig(ClientWorker.java:979) 原因：nacos 地址应该和应用连接的不一致，修改一致后恢复正常 nacos 配置文件配置 “/nacos”， 应用直接连接 “/” bash 1 server.servlet.contextPath=/nacos

GKE添加VPC防火墙规则有与GCE有一些区别，必须找到GKE的”网络标记“才可以，如下 选择 Kubernetes Engine => 选择 ”集群“ 进入 GKE 集群主页 随便选择一个集群，进入集群详细页面 选择集群中的任意一个节点池 找到节点池中任意一个节点，点击进入 进入后向下拉找到”网络标记“部分，这个网络标记可以标记这个集群的所有节点 如果想自定义”网络标记“的名称，可以在集群首页选择标记进行修改

本文档使用以下术语 机器系列：针对特定工作负载优化的一组精选处理器和硬件配置。创建虚拟机时，您可以从首选机器系列中选择预定义或自定义机器类型。 机器系列：机器系列按系列和世代进一步分类。例如，通用机器系列中的 N1 系列是 N2 系列的旧版本。世代编号或系列号越高，表示底层 CPU 平台或技术较新。例如，M3 系列是 M2 系列的较新世代。 机器类型：每个机器类型都有一个预定义机器类型，用于为您的虚拟机提供一组资源。如果预定义机器类型不能满足您的需求，您还可以为某些机器系列创建自定义机器类型。 代 Intel AMD Arm 第 4 代机器系列 N4, C4, X4 N/A C4A 第 3 代机器系列 C3、Z3、H3、M3、A3 C3D N/A 第 2 代机器系列 E2、N2、C2、M2、A2、G2 N2D、C2D、T2D、E2 T2A 第 1 代机器系列 N1、M1 机器系列和系列建议 下表提供了针对不同工作负载的建议。 通用工作负载 E2 N2、N2D、N1 C3、C3D Tau T2D、Tau T2A 以更低的费用进行日常计算 在多种机器类型之间实现均衡的性价比 在各种工作负载中始终如一地保持高性能 最佳每核心性能/费用（适用于横向扩容工作负载） 低流量 Web 服务器 后台应用 容器化的微服务 微服务 虚拟桌面 开发和测试环境 中低流量 Web 和应用服务器 容器化的微服务 商业智能应用 虚拟桌面 CRM 应用...

工具命令集合 长期总结 - Linux日志查询命令 长期总结 - Linux网络命令合集 长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例 探索kubectl - 巧用jsonpath提取有用数据 探索kubectl - kubectl诊断命令集合 Pod 检查 Pod 就绪探针 bash 1 kubectl get pods <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 查看 Pod 事件 bash 1 kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name> 获取 Pod Affinity 和 Anti-Affinity bash 1 kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.spec.affinity}' 列出 Pod 的 anti-affinity 规则 bash 1 kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{....

本文将介绍 Harbor 从 v1.10.7 升级到 v2.10.0，以及如何将 Harbor 从 v2.10 回滚到 v1.10.7。 升级条件 Linux服务器 4 个 CPU 和 8 GB 内存（强要求），100G可用空间（跨多版本时存放备份文件以及镜像文件，这部分要求） Docker-compose > 1.19.0+ 备份现有的 Harbor /data/database 目录 本次升级主要是使用了 harbor 内置的数据库，所以升级步骤比较容易。 官方升级路线 harbor 的升级，是不能跨很多版本进行升级，官方对此有详细说明 [1] ，可以看到路线为： 1.10.0 [1] => 2.4.0 [2] => 2.6.0 [3] => 2.8.0 [4] => 2.10.0 [5] 模拟升级步骤 github release 页下载对应的安装包 解压 bash 1 2 # 命令主要为将harbor压缩包内文件解压到指定目录中，由于 harbor 解压后文件名无论版本如何都为“harbor” $ mkdir ./harbor-v1.10 && tar -xf harbor-offline-installer-v1.10.0.tgz -C ./harbor-v1.10 --strip-components 1 备份默认的配置文件（仅限于 v1....

下载 nacos-server bash 1 $ tar zxvf nacos-server-2.2.3.tar.gz -C /opt/ 创建nacos用户 bash 1 useradd nacos -s /sbin/nologin -M 修改 java 环境变量 使用openjdk启动，需要配置JAVA_HOME在启动脚本中 bash 1 2 3 4 $ rpm -ql java-1.8.0-openjdk-headless # 找到 jre 根目录配置 JAVA_HOME # /opt/nacos/bin/startup.sh JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.412.b08-1.el7_9.x86_64/jre 启动命令 集群模式需要同时启动多个节点 bash 1 2 3 4 5 6 7 启动命令 # 单机 sudo -u nacos /opt/nacos/bin/startup.sh -m standalone # 集群 sudo -u nacos /opt/nacos/bin/startup.sh -m cluster # 停止服务 sudo -u nacos /opt/nacos/bin/shutdown....

tls 证书在 k8s 集群上大量使用的话，当到期时会存在批量替换的难度，比如说每个名称空间，多个业务的使用，在这篇博文中，将尝试批量替换整个集群的证书（前提，在没有使用 vault, cert-manager这类组件的集群之上）。 基本操作 步骤1：首先不知道有多少个名称空间使用了这个证书，所以需要遍历所有的名称空间，这里使用 kubectl 的 json path 实现 bash 1 $ kubectl get ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}' 步骤2：拿到名称空间的名字后，就需要循环这个名称空间下所有的 secret bash 1 2 3 4 for ns in `kubectl get ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}'` do kubectl get secret -n $ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}' done 步骤3：找到与这个匹配的证书进行替换 把步骤3拆解为下面几个步骤： 拿去到符合要求的secret的名字 匹配名称是否为修改的secret 做替换操作 由于步骤2使用的是 jsonpath 拿到的 secret name，由于 kubectl 并不支持高级jsonpath语法，官方推荐使用jq，那么使用jq获取名字 bash 1 kubectl get secret -n $ns -o json|jq -r ....

什么是jsonnet jsonnet是用于app或开发工具的数据模板语言，主要用于json的扩展，具有下面功能： 生成配置数据 无副作用 组织化，简化，统一化 管理无序的配置 jsonnet可以通过面向对象消除重复。或者，使用函数。与现有/自定义应用程序集成。生成 JSON、YAML、INI 和其他格式。 安装jsonnet Jsonnet 有两种实现（C++ 和 Go） 在 Debian/Ubuntu 之上，可以直接使用 apt 源来安装 bash 1 apt install jsonnet -y 安装 go 实现的，可以用下面命令，前提是安装了go bash 1 go get github.com/google/go-jsonnet/cmd/jsonnet 什么是jsonnet-bundler jsonnet-bundler 是 Jsonnet 的包管理器，用于个简化 jsonnet 项目中依赖关系管理的工具。使用 Jsonnet Bundler 可以带来下面便利之处： 使用 jsonnetfile.json 作为依赖关系管理 自动安装和更新依赖项。 版本选择，使用 jsonnetfile.json 可以确保项目使用正确版本的依赖。 可重复构建， 使用 jsonnetfile.json 管理的项目可以在不同环境中构建并确保结果的一致性。 更方便的与 GitOps 结合， Jsonnet Bundler 提供 与 GitOps 的集成。 jsonnet-bundler 安装 Jsonnet Bundler 有两种安装模式，实际上就是 Go 程序通用的安装方式：...

处理记录 Ceph版本：octopus 首先遇到問題是，业务端无法挂在 cephfs 查看内核日志发现是 bad authorize reply ，以为是 ceph keyring被替换了 text 1 2 3 4 5 6 7 8 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10....

Overview 阅读完本文，您当了解 Linux oom kill Kubernetes oom 算法 Kubernetes QoS 本文只是个人理解，如果有大佬觉得不是这样的可以留言一起讨论，参考源码版本为 1.18.20，与高版本相差不大 什么是OOM Kill 当你的Linux机器内存不足时，内核会调用Out of Memory (OOM) killer来释放一些内存。这经常在运行许多内存密集型进程的服务器上遇到。 OOM Killer是如何选择要杀死的进程的？ Linux内核为每个运行的进程分配一个分数，称为 oom_score，==显示在内存紧张时终止该进程的可能性有多大==。该 Score 与进程使用的内存量成比例。 Score 是进程使用内存的百分比乘以10。因此，最大分数是 $100% \times 10 = 1000$。此外，如果一个进程以特权用户身份运行，那么与普通用户进程相比，它的 oom_score 会稍低。 在主发行版内核会将 /proc/sys/vm/overcommit_memory 的默认值设置为零，这意味着进程可以请求比系统中当前可用的内存更多的内存。这是基于以下启发式完成的：分配的内存不会立即使用，并且进程在其生命周期内也不会使用它们分配的所有内存。如果没有过度使用，系统将无法充分利用其内存，从而浪费一些内存。过量使用内存允许系统以更有效的方式使用内存，但存在 OOM 情况的风险。占用内存的程序会耗尽系统内存，使整个系统陷入瘫痪。当内存太低时，这可能会导致这样的情况：即使是单个页面也无法分配给用户进程，从而允许管理员终止适当的任务，或者内核执行重要操作，例如释放内存。在这种情况下，OOM Killer 就会介入，并将该进程识别为牺牲品，以保证系统其余部分的利益。 用户和系统管理员经常询问控制 OOM Killer 行为的方法。为了方便控制，引入了 /proc/<pid>/oom_adj 来防止系统中的重要进程被杀死，并定义进程被杀死的顺序。 oom_adj 的可能值范围为 -17 到 +15。Score 越高，相关进程就越有可能被 OOM-killer Kill。如果 oom_adj 设置为 -17，则 OOM Killer 不会 Kill 该进程。 oom_score 分数为 1 ~ 1000，值越低，程序被杀死的机会就越小。 oom_score 0 表示该进程未使用任何可用内存。 oom_score 1000 表示该进程正在使用 100% 的可用内存，大于1000，也取1000。 谁是糟糕的进程？ 在内存不足的情况下选择要被终止的进程是基于其 oom_score 。糟糕进程 Score 被记录在 /proc/<pid>/oom_score 文件中。该值是基于系统损失的最小工作量、回收的大量内存、不终止任何消耗大量内存的无辜进程以及终止的进程数量最小化（如果可能限制在一个）等因素来确定的。糟糕程度得分是使用进程的原始内存大小、其 CPU 时间（utime + stime）、运行时间（uptime - 启动时间）以及其 oom_adj 值计算的。进程使用的内存越多，得分越高。进程在系统中存在的时间越长，得分越小。...

本文使用 helm 方式部署 grafana 9 并同样将 keycloak 部署在 kubernetes 集群之上；接下来使用 keycloak 作为 grafana authentication，并实现 oauth2 的用户权限管理。 在Kubernetes 集群之上使用helm部署keycloak 在 kubernetes 集群安装 keycloak 有两种方式： bitnami helm offical 下面使用 offical 提供的方式进行部署 bash 1 kubectl create -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/kubernetes/keycloak.yaml helm 部署完成后默认密码是存储在 secret 中，上面方式安装的密码默认为 admin/admin Keycloak configuration 创建realm Realm 管理这一组用户(users), 凭据(credentials), 角色(roles) 和 组(groups)，realm之间是相互隔离，一个用户属于并登录到某个 realm，只能管理和验证其控制的用户。 下面为 grafana 创建一个 realm，如果你的环境已经存在通用的 realm，则可以使用这个 realm，默认 keycloak 的 realm 是 master，超级管理员属于这个 realm。 创建 client Client 是可以请求Keycloak对用户进行身份验证的实体。最常见用途是希望使用Keycloak来保护自己并提供单点登录(SSO)解决方案的应用程序和服务。客户端也可以是只希望请求身份信息或访问令牌的实体，以便它们可以安全地调用由 Keycloak 保护的网络上的其他服务。因此，我们需要为 grafana 创建一个 client...

背景与架构设计 网络中存在的挑战 挑战1：Kubernetes 的每个 Pod 拥有一个独立的 IP 地址。对外部访问则依赖 NodePort、LoadBalancer 或 Ingress，出于安全考虑不可能对每个 Pod 都暴露其 8849 端口 (NodePort) 或者使用 Ingress 配置大量的域名，这样无法连接到单独的某一个 Pod (通过Service)。 挑战2：网络环境是完全隔离的，用户无法通过 Pod IP 直接访问 Pod，所有的用户流量只能通过对应 IDC 的唯一入口进入。 挑战3：出于安全考虑不可能对每一个 Java 服务 (Pod) 在他的工作周期期间所有时间都暴露对应的 Jprofiler 端口，而仅仅想使用时可以连接，用后关闭。 JProfiler网络需求 JProfiler 可以通过加载 JVM 代理（libjprofilerti.so）与远程 GUI 通信，他的实现原理如下： JVM 启动时加载 JProfiler 代理，绑定到一个特定端口（如 8849）。 本地 JProfiler GUI 通过该端口连接到远程 JVM。 代理与 GUI 之间通过 TCP 传输性能数据。 在 Kubernetes 中，JProfiler 代理运行在 Pod 内部，但由于网络隔离和动态 IP，GUI 无法直接连接到 Pod。因此，我们需要一种机制将 JProfiler 的端口动态映射到可访问的外部端点。 需要实现的架构 下图是基于上面提到的问题从而设计的集群架构...

什么是传感器 传感器 (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....