Guaranteed Pod 的核心判定条件是「Pod 内所有容器的所有已声明计算资源（CPU、内存等），其 requests 与 limits 完全相等」，但还有几个细节补充和可选配置（视你的需求而定），下面逐一拆解清楚：
一、 Guaranteed Pod 完整判定条件（无遗漏）
首先明确：K8s 的 QoS 等级（Guaranteed/Burstable/BestEffort）是针对 Pod 整体 判定的，Guaranteed 的完整条件有 3 点，核心是「requests=limits」，其余是补充约束：
1. 核心条件（必须满足）
对 Pod 内的 所有容器（包括 initContainers 初始化容器、ephemeralContainers 临时容器），每一种声明的计算资源（CPU、memory，若声明了 ephemeral-storage 也需满足），都必须满足：
resources.requests.xxx = resources.limits.xxx（数值完全相等）
2. 补充条件 1（隐性满足，无需手动配置）
如果容器 只声明了 limits，未声明 requests，K8s 会 自动将 requests 赋值为与 limits 相等的值，这种情况也满足 Guaranteed 判定。 示例：
# 仅声明 limits，未声明 requests，K8s 自动补全 requests.cpu=1、requests.memory=1Gi，属于 Guaranteed
containers:
- name: app
image: nginx
resources:
limits:
cpu: "1"
memory: 1Gi
3. 补充条件 2（无资源声明的特殊情况）
如果容器 完全不声明任何 requests/limits（CPU、memory 都不写），则该容器不影响 QoS 判定；但只要 Pod 内有一个容器声明了资源且未满足「requests=limits」，整个 Pod 就无法被判定为 Guaranteed。
注意：生产环境中，Guaranteed Pod 建议显式声明
requests=limits，避免依赖隐性补全，提高可维护性。
4. 反例（不满足 Guaranteed 的情况）
- Pod 内有一个容器的
cpu.requests=0.5、cpu.limits=1（不相等）； - 仅声明了
requests，未声明limits； - 不同容器的资源对齐状态不一致（一个容器满足，一个容器不满足）。
二、 仅需「Guaranteed QoS 等级」：无需额外配置
如果你的需求只是「让 Pod 被判定为 Guaranteed 等级」（享受 K8s 调度优先、OOM 优先级最低等权益），满足上述资源对齐条件即可，无需任何额外配置，Pod 创建后会自动被标记为 Guaranteed。
示例：标准 Guaranteed Pod 配置（无额外配置，直接生效）
apiVersion: v1
kind: Pod
metadata:
name: standard-guaranteed-pod
spec:
# 若有 init 容器，也需满足 requests=limits
initContainers:
- name: init-demo
image: busybox
command: ["sh", "-c", "echo init done"]
resources:
requests:
cpu: "0.1"
memory: 256Mi
limits:
cpu: "0.1"
memory: 256Mi
# 主容器满足 requests=limits
containers:
- name: app
image: nginx:1.25
resources:
requests:
cpu: "1"
memory: 1Gi
limits:
cpu: "1" # 与 requests 完全相等
memory: 1Gi # 与 requests 完全相等
# 临时容器（若有）也需满足 requests=limits
ephemeralContainers:
- name: debug
image: busybox
command: ["sh"]
stdin: true
tty: true
resources:
requests:
cpu: "0.1"
memory: 256Mi
limits:
cpu: "0.1"
memory: 256Mi
验证：确认 Pod 为 Guaranteed 等级
创建 Pod 后，通过以下命令验证 QoS 等级：
# 查看 Pod 的 QoS 等级（输出中包含 qosClass: Guaranteed 即生效）
kubectl describe pod standard-guaranteed-pod | grep -i "QoS Class"
三、 需「Guaranteed + cpuset 物理核绑定」：额外配置 kubelet（你的核心需求）
如果你的需求是「Guaranteed Pod 触发 cpuset 物理核硬隔离」（满足业务/管理池分离、避免资源抢占），则 需要额外配置 kubelet 的 CPU 管理策略，仅满足 Guaranteed 是不够的。
1. 额外配置：kubelet 开启 static CPU 管理策略
这是 K8s 原生支持的配置，只有开启 static 策略，kubelet 才会为 Guaranteed Pod 分配 独占的 cpuset 物理核，实现硬隔离（默认 none 策略不会做 cpuset 绑定）。
步骤 1：修改 kubelet 配置文件（/var/lib/kubelet/config.yaml）
# 核心配置：开启 static 策略
cpuManagerPolicy: static
# 可选：关闭按 socket 对齐，支持精细核分配（按需开启）
cpuManagerPolicyOptions:
alignBySocket: false
# 可选：预留系统 CPU 核，避免挤占管理池
reservedSystemCPUs: "0"
# 可选：reconcile 周期，默认 10s
cpuManagerReconcilePeriod: 10s
步骤 2：重启 kubelet 使配置生效
systemctl daemon-reload
systemctl restart kubelet
2. 关键说明
- 该配置是 节点级 的（每个节点独立配置），配置后仅对该节点上后续创建的 Guaranteed Pod 生效，已运行的 Pod 无影响；
static策略 仅对 Guaranteed Pod 生效，Burstable/BestEffort Pod 仍按none策略处理，不做 cpuset 绑定；- 配置生效后，Guaranteed Pod 会被自动分配独占的物理核，无需额外注解，底层通过 cgroup 的
cpuset.cpus实现隔离。
3. 验证：Guaranteed Pod 已绑定 cpuset 物理核
# 1. 查看 Pod 的 cgroup 路径
POD_CGROUP=$(kubectl describe pod standard-guaranteed-pod | grep -i "Cgroup Path" | awk '{print $3}')
# 2. 查看 Pod 绑定的物理 CPU 核（输出具体核范围即说明 cpuset 绑定生效）
cat /sys/fs/cgroup/cpuset/${POD_CGROUP}/cpuset.cpus
四、 其他可选配置（按需补充，非必须）
1. 配置 nodeSelector/nodeAffinity：绑定指定节点
若需将 Guaranteed Pod 调度到特定节点（如管理池节点），可添加节点选择约束，无额外依赖：
spec:
nodeSelector:
node-pool: management-node # 仅调度到打了该标签的节点
2. 配置 tolerations：容忍节点污点
若目标节点有污点（如管理节点），需添加容忍度才能调度上去：
spec:
tolerations:
- key: "pool-type"
operator: "Equal"
value: "management"
effect: "NoSchedule"
3. 配置 resourceQuota：限制命名空间内 Guaranteed Pod 总量
若需控制某个命名空间内的 Guaranteed Pod 总资源，可配置 ResourceQuota，无需额外配置 Pod：
apiVersion: v1
kind: ResourceQuota
metadata:
name: guaranteed-quota
namespace: management-pool-ns
spec:
hard:
limits.cpu: "4"
limits.memory: "8Gi"
pods: "20"
五、 总结
- Guaranteed Pod 核心：所有容器的所有声明资源，requests=limits（显式声明或 K8s 自动补全均可）；
- 仅需 QoS 等级：无需额外配置，满足资源对齐即可；
- 需 cpuset 物理核绑定：额外配置 kubelet 的
cpuManagerPolicy=static（节点级）； - 其他可选配置（节点绑定、污点容忍、配额限制）：按需补充，不影响 Guaranteed 判定和 cpuset 绑定。
