TG咨询Kubernetes 专用节点配置的核心，不是简单购买几台新服务器，而是让节点用途、调度规则和资源边界彼此对应。常见场景包括把 GPU 推理任务、数据库工作负载、持续集成任务或高磁盘吞吐作业安排到独立节点。下面按实施顺序列出5步，适用于自建集群和云厂商托管集群。
第一步：先定义专用节点的边界
先写清楚“为什么要专用”。如果目标是性能稳定，应关注 CPU 核数、内存、磁盘类型和网络带宽；如果目标是安全隔离，还要考虑节点访问权限、网络区域和运维人员范围。专用节点并不等于所有资源都必须独占，例如一组节点可以专门承载 PostgreSQL，但仍需预留系统组件和监控代理的空间。
建议为每类节点建立稳定的用途标签，而不是使用主机名、采购批次或临时编号。比如使用 node-purpose=database、node-purpose=gpu 或 node-purpose=ci。标签应描述能力或用途，避免把某个短期项目名称写进调度规则。
第二步：登记标签并设置污点
节点加入集群后，先确认操作系统、容器运行时、时钟同步、磁盘挂载和 kubelet 状态正常，再添加标签。示例命令为：kubectl label node worker-a node-purpose=database。实际名称应替换为集群中的节点名。
如果只设置标签，其他工作负载仍可能被调度到这些节点。需要减少误调度时，可增加污点，例如：kubectl taint node worker-a dedicated=database:PreferNoSchedule。这种策略会优先避开节点，但资源不足时仍可能接纳不匹配的任务，适合成本敏感、隔离要求中等的场景。
若必须禁止无关工作负载进入，则应使用更严格的污点效果，并为目标工作负载配置对应的容忍度。污点不是安全边界的替代品，仍要配合 RBAC、网络策略和镜像安全检查。
第三步：在工作负载中声明调度条件
选择节点时，优先使用节点亲和性，而不是直接绑定某个节点名称。节点亲和性可以按硬约束和软偏好区分：硬约束适合 GPU 驱动、专用磁盘或合规要求，节点不满足时任务保持等待；软偏好适合成本优化，在专用节点不足时允许使用普通节点。
需要同时配置的三项内容
- 节点亲和性：匹配 node-purpose=database 等标签，明确任务应去哪里。
- 容忍度：允许工作负载进入带有 dedicated=database 污点的节点。
- 资源请求与限制：为容器设置 requests 和 limits，避免单个任务挤占整台机器。
例如，一个内存密集型批处理任务可以偏好 node-purpose=high-memory，并将内存请求设在实际稳定需求附近。请求值过低会造成过度装箱，过高则会降低节点利用率。首次上线时可根据一到两周的工作负载峰值调整，而不应只按平均使用量估算。
第四步：为系统与故障预留资源
专用节点仍需运行 kubelet、容器运行时、日志采集、节点监控和网络组件。应通过 kubelet 的系统预留和 Kubernetes 预留参数，为这些服务留出空间。具体比例取决于节点规格、日志量和 DaemonSet 数量；在中小型节点上，预留约5%至15%的内存和 CPU 是常见起点，但高日志量或高网络流量环境可能需要更多。
同时检查磁盘压力。容器镜像、临时文件和日志会共同消耗节点磁盘，不能只按业务数据容量规划。数据库、构建缓存等场景还应区分系统盘、容器盘和持久化数据盘，避免日志增长导致业务容器被驱逐。
第五步：验证、迁移与持续检查
- 使用 kubectl get nodes --show-labels 检查标签，确认污点和节点状态符合预期。
- 部署一个最小化测试工作负载，验证它能落到目标节点，并确认普通工作负载不会误入。
- 检查事件、资源使用率、磁盘压力和容器重启次数，重点观察高峰时段。
- 迁移生产任务前，先用滚动方式调整副本或分批切换，并确认持久化卷、服务发现和备份策略正常。
- 建立节点下线流程。维护前先标记不可调度，再驱逐可迁移工作负载；有本地数据或单副本服务时，必须先确认数据安全。
还要测试节点故障后的行为。若专用节点只有一台，节点宕机会让相关任务整体中断；增加同用途节点、设置拓扑分布约束并保留足够副本，可以降低单点风险，但会增加机器和运维成本。
常见问题
专用节点一定要使用污点吗？
不一定。只需要优先调度时，标签加亲和性即可；要求严格隔离时，才应增加污点和容忍度组合。
硬亲和性和软亲和性怎么选？
硬亲和性适合必须依赖特定硬件或合规区域的任务；软亲和性适合节点不足时仍希望任务运行的场景。
专用节点可以运行系统组件吗？
通常可以。网络插件、监控代理和日志组件往往需要在节点上运行，应将它们计入资源预留，不要把整台机器的容量全部分配给业务。
如何判断配置是否生效？
同时查看节点标签、污点、工作负载实际落点、调度事件和资源曲线。只看工作负载处于运行状态，不能证明它遵守了预期规则。
完成以上五步后，Kubernetes专用节点配置才算从“划出机器”变成了可验证的调度策略。后续应随着负载变化复查标签、资源请求、节点容量和故障演练结果。
