发布 · XB 现场笔记

Hugo 发布选项决定哪些页面进入产物

Sat, 18 Mar 2028 00:00:00 +0000

Hugo 在构建运行时判断哪些页面应当渲染。文章元数据提供发布时间与草稿状态，项目配置和命令参数提供包含规则，构建时钟提供判断所用的时间。生成目录一旦部署，在下次产物替换之前不会自行变化。因此，日期走到午夜不等于触发发布；没有写 draft: true 的文件，也不会自动被当成草稿。这两个边界决定了排期内容能否按预期上线。

元数据和构建选项分别起作用

在默认规则下，标记为 draft: true 的页面不进入产物；发布时间在未来的页面也会被排除，已经过了失效时间的页面同样如此。Hugo 根据 front matter 配置解析各类日期，显式的 publishDate 可以不同于页面显示的 date。对必须精确到某个边界的排期，应使用包含时区的完整时间戳，避免本机和构建服务器把同一个日期解释为不同时间。

--buildDrafts 包含草稿，--buildFuture 包含未来内容，--buildExpired 包含已失效内容，短选项分别是 -D、-F 和 -E。这些开关处理不同条件：一篇发布时间尚未到达的草稿，需要同时允许草稿和未来内容才能提前进入产物。项目配置或环境配置也能启用相同行为，所以只看文章里的标记不足以判断实际发布结果，还必须检查本次构建的有效选项。

本站明确设置了 buildFuture: true，用于保留包含未来日期文章的既有公开目录。因此，本站这些文章的日期不是保密截止时间，也不能用 Hugo 的默认排期规则推断它们尚未公开。修改发布策略之前，需要把配置和预期 URL 清单一起比较，否则关闭一个看似普通的开关，就可能让大量已经存在的地址消失。介绍默认机制与解释本站事实，应当采用各自对应的证据。

预览产物仍然可以被公开

预览开关只改变输出包含什么，不会给产物增加禁止部署的属性。如果流水线上传了用 -D -F 生成的目录，草稿和未来页面一样可以被访问。因此，预览应使用独立输出位置，正式发布则根据计划中的选项重新构建。Git 发布标签只是标识源码历史，既不会改变 Hugo 的包含规则，也不能证明某个生成目录已经经过审阅。交付记录需要关联源码版本、构建选项和实际产物。

按时发布还需要在发布时间之后执行新的构建与部署。反过来，把已经公开的页面重新标记为草稿，也不会撤回服务器上的旧 HTML 或缓存副本。需要重建、替换被服务的产物，再检查公共地址。Hugo 通常不会自动删除输出目录里的所有遗留文件，因此独立的新目录或合适的清洁构建，是证明被排除页面确实不存在的必要步骤。导航里不显示链接，远不足以证明内容已经下线。

坏掉的样子

把预览目录覆盖到发布目录，可能让一篇后来恢复为草稿的文章仍能通过直接地址打开，而索引里已经看不到它。排查应检查生成文件、订阅源、站点地图以及真正对外的页面，区分索引隐藏和文件移除。另一个容易遗漏的规则是：章节页面标记为草稿，并不会自动把所有子页面也变成草稿。若整个子树需要排除，应设置具体子页元数据，或依照文档使用级联配置。

时区差异则可能让两台构建机器从同一个提交生成不同页面。边界测试应固定 Hugo 版本和构建时钟，并记录生效参数。不要在尚未弄清日期解析规则、环境时区和参数来源之前，为了让页面出现而随意改动发布日期。那样可能掩盖配置错误，还会改变订阅顺序和页面展示时间。首先使输入和时钟可重现，才能判断差异真正来自哪里。

快速验证

安装 Python 3 和 Hugo 0.165.0 后，可运行下面的隔离实验。它在临时项目中创建五篇页面，分别构建到八个独立目录，不修改当前仓库，也不执行部署。

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess

with TemporaryDirectory(prefix="hugo-publication-") as directory:
 root = Path(directory)
 (root / "content/posts").mkdir(parents=True)
 (root / "layouts/_default").mkdir(parents=True)
 (root / "hugo.yaml").write_text("baseURL: https://example.org/\n")
 (root / "layouts/index.html").write_text("<h1>Publication test</h1>")
 (root / "layouts/_default/list.html").write_text("{{ .Title }}")
 (root / "layouts/_default/single.html").write_text("{{ .Title }}")
 for name, extra in {
 "visible": "",
 "draft": "draft: true\n",
 "future": "publishDate: 2030-01-01T00:00:00Z\n",
 "future-draft": "draft: true\npublishDate: 2030-01-01T00:00:00Z\n",
 "expired": "expiryDate: 2025-12-01T00:00:00Z\n",
 }.items():
 (root / f"content/posts/{name}.md").write_text(
 f"---\ntitle: {name}\ndate: 2025-01-01T00:00:00Z\n"
 + extra + "---\nPublication fixture.\n"
 )
 cases = [
 ("normal", "2026", [], {"visible"}),
 ("drafts", "2026", ["-D"], {"visible", "draft"}),
 ("future", "2026", ["-F"], {"visible", "future"}),
 ("preview", "2026", ["-D", "-F"], {"visible", "draft", "future", "future-draft"}),
 ("expired", "2026", ["-E"], {"visible", "expired"}),
 ("all", "2026", ["-D", "-F", "-E"], {"visible", "draft", "future", "future-draft", "expired"}),
 ("boundary", "2030", [], {"visible", "future"}),
 ("later", "2031", [], {"visible", "future"}),
 ]
 for name, year, flags, expected in cases:
 destination = root / f"output-{name}"
 subprocess.run(
 ["hugo", "--source", str(root), "--destination", str(destination),
 "--clock", year + "-01-01T00:00:00Z", *flags],
 check=True, capture_output=True, text=True,
 )
 actual = {p.parent.name for p in destination.glob("posts/*/index.html")}
 assert actual == expected, (name, actual, expected)
 print(name, sorted(actual))

断言依次检查默认排除、单独打开各个开关、组合预览，以及时间恰好到达和越过发布边界后的结果。后两次普通构建仍然不包含两篇草稿。未来草稿只有同时使用 -D 和 -F 才会提前出现；-E 则独立包含已过期页面。这证明的是受控条件下 Hugo 的渲染选择，没有覆盖部署调度、CDN 缓存失效，也没有套用本站主动包含未来页面的配置。正式发布时，还需要从本次产物和公共路由分别取得证据，确认生成结果与线上实际一致。

修改发布选项时，应保留普通、未来、草稿、未来草稿和过期五类用例，它们覆盖不同的包含条件。检查本次新生成的文件，不能因为导航里没有链接，就断言被排除的页面肯定不在产物里。

来源

Hugo：基本用法，草稿、未来和失效内容，以及输出目录行为，已核验 2026-09-06。
Hugo：Front matter，发布元数据和级联设置，已核验 2026-09-06。
Hugo 命令参考，内容包含开关和构建时钟，已核验 2026-09-06。

Kubernetes 滚动更新逐步替换 Pod

Sat, 27 Nov 2027 00:00:00 +0000

先选择发布的形状，再调整速度。新旧版本能否同时处理请求？能否安全共享存储和任务所有权？如果新版本起不来，如何恢复？这些问题决定 Deployment 应该用 RollingUpdate 重叠运行，还是用 Recreate 先停旧版、再起新版。姊妹篇讨论滚动的节奏和现场观察；本篇讨论兼容性、停机与恢复边界。

逐步替换，还是先停后起

RollingUpdate 是 Deployment 的默认策略。surge 和 unavailable 两个预算控制替换过程，允许新旧 ReplicaSet 同时存在。就绪状态参与可用副本的计算，但不代表业务逻辑正确，更不代表每个请求都成功。不能因为看到 Ready，就推断订单、支付或后台任务已经通过发布验收。

Recreate 在 Deployment 升级时等待旧 Pod 终止，再创建新版本，因此应计划一段没有可用服务副本的时间。选择这个策略时，要移除 rollingUpdate 配置块；其中的字段只属于滚动更新。停机窗口要通过测量得到，不能顺手把三十秒当成保证。旧进程退出慢、新镜像下载慢、存储挂载慢，都可能拉长用户实际感受到的中断。

兼容性才是选择依据

允许版本重叠，意味着接口、持久化数据以及后台工作都能兼容。前端健康检查可能正常，旧 worker 却读不懂新 worker 刚写入的记录。调整副本数之前，应测试混合版本的读写、任务领取和重试行为。副本预算能安排进退顺序，不能修复不兼容的数据库结构变化。

有状态并不自动意味着必须选择 Recreate：协调正确的副本式应用，也可能支持新旧版本同时运行。反过来，Recreate 不是分布式锁。它的先停后起约束适用于 Deployment 升级；如果人工删除一个 Pod，ReplicaSet 可能在旧 Pod 仍处于终止状态时创建替代者。真正的单写者需要应用层协调，必要时还要有隔离旧所有者的机制，确保失去资格的进程不能继续写入。不能把发布策略当成这种机制的替代品。

存储术语也不能混淆。ReadWriteOnce 限制的是一个节点以读写方式挂载，并不等于只能有一个 Pod；同一节点上的多个 Pod 仍可能使用同一卷。对于支持的 CSI 卷，ReadWriteOncePod 才提供单 Pod 访问约束。应检查实际驱动、卷的访问模式与工作负载需求，而不是看到一个存储标签，就认定已经解决了所有权问题。

回滚也是一次变更

保留可以重新启动的旧镜像和修订历史。kubectl rollout undo 恢复记录过的 Pod 模板；只把镜像地址改回去，可能漏掉已经变化的启动参数或环境引用。这两种操作都不会撤销数据库迁移，也不会恢复独立修改过的 ConfigMap 内容。旧模板继续引用同一个 ConfigMap 名称时，重新启动的旧程序仍可能读到新数据。

发布前要记录镜像、配置和数据结构之间的兼容关系。如果需要混合运行或回退，应优先安排向后兼容的迁移顺序。恢复流程必须演练，包括谁执行、按什么顺序做、需要多久，以及如何判断旧版已经恢复业务。只留着旧 ReplicaSet，不能证明恢复是安全的。使用 Recreate 时，回到旧版也可能再经历一次停机和启动；恢复时间不能只按正常升级的一半估算。

坏掉的样子

没有正确协调的 worker，可能在所有 Pod 都 Ready 时重复执行任务或破坏数据。此时需要检查任务所有权与版本兼容性，而不只是看容器是否健康。另一类故障是 Recreate 的冷启动超出预算：镜像拉取或卷挂载很慢，应用真正开始启动之前，停机时间就已经被耗尽。因此演练要包含真正的冷启动和旧版退出耗时，不能只测缓存齐全时的进程启动。

四个副本设置 maxUnavailable: 50%，预算允许减少到两个可用副本，不会自动变成一个。新替代 Pod 崩溃可能让进度停滞；另外发生的节点故障等独立事件，才可能把现有容量继续压低。决定采用这个预算之前，先验证两个实例能否承担预期流量，而不是把「更新仍在允许范围内」等同于业务容量足够。

零 unavailable 也无法防止无关故障。另一个极端是允许全部副本不可用：这样的配置可以合法存在，只是通常不符合服务目标。若团队要禁止它，应明确这是自己的发布政策，而不是 Kubernetes API 的校验规则。真正不能同时为零的是 surge 和 unavailable，否则替换过程没有可推进的空间。

快速验证

把下面保存为 strategy_window.py，运行 python3 strategy_window.py。这是只使用标准库的本地模型，仅接受正整数副本数与非负整数预算。它计算规划量，不模拟控制器，也不是完整的 API 校验器；百分比换算、自动扩缩容和副本数为零的情况不在这个模型内。Kubernetes 允许把 Deployment 缩容到零；程序拒绝它，只因为本练习讨论的是有副本需要替换的场景。

"""Integer rollout-budget arithmetic; no cluster or traffic is exercised."""


def rolling_budget(replicas, surge, unavailable):
 values = (replicas, surge, unavailable)
 if any(type(value) is not int for value in values):
 raise ValueError("this model accepts integers only")
 if replicas <= 0 or surge < 0 or unavailable < 0:
 raise ValueError("positive replicas and nonnegative budgets required")
 if surge == 0 and unavailable == 0:
 raise ValueError("surge and unavailable cannot both be zero")
 planned_floor = max(0, replicas - unavailable)
 target_ceiling = replicas + surge
 return planned_floor, target_ceiling


def main():
 assert rolling_budget(6, 1, 1) == (5, 7)
 assert rolling_budget(4, 0, 2) == (2, 4)
 assert rolling_budget(4, 1, 4) == (0, 5)
 for invalid in [(4, 0, 0), (4, -1, 1), (0, 1, 0)]:
 try:
 rolling_budget(*invalid)
 except ValueError:
 pass
 else:
 raise AssertionError(f"invalid model input accepted: {invalid}")
 print("rolling: planned availability floor=5, replica target ceiling=7")
 print("full-unavailability budget: planned floor=0 (permitted)")
 print("recreate: expect a zero-serving interval during replacement")
 print("PASS: budget arithmetic only; runtime availability untested")


if __name__ == "__main__":
 main()

预期输出四行，最后一行明确写着只通过预算算术、未测试运行时可用性。六副本、一 surge、一 unavailable 的结果是五和七；允许四个副本全部不可用的例子，故意得到零，而不是抛出「非法配置」。两项预算同时为零、负预算、零副本等不属于本模型有效输入的情况，则通过断言检查拒绝路径。

正在终止的 Pod、独立故障、调度以及真实请求处理都没有进入模型。因此，五不是实际观测到的服务能力下限，七也不是所有运行进程的绝对上限。程序只帮助检查算术和策略假设，不能给线上可用性出具证明。把数字换成自己的副本配置之前，也要先处理百分比和实际需求变化，而不是直接复制结论。

本次修订在 Linux 的 Python 3.12.14 中执行了断言，没有执行 Kubernetes 集成实验。采用某个策略前，应在测试环境演练升级和回滚，同时持续发请求、检查存储使用，并运行混合版本业务测试。把这些现场结果与本地算术结果分开记录，才知道哪些结论有真实环境的证据支持，哪些还只是规划假设。

来源

Kubernetes Deployment，升级顺序与修订回退，已核验 2026-10-15。
Deployment API，策略字段与更新预算，已核验 2026-10-15。
Kubernetes 持久卷，节点级与 Pod 级访问模式，已核验 2026-10-15。
Kubernetes ConfigMap，配置引用与传播，已核验 2026-10-15。
Kubernetes StatefulSet 删除注意事项，身份与重复进程风险，已核验 2026-10-15。

镜像标签可以移动，既有容器仍保留原先选择的镜像

Tue, 24 Aug 2027 00:00:00 +0000

镜像标签是与镜像引用关联的可读名字。如果仓库策略没有禁止重新指派，同一个标签之后可以标识另一个产物。v1.4 和 latest 的区别首先是命名惯例，而不是前者天然不可变。要复现部署，需要记录实际选择的产物，以及影响行为的平台和运行配置。只保存一个看起来像版本号的名字，并不足以证明当时运行的是哪些内容。

坏掉的样子

latest 不会要求仓库寻找最新上传镜像或最高语义版本，它是在引用省略标签时采用的惯例默认值。发布另一个版本，不会自动移动 latest；必须有人或自动化更新这个具体引用。如果把每次 push 都解释成自动更新 latest，就会错误理解发布流程，甚至误判为什么一个节点仍然取得旧版本。

标签的本地解析结果，也可能不同于仓库当前结果。拉取策略、本地镜像是否存在，以及编排工具的行为，共同决定何时查询仓库。因此，两台机器运行相同可读标签，仍可能使用不同产物。仅记录命令文本，会留下实际取回什么、是否保留缓存引用等不确定性；排查时应读取所选产物身份。

移动标签不会改写已经创建的容器所选择的镜像。重启该容器，会保留原配置的镜像和可写状态，不会按照标签的新目标重新创建实例。如果更新流程只是重新打标签，然后 restart 旧容器，命令可能成功，应用却仍运行旧内容。标签更新、容器替换和容器重启需要分别判断，不能混成同一个动作。

快速验证

先取得固定基础镜像，再用 Python 和 Docker 构建器运行脚本。实测环境是 Docker 29.3.1、Linux arm64。所有标签使用独特的本地名字，不向仓库推送任何内容；容器关闭网络，清理只删除实验自己的容器与标签。因此可以实际验证移动行为，又不改变已有发布引用：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def inspect(name,kind='image'):return json.loads(docker(kind,'inspect',name).stdout)[0]

name='xbcatm-tags-'+uuid.uuid4().hex[:10];tags=[name+':one',name+':two',name+':release',name+':latest'];container=name+'-old'
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory)
 (root/'Dockerfile').write_text(f'FROM {BASE}\nCOPY version.txt /version.txt\nCMD ["cat", "/version.txt"]\n')
 for tag,version in zip(tags,['one','two']):
 (root/'version.txt').write_text(version+'\n');docker('build','--network','none','-t',tag,str(root))
 one=inspect(tags[0])['Id'];two=inspect(tags[1])['Id'];assert one!=two
 docker('image','tag',tags[0],tags[2]);docker('image','tag',tags[0],name)
 assert inspect(tags[2])['Id']==inspect(tags[3])['Id']==one
 docker('create','--name',container,'--network','none',tags[2])
 docker('image','tag',tags[1],tags[2])
 assert inspect(tags[2])['Id']==two and inspect(tags[3])['Id']==one
 assert inspect(container,'container')['Image']==one
 assert docker('start','--attach',container).stdout.strip()=='one'
 assert docker('run','--rm','--network','none',tags[2]).stdout.strip()=='two'
 assert docker('run','--rm','--network','none',tags[3]).stdout.strip()=='one'
 print('moving release changes newly created containers; the existing container still runs its original image')
 print('omitting a tag selected latest, but updating release did not update latest')
 docker('image','rm',tags[2]);assert inspect(tags[1])['Id']==two
 print('removing one tag leaves another reference to the same image intact; all operations stayed local')
finally:
 docker('rm','-f',container,check=False);docker('image','rm',*tags,check=False)

脚本构建两个镜像，/version.txt 分别包含 one 与 two，镜像身份不同。它先让 release 指向第一份镜像，再用没有显式标签的仓库名标记同一镜像。检查确认，省略标签会得到 latest，而这两个引用最初都选择第一份镜像。这里直接验证默认标签规则，不靠名字含义猜测。

移动 release 之前，脚本从该引用创建一个容器，但暂不启动。随后把 release 移到第二份镜像。此时 release 选择新产物，latest 仍选择第一份。实验把标签重新指派与默认标签惯例分开，说明相关名字不会自动一起移动；如果生产流程会同时更新多个标签，那是流程自身明确执行的行为。

启动先前创建的容器，输出 one；从 release 新建容器，输出 two；从 latest 新建容器，则输出 one。容器检查也保留最初所选的镜像身份。这些断言对照实际运行结果，因此不只是根据标签表的显示推理。尤其是“创建后尚未运行”的旧容器，仍然不会因标签移动而更换镜像。

删除 release 标签后，第二份镜像仍通过 two 标签可用。标签是引用，删除一个引用，不一定删除共享内容或所有其他名字。实际回收取决于剩余引用和引擎存储规则；本实验不会清理构建缓存，也不测量物理空间回收。不能把取消一个标签直接当作磁盘上的全部层已经消失。

实验比较当前引擎返回的身份，但不假定 inspect 的 Id 在所有版本和存储方式下都等于 OCI 配置摘要。现代镜像存储可能暴露不同对象层次。仓库索引、平台清单、镜像配置和层数据，各自都有摘要，所以说明身份时应保留对象类型与引用上下文。相同哈希格式不能代替对象含义。

提升经过测试的同一产物

通过仓库部署时，从发布流程记录带仓库名的摘要引用。摘要可能标识包含多个平台清单的镜像索引，因此仍要选择预期平台。保留对应产物及其必需数据，才能让后续回滚真正拉取成功；单独保存哈希无法恢复已经不可取得的内容。产物身份确定与产物持续可用，是不同的要求。

标签可以继续用于人类查找。如果发布流程承诺版本标签永不移动，就应配置并验证仓库的不可变策略，而不是看到版本形状就认定承诺成立。固定摘要也不会证明作者是谁或软件安全，来源证明与行为验证分别回答这些问题。内容寻址解决的是选择哪份对象，不会替代整个发布审查。

部署后，把运行工作负载选择的产物及其预期行为，与发布记录逐一对照。标签已更新、拉取成功和容器正在运行，是三个独立观察。只有把它们连接到同一份通过验证的产物，才能确认本次发布真正生效，而不是仅仅完成了若干看起来相关的命令。

来源

Docker image tag，本地标签创建与默认 latest 标签，已核验 2026-09-12。
Docker image pull，按标签或摘要拉取仓库产物，已核验 2026-09-12。
OCI image index 1.1.1，索引引用不同平台镜像清单的结构，已核验 2026-09-12。
OCI image manifest 1.1.1，清单对配置与层对象的引用，已核验 2026-09-12。

git tag 把一次发布固到提交

Fri, 11 Jun 2027 00:00:00 +0000

发布标签为某个源码版本提供一个容易交流的名字。它与分支不同，创建新提交时不会自动前进。但 Git 并没有从物理上禁止标签变化：拥有相应权限的人仍能替换或删除标签引用。可靠的发布约定来自几件事共同作用：记录对象标识、坚持发布名称不可变，以及限制谁能够更新发布引用。不能仅凭“用了标签”就断言任何人拿到的代码一定相同。

两种标签

轻量标签是直接指向某个对象的引用，通常指向提交。附注标签则指向单独的标签对象，其中保存目标、打标签者身份、时间、说明，以及可选的签名。打标签的人并不一定是提交作者；有了这些元数据，也不意味着附注已经经过密码学签名。发布记录需要说明谁作出发布决定，而不是把提交作者与发布者混为一谈。

对于附注标签，git rev-parse refs/tags/v2.4.1 得到标签对象标识，git rev-parse 'refs/tags/v2.4.1^{commit}' 则解引用到目标提交。当说明或签名身份也是发布证据的一部分时，应同时记录二者。只比较提交会漏掉标签留言或签名者变化；只比较可读名称，则连源码是否一致也无法确定。对象标识与名称各自承担不同的核对职责。

为什么给发布签名

git tag -v 使用配置的签名后端及本地信任材料验证签名标签。密码学验证成功之后，还需要确认该密钥确实属于项目发布策略认可的人。一个陌生人的有效签名，并不能证明维护者批准了这次发布。密钥的来源、授权范围和撤销状态，都应由实际发布流程明确管理，而不是靠命令里出现“成功”两个字代替。

源码标签有签名，也不能直接证明下载的二进制就是从该源码构建的。制品校验和、构建来源记录及构建过程，需要补上这条独立关系。另外，不要把验签命令接到 head 后面，再依赖管道最后一项的退出码：只截取几行输出可能掩盖验签失败。发布检查应保留并判断验签命令自身的结果，显示多少行只是界面选择。

移动要格外小心

修正尚未分享的本地标签，与替换消费者已经获取的标签，是两种不同操作。标签一旦分发，应优先使用新版本名称，并记录旧版本被撤回的原因。修补安全缺陷也不要求重写旧标签；保留原引用反而有助于识别受影响部署。服务端的引用保护应阻止未经授权的发布标签更新与删除，不能只靠客户端的习惯维持这个约定。

如果特殊情况下确实批准替换，应公布准确的新旧对象标识，并只协调那个明确的引用。把所有标签一起强制获取，会覆盖其他无关的本地引用，不应成为常规修复建议。消费者需要知道自己持有的是哪一个对象，不能让两个不同提交在没有说明的情况下继续共享同一个发布名称。

坏掉的样子

latest 这类浮动名称可能在两次构建之间解析到不同提交。即便界面保留方便阅读的名字，也应为每个制品和每次部署记录真正解析到的提交标识。同名不保证两次构建一致，而固定提交也不会自动固定外部依赖或编译器版本。源码定位与可复现构建有关，却不能互相替代。

另一种故障是发布标签只存在于某个本地克隆。普通分支推送不一定传输它；--follow-tags 处理的是从推送提交可达、符合条件的附注标签，不是本地全部标签。应使用 git ls-remote --tags 核对准确的远端引用及对象标识，不能对版本号作模糊子串匹配，否则可能把另一个版本当成目标。远端可见只能证明分发，不能证明构建正确或签名可信。

快速验证

在 POSIX 系统上用 Python 3 及 Git 运行下面的实验。它创建独立临时仓库，使用示例身份，为演示明确关闭签名，并且不配置远端。所有提交和标签都位于这个临时仓库，不会给当前项目打标签；退出后由临时目录管理器清理。命令通过参数列表调用，不需要拼接或解释来自外部的 Shell 文本。

import os
import subprocess
import tempfile

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-tag-demo-") as directory:
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Tag Example",
 "-c", "user.email=tags@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "tag.gpgsign=false",
 "-c", "core.hooksPath=/dev/null", *args],
 cwd=directory, env=env, text=True, capture_output=True, check=check,
 )

 git("init", "-q")
 git("commit", "--allow-empty", "-qm", "first")
 first = git("rev-parse", "HEAD").stdout.strip()
 git("tag", "-a", "demo-v1", "-m", "example release")
 git("tag", "demo-bookmark")
 print("annotated:", git("cat-file", "-t", "demo-v1").stdout.strip())
 print("lightweight:", git("cat-file", "-t", "demo-bookmark").stdout.strip())
 git("commit", "--allow-empty", "-qm", "second")
 target = git("rev-parse", "demo-v1^{commit}").stdout.strip()
 print("tag-still-first:", target == first)
 print("head-moved:", git("rev-parse", "HEAD").stdout.strip() != first)
 duplicate = git("tag", "demo-v1", check=False)
 print("existing-name-refused:", duplicate.returncode != 0
 and git("rev-parse", "demo-v1^{commit}").stdout.strip() == first)
 verification = git("tag", "-v", "demo-v1", check=False)
 print("unsigned-rejected:", verification.returncode != 0)

开头应分别输出对象类型 tag 和 commit，随后四个判断都为真。新提交让分支前进，但标签仍指向第一个提交；不带强制选项复用既有名称会失败，目标保持不变。这项本地保护与服务端引用保护不同。未签名的附注会验签失败。这个实验有意不把“标签存在”冒充“可信签名”或“远端已经发布”：后两项仍需要项目实际认可的密钥策略，以及对真实远端引用的准确检查。

来源

git tag 参考，标签对象及替换已分发标签的影响，已核验 2026-10-15。
Git 打标签基础，轻量与附注标签及共享行为，已核验 2026-10-15。

滚动更新分批换上新版本

Mon, 07 Jun 2027 00:00:00 +0000

滚动更新是一种受控替换，不是服务绝不中断的承诺。它的价值在于引入新副本时可以保留部分旧副本；用户能否平稳完成请求，还取决于资源余量、健康检查是否可信，以及应用如何退出。本文讨论已经选择滚动更新之后怎样调节节奏、怎样观察过程；姊妹篇讨论更靠前的问题：两个版本到底能不能同时运行。

浪涌与缺口

十个期望副本，配 maxSurge: 2，更新目标上限是十二，不是十一。maxUnavailable: 1 给控制器的可用性预算是九个。这不是「每一波最多删除一个旧 Pod」：只要已经有足够的新副本可用，控制器就能继续撤掉多个旧副本。正在终止的 Pod 还可能保留一段时间并继续消耗资源，因此十二也不是所有 Pod 对象或进程数量的绝对上限。

百分比必须先换算整数：surge 向上取整，unavailable 向下取整。三个副本使用默认的百分之二十五，实际就是一个 surge、零个 unavailable。这里有一个边界例外：surge 为零、非零的 unavailable 百分比却向下取成零时，控制器会把有效 unavailable 调整为一，让替换能够推进。因此，不能从这个换算得到的零，推断更新一定不会主动减少可用副本。

两个参数都不会替你预留节点资源。选择速度之前，要把资源请求量与可调度容量、命名空间配额、放置约束以及旧 Pod 的退出耗时一起检查。账面上多出的两个位置，并不一定真有节点能承接；新 Pod 全部 Pending 时，调大 surge 也不会凭空生出机器。

健康是换班的门槛

首先确认清单中确实配置了就绪探针。就绪检查应该回答「这个实例现在能否处理预期的流量」。只检查端口监听可能漏掉应用故障；检查必要的后端依赖可能更准确，但共享依赖短暂失败也可能让全部副本一起退出就绪状态。是否应该停止接流量，要根据业务的降级能力决定，而不是机械地把所有依赖都塞进探针，更不能一看到失败就放宽条件。

minReadySeconds 要求新 Pod 持续就绪一段时间，之后才计入 Deployment 的可用副本。它不会把 Service 流量也延迟到这段时间结束。启动慢的容器可以用 startup probe，避免还在初始化就被存活检查重启。这些检查仍不能证明订单处理正确，也不能证明实例能持续承受生产负载。

退出过程需要单独验证。端点状态传播、旧连接排空、应用处理终止信号、终止宽限期必须配合。应用即使一直把就绪端点返回成功，也可能在退出时丢掉正在处理的请求。把「Pod 数量看起来充足」当成「用户请求没有失败」，会漏掉这一整类问题。

选一个有意为之的节奏

对于有额外容量的小规模服务，一个 surge、零个 unavailable 是可以考虑的起点。它限制更新过程主动削减可用副本，却不能阻止节点故障、依赖故障或请求错误。PodDisruptionBudget 也不会约束 Deployment 自己执行的滚动升级；不要把节点维护时的驱逐保护，误当成应用发布的额外保险。

人工暂停适合停下来检查，但它不是精确的单 Pod 金丝雀发布，也不锁定固定的流量比例。暂停生效前，控制器可能已经推进；暂停后，现有副本仍会运行并接流量。如果要求新版严格只接少量流量，就需要独立控制的金丝雀副本与路由。发布前应写明错误率、延迟、重启和关键业务检查的通过线，并规定完成后的观察时长，不能等看见曲线才临时决定标准。

坏掉的样子

滚不完时，先找故障发生在哪一层。调度事件指向资源或放置问题；拉取镜像失败指向镜像引用或仓库访问；容器日志与探针事件用来区分进程崩溃和就绪失败。先确认探针是否准确发现了故障，再决定要修应用、修配置，还是修检查本身。仅凭一个超时就降低健康标准，可能把尚未承接流量的错误推进到全量。

坏版本可能先消耗允许的不可用额度，然后才停滞，并不保证旧副本全部留下。progressDeadlineSeconds 会报告进度停滞，但不会自动回滚，也不会把所有协调动作冻结。应为该条件配置告警，再根据证据决定修复或回退。滚动顺利结束也不等于业务验收完成：慢内存泄漏、连接耗尽与真实流量下的错误，可能在后续观察期才出现。观察通过以前，应保留可用的修订历史和旧镜像，并确认旧版仍能启动。

快速验证

把下面的标准库练习保存为 rounding_window.py，运行 python3 rounding_window.py。程序用整数算术检查百分比换算，包括小规模副本、恰好整除的边界以及百分之百。它不是 Deployment 控制器模拟器，也不是完整的 API 校验器；不能把函数接受的所有输入都理解为有效的发布配置。百分之零到百分之一百的输入范围只是本练习的限制，并不是 maxSurge 的 API 上限。

"""Check percentage rounding only; no Kubernetes API calls."""


def round_percent(replicas, percent, *, up):
 if type(replicas) is not int or replicas <= 0:
 raise ValueError("this exercise requires positive integer replicas")
 if type(percent) is not int or not 0 <= percent <= 100:
 raise ValueError("this exercise accepts integer percentages 0..100")
 numerator = replicas * percent
 return (numerator + 99) // 100 if up else numerator // 100


def main():
 cases = [(1, 1, 0, 1), (3, 25, 0, 1), (4, 50, 2, 2),
 (10, 20, 2, 2), (10, 10, 1, 1), (4, 100, 4, 4)]
 for replicas, percent, down, up in cases:
 assert round_percent(replicas, percent, up=False) == down
 assert round_percent(replicas, percent, up=True) == up
 print(f"replicas={replicas}, percent={percent}: down={down}, up={up}")
 print("PASS: percentage rounding only; no cluster exercised")


if __name__ == "__main__":
 main()

预期先输出六行案例，再输出一行明确限定为百分比换算的 PASS。三个副本乘百分之二十五，向下取整为零、向上取整为一；十个副本乘百分之二十，两种方向都是二。百分之百的案例确认换算结果可以覆盖全部副本，并不因服务目标不允许停机就自动变成数学错误。本次修订在 Linux 的 Python 3.12.14 中执行了这些断言。通过只证明算术一致，没有证明服务可用性。

把数字用到真实发布前，先选择正确的测试集群上下文与命名空间，并确认 Deployment 实际配置。如果已有 api Deployment、Pod 标签为 app=api，可用 kubectl rollout status deployment/api --timeout=120s 观察收敛，在另一个终端用 kubectl get pods -l app=api -w 观察替换。客户端等待超时，只表示命令不再等待，并没有取消更新。如果可能同时发起多个版本，使用 --revision=N 指定要检查的修订号。观察结束时按 Ctrl-C。

这里没有执行这些集群命令。仍需在测试环境升级期间收集 Pod 事件、日志和 Deployment 状态，同时持续从真实 Service 或入口路径发请求，把错误和退出期间的延迟一起记录。事件中的对象名称、发生时间要与这次发布对应，不能把其他服务的故障当成当前更新的证据。这些才是尚待完成的集成验证；只看最终成功的一行输出，无法证明零停机。

来源

Kubernetes Deployment，更新预算、就绪时间、暂停与进度条件，已核验 2026-10-15。
Kubernetes 探针，启动、存活与就绪检查的职责，已核验 2026-10-15。
Kubernetes Pod 生命周期，终止流程与连接排空，已核验 2026-10-15。
Kubernetes 资源管理，资源请求与调度容量，已核验 2026-10-15。
Kubernetes 干扰，PodDisruptionBudget 在滚动升级中的边界，已核验 2026-10-15。
kubectl 命令参考，更新状态与客户端超时，已核验 2026-10-15。
Kubernetes 控制器的取整实现，固定版本的 ResolveFenceposts 对两个取整结果都为零的处理，已核验 2026-10-15。

让已经验证的产物逐级进入环境

Wed, 17 Feb 2027 00:00:00 +0000

预发布测试说明的是当时实际运行的产物与环境。生产部署前重新构建，会得到另一份输出，需要检查它的身份，或者重新验证它的行为。产物晋级指把已验证的那份文件继续交给下一个环境，并记录这次决定。它减少了一类不确定性，但不会让预发布与生产环境自动等价，也不会免除部署之后的运行检查。交付字节一致，是发布判断的一部分，而不是全部。

明确究竟把什么向前传递

使用不可变的软件包标识或内容摘要定位构建结果。会移动的标签、分支名乃至源码提交，本身都不足以唯一证明部署了哪些字节。同一源码的两次构建，可能因为工具链、依赖解析、嵌入设置或打包步骤而不同。可复现的重建确实可能得到完全相同的字节，但应先比较结果，再把它视为之前通过测试的同一产物，而不是仅凭源码相同推断。

应区分构建阶段与发布阶段。发布组合包含特定产物及该部署需要的配置，运行过程再把这个组合放到真实依赖和数据之上。记录产物身份与合适的配置版本，同时避免泄露秘密。如果前端环境设置在打包时直接编译进 JavaScript，修改设置就会改变字节，也就是生成了另一份需要验证的产物。不能一边修改包内内容，一边继续沿用原包通过测试的身份。

坏掉的样子

某些流水线名义上在晋级产物，部署脚本却悄悄重新编译；另一些流程下载了正确归档，却又覆盖归档内部的配置文件。这两种操作都改变了测试时的输入。应明确哪些设置位于不可变负载之外，并通过应用已有的配置接口读取。校验和如果发生在后续修改之前，就不能继续代表运行时文件；核验时点与文件变化顺序必须一起审查。

即便产物相同，数据库结构、功能开关、依赖版本、权限、资源限制或网络路径变化，也能让行为不同。晋级保证的是字节连续性，不是整个执行上下文都一致。部署后仍要验证关键生产行为；预发布结果无法在生产重现时，要比较真正相关的环境差异，而不是看到摘要相同就认定问题与发布无关。配置也是发布组合的一部分，需要可追溯的变化记录。

回滚同样有前提。旧程序可能无法理解新写入的数据，或者无法适应已经完成的破坏性结构迁移。把指针切回旧产物，并不会撤销这些外部影响。恢复说明应关联数据兼容性、配置和依赖状态；不能反向恢复时，就应准备必要的向前修复。不能把“重新选择旧镜像”描述成所有故障都适用的完整回滚方案。

快速验证

把代码保存为 promote.py，执行 python3 promote.py。示例只使用 Python 标准库、临时目录和绑定回环地址的 HTTP 服务。它写出一份很小的应用文件，记录摘要，再复制进两个本地环境。production-simulation 只是临时目录的标签，不会触发外部部署，也不会接触真实生产配置。这个命名用于让输出清楚地区分两个运行位置。

from hashlib import sha256
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from pathlib import Path
from tempfile import TemporaryDirectory
from threading import Thread
from urllib.request import ProxyHandler, build_opener
import json
import runpy
import shutil

source = 'def render(config):\n return {"build": "local-build-41", "tier": config["tier"]}\n'
digest = sha256(source.encode()).hexdigest()


def verify(path):
 if sha256(path.read_bytes()).hexdigest() != digest:
 raise ValueError('artifact changed')


def handler(path, config):
 verify(path)
 render = runpy.run_path(str(path))['render']

 class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 data = path.read_bytes() if self.path == '/artifact' else json.dumps(render(config)).encode()
 self.send_response(200)
 self.send_header('Content-Length', str(len(data)))
 self.end_headers()
 self.wfile.write(data)

 def log_message(self, *args):
 pass

 return Handler


with TemporaryDirectory() as directory:
 root = Path(directory)
 artifact = root / 'build.py'
 artifact.write_text(source)
 opener = build_opener(ProxyHandler({}))
 observed = []
 for tier in ('staging-local', 'production-simulation'):
 destination = root / tier
 destination.mkdir()
 deployed = destination / 'app.py'
 shutil.copyfile(artifact, deployed)
 config = {'tier': tier}
 server = ThreadingHTTPServer(('127.0.0.1', 0), handler(deployed, config))
 thread = Thread(target=server.serve_forever)
 thread.start()
 try:
 origin = f'http://127.0.0.1:{server.server_port}'
 with opener.open(origin + '/artifact', timeout=5) as response:
 received_digest = sha256(response.read()).hexdigest()
 with opener.open(origin + '/', timeout=5) as response:
 rendered = json.load(response)
 assert received_digest == digest
 assert rendered == {'build': 'local-build-41', 'tier': tier}
 observed.append({'artifact_sha256': received_digest, 'response': rendered,
 'config_sha256': sha256(json.dumps(config, sort_keys=True).encode()).hexdigest()})
 finally:
 server.shutdown()
 thread.join()
 server.server_close()
 deployed.write_text(source + '# rebuilt\n')
 try:
 verify(deployed)
 except ValueError:
 changed_rejected = True
 else:
 changed_rejected = False
 assert changed_rejected
 print(json.dumps({'environments': observed, 'changed_copy_rejected': changed_rejected}))

每个服务启动之前，脚本都核对复制文件是否符合原始摘要，再加载其中的应用函数。请求 /artifact 会返回部署文件的真实字节；请求 / 则用该环境单独提供的配置执行应用函数。两次 HTTP 下载得到相同的产物摘要，两份应用响应也都声明 local-build-41。这些结果结合文件复制与实际请求，建立了本地传递的证据。

响应中的环境标签不同，记录的配置摘要也不同；这里的配置仅包含无害标签。它说明同一份应用字节可以因为明确的配置输入而产生不同输出。服务停止后，脚本再修改一份副本，同样的摘要检查会拒绝它，因而这道身份门禁能够发现示例中的静默重建。不能把摘要检查称为功能测试，二者分别验证不同性质。

本实验没有模拟注册仓库、认证、数据库迁移、真实生产流量或回滚，只覆盖本地文件传递、校验、独立配置以及 HTTP 结果。它也不能证明某个真实部署系统已经遵循相同规则。把范围写清楚，才能让读者理解哪些步骤可直接观察，哪些发布条件仍需要结合自己的系统另行验证。

核对真正运行的发布组合

把晋级决定关联到产物与配置版本，然后检查已部署进程或实际服务的文件，不能只依赖上传成功。为需要的恢复窗口保留批准过的原产物。如果后续阶段生成了另一份软件包，应为新输出分配新的身份，并执行与变化相关的验证。可用的晋级记录，应能够回答传递了哪些字节、带了哪份配置，以及传递之后实际观察到了什么行为。

来源

The Twelve-Factor App: build, release, run，区分构建产物、发布组合和运行过程，已核验 2026-09-13。
The Twelve-Factor App: config，随部署环境变化的配置，已核验 2026-09-13。

语义化版本让兼容性承诺更明确

Sat, 13 Feb 2027 00:00:00 +0000

依赖版本有价值的前提，是发布者与使用者对公共契约有共同认识。语义化版本为变化提供一套表达：从 1.0.0 开始，不兼容的公共接口变化需要提升主版本，兼容的功能增加需要提升次版本，兼容的问题修复需要提升补丁版本。数字归纳的是发布者对这一版的判断，并不会自行检查实现，也不能保证应用升级之后必然正确运行。理解承诺边界，比只记住三个数字更有用。

先声明兼容性覆盖哪些内容

公共接口可以包括导出的函数、正式说明的命令参数、配置格式、响应字段和明确约定的错误行为。边界应写得足够清楚，才能判断一次变化是否违约。保持契约不变的内部重构，与删除已经承诺支持的参数，不属于同一类变化。修正原先违反文档契约的行为，可能仍是兼容的缺陷修复，即便有人曾经观察并依赖那个错误表现。仍需在变更说明中解释，并验证受影响的调用方。

语义化版本规范要求：把公共功能标记为废弃时，应提升次版本；之后真正移除功能，则需要按不兼容变化处理。已经发布的某个版本，其内容不应继续变化，修正应通过另一个新版本交付。在相同版本标签背后替换文件，会破坏追溯：两个依赖声明完全相同的安装过程，可能得到不同的字节，排查问题时也无法再靠版本号明确区分。

主版本为零表示初始开发阶段，公共接口不应被视为稳定。维护者可以为这一阶段声明额外约定，但使用者不能默认所有零主版本更新都兼容。预发布版本的优先级低于对应的正式版本；加号之后的构建元数据不参与优先级比较。因此，两个版本在排序意义上相等，不意味着它们的包内容、来源或文件摘要相同。兼容性、选择顺序与产物身份是不同问题。

坏掉的样子

标错的次版本即使满足依赖范围，也可能破坏已声明的契约。标号正确的发布，也可能暴露应用对内部实现细节的依赖。升级时仍应读变更说明，运行有代表性的集成验证；需要重复解析依赖时保留锁文件。锁文件记录当时选择了哪些版本，不能替这些版本证明行为正确，更不是来源真实性的证明。版本范围允许安装，只说明解析条件满足了。

包管理器的范围语法又是另一层规则。语义化版本规范定义版本及优先级，具体工具决定约束怎样筛选候选。在 node-semver 中，插入符通常允许最左非零分量右侧的变化，所以 ^0.2.3 不接受 0.3.0，^0.0.3 也不接受 0.0.4。三个分量完整的波浪号范围，通常只允许同一次版本线内的补丁更新。不能把所有插入符都理解成“只要主版本不变就行”。

预发布筛选还有附加规则。宽泛的稳定版本范围，不会自动接纳数值更高的测试版；明确允许某个预发布三元组后，才可能接纳该三元组后续的预发布版本。应验证实际解析器，而不是用普通字符串排序推断升级关系，也不要把数值更大直接等同于可被当前范围选择。不同生态的约束语法不能仅凭相似外观相互套用。

快速验证

本轮安装尝试在解析器断言执行之前以失败状态退出；这里没有把现有其他版本库的行为算成该固定版本示例的通过证据。

将代码保存为 semver.py，在已有 Node 和 npm 的环境执行 python3 semver.py。实验需要访问公共 npm 仓库。脚本在临时目录安装 semver@7.7.2，隔离配置和缓存，关闭包安装脚本，再调用这个库真实的比较函数。它不会修改当前项目的依赖声明或锁文件；结束时临时安装目录随上下文清理。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import subprocess

with TemporaryDirectory() as directory:
 root = Path(directory)
 user_config = root / 'user.npmrc'
 global_config = root / 'global.npmrc'
 user_config.write_text('')
 global_config.write_text('')
 env = {'PATH': os.environ['PATH'], 'LC_ALL': 'C',
 'NPM_CONFIG_USERCONFIG': str(user_config),
 'NPM_CONFIG_GLOBALCONFIG': str(global_config),
 'NPM_CONFIG_CACHE': str(root / 'cache')}
 subprocess.run(['npm', 'install', '--ignore-scripts', '--no-audit', '--no-fund',
 '--package-lock=false', '--registry=https://registry.npmjs.org',
 'semver@7.7.2'], cwd=root, env=env, check=True, capture_output=True)
 script = r'''
const s = require('semver');
const assert = require('node:assert/strict');
const cases = [
 ['1.9.0', '^1.2.3', true], ['2.0.0', '^1.2.3', false],
 ['1.2.9', '~1.2.3', true], ['1.3.0', '~1.2.3', false],
 ['0.2.9', '^0.2.3', true], ['0.3.0', '^0.2.3', false],
 ['0.0.4', '^0.0.3', false], ['1.3.0-beta.1', '^1.2.3', false],
 ['1.3.0-beta.2', '^1.3.0-beta.1', true]
].map(([version, range, expected]) => {
 const accepted = s.satisfies(version, range);
 assert.equal(accepted, expected);
 return {version, range, accepted};
});
assert.equal(s.compare('1.2.3+build.1', '1.2.3+build.2'), 0);
assert.equal(s.lt('1.3.0-beta.2', '1.3.0'), true);
assert.equal(s.valid('1.02.3'), null);
console.log(JSON.stringify({library: require('semver/package.json').version, cases,
 metadata_precedence_equal: true, prerelease_before_release: true, leading_zero_rejected: true}));
'''
 result = subprocess.run(['node', '-e', script], cwd=root, env=env,
 capture_output=True, text=True, check=True)
 print(json.dumps(json.loads(result.stdout)))

九个范围案例应当全部符合断言：^1.2.3 接受 1.9.0，拒绝 2.0.0；波浪号拒绝下一次版本；两个零主版本范围更加收敛。稳定范围拒绝 1.3.0-beta.1，明确指定预发布的范围则接受 1.3.0-beta.2。输出保留版本、范围与布尔结果，便于逐项看清究竟是哪条条件在起作用。

其余断言准备检查两份构建元数据的优先级相等、测试版排在相应正式版之前，以及 1.02.3 这种带前导零的版本无效。完整运行通过后也只覆盖解析与选择规则，不验证某个真实依赖升级的兼容性；本轮没有执行到这些断言。决定版本提升幅度时，仍需把公共接口的实际变化和受影响调用方放在一起审阅。版本号负责传达判断，变更说明与测试负责让别人能够核对这个判断。

来源

Semantic Versioning 2.0.0，公共接口承诺、版本优先级和初始开发规则，已核验 2026-10-15。
npm: node-semver，插入符、波浪号及预发布范围的实际语义，已核验 2026-10-15。

蓝绿部署让两套环境随时待命

Mon, 02 Nov 2026 00:00:00 +0000

蓝绿部署在独立环境中准备新应用版本，同时让旧版本继续服务流量。就绪检查通过后，路由把新的工作导向新环境。保留旧环境可以缩短回滚，因为恢复不必等待重新构建。但这个模式本身并不保证全部依赖都有两份、切换瞬间完成，或每一项数据修改都可以撤销。发布方案必须明确哪些东西被切换，以及哪些状态仍然共享。

定义切换究竟控制什么

路由机制可能是负载均衡后端、服务选择器，也可能是 DNS。它们的传播与连接语义不同。修改一个控制面对象，不等于所有数据面实例在同一瞬间采用新值。权威配置已经改变后，DNS 缓存与既有连接仍可能访问旧地址，因此配置写入成功只能作为开始观察的时间点，不能直接作为全局完成证据。

应明确路由选择发生在每次请求、每条连接、每个会话，还是队列任务这一层。长连接可能继续留在蓝色环境，新连接则进入绿色；另一些代理会为每个请求重新选择上游。因此，最长客户端连接不一定决定所有部署的排空时间。需要记录实际机制及其超时、终止行为，并知道强制关闭会怎样影响正在执行的工作。

两套版本都应有能力承担分配给自己的流量与依赖，这并不意味着软件版本必须相同，也不意味着整个系统永远精确支付双倍费用。容量可以分阶段准备，数据库或辅助服务也可能共享。节省资源会改变恢复条件：若旧环境已经缩容到很小，切回路由也无法立刻得到原来的完整服务能力。

在重叠窗口内保持数据兼容

共用数据库很常见，但它是设计选择，不是蓝绿部署的定义。使用两个数据库会引入复制、同步和数据对账问题。反转路由不能抹去绿色环境已经接受的写入，也不能安全地凭空补出蓝色环境缺失的事务。应像定义请求流向一样，明确每类数据在切换和回滚时怎样处理。

共用存储时，可以用先扩展再收缩的方式支持版本重叠。先增加兼容字段，部署能容忍两种表示的读写逻辑，必要时回填数据，最后再删除旧结构。仅等待旧 HTTP 连接结束还不够：旧工作进程、定时任务、回滚版本以及外部消费者，都可能仍依赖旧模式。清理条件应覆盖这些实际使用者。

兼容性不仅是列名存在。两个版本可能都能解析字段，却把相同数值解释成不同单位。迁移可能导致查询报错、写入不一致，也可能造成稍后才暴露的数据损坏；不能断言一定损坏，也不能假定总会干净地拒绝操作。宣布回滚安全之前，需要执行具有代表性的读写路径，并检查业务结果而不只是健康检查。

坏掉的样子

切换期间看到两个版本，并不自动说明部署失败。排空、逐步传播或有意分流，都可能产生这种正常现象。只有客户端或共享状态无法容忍重叠时，它才成为故障。可在适当诊断中记录发布标识，然后将错误与路由状态、连接年龄及版本兼容性关联，避免把所有差异都归因于非原子切换。

反过来，同一个客户端连续五十次看到绿色，也不能证明全局原子性。它可能始终访问同一个边缘节点，或复用同一条连接。就绪副本数量也不能证明服务选择器、端点列表、入口控制器以及外部负载均衡器都指向这些副本。需要检查完整请求路径，并从具有代表性的客户端位置验证实际结果。

不要因为切换命令成功，就立即关闭蓝色环境。应预先定义回滚窗口，监控错误和延迟变化，并在不兼容清理前确认旧后台工作已经退出。如果回滚所依赖的状态已经不可逆改变，就需要前向修复或演练过的数据恢复，而不是反复拨动路由。保留一套进程，并不等于保留了所有恢复前提。

快速验证

用 Python 3 执行下面模型，保持断言开启。代码只改变内存字典：两个路由实例分别更新，已有会话保留当初选定的环境，而模式契约决定两个版本能否运行。这是明确写出的模型，并非某个负载均衡器的测量结果，也不是 Kubernetes 集成测试。

routers = {"edge-a": "blue", "edge-b": "blue"}
existing = {"session-1": "blue", "session-2": "blue"}
routers["edge-a"] = "green"
assert set(routers.values()) == {"blue", "green"}
routers["edge-b"] = "green"
assert set(routers.values()) == {"green"}
assert set(existing.values()) == {"blue"}
print("new routes green; existing sessions still blue")

required = {"blue": {"amount_cents"}, "green": {"amount_cents", "currency"}}
def compatible(schema, colour):
 return required[colour] <= schema
schema = {"amount_cents", "currency"}
assert all(compatible(schema, colour) for colour in required)
routers = dict.fromkeys(routers, "blue")
assert compatible(schema, "blue")
print("rollback remains schema-compatible")

# A destructive replacement can invalidate the old version.
required["green"] = {"amount_minor", "currency"}
schema = {"amount_minor", "currency"}
assert compatible(schema, "green")
assert not compatible(schema, "blue")
print("routing rollback cannot restore a removed column")

第一个断言暴露了路由实例更新到一半时的混合状态。即使两个实例都选择绿色，模型中的旧会话仍留在蓝色。追加字段后的模式支持切回旧版本，而后来破坏性的字段替换不支持。三行输出分别指出这些边界，不给出并不存在的通用切换时长，也不把进程存活等同于数据兼容。

随后应在隔离部署中，使用真实路由器、代表性流量和可回退的测试数据重复这些检查。分别测量传播、排空与回滚，并保留路由收敛以及应用兼容的证据。前者回答新工作去了哪里，后者回答两套版本能否正确处理当前状态；两类结果不能相互替代。

来源

Martin Fowler：蓝绿部署，该模式的原始论述，包含共享数据库这一前提，已核验 2026-09-16。
Kubernetes：Deployment，滚动更新、就绪与回滚语义，已核验 2026-09-16。
AWS：蓝绿部署白皮书，路由层切流及其代价，已核验 2026-09-16。
AWS Route 53 切流, DNS 缓存、加权切换及容量取舍，已核验 2026-10-15。

发布 · XB 现场笔记

Hugo 发布选项决定哪些页面进入产物

元数据和构建选项分别起作用

预览产物仍然可以被公开

坏掉的样子

快速验证

延伸阅读

来源

Kubernetes 滚动更新逐步替换 Pod

逐步替换，还是先停后起

兼容性才是选择依据

回滚也是一次变更

坏掉的样子

快速验证

延伸阅读

来源

镜像标签可以移动，既有容器仍保留原先选择的镜像

坏掉的样子

快速验证

提升经过测试的同一产物

延伸阅读

来源

git tag 把一次发布固到提交

两种标签

为什么给发布签名

移动要格外小心

坏掉的样子

快速验证

延伸阅读

来源

滚动更新分批换上新版本

浪涌与缺口

健康是换班的门槛

选一个有意为之的节奏

坏掉的样子

快速验证

延伸阅读

来源

让已经验证的产物逐级进入环境

明确究竟把什么向前传递

坏掉的样子

快速验证

核对真正运行的发布组合

延伸阅读

来源

语义化版本让兼容性承诺更明确

先声明兼容性覆盖哪些内容

坏掉的样子

快速验证

延伸阅读

来源

蓝绿部署让两套环境随时待命

定义切换究竟控制什么

在重叠窗口内保持数据兼容

坏掉的样子

快速验证

来源