未使用--force标志时，kubectl replace何时会重建资源？

CRD触发重建删除的场景 #

• 修改CRD的spec.scope字段：比如把作用域从Namespaced改成Cluster，或者反向修改。Kubernetes会判定这是资源定义的根本性变更，无法原地更新，只能先删除旧CRD，再重建新CRD，所有关联的CRD实例会随旧CRD一起被删除。
• 修改CRD的spec.names.kind或spec.names.plural字段：这两个字段是CRD的核心标识，变更后Kubernetes无法将新定义与原有CRD资源关联，会触发删除旧CRD并重建新CRD的流程，实例也会被一并清理。
• 修改CRD的spec.group字段：API组是CRD的关键属性，变更后旧API组下的CRD实例会随着旧CRD的删除而被移除。

Namespace触发删除的场景 #

• 修改Namespace的metadata.name字段：Namespace的名称属于不可变属性，执行replace时Kubernetes无法修改现有Namespace的名称，会尝试创建新名称的Namespace，同时删除旧Namespace及其内部所有资源。
• 修改Namespace的metadata.uid字段（手动构造YAML修改后执行replace）：UID是资源的唯一标识，变更后Kubernetes会判定为全新资源，进而删除原Namespace及其中的所有资源。

参考gitops-engine注释：避免对CRDs使用kubectl replace，因为'replace'可能会重建资源，进而删除所有CRD实例。同样的情况也适用于namespaces，这会删除命名空间及其内部的所有资源，因此我们也希望避免在这种情况下使用kubectl replace。

内容的提问来源于stack exchange，提问作者TN.