为高优先级应用（LSE优先级）配置CPU独占与隔离，可以确保关键业务应用获得独占的CPU资源，避免与其他应用争抢资源，从而保证应用性能的稳定性和可预测性。
适用场景
需要为关键业务应用提供独占CPU资源，确保性能稳定
需要避免高优先级应用与低优先级应用之间的CPU资源争抢
需要验证CPU独占与隔离配置是否生效
功能概览
CPU核级独占：为高优先级应用分配独占的CPU核心
资源隔离：通过cgroup cpuset确保其他应用不会使用已分配的CPU核心
优先级保障：与混部优先级系统集成，支持LSE（Latency-Sensitive-Exclusive）优先级
操作指南
环境准备
确保集群中已安装并配置好koord-runtime-proxy组件，并已正确配置kubelet使用该runtime proxy。
1、检查节点状态
kubectl get node -o wide确认目标节点状态为Ready，并记录节点名称。
2、检查 DaemonSet 状态
kubectl -n koordinator-system get ds koord-runtime-proxy koord-runtime-proxy-arm64确保DaemonSet状态正常。
创建高优先级应用
1、LSE优先级绑定
无需手动创建 ColocationProfile；请参照在离线应用优先级管理文档中的步骤，将应用与 LSE 优先级配置进行绑定。
2、创建高优先级应用
创建以下YAML文件并应用，部署一个高优先级应用：
apiVersion: apps/v1kind: Deploymentmetadata:
name: nginx
namespace: defaultspec:
replicas: 2
selector:
matchLabels:
app: nginx
version: v1
template:
metadata:
labels:
app: nginx
version: v1
koordinator.sh/colocation-profile: highest
spec:
nodeSelector:
ccse.ctyun.cn/host-code: amd64-3559d # 替换为实际节点名称
containers:
- image: registry-huadong1.crs-internal.ctyun.cn/open-source/nginx:1.26-alpine-slim
name: container-1
resources:
limits:
cpu: "1"
memory: 512Mi
requests:
cpu: "1"
memory: 512Mi验证CPU独占与隔离
注意
FullPCPUs策略
使用
FullPCPUs策略可以确保分配完整的物理CPU核心，避免跨物理核心的线程干扰当节点剩余的逻辑CPU数量足够但完整的物理核心不足时，会继续分配
性能影响
CPU独占会减少节点上可用的CPU资源，可能影响整体资源利用率
建议只为真正需要稳定性能的关键业务应用配置CPU独占
监控与调优
定期监控CPU使用情况，根据实际负载调整资源分配
使用节点监控工具（如top、htop等）验证CPU隔离效果
兼容性
确保所有节点都正确配置了koord-runtime-proxy
不同版本的Kubernetes和容器运行时可能需要不同的配置
常见问题
如何确认CPU独占是否生效？
可以通过以下方式验证：
检查Pod的注解中是否包含
scheduling.koordinator.sh/resource-status字段。在节点上查看容器的cpuset配置是否与调度器分配一致。
使用性能监控工具观察CPU使用情况。
为什么BE应用无法使用某些CPU核心？
这是预期的行为。高优先级应用（LSE）独占的CPU核心会被排除在BE应用的cpuset之外，确保资源隔离。
如何修改已部署应用的CPU独占配置？
需要更新应用的ColocationProfile配置，并重启相关Pod使配置生效。
CPU独占会影响节点调度吗？
是的，调度器会考虑节点的可用CPU核心数量进行调度决策。当所有CPU核心都被独占时，新的高优先级应用将无法调度到该节点。
