Kustomize的设计理念和使用说明，能否详细解释一下？

Kustomize 设计理念与使用说明 一、设计理念 Kustomize 的设计理念是基于"基础配置 + 补丁"的模式，这里解释一下为什么需要在 base 目录下创建基础配置： 基础配置的重要性： base 目录下的配置是所有环境共享的基础配置 包含了服务最基本的定义和配置 确保了不同环境的配置一致性 环境差异管理： overlays 目录只存放与基础配置的差异部分 每个环境只需要关注自己特有的配置 避免了配置重复和维护困难 配置复用： 基础配置可以被多个环境复用 减少了重复配置的维护成本 确保了配置的一致性 如果只在 overlays 下创建配置的问题： 每个环境都需要维护完整的配置 配置变更需要在多个环境中同步修改 容易造成环境间的配置不一致 难以追踪配置的变化 base 中放置： 容器端口 资源限制 健康检查 基础标签 overlays 中放置： 环境变量 镜像版本 副本数量 特定注解 二、工作流 kustomization工作流方式 Kustomize 不是一个新工具，它自 2017 年以来一直在建设中，并在 1.14 版本中作为原生 kubectl 子命令引入。Kustomize 由 Google 和 Kubernetes 社区构建，符合 Kubernetes 使用 Kubernetes 对象定义配置文件和以声明方式管理这些配置的原则。Kustomize 配置对象称为 Kustomization，用于描述如何生成或转换其他 Kubernetes 对象。Kustomization 在名为 kustomization.yaml 的文件中以声明方式定义，此文件可由 Kustomize 本身生成和修改。 在 kustomize 中，可以定义常见、可重复使用的 kustomization（称为基础）并使用多个其他 kustomization（称为覆盖层）对其进行修补，这些 kustomization 可以选择性地覆盖基础中定义的设置以生成变体。然后，Kustomize 根据 kustomization 基础和覆盖层中定义的配置转换和生成资源，此过程称为融合或渲染。接下来，这些渲染资源会写入标准输出或文件，并保持原始 YAML 文件不变，以便许多不同的叠加层重复使用基础。 这种无模板方法在 Kustomization 库的易用性和可重用性方面非常强大。使用它你能够以几乎任何想要的方式自定义 Kubernetes 配置，而无需为每个单独的用例提供大量值。