Pod 提示 must specify limits.memory：主容器有配置，也要检查 initContainer

Deployment 已经创建，ReplicaSet 却不断报 FailedCreate，具体信息是 failed quota: ... must specify limits.memory。即使应用容器写了内存上限，Pod 中另一个普通容器或 initContainer 没有相应声明，仍可能在命名空间配额准入阶段被拒绝。

先区分“缺少必填资源声明”和“超过剩余配额”。命名空间的 Used 小于 Hard，并不能让缺少声明的 Pod 获准创建；这条报错也不是应用运行后发生了内存溢出。

看实际生成的 Pod 模板，而非单个容器片段

下面是只读检查示例，替换命名空间和对象名：

kubectl -n app describe deployment web
kubectl -n app describe replicaset web-abc123
kubectl -n app get deployment web -o yaml
kubectl -n app get resourcequota
kubectl -n app get limitrange

Deployment 可能成功保存，但它要创建的 Pod 被拒绝，因此当前未必存在可供 describe 的失败 Pod。ReplicaSet 的事件更能指明创建阶段的拒绝原因；同时确认事件对应当前模板，避免检查旧副本的配置。

检查 spec.template.spec.containers 的每一个容器，也检查 spec.template.spec.initContainers。初始化阶段也需要资源，不会因为容器最终结束就免除准入规则。如果 Operator、Helm 或注入机制增加了辅助容器，提交的源文件片段可能与实际准入对象不同，还需核对生成过程和平台提供的拒绝信息。

按配额要求补齐相应声明

报错只要求 limits.memory 时，先查哪个容器缺少内存 limit；不要把它概括成所有集群都必须填写 CPU 和内存的全部 requests/limits。其他必填项由这个命名空间实际生效的 ResourceQuota、LimitRange 等策略决定。

下面是资源声明位置示例，数值只是结构示例，须按初始化任务的实际需求和平台限制确定：

spec:
  template:
    spec:
      initContainers:
        - name: prepare
          image: your-existing-init-image
          resources:
            requests:
              memory: 64Mi
            limits:
              memory: 128Mi

这段只展示已有 initContainer 的资源字段，不能覆盖它原本的镜像、命令、挂载和其他配置。不要为了通过配额把内存上限设得任意小：实际执行超过限制仍可能被终止。requests 影响资源预留和调度，limits 约束运行上限，两者需符合应用需求和 LimitRange 条件。

普通 initContainer 顺序执行，资源核算与同时运行的应用容器不同；不能把所有初始化资源简单相加就当作最终 Pod 需求。原生 sidecar 等较新机制还需要按版本和容器类型单独核算。本场景优先补齐声明，不借机猜测整个命名空间的资源公式。

有默认 LimitRange，仍需检查它是否生效

平台可以通过 LimitRange 为没有声明的容器提供默认值。但默认值是否存在、是否符合配额，以及新 Pod 实际采用了什么，都要核对，不能认为创建了一个 LimitRange 就自动修正所有已经存在的对象。

若修改后报错变成 exceeded quota，说明进入了另一项校验：要比较实际 Pod 的需求与命名空间剩余额度，考虑更新期间的新旧副本，而不是继续寻找“缺 limit”的容器。不要直接删除配额、提高全站默认值或删除其他业务 Pod 来绕开限制。

修改前保存工作负载及资源配置，通过原部署入口更新，并评估新增资源需求和滚动更新影响。验收应确认新 ReplicaSet 成功创建 Pod，初始化步骤完成、应用就绪，同时观察是否出现调度不足或初始化 OOM 等新问题。需要回退时恢复原部署配置；原配置仍违反配额的情形，应保留可用副本并协调资源方案，不能把回退当作创建成功的保证。