1. 积重难返的运维服务体系 针对明确的运维诉求，开发相应的运维服务以供运维、业务用户使用，本无可厚非。但如果仅满足于此，很容易出现下面的情况: 用户频繁地寻找各个系统的入口，在各个系统之间来回跳转，忙于寻找各种按钮、拷贝参数。 一旦这样的运维服务多

1. 现象 - Tekton 克隆代码任务慢 在执行克隆任务时，Tekton 很费时间，多仓库下一般都需要 2 分 30 秒左右。如下图: 仅克隆的流水线就需要执行 2 分钟 16 秒，而克隆脚本实际上仅执行 1-3 秒。其中大部分时间花在了哪里？能不能减少？这是本篇主要想讨论的问题。 2. 分析克

1. Falco 是什么 Falco 是由 Sysdig 贡献给 CNCF 的云原生运行时安全相关项目。 Falco 实现了一套可扩展的事件规则过滤引擎，通过获取事件、匹配安全规则、产生告警通知系列操作，能够发现系统中的安全问题。其中的事件来自系统调用，同时也支持 ebpf 探针，规则是开源的[1]，可以自行定

1. 运行 Stable Diffusion 推荐配置 内存: 不低于 16 GB DDR4 或 DDR5 存储: 不低于 10 GB 可用空间 GPU: 不低于 6 GB 显存 N 卡 如果硬件达不到要求，也可以使用各种优化 fork 兼容更低配置的硬件，但生成时间会增长。 当前的开发主机配置为: 2.9 GHz 8-Core Intel Core i7 16 GB 2666 MHz DDR4 250 GB SSD 由于没有 GPU，生成图片时，

1. 跳过证书校验无法获取监控 如果指标抓取时，能跳过 TLS 认证是最便捷的。其 Prometheus 的 ConfigMap 配置如下: 1 2 3 4 5 6 7 8 9 - job_name: etcd metrics_path: /metrics scheme: https tls_config: insecure_skip_verify: true static_configs: - targets: [ '1.1.1.1:2379' ] - targets: [ '2.2.2.2:2379' ] - targets: [ '3.3.3.3:2379' ] 但 Prometheus Targets 报错 Get "https://3.3.3.3:2379/metrics": remote error: tls: bad certificate 在 targets 页面的报错如下图: 2. curl 验证抓取请求 跳过证书 1 2 3 curl https://1.1.1.1:2379/metrics -k curl: (35)