Kubernetes 实战:使用 DaemonSet 在特定节点上运行 Pod

Kubernetes 实战:使用 DaemonSet 在特定节点上运行 Pod

website Kubernetes website and documentation repo: website 项目地址: https://gitcode.com/gh_mirrors/webs/website

前言

在 Kubernetes 集群管理中,DaemonSet 是一种确保所有(或某些)节点上都运行一个 Pod 副本的控制器。本文将深入探讨如何利用 DaemonSet 的节点选择功能,实现在特定节点上运行 Pod 的高级场景。

理解 DaemonSet 的基本概念

DaemonSet 是 Kubernetes 中一种特殊的控制器,它确保集群中符合条件的每个节点上都运行一个指定的 Pod 副本。当有新节点加入集群时,DaemonSet 会自动在新节点上创建 Pod;当节点从集群中移除时,对应的 Pod 也会被回收。

实际应用场景

在实际生产环境中,我们经常遇到需要在特定节点上运行 Pod 的需求,例如:

  1. 在配备 SSD 存储的节点上运行高性能缓存服务
  2. 在 GPU 节点上运行机器学习推理服务
  3. 在特定区域的节点上运行监控代理

详细操作步骤

第一步:标记目标节点

首先,我们需要识别并标记那些我们希望运行 DaemonSet Pod 的节点。假设我们要在配备 SSD 存储的节点上运行 Pod:

kubectl label nodes node1 node2 ssd=true

这个命令为 node1node2 添加了 ssd=true 的标签。

第二步:创建 DaemonSet 配置文件

接下来,我们创建一个 DaemonSet 的 YAML 配置文件,确保它只会在带有 ssd=true 标签的节点上运行 Pod:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ssd-cache-daemon
  labels:
    app: ssd-cache
spec:
  selector:
    matchLabels:
      name: ssd-cache
  template:
    metadata:
      labels:
        name: ssd-cache
    spec:
      nodeSelector:
        ssd: "true"
      containers:
      - name: cache-container
        image: registry.example.com/cache:latest
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - mountPath: /cache
          name: cache-volume
      volumes:
      - name: cache-volume
        hostPath:
          path: /var/cache

关键配置说明:

  • nodeSelector 字段指定了 Pod 只会在带有 ssd=true 标签的节点上运行
  • 我们为容器配置了资源限制和请求
  • 使用了 hostPath 卷来挂载节点的本地存储

第三步:部署 DaemonSet

使用以下命令部署 DaemonSet:

kubectl apply -f ssd-daemonset.yaml

第四步:验证部署

部署完成后,我们可以检查 Pod 的运行情况:

kubectl get pods -o wide

输出将显示 Pod 只运行在带有 ssd=true 标签的节点上。

第五步:动态扩展

如果后续有新的 SSD 节点加入集群,只需为其打上标签:

kubectl label node node3 ssd=true

DaemonSet 控制器会自动检测到这个变更,并在新节点上创建 Pod。

高级配置选项

除了基本的节点选择外,DaemonSet 还支持更复杂的调度策略:

  1. 污点和容忍度:可以与节点污点配合使用,实现更精细的调度控制
  2. 亲和性/反亲和性:使用节点亲和性规则实现更复杂的调度需求
  3. 更新策略:配置滚动更新参数控制 DaemonSet 的更新行为

最佳实践建议

  1. 标签命名规范:使用一致的标签命名约定,如 storage-type=ssd 而非简单的 ssd=true
  2. 资源限制:始终为 DaemonSet Pod 设置适当的资源限制
  3. 监控:监控 DaemonSet Pod 的资源使用情况,特别是当它们在每个节点上运行时
  4. Pod 优先级:考虑为关键的系统级 DaemonSet 设置适当的 Pod 优先级

常见问题排查

如果 DaemonSet Pod 没有按预期运行,可以检查以下方面:

  1. 节点标签是否正确设置
  2. DaemonSet 的 nodeSelector 配置是否正确
  3. 节点是否有足够的资源运行 Pod
  4. 是否存在其他调度限制(如污点、资源配额等)

通过本文介绍的方法,你可以有效地控制 DaemonSet Pod 在集群中的分布,满足各种特定的部署需求。

website Kubernetes website and documentation repo: website 项目地址: https://gitcode.com/gh_mirrors/webs/website

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

资源下载链接为: https://pan.quark.cn/s/3d8e22c21839 随着 Web UI 框架(如 EasyUI、JqueryUI、Ext、DWZ 等)的不断发展与成熟,系统界面的统一化设计逐渐成为可能,同时代码生成器也能够生成符合统一规范的界面。在这种背景下,“代码生成 + 手工合并”的半智能开发模式正逐渐成为新的开发趋势。通过代码生成器,单表数据模型以及一对多数据模型的增删改查功能可以被直接生成并投入使用,这能够有效节省大约 80% 的开发工作量,从而显著提升开发效率。 JEECG(J2EE Code Generation)是一款基于代码生成器的智能开发平台。它引领了一种全新的开发模式,即从在线编码(Online Coding)到代码生成器生成代码,再到手工合并(Merge)的智能开发流程。该平台能够帮助开发者解决 Java 项目中大约 90% 的重复性工作,让开发者可以将更多的精力集中在业务逻辑的实现上。它不仅能够快速提高开发效率,帮助公司节省大量的人力成本,同时也保持了开发的灵活性。 JEECG 的核心宗旨是:对于简单的功能,可以通过在线编码配置来实现;对于复杂的功能,则利用代码生成器生成代码后,再进行手工合并;对于复杂的流程业务,采用表单自定义的方式进行处理,而业务流程则通过工作流来实现,并且可以扩展出任务接口,供开发者编写具体的业务逻辑。通过这种方式,JEECG 实现了流程任务节点和任务接口的灵活配置,既保证了开发的高效性,又兼顾了项目的灵活性和可扩展性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

尤琦珺Bess

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值