Pod控制器-DaemonSet(DS)

本文深入探讨Kubernetes中的DaemonSet控制器,详细解释其工作原理与应用场景,包括如何确保集群中每个节点运行指定Pod副本,以及如何进行部署与管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Pod控制器介绍

Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类:

  • 自主式pod:kubernetes直接创建出来的Pod,这种pod删除后就没有了,也不会重建
  • 控制器创建的pod:kubernetes通过控制器创建的pod,这种pod删除了之后还会自动重建

什么是Pod控制器?
Pod控制器是管理pod的中间层,使用Pod控制器之后,只需要告诉Pod控制器,想要多少个什么样的Pod就可以了,它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障,它会基于指定策略重新编排Pod。

在kubernetes中,有很多类型的pod控制器,每种都有自己的适合的场景,常见的有下面这些:

ReplicationController:比较原始的pod控制器,已经被废弃,由ReplicaSet替代
ReplicaSet:保证副本数量一直维持在期望值,并支持pod数量扩缩容,镜像版本升级
Deployment:通过控制ReplicaSet来控制Pod,并支持滚动升级、回退版本
Horizontal Pod Autoscaler:可以根据集群负载自动水平调整Pod的数量,实现削峰填谷
DaemonSet:在集群中的指定Node上运行且仅运行一个副本,一般用于守护进程类的任务
Job:它创建出来的pod只要完成任务就立即退出,不需要重启或重建,用于执行一次性任务
Cronjob:它创建的Pod负责周期性任务控制,不需要持续后台运行
StatefulSet:管理有状态应用

DaemonSet(DS)

DaemonSet类型的控制器可以保证在集群中的每一台(或指定)节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说,如果一个Pod提供的功能是节点级别的(每个节点都需要且只需要一个),那么这类Pod就适合使用DaemonSet类型的控制器创建。
在这里插入图片描述

DaemonSet控制器的特点:

  • 每当向集群中添加一个节点时,指定的 Pod 副本也将添加到该节点上
  • 当节点从集群中移除时,Pod 也就被垃圾回收了

下面先来看下DaemonSet的资源清单文件

apiVersion: apps/v1 # 版本号
kind: DaemonSet # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: daemonset
spec: # 详情描述
  revisionHistoryLimit: 3 # 保留历史版本
  updateStrategy: # 更新策略
    type: RollingUpdate # 滚动更新策略
    rollingUpdate: # 滚动更新
      maxUnavailable: 1 # 最大不可用状态的 Pod 的最大值,可以为百分比,也可以为整数
  selector: # 选择器,通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

创建pc-daemonset.yaml,内容如下:

apiVersion: apps/v1
kind: DaemonSet      
metadata:
  name: pc-daemonset
  namespace: dev
spec: 
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
# 创建daemonset
[root@k8s-master01 ~]# kubectl create -f  pc-daemonset.yaml
daemonset.apps/pc-daemonset created

# 查看daemonset
[root@k8s-master01 ~]#  kubectl get ds -n dev -o wide
NAME        DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE   AGE   CONTAINERS   IMAGES         
pc-daemonset   2        2        2      2           2        24s   nginx        nginx:1.17.1   

# 查看pod,发现在每个Node上都运行一个pod
[root@k8s-master01 ~]#  kubectl get pods -n dev -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE    
pc-daemonset-9bck8   1/1     Running   0          37s   10.244.1.43   node1     
pc-daemonset-k224w   1/1     Running   0          37s   10.244.2.74   node2      

# 删除daemonset
[root@k8s-master01 ~]# kubectl delete -f pc-daemonset.yaml
daemonset.apps "pc-daemonset" deleted

本文摘抄或总结其他笔记,笔记不涉及任何商业用途,如果侵权请及时联系处理

参考:

k8s官方文档
yooome / LearningNotes

### Kubernetes DaemonSet 部署 Master 节点缺少 Pod 的解决方案 #### 一、检查节点状态 确保所有节点,包括Master节点处于正常工作状态。可以通过`kubectl get nodes`命令查看各个节点的状态。如果发现某些节点不可用或存在异常,则需要进一步排查这些节点上的问题。 #### 二、验证Flannel网络配置 由于提到所有节点需上传flannel镜像至/opt目录并由master节点应用kube-flannel.yml文件[^2],因此要确认此操作已在集群内全部完成,并且Flannel CNI插件已成功启动运行。这一步骤对于跨主机容器间通信至关重要,任何错误都可能导致Pod无法被正确分配给目标节点。 #### 三、调整调度策略排除控制平面组件所在节点 默认情况下,Kubernetes不会将普通的工作负载安排到标记为“control-plane”的节点上(即通常所说的master节点)。这是因为通过taints/tolerations机制设置了排斥规则来保护关键系统的稳定性。然而,在特定场景下比如小型开发测试环境中可能希望改变这种行为以便充分利用资源。此时可考虑移除相关污点或者增加容忍度设置让DaemonSets能够覆盖整个集群中的每一个成员: ```bash # 移除master节点上的NoSchedule taint kubectl taint nodes <your-master-node-name> node-role.kubernetes.io/control-plane- ``` 上述命令将会使得master节点不再具有阻止其他pods调度上去的特性,从而允许DaemonSet管理下的Pod实例也能在此类特殊位置创建出来。 #### 四、重启API Server和服务代理进程 有时简单的服务重启就能解决问题。尝试停止再重新开启apiserver以及kube-proxy等相关后台程序可能会刷新内部缓存数据结构进而恢复正常的服务发现流程。具体做法取决于所使用的操作系统版本及其初始化方式;例如systemd环境下可以使用如下指令: ```bash sudo systemctl restart kubelet.service sudo systemctl restart kube-apiserver.service sudo systemctl restart kube-controller-manager.service sudo systemctl restart kube-scheduler.service sudo systemctl restart kube-proxy.service ``` 以上措施有助于清除潜在的数据不一致情况,特别是当遇到因同步过程发生部分Node信息丢失而导致DaemonSet的部分Pod实例无法调度的情况时尤为有效[^1]。 #### 五、核对资源配置请求与实际可用容量之间的匹配程度 最后还需仔细对比期望部署的应用所需CPU/内存等硬件参数同当前环境所能提供的最大限额之间是否存在冲突。即使是在看似充足的条件下也有可能因为预留不足或其他因素造成个别实例得不到满足而一直处于Pending阶段。针对这一点可通过编辑YAML描述文档适当降低单个单元消耗量或是扩大整体供给规模加以改善。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

GC-757

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

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

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

打赏作者

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

抵扣说明:

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

余额充值