把团队知识库接进 IDE：Kiro 用 MCP 连 Bedrock Knowledge Bases

开发时查架构决策记录、API 规范或编码标准，通常要切到 wiki 搜半天，再切回编辑器改代码，一次上下文切换就是十几分钟。Kiro 这个 agentic IDE 通过 MCP 协议把 Amazon Bedrock Knowledge Bases 接进编辑器，让开发者直接用自然语言查团队文档，答案带引用来源。

这套方案解决四个具体问题：上下文切换（不用离开编辑器查文档）、知识碎片化（文档散落多个系统）、新人生效慢（熟悉文档结构要几天）、合规滞后（代码评审时才暴露规范违反）。

实现上，官方 awslabs.bedrock-kb-retrieval-mcp-server 做桥接：Kiro 通过 MCP 连本地子进程，服务端调用 Bedrock Knowledge Bases 的 Retrieve API（不是 RetrieveAndGenerate），用 Titan Text Embeddings v2 做向量检索，返回带引用的段落。

已有 Knowledge Base 的团队不用重建，给现有 KB 打上 mcp-multirag-kb=true 标签，MCP 服务器会自动发现，多个 KB（API 文档、架构决策、runbook）可以一起打标，Kiro 跨库查询。从零开始的话，示例仓库提供完整 AWS CDK 应用，一键部署 S3 存储桶、OpenSearch Serverless 向量库和 Bedrock Knowledge Base，几分钟搞定。

典型场景：问"我们的错误处理模式是什么"直接返回团队定的异常类结构；问"Orders API 要什么认证"直接给出 OpenAPI spec 里的 JWT scope 和限流要求；还能在 CI/CD 里用 Kiro CLI 跑无头查询，PR 评审时自动校验代码是否符合安全规范。

Kiro 自带的 Steering 文件（静态项目规则）和 Agent Skills（工作流指引）管行为，Knowledge Bases 存组织知识，MCP 是连接层——三者分工不同，这套方案是互补不是替代。适合文档量大、靠人记不住的团队。

#DevOps #运维 #Kiro #MCP #Bedrock #KnowledgeBases #RAG #Amazon #IDE #向量检索
@DevOpsTalkCN

KubeCon 北美 2026 议程公布，新增 AI 推理与 Agent 专场

KubeCon + CloudNativeCon 北美 2026 将于 11 月 9-12 日在盐湖城举行，完整议程已上线。今年新增 AI Inference + Agentic 专场，聚焦 Kubernetes 上的 AI 推理、Agent 工作流、GPU 调度、模型服务与生产级 AI 可观测性，涉及 vLLM、KServe、Ray 和 OpenTelemetry 等项目。

平台工程专场关注内部开发者平台、自助服务与自动化实践；安全专场覆盖供应链安全、身份与运行时防护、漏洞管理和策略执行。CNCF 调查显示，82% 的容器用户在生产环境运行 Kubernetes，66% 使用生成式 AI 的组织依赖它。CNCF 执行董事 Jonathan Bryce 表示，从训练模型转向生产运行是当前真正的工程挑战。

值得关注的议程亮点：
• 专场演讲：Kubernetes Solutions for Agent-Shaped Problems（Google 的 Tim Hockin 与 Dmitry Berkovich）
• 平台工程：How EarnIn Brought Testing to the Full CNCF Stack（EarnIn 的 Priya Namasivayam）
• 安全：Gone in 60 Minutes: Effectively Close the Exploitable Window with Detection as Code（ARMO 与 fusioncore.ai）
• 11 月 9 日联合活动：ArgoCon、BackstageCon、Cloud Native AI + Inference Day、CiliumCon、WasmCon

标准注册截止 9 月 2 日；Dan Kohn 奖学金提供免费注册或差旅资助，差旅申请截止 9 月 13 日，注册奖学金申请截止 10 月 4 日。

#DevOps #运维 #KubeCon #CNCF #Kubernetes #AI推理 #Agent #平台工程 #云原生安全 #vLLM #KServe #OpenTelemetry #eBPF #Cilium #Argo #Backstage
@DevOpsTalkCN

LFX 导师计划：从写文档到上手部署可观测系统

一位前端工程师加入 LFX 导师计划，原以为只是写三个月文档，结果几周后就在 AWS EC2 上部署 OpenTelemetry Collector、排查机器间网络问题、定位看似健康却不出指标的管道。这段经历让他从零基础接触可观测性，到独立构建和排障系统。

他部署的系统架构是：多个 EC2 实例跑 Django 应用，每个应用旁部署 OpenTelemetry Collector，另有一台专用 EC2 跑 Prometheus 作为指标后端，所有实例以 Prometheus 格式导出指标。

最大的挑战不在单个工具，而在组件间的交互：EC2 因网络限制无法互通、Collector 运行但不导出数据、管道静默丢弃遥测、本地正常但 AWS 部署失败。多数故障是"沉默"的——指标缺失、管道断裂、服务看似健康实则不可达。

导师制核心是自主性：导师给方向和反馈，但不替学员解决问题。讨论方案背后的推理过程比方案本身更有价值。一次测试平台无法自动化部署且有时限，团队讨论后改用替代方案并成功。

这段经历最大的转变不是学会某个工具，而是理解系统是必须被设计成能扛住故障的管道。
产出：
• 合并进 OpenTelemetry 文档的改进
• Prometheus 与 OpenTelemetry 互操作文档
• 非 Kubernetes 环境可观测性部署的蓝图提案

#DevOps #运维 #LFX #CNCF #OpenTelemetry #Prometheus #可观测性 #AWS #EC2 #导师计划
@DevOpsTalkCN

Postgres 多租户 BYOK 列加密：用 pgcrypto 实现客户自管密钥

B2B SaaS 场景下，多租户共享表结构，部分敏感列需要按租户加密。仅靠磁盘加密不够——客户要求自带密钥（BYOK），即使整个数据库泄露，只要客户侧密钥不泄露，敏感数据仍然安全。本文用 pgcrypto 演示了按组织维度做列级加密的完整方案。

设计约束很明确：所有组织共用表，行按 organization_id 归属；敏感列按组织用各自密钥加密；密钥存放在 AWS KMS，应用在查询时获取，数据库本身不持有密钥；非 BYOK 租户走同一套代码路径。方案采用信封加密：KMS 持有每组织的 KEK（客户自有、可吊销），应用在内存中短暂持有 DEK，DEK 由 KEK 加密后存于 KMS，使用时调用 KMS Decrypt 解包后直接传入查询。KMS 看不到数据，Postgres 只在查询执行期间接触 DEK，明文 DEK 仅存在于应用内存、随请求生命周期结束。

演示 schema 中，organizations.kms_key_arn 标识组织是否启用 BYOK，orders.secret 存 BYOK 行的密文，非 BYOK 行存明文做对比。生产环境建议列一律存密文，非 BYOK 租户用平台托管密钥。

读取模式分两种：单组织查询是常见路径，应用从 KMS 解包 DEK 后传入查询，每请求一次 KMS 调用（缓存 DEK 则每会话一次），是性能最优的 fast path；跨组织混合查询（管理视图、分析任务）可用 CTE 携带多个密钥，LEFT JOIN 让非 BYOK 行自然落入 kms_key_arn IS NULL 分支。

错误密钥行为值得注意：pgp_sym_decrypt 用错密钥会直接抛错而非返回乱码，这是 PGP 格式自带完整性校验的特性，不会静默返回错误数据。

生产落地有几个关键细节：DEK 必须作为绑定参数传入，绝不能拼进 SQL 文本，否则可能泄露到日志、trace 或会话元数据；加密状态应记录在行级别而非依赖组织当前 BYOK 设置，因为租户可能后续启用、停用或轮换密钥；非 BYOK 组织也要分配平台托管 DEK，保证敏感列始终以密文存储；密钥轮换要提前规划，租户换密钥时旧行需要明确处理方案；性能影响需实测，尽量只加密真正敏感的列。

PostgreSQL 自带 pgcrypto 扩展足以支撑多租户敏感数据的按租户加密，无需引入额外加密服务。

#DevOps #运维 #PostgreSQL #pgcrypto #BYOK #AWSKMS #数据加密 #多租户
@DevOpsTalkCN

AI 让漏洞发现变快，响应计划必须跟上

漏洞发现的速度已经超过团队修复能力，CVE 目录也跟不上 AI 的发现量。M-Trends 报告估计平均利用时间已到负七天，意味着利用先于补丁出现。响应和修复时间必须压缩，风险接受也变得更难向董事会和审计解释。

对任何代码库而言，这是激增而非无尽洪流。代码有限，AI 发现的漏洞大多属于已知类别、有已知修复方式。难点不在漏洞有多罕见，而在数量。

四步计划：扫描、排序、修复、兜底

扫描阶段要把所有发现汇入一处管理。CVE 发现是常规部分，新工作在于非 CVE 发现——扫描需纳入 CVE 目录之外的漏洞数据，包括 AI 发现的缺陷，并接入同一套处理和修复流程。只管理 CVE 的工具对这一类新发现是盲的。

排序阶段有三个关键信号：漏洞包是否实际加载进内存运行、能否被网络访问或暴露触达、资产被攻破是否有真实业务影响。前两个只能在线上环境测量。团队应聚焦分析产出的短清单，并信任辅助排序的工具——降级处理是主动决策，只有团队信任过滤器才站得住。

修复阶段不能手工逐个处理。在根上修：补一次基础镜像，而不是修补每个实例。自动化所有权和分派，让发现自动路由到对应团队。能用自动修复就用，生成的 PR 和配置变更能提升修复吞吐。在生产前拦截：不需要上线的就在准入控制器或流水线里挡住。还要熟悉其他杠杆——切断易受攻击工作负载的网络访问也是修复，往往比等补丁快。组织层面需要真正把这件事排上优先级，用业务驱动的指标争取支持。

最后为漏洞被利用做计划。修不完的，运行时是安全网。利用后的行为无论入口多新颖都相似：提权、侦察、取密钥。不必识别利用本身，抓住利用与业务影响之间的窗口就能保护组织。实践中要监控工作负载的失陷指标，测量检测和响应速度并找出瓶颈，用 AI 代理处理过多告警或夜间覆盖不足，把响应推到离数据源更近的位置，提前建好遏制剧本、升级路径和业务通知流程。人手或技能不足时，用服务商或 agentic SOC 工具补充。

发现已经规模化，响应也必须跟上。
@DevOpsTalkCN

IntervalStyle：改的是解析，不只是输出格式

PostgreSQL 的 IntervalStyle 参数常被当成纯输出格式偏好，但它同样改变 interval 的输入解析方式。默认值是 postgres，上下文为 user，自 8.4 起随 interval 输入输出重构引入。四种风格中，sql_standard 和 iso_8601 各藏一个坑。

sql_standard 会悄悄翻转数据符号

SQL 标准要求 interval 每个字段同号，前导负号作用于整个值；而 PostgreSQL 传统上各字段独立符号。IntervalStyle 决定歧义字面量按哪套规则解析：

```
SET IntervalStyle = 'postgres';
SELECT extract(epoch from interval '-1 2:03:04');
-- -79016（负一天，加 2:03:04）

SET IntervalStyle = 'sql_standard';
SELECT extract(epoch from interval '-1 2:03:04');
-- -93784（负一天，减 2:03:04）
```

同一字面量，两种结果，相差四小时多。sql_standard 是四种风格里唯一改变输入含义的，且恰好命中人们随手写的写法。防御办法：负 interval 的每个字段都显式加符号，'-1 days -2:03:04' 在任何设置下含义一致。

iso_8601 的坑在输出端

对混合符号 interval，PostgreSQL 输出负号设计符，如 P-1Y-2M3DT-4H-5M-6S。基础 ISO 8601 没有负时长（带符号时长是 8601-2:2019 的扩展），严格解析器会拒绝这种输出。interval 可能为负时，切到 iso_8601 并不能换来互操作性。

改风格影响所有文本协议客户端

大多数驱动默认走文本格式返回结果，interval 列以字符串到达，驱动用写死的代码解析——几乎都只认 postgres 风格。node-postgres 的解析器只懂 postgres 风格，文档明确要求改过就改回来。按库或按角色设 iso_8601 让某个 API 端点好看，其他所有读 interval 的客户端会在没人动过的代码里解析出错。（二进制格式不受影响，风格只存在于文本表示。）

建议

服务端保持 postgres，把它当会话级参数用。导出或 API 需要 ISO 8601 时长时，在产生数据的事务里 SET LOCAL IntervalStyle = 'iso_8601'，或在应用层格式化。sql_standard 绝不要设到比会话更广的范围——它改的是输入含义，不只是输出长相。负 interval 每个字段都写符号，不发送歧义数据，任何设置都无法曲解它。

#DevOps #运维 #PostgreSQL #IntervalStyle #数据库 #参数调优
@DevOpsTalkCN

独立部署让测试失真，开源工具如何用观测替代手工维护

微服务独立部署让集成测试的 mock 数据快速过期，测试可能通过，但验证的却是几个月前的旧行为。这不是代码质量问题，而是覆盖时效性问题——测试写得好，但测错了对象。

20 个服务、每个每周部署两次，生产环境每周产生 40 次潜在的 mock 失效事件。上游加个字段、改个错误码、调整认证头，下游 mock 就悄悄失真，没有任何可见信号。靠平台团队手工追踪每个上游部署并更新 mock，在交付压力下必然失效。这是结构性问题，需要结构性解法。

传统工具如 Testcontainers、WireMock、Pact 都很有价值，但共同局限是：行为假设在某个时间点编码后就开始老化。观测式工具则从实时行为中推导假设，跑一次捕获会话就能同时刷新所有集成测试假设，维护成本不再与上游部署频率成正比。

三种开源工具的实现路径差异明显：

Keploy 用 eBPF 捕获真实流量，直接解决独立部署的时效问题，最贴近生产行为。

Microcks 可导入真实 API 流量，适合已有流量记录的团队。

VCR 系（go-vcr、VCR.py）录制真实 HTTP 响应供回放，实现简单但需注意录制内容的时效管理。

在 CI/CD 中定时刷新 fixture，能让集成测试跟上频繁变更的微服务。建议平台团队先从少数高风险集成边界试点，再逐步推广到全架构。

对线上环境的意义：如果你们正被"测试全绿但上线就炸"困扰，且服务数量已多到手工维护 mock 跟不上节奏，观测式测试值得试点。从两三个关键依赖边界开始，用真实流量替代手工假设，能显著减少因 mock 过期导致的线上事故。

#DevOps #运维 #云原生 #微服务 #集成测试 #Keploy #Microcks #Pact #WireMock #Testcontainers #eBPF #CICD
@DevOpsTalkCN

别把 GPU 当 Web Pod 调度

Kubernetes 默认把 GPU 当成不透明的整数资源来调度，一个 Pod 独占整卡，但推理负载往往只用掉十几到三十几个百分点的算力。集群看起来排满了，账单却按整卡在涨——"已调度"和"已利用"之间的落差，就是云原生 AI 预算悄悄漏掉的地方。问题不在 GPU 贵，而在拿无状态 Web 服务的默认模式去套最贵、最不可替代的计算单元。

共享一张卡，有三种不同工具

- 时间切片（time-slicing）：纯软件方案，驱动按毫秒级轮转上下文，几乎支持所有 NVIDIA 卡，ConfigMap 即可开启。但没有内存、故障隔离，也没有算力保证，适合开发、笔记本和低优先级突发推理。
- MPS：多进程上下文复用，内核在不同 SM 上并发执行，吞吐和延迟优于时间切片，但同样无内存隔离，故障隔离弱，一个客户端崩溃可能拖垮邻居。
- MIG：硬件级分区，单卡最多 7 个隔离实例，各自独立内存、算力和故障域。需要 Ampere 或更新架构（A100/H100 等），T4/V100 不支持。配置静态、需提前规划，适合不可信租户或需要可预测 QoS 的场景。

配置 MIG 切片后，调度器终于能按资源属性而非整数计数来分配，例如 nvidia.com/mig-1g.5gb: "1" 表示申请一个 5GB 的 MIG 切片而非整卡，四副本可共享一张物理卡。

更长期的方案是动态资源分配（DRA）。Kubernetes v1.34（2025 年 9 月发布）中 DRA 核心框架 GA，调度器首次能原生表达"要一个具备这些属性的设备"而非整数。但注意：框架虽稳定，细粒度共享能力（可消费容量、扩展资源映射）在该版本仍是 alpha 或 beta，DRA 方向正确，但还不能完全替代 device plugin。

按因果信号扩缩容，别盯 CPU

GPU 推理 Pod 里 CPU 是去相关代理——加速器干重活，CPU 只做 tokenize、HTTP 和批处理。CPU 30% 时 GPU 可能已 100%、KV cache 打满、请求在队列堆积，HPA 却读着"健康"无动于衷。应改用因果信号：队列深度是领先指标，GPU 利用率（DCGM exporter 采集到 Prometheus）是同步护栏。KEDA 是标准机制，因为信号在 Pod cgroup 之外、HPA 够不着，且它能缩到零。用 backlog 决定副本数，用 GPU 百分比做上限。教程里抄来的 5% 阈值只是演示值，真实 serving 应看 70–80%。

冷启动税，没人提前算

共享和 scale-to-zero 的代价是冷启动——LLM 冷启动不是容器重启，多 GB 权重要加载进 VRAM，从本地 NVMe 读大模型可能耗时数十秒，还没算 CUDA graph capture。此时别急着上 lazy-pull 镜像快照：推理负载启动几秒内就要读几乎整个镜像（CUDA 库和权重），按需拉取只是把卡顿从拉取挪到首次推理。AWS 给 EKS 推的"并行"拉取模式就是承认这点——更快的全量下载，而非懒加载。结构性解法是停止把模型权重塞进容器镜像，并维持一个小的热基线，减少启动延迟和 GPU 浪费。

#DevOps #运维 #Kubernetes #GPU #NVIDIA #MIG #DRA #KEDA #LLM #云原生
@DevOpsTalkCN

Kubernetes 按整卡调度 GPU，LLM 推理吃大亏

Kubernetes 默认把 GPU 当整数资源调度：Pod 申请 nvidia.com/gpu: 1 就独占整卡，哪怕模型只用了一小块显存。实测中八卡节点每张卡都显示 Allocated 1/1，利用率却只有 10% 左右——7B 模型在 80GB 显存里只用了约六分之一。这不是调参问题，是资源模型的问题：调度器只数卡，不知道你的模型需要 14GB 而卡有 80GB，也不知道两个 Pod 本可共存。

单纯开自动扩缩容只会把浪费线性放大。HPA 能拉起更多整卡 Pod，Karpenter 能拉起更多整卡节点，但装箱的容器形状就是错的。

三种共享单卡的方式，差别很大

NVIDIA GPU Operator 提供三种机制，选错要么损失吞吐、要么让租户互相影响：

• 时间切片（time-slicing）：纯软件，驱动按毫秒级轮转上下文切换。几乎支持所有 NVIDIA GPU（T4/V100/L40S/A100/H100），用 ConfigMap 配 replicas: N 即可让一张卡变成四张。代价：无内存隔离、无故障隔离、无算力保证，一个 Pod OOM 可能拖垮整卡。适合笔记本、开发环境、低优先级突发推理。

• MPS：CUDA MPS 服务端多路复用进程上下文，内核在不同 SM 上"并发"跑，延迟更低、利用率更高。但依然没有内存隔离，故障隔离较弱，且是三者中在 Kubernetes 里最不成熟的。适合你掌控所有租户、追求吞吐的场景。

• MIG：唯一硬件级分区，把一张卡切成最多 7 个隔离实例，各自有独立显存、SM 和故障域。真正的隔离——租户在自己的切片里崩溃不影响整卡。代价：仅 Ampere 及更新架构（A100/H100/H200/B 系列，T4/V100 不行），且 profile 是静态的，重配置要排空 GPU。GPU Operator 配 mig.strategy=mixed 后，MIG 实例以 nvidia.com/mig-1g.5gb 这类完整资源名暴露，Pod 可以直接按名申请切片。

LLM 推理 Pod 应按有状态对待

权重加载是没人预算的隐性成本：典型冷启动要 60–120 秒，140GB BF16 模型从本地 NVMe 加载到 H100 约 40–50 秒，再加 25–30 秒 CUDA graph 捕获——本地盘加载就超一分钟，还没算拉镜像。所以 minReplicas: 0 意味着每次流量恢复都要付这笔延迟。

KServe 的 InferenceService 可以同时解决两件事：用 MIG 切片共享硅片，把权重加载当状态水合而非廉价重启。把 nvidia.com/gpu: "1" 换成 nvidia.com/mig-1g.5gb: "1" 就能从独占 80GB H100 变成让六个租户共享同一张卡；storageUri: "pvc://model-cache/..." 用节点本地缓存缩短权重加载，initialDelaySeconds: 60 避免权重没加载完就被标记 Ready。

核心教训：别再把整张昂贵 GPU 自动分配给只需要一小块的负载。Kubernetes 的 Dynamic Resource Allocation（DRA）提供了更细粒度的设备感知调度方式，值得关注。

#DevOps #运维 #Kubernetes #GPU #NVIDIA #MIG #MPS #LLM #KServe #DRA
@DevOpsTalkCN

Dragonfly 轻量部署：去掉 Manager 和数据库，一条 Helm 命令搞定镜像分发

Dragonfly 用 P2P 加速文件与容器镜像分发，但标准安装要部署 Scheduler、Seed Client、Client 之外，还得有 Manager 做动态配置，背后挂 MySQL 和 Redis。对单集群、只想解决镜像拉取时 registry 过载的场景，这套太重了。

轻量部署模式去掉了 Manager、MySQL 和 Redis，Scheduler 作为唯一协调组件，整个安装用一条 Helm 命令完成。本文讲清轻量架构怎么运作，并在本地 kind 集群里跑通。

传统部署里 Manager 是控制面，提供 Web 控制台、OpenAPI 集成（如 registry 触发的预热）、多 P2P 集群管理，并把动态配置分发给 Scheduler 和 Client，状态存 MySQL，Redis 做缓存和异步任务分发。单集群只做 P2P 分发时，真正需要的其实只有动态配置——也就是 YAML 里的调度限制、黑名单、Client 发现 Scheduler 的端点。去掉 Manager 地址后，Scheduler 和 Client 可以脱离数据库后端独立运行。

轻量部署用两个原生 Kubernetes 原语替代 Manager：ConfigMap 和 headless Service。manager.addr 未设置时，Scheduler 和 Client 从本地 /etc/dragonfly/dynconfig.yaml 加载动态配置，该文件由 Helm chart 通过 ConfigMap 挂载；文件不存在则启动时生成默认值。Scheduler 的 dynconfig.yaml 定义集群级调度参数，比如 seed peer 并发上传上限 loadLimit: 2000、候选父节点数 candidateParentLimit: 3、过滤父节点数 filterParentLimit: 15、peer 并发上传上限 loadLimit: 200。配置按 refreshInterval（默认一分钟）周期性重载，ConfigMap 更新后无需重启 Pod 即可生效，这些参数也暴露为 Helm values（scheduler.dynconfig、seedClient.dynconfig、client.dynconfig），保持声明式、GitOps 对齐。

Client 发现 Scheduler 的方式也变了：Manager 模式下 Client 查 Manager 找 Scheduler，轻量模式下 Client 的 dynconfig.yaml 直接指向 Scheduler 的 headless Service 地址（dragonfly-scheduler.dragonfly-system.svc.cluster.local:8002），dfdaemon 进程通过 DNS 解析出所有 Scheduler Pod IP，逐个健康检查并过滤不健康实例。Scheduler StatefulSet 扩缩容后，Client 自动通过 DNS 发现新端点。Scheduler 跑在静态 IP（如集群外）时，可用 scheduler.addrs 显式定义列表，非空时优先于 addr。

集群内落地三个工作负载：Scheduler（StatefulSet）协调跨 peer 的任务调度和分片分发；Seed Client（StatefulSet）作为 P2P 网络根 peer，直接从源仓库下载内容；Client（DaemonSet）跑在每个节点，dfinit 配置 containerd 把镜像拉取路由到本地 peer client。这套架构升级时无需数据库备份或迁移脚本，状态存在本地磁盘缓存，可按需从源重建。

三种部署模式对比：轻量部署只装 Scheduler、Seed Client、Client，适合单集群、边缘或 CI/CD 管道；轻量 + Redis（scheduler.database.redis.addrs）支持持久化任务和缓存元数据保留；带 Manager 的完整部署提供 Web 控制台、OpenAPI、多集群管理和 API 触发的预热。功能差异上，黑名单、任务分发、dfctl 预热三种模式都支持；持久化任务和持久化缓存任务需要 Redis；OpenAPI 预热、Web 控制台、OpenAPI 集成、个人访问令牌只有 Manager 模式才有。Helm chart 默认禁用 Manager、MySQL 和 Redis，轻量部署就是默认基线。

kind 集群跑通步骤：先建多节点集群（一个 control-plane 加两个 worker），预拉 dragonflyoss/scheduler、client、dfinit 三个镜像并 load 进 kind 节点，再写 charts-config.yaml 配置镜像和 metrics，dfinit 开启并指向 containerd 配置路径、proxyAllRegistries 设为 true，最后 helm repo add dragonfly 后 helm install 部署，验证四个 Pod 启动成功（每 worker 节点一个 Client、一个 Scheduler、一个 Seed Client）。

对单集群或边缘场景，这套轻量部署把组件砍到最少，升级不用管数据库，配置走 ConfigMap 热更新，值得一试。

#DevOps #运维 #Dragonfly #P2P #Kubernetes #Helm #镜像分发 #CNCF #containerd
@DevOpsTalkCN

把 K8s 发布校验从 45 分钟压到 2 分钟

发布流水线变绿，不代表应用真的健康。部署完成只是交付信号，应用健康是运行时信号，两者在 Kubernetes 里经常脱节：Pod 可能没 Ready、卡在 Pending、CrashLoopBackOff，或镜像拉取失败。流水线视角里部署已完成，用户视角里服务可能已降级。

我们团队在大型支付环境管理 K8s 负载，过去每次发布靠工程师手动校验：登录集群、逐命名空间缩容、查 Pod 状态、发布新版本、扩容、再查状态、翻日志。小发布还能扛，大生产发布跨多集群、多命名空间、数百个工作负载，一次校验约 45 分钟。更糟的是不一致——发布压力下容易漏查命名空间，Pod 可能 Running 但没 Ready，发布结论过度依赖执行校验的人。

我们没建新平台、没写 Operator、没换部署系统，直接复用现有 CI/CD 流水线和内部部署平台。流水线自动执行完整发布流：缩容目标负载、确认 Pod 下线、部署新版本、扩容、跨命名空间检查 Pod 健康。健康则通过，不健康则上报失败 Pod 及原因，始终不健康可触发回滚。每个校验阶段调用内部部署 API，传入集群、命名空间、发布名和操作，平台执行后返回状态，流水线据此决定继续、等待、通过、失败或回滚——本质是个小型发布控制循环。

最关键的检查是 Pod 就绪状态。Running 和 Ready 不是一回事：Running 只代表容器进程启动了，Ready 才代表 K8s 认为 Pod 可以接收流量。五个副本全 Running 但只有三个 Ready，应用就没完全健康。失败原因同样重要：Pending 指向调度或资源问题，CrashLoopBackOff 通常指向启动失败、缺配置或依赖问题，ImagePullBackOff 指向镜像标签、仓库或认证问题。流水线不只报"不健康"，而是报哪个 Pod 失败、为什么，省去工程师从零排查。

另一个关键设计是 60 秒稳定窗口。Pod 刚变 Ready 就立刻判定成功会制造假信心——Pod 可能 Ready 几秒后又崩溃，或依赖问题在开始处理流量后才暴露。流水线要求 Pod 保持 Ready 满 60 秒才通过，避免在第一个绿灯瞬间误判发布成功。

时间节省是次要的，真正的收益是一致性和信心：发布结论不再取决于执行校验的人，而是来自流程本身。发布校验从约 45 分钟降到约 2 分钟，同时消除了发布焦虑和重复手工操作。

#DevOps #运维 #Kubernetes #CICD #SRE #发布管理 #Helm #Pod健康检查
@DevOpsTalkCN

Postgres 时间表结构迁移实战

PDXPUG 九月聚会将聚焦 Postgres 时间表（Temporal Schema）迁移。Postgres v18 已支持时间主键、唯一约束和外键（NO ACTION），v19 有望加入 UPDATE/DELETE FOR PORTION OF，现在正是评估迁移的时机。

时间表结构的优势在于：简化历史数据重建的查询与连接、以保留引用完整性的方式实现软删除、避免外键引用已更新数据带来的 bug，以及用更规范的方式表达历史数据。

演讲者 Paul Jungwirth 将用一个运行超 12 年的计时与开票应用为例，展示旧结构痛点，并演示如何迁移到包含应用时间 daterange 和 tstzrange 列的结构。他也会讨论时间表使用中仍存的痛点及缓解建议。

Paul 是波特兰自由开发者，自 2010 年起构建 Postgres 应用，贡献涉及 GiST 索引、multiranges 及 SQL:2011 应用时间特性。

活动于 9 月 8 日 18:30-20:30 在 UpStart Collective（U.S. Bancorp Tower）举行，与 devopsdays Portland 同期。若你在考虑引入时间表，这场分享能帮你了解整体方案与代价。

#DevOps #运维 #Postgres #TemporalSchema #SQL2011 #数据库 #PDXPUG
@DevOpsTalkCN

多AZ集群里，服务网格的“默认负载均衡”正在悄悄收税

Kubernetes Service 和 Istio Envoy sidecar 默认在所有健康端点间随机分发流量，完全不感知 Pod 所在可用区。单 AZ 部署没问题，但一旦为容灾把 Pod 铺到三个 AZ，这个默认行为就成了隐患：us-east-1a 的 Pod 调用下游服务，约三分之二概率打到别的 AZ。一条请求路径经过三四个内部服务和数据库副本，跨 AZ 跳转次数会迅速累积。AWS NLB 默认也开启跨区负载均衡，入口流量同样会被随机分发到任意 AZ。

具体代价有两块。延迟：一个约 3500 RPS 的中型生产集群中，同 AZ 请求 p50 为 15-18ms，跨 AZ 则到 25-30ms，慢 40%-65%。约三分之二请求跨 AZ，加权后 p50 约 24ms，而本可做到约 17ms。钱：AWS 对区域内跨 AZ 流量收取 $0.01/GB，服务间流量通常是外部流量的 5-10 倍。该环境保守估算，入口、服务间、数据库和 Kafka 的跨 AZ 流量每月约 $600，还没算 Aurora 自动跨 AZ 复制和日志传输。具体数字取决于流量构成，建议用 AWS Cost Explorer 的 DataTransfer-Regional-Bytes 自己核对。

修复方案是 Istio 的 locality-aware 负载均衡，通过 DestinationRule 配置。不要用 100% 本地 AZ 的极端策略，那会丧失吸收故障的能力。推荐加权分布：80% 同 AZ，另外两个 AZ 各 10%，配合 outlier detection 自动剔除不健康端点。配置示例：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: checkout-service-locality-lb
spec:
host: checkout-service.prod.svc.cluster.local
trafficPolicy:
loadBalancer:
localityLbSetting:
enabled: true
distribute:
- from: us-east-1a/*
to:
"us-east-1a/*": 80
"us-east-1b/*": 10
"us-east-1c/*": 10
outlierDetection:
consecutiveErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50

生效有三个前提：Pod 需均匀分布，用 topologySpreadConstraints 的 maxSkew: 1 保证；ingress gateway Pod 也要铺满所有 AZ；NLB 需通过 service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "false" 注解关闭跨区负载均衡，否则 LB 会重新引入随机性。

收益不仅是延迟改善，更重要的是故障爆炸半径变小。随机分发下，失去一个 AZ 会让剩余两个 AZ 瞬间多扛 50% 负载，容易级联饱和。80/10/10 策略下，失去一个 AZ 只重新分配它原本承担的 80% 流量，其他 AZ 相对增量小得多，outlier detection 会自动绕开故障。代价是运维复杂度：流量分布不再是直观的 33/33/33，排查“为什么这个 AZ 流量多”时需要知道 locality 策略的存在，上线前务必文档化。

先在低环境用 k6 或 Locust 做真实负载验证，再在生产最低流量服务上金丝雀发布，观察错误率和 p95 延迟。Locality-aware 负载均衡是 Istio 存在多年的功能，被跳过只因默认行为“能用”。等对账 AWS 数据传输账单或 AZ 故障被 paged 时，就晚了。

#DevOps #运维 #Istio #Kubernetes #AWS #负载均衡 #服务网格 #多AZ #SRE
@DevOpsTalkCN

PostgreSQL 的 JIT 开关：开了不等于在用

jit 参数控制 PostgreSQL 是否用 LLVM 将查询编译为原生代码，默认开启。它用编译时间换长查询的执行速度，对 CPU 密集的分析型查询划算，短查询则纯亏。是否生效及耗时，会显示在 EXPLAIN ANALYZE 底部的 JIT 段。

一个观测陷阱：EXPLAIN (ANALYZE, COSTS OFF) 会连 JIT 段一起隐藏，看不到不代表没跑。TIMING OFF 则只去掉耗时行，JIT 段保留。

jit_provider 指定执行编译的共享库，默认 llvmjit，基本不用改。但它指向的库不一定装了：PGDG 的 Debian/Ubuntu 包把 llvmjit.so 放在单独的 postgresql-18-jit 包里，服务器包只是推荐安装；RPM 系更是完全不拉取。用 --no-install-recommends 装的 Docker 镜像大多没有。

库缺失时，jit 显示 on，查询正常跑，日志无任何报错——配置和实际行为脱节，唯一能发现的是 pg_jit_available() 返回 false。建议在所有服务器上跑一下这个函数确认，不少集群“启用”JIT 多年，实际从未编译过一条指令。

#DevOps #运维 #PostgreSQL #JIT #LLVM #数据库 #性能调优
@DevOpsTalkCN

AlloyDB 深度评测：兼容性真相与 HTAP 实战

Google 的 AlloyDB 声称与 PostgreSQL 完全兼容，分析查询性能最高可达原生 Postgres 的 100 倍。作者用一年时间实测后得出结论：兼容性仅停留在 wire protocol 层，底层存储引擎与社区版分道扬镳。本文是这份评测的核心发现。

存储架构上，AlloyDB 将 WAL 视为数据库本身，计算节点不再写完整数据页，而是把日志记录发送到基于 Colossus 的分布式存储层，由 Log Processing Service 异步物化数据页。这带来四个好处：故障切换无需回放 WAL、读副本不再是数据拷贝、存储扩容自动化、写路径省去 full_page_writes 开销。代价是存储格式专有，pageinspect 这类工具彻底失效，你无法再逐字节检查 MVCC 头来排查 bloat 问题。

VACUUM 并未像宣传那样被存储层吸收。死元组清理、可见性映射维护、事务 ID 回卷冻结仍跑在计算节点上，Google 只是用自适应调度器替换了社区版的固定阈值。实测中 n_dead_tup 依然呈锯齿状波动，autovacuum_count 照常递增。监控告警阈值若按社区版 autovacuum 调参，将失去意义。

列式存储是性能核心。TPC-H Q6 在 SF100 下从 182 秒降到 0.6 秒，311 倍加速，但这是最佳场景。Q5 加速 9.8 倍，Q12 4.8 倍，Q1 仅 2 倍，点查无提升。列式引擎对写热点表有代价，SF100 下并发扫描使写吞吐下降 29%，比行存的 16% 更糟。自动填充可能静默失败，必须用 google_columnar_engine_add 显式固定列并验证数据驻留。

AlloyDB Omni 是另一款产品：跑在标准 PostgreSQL 存储上，无共享存储、无托管故障切换，但内置列式引擎和 ScaNN 向量索引。ScaNN 的 sq8 量化索引比 ivfflat 小约 30 倍，构建快 7-9 倍，但查询参数 scann.num_leaves_to_search 必须先 LOAD 'alloydb_scann' 才生效，否则静默使用浅层搜索，作者因此跑出过 0.15 的召回率。

读池经济性取决于负载形态。AlloyDB 节点单价约为 Cloud SQL 两倍，但共享一份存储。全天候平稳读负载下，约 5TB 数据才打平；若读负载集中在业务时段，打平点降至约 765GB。跨区域仅支持主备模式，无 active-active。

结论：AlloyDB 是披着 PostgreSQL 协议外衣的企业级 HTAP 引擎，适合已在 GCP 上、需要免运维故障切换和实时分析的大数据量团队。依赖 timescaledb、plv8 等扩展、需要深度调优或物理格式可见性的团队应谨慎。迁移前务必验证扩展白名单、列式存储驻留状态和写竞争表现。

完整基准数据与 EXPLAIN ANALYZE 输出：GitHub

#DevOps #运维 #PostgreSQL #AlloyDB #HTAP #列式存储 #ScaNN #GCP #数据库评测
@DevOpsTalkCN

PostgreSQL JIT 排障：两个开关定位编译 bug

PostgreSQL 的 JIT 编译器承担两项工作：编译表达式和元组变形（tuple deforming）。jit_expressions 和 jit_tuple_deforming 这两个布尔参数分别控制这两项功能，默认开启，属于 Developer Options 类别，官方文档明确警告不建议在生产库上修改。

表达式编译把执行器对 WHERE 子句、目标列表、聚合转换的解释执行替换为针对具体表达式生成的原生代码。元组变形则是在此之前，把存储元组的压缩字节转换为执行器所需的 datum 和 null 数组。JIT 会为特定元组描述符生成专用变形函数，省去通用逻辑。

这两个参数看似对称，实则不然。关闭 jit_tuple_deforming 后，JIT 块中只是少了变形函数；但关闭 jit_expressions 后，整个 JIT 块完全消失——因为变形代码只在编译消费它的表达式过程中生成，没有表达式编译就无处挂载变形器。

这正是它们作为排障工具的价值：怀疑 JIT 导致崩溃或结果错误时，先 SET jit = off 确认问题是否消失；再开启 JIT 并关闭 jit_tuple_deforming，若问题解决则变形编译器是元凶，否则就是表达式编译器。两个开关、三种结果、一个嫌疑对象，全程无需重启。

注意这不是调优旋钮。若 JIT 编译开销大于收益，应调整成本阈值或直接关闭 JIT，而不是逐个关功能。日常保持两者开启，排障时用 SET 临时切换即可。

#DevOps #运维 #PostgreSQL #JIT #数据库 #性能调优 #故障排查
@DevOpsTalkCN