k8s工作负载控制器--DaemonSet

目录

• 一、概述
• 二、适用场景
• 三、基本操作
  • 1、官网的DaemonSet资源清单
  • 2、字段解释
  • 3、编写DaemonSet资源清单
  • 4、基于yaml创建DaemonSet
  • 5、注意点
    • 5.1、必须字段
    • 5.2、DaemonSet 对象的名称
    • 5.3、.spec.selector 与 .spec.template.metadata.labels之间的关系
  • 6、查看DaemonSet
    • 6.1、查看DaemonSet列表
    • 6.2、查看 DaemonSet 控制器所创建的 Pod 副本信息
  • 7、滚动更新
    • 7.1、查看DaemonSet详情
    • 7.2、更新nginx镜像版本
    • 7.3、查看滚动更新状态
    • 7.4、查看DS滚动更新过程
    • 7.5、查看DS滚动更新版本
  • 8、版本回退
    • 8.1、回滚
    • 8.2、查看版本回退情况
  • 9、删除DaemonSet
    • 9.1、直接删除DS
    • 9.2、基于创建的资源清单删除DS
• 四、DaemonSet调度
  • 1、调度方式
  • 2、指定nodeName节点运行
    • 2.1、原理机制
    • 2.2、示例
      • 2.2.1、创建一个DaemonSet资源清单，指定nodeName
      • 2.2.2、应用 DaemonSet
      • 2.2.3、查看 DaemonSet Pod 的状态
  • 3、通过标签运行 (nodeSelector)
    • 3.1、原理机制
    • 3.2、示例
      • 3.2.1、给 k8s-node1 添加标签
      • 3.2.2、创建DaemonSet 资源清单，使用nodeSelector
      • 3.2.3、应用 DaemonSet
      • 3.2.4、查看 DaemonSet Pod 的状态
      • 3.2.5、删除k8s-node1上的标签
  • 4、通过亲和力调度 (node Affinity 和 node Anti-affinity)
    • 4.1、Node Affinity (节点亲和性)
      • 4.1.1、原理
      • 4.1.2、给node-k8s2添加标签
      • 4.1.3、创建 DaemonSet 资源清单，使用 nodeAffinity
      • 4.1.4、应用DaemonSet
      • 4.1.5、查看 DaemonSet Pod 的状态
    • 4.2、Node Anti-affinity (节点反亲和性)
      • 4.2.1、原理
      • 4.2.2、给node-k8s2添加标签
      • 4.2.3、创建 DaemonSet 资源清单，使用 node Anti-affinity
      • 4.2.4、应用DaemonSet
      • 4.2.5、查看 DaemonSet Pod 的状态
  • 5、污点与容忍度（Tolerations 和 Taints）
    • 5.1、原理
    • 5.2、示例
      • 5.2.1、给 k8s-node1 添加 taint
      • 5.2.2、创建 DaemonSet 资源清单
      • 5.2.3、应用Daemonset
      • 5.2.4、 查看 DaemonSet Pod 的状态
• 五、如何与 DaemonSet 中的 Pod 进行通信
  • 1、 推送（Push）
    • 1.1、实现
    • 1.2、示例
  • 2、 NodeIP 和已知端口
    • 2.1、实现
    • 2.2、示例
  • 3、DNS
    • 3.1、实现
    • 3.2、示例
  • 4、Service
    • 4.1、实现
    • 4.2、示例

一、概述

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的主要作用，是在 Kubernetes 集群里，运行一个 Daemon Pod。 DaemonSet 只管理 Pod 对象，然后通过 nodeAffinity 和 Toleration 这两个调度器参数的功能，保证了每个节点上有且只有一个 Pod

二、适用场景

DaemonSet适用于每个node节点均需要部署一个守护进程的场景

• 日志采集agent，如fluentd或logstash
• 监控采集agent，如Prometheus Node Exporter,Sysdig Agent,Ganglia gmond
• 分布式集群组件，如Ceph MON，Ceph OSD，glusterd，Hadoop Yarn NodeManager等
• k8s必要运行组件，如网络flannel，weave，calico，kube-proxy等

三、基本操作

1、官网的DaemonSet资源清单

apiVersion: apps/v1
kind: DaemonSet
metadata:name: fluentd-elasticsearchnamespace: kube-systemlabels:k8s-app: fluentd-logging
spec:selector:matchLabels:name: fluentd-elasticsearchtemplate:metadata:labels:name: fluentd-elasticsearchspec:tolerations:# 这些容忍度设置是为了让该守护进程集在控制平面节点上运行# 如果你不希望自己的控制平面节点运行 Pod，可以删除它们- key: node-role.kubernetes.io/control-planeoperator: Existseffect: NoSchedule- key: node-role.kubernetes.io/masteroperator: Existseffect: NoSchedulecontainers:- name: fluentd-elasticsearchimage: quay.io/fluentd_elasticsearch/fluentd:v2.5.2resources:limits:memory: 200Mirequests:cpu: 100mmemory: 200MivolumeMounts:- name: varlogmountPath: /var/log# 可能需要设置较高的优先级类以确保 DaemonSet Pod 可以抢占正在运行的 Pod# priorityClassName: importantterminationGracePeriodSeconds: 30volumes:- name: varloghostPath:path: /var/log

2、字段解释

apiVersion: apps/v1    #指定YAML文件的API版本，这里是apps/v1
kind: DaemonSet    #定义资源类型，这里是DaemonSet
metadata:    #包含DaemonSet的元数据name: fluentd-elasticsearch     #此DaemonSet的名称namespace: kube-system    #定义DaemonSet所属的命名空间labels:    #定义标签k8s-app: fluentd-logging    #此标签表示该DaemonSet与日志处理有关
spec:    #DaemonSet的规约，包含了DaemonSet的规格和行为的详细配置selector:    #定义了DaemonSet所管理的Pods的标签选择器，即哪些Pods应该被这个DaemonSet管理。这里matchLabels必须与template.metadata.labels相匹配。matchLabels:name: fluentd-elasticsearchtemplate:    #Pod的模板，用于创建和管理DaemonSet下的Podsmetadata:    #Pod的元数据，这里包含了与spec.selector.matchLabels相匹配的标签。labels:name: fluentd-elasticsearchspec:    #Pod的规约tolerations:     #定义了Pod可以容忍的节点污点，允许Pod在带有特定污点的节点上运行。这里配置了两个容忍度，分别针对控制平面节点和标记为master的节点，确保日志采集容器可以在这些特殊节点上运行。# 这些容忍度设置是为了让该守护进程集在控制平面节点上运行# 如果你不希望自己的控制平面节点运行 Pod，可以删除它们- key: node-role.kubernetes.io/control-plane    #污点的键,通常表示控制平面节点的标签。operator: Exists    #Exists，表示只要节点上有与key匹配的污点，无论其值是什么，都将被视为匹配effect: NoSchedule    #NoSchedule，表示如果节点上存在与key匹配的污点，则默认情况下不允许Pod被调度到该节点。但是，由于这个Pod声明了对该污点的容忍度，所以Pod可以被调度到带有node-role.kubernetes.io/control-plane污点的节点上。- key: node-role.kubernetes.io/master    #指向标记为master的节点的污点键。operator: Exists    #只要节点上有与key匹配的污点，无论其值是什么，都将被视为匹配。effect: NoSchedule    #表明默认情况下，没有相应容忍度的Pod将不能被调度到带有node-role.kubernetes.io/master污点的节点上。但是，由于这个Pod声明了对该污点的容忍度，所以Pod可以被调度到带有node-role.kubernetes.io/master污点的节点上。containers:    #Pod的容器配置- name: fluentd-elasticsearch    #容器的名称image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2    #指定容器的镜像来源resources:    #定义了容器的资源限制和请求limits:    #容器的最大资源限制memory: 200Mirequests:    #容器启动时请求的最小资源量cpu: 100mmemory: 200MivolumeMounts:    #容器如何挂载卷- name: varlog    #指定了要挂载的卷的名称mountPath: /var/log    #定义了容器内部挂载卷的路径# 可能需要设置较高的优先级类以确保 DaemonSet Pod 可以抢占正在运行的 Pod# priorityClassName: importantterminationGracePeriodSeconds: 30    #定义了当Pod被删除时，Kubernetes等待的秒数，以允许容器优雅地关闭。volumes:    #定义Pod可以使用的卷- name: varlog    #定义了一个卷的名称hostPath:    #指定了这个卷的主机路径path: /var/log

3、编写DaemonSet资源清单

daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:name: simple-daemonsetnamespace: default
spec:selector:matchLabels:app: simple-daemonset-apptemplate:metadata:labels:app: simple-daemonset-appspec:containers:- name: nginx-containerimage: nginx:latestports:- containerPort: 80

4、基于yaml创建DaemonSet

kubectl apply -f daemonset.yaml 

5、注意点

5.1、必须字段

DaemonSet需要apiVersion、kind 、metadata 和spec字段

以下是DaemonSetYAML定义中最基本的必需字段：

apiVersion: apps/v1
kind: DaemonSet
metadata:name: <daemonset-name>namespace: <namespace>
spec:selector:matchLabels:<label-key>: <label-value>template:metadata:labels:<label-key>: <label-value>spec:containers:- name: <container-name>image: <image-name>

• apiVersion：指定YAML文件使用的Kubernetes API版本。对于DaemonSet，通常使用apps/v1。

• kind：指定资源类型，这里应为DaemonSet。

• metadata：

  • name：DaemonSet的名称，必须是唯一的。
  • namespace：DaemonSet所在的命名空间，默认为default，但强烈建议明确指定。

• spec：DaemonSet的规格，定义了它的行为和管理的Pod的模板。

  • selector：选择器，用于标识DaemonSet管理的Pods。

    • matchLabels：一个键值对的映射，用于匹配DaemonSet管理的Pods的标签。这是必须的，用于确保DaemonSet管理的Pods与之关联。

  • template：Pod的模板，定义了DaemonSet创建的Pods的结构。

    • metadata：Pod的元数据，其中必须包含与spec.selector.matchLabels相匹配的labels字段。
    • spec：Pod的规格，定义了容器、卷、网络设置等。
      • containers：一个或多个容器的列表，每个容器都需要定义name和image。

5.2、DaemonSet 对象的名称

DaemonSet 对象的名称必须是一个合法的 DNS 子域名。

• 不能超过 253 个字符
• 只能包含小写字母、数字，以及 '-' 和 '.'
• 必须以字母数字开头
• 必须以字母数字结尾

5.3、.spec.selector 与 .spec.template.metadata.labels之间的关系

.spec.selector 必须与 .spec.template.metadata.labels 匹配。这意味着 matchLabels 中定义的每个键值对都必须存在于 .spec.template.metadata.labels 中，以确保DaemonSet能够正确地选择它所创建的Pods。如果 .spec.selector 中的标签是 .spec.template.metadata.labels 的子集，则这种匹配是有效的。但如果 .spec.template.metadata.labels 中缺少 .spec.selector 中的任何一个标签，或者标签值不同，那么配置将被视为无效，Kubernetes API将拒绝这个配置。

6、查看DaemonSet

6.1、查看DaemonSet列表

kubectl get ds -n default -o wide

NAME：DaemonSet的名称。在这个例子中，DaemonSet的名称是simple-daemonset。

DESIRED：这是DaemonSet期望在集群中运行的Pod数量。对于DaemonSet而言，这通常是集群中节点的数量，因为DaemonSet的目标是在每个节点上运行至少一个Pod的实例。在这个例子中，DESIRED的值是2，是因为集群有两个节点。

CURRENT：这是DaemonSet当前管理的Pod数量。理想情况下，CURRENT的值应该等于DESIRED的值，这意味着DaemonSet已经达到了其目标状态。在这个例子中，CURRENT的值也是2，与DESIRED相匹配。

READY：这是DaemonSet管理的Pod中处于就绪状态的数量。就绪状态（Ready）意味着Pod中的所有容器都已经启动并且健康检查（如果有的话）已通过。在这个例子中，READY的值是2，表明Pod已经准备好并正在运行。

UP-TO-DATE：这是当前正在运行的Pod中与DaemonSet最新模板匹配的数量。当DaemonSet更新其Pod模板时，这个数字可以帮助你跟踪更新进度。在这个例子中，UP-TO-DATE的值是2，意味着所有运行的Pod都使用了最新的模板。

AVAILABLE：这是DaemonSet管理的Pod中可以服务流量的数量。这个数字通常与READY相同，除非某些Pod由于某种原因被标记为不可用。在这个例子中，AVAILABLE的值是2，与READY一致。

NODE SELECTOR：这是DaemonSet使用的节点选择器，它定义了哪些节点可以运行DaemonSet的Pod。表示DaemonSet没有使用节点选择器，它的Pod可以在任何节点上运行。如果NODE SELECTOR包含特定的键值对，那么DaemonSet的Pod将仅在具有相应标签的节点上运行。

AGE：这是DaemonSet的创建时间，以持续时间的形式给出。在这个例子中，DaemonSet的AGE是65s，意味着它在65秒前创建。

6.2、查看 DaemonSet 控制器所创建的 Pod 副本信息

kubectl get pods -n default -o wide

7、滚动更新

7.1、查看DaemonSet详情

kubectl get ds -n defaultkubectl get daemonset simple-daemonset -n default -o json | jq '.spec.updateStrategy'

可以看到DaemonSet支持RollingUpdate滚动更新策略

• RollingUpdate：这是默认的更新策略。使用 RollingUpdate 更新策略时，在更新 DaemonSet 模板后， 老的 DaemonSet Pod 将被终止，并且将以受控方式自动创建新的 DaemonSet Pod。 更新期间，最多只能有 DaemonSet 的一个 Pod 运行于每个节点上。
• maxSurge：定义了在更新过程中可以超出desiredNumberScheduled（期望的Pod数量）的额外Pod数量。在这个例子中，maxSurge设置为0，意味着在更新过程中不会创建超过当前期望数量的额外Pod。换句话说，DaemonSet在终止一个旧的Pod之前不会创建一个新的Pod。
• maxUnavailable：定义了在更新过程中可以有多少Pod不可用。maxUnavailable设置为1，意味着在更新过程中，可以有最多1个Pod不可用。这通常发生在旧的Pod被终止，而新的Pod尚未完全启动并变得可用时。
• type ：为 RollingUpdate 是要启用 DaemonSet 的滚动更新功能必须设置的

7.2、更新nginx镜像版本

kubectl set image daemonsets simple-daemonset nginx-container=nginx:1.14.0 -n default

7.3、查看滚动更新状态

kubectl rollout status ds simple-daemonset -n default

7.4、查看DS滚动更新过程

kubectl describe ds simple-daemonset -n default

7.5、查看DS滚动更新版本

kubectl rollout history ds simple-daemonset -n default

REVERSION1就是初始版本

8、版本回退

8.1、回滚

kubectl rollout undo daemonset -n default simple-daemonset --to-revision=1

8.2、查看版本回退情况

kubectl describe ds simple-daemonset -n default

9、删除DaemonSet

9.1、直接删除DS

kubectl delete ds simple-daemonset -n default

9.2、基于创建的资源清单删除DS

kubectl delete -f daemonset.yaml

四、DaemonSet调度

1、调度方式

DaemonSet通过kubernetes默认的调度器scheduler会在所有的node节点上运行一个Pod副本，可以通过如下三种方式将Pod运行在部分节点上

• 指定 nodeName 节点运行
• 通过标签运行 nodeSelector
• 通过亲和力调度 node Affinity 和 node Anti-affinity
• 污点与容忍度（Tolerations 和 Taints）
• Priority 和 Preemption (优先级和抢占)

2、指定nodeName节点运行

这种方式通常不用于 DaemonSet，因为 DaemonSet 的目标是在尽可能多的节点上运行 Pod 副本。但是可以通过 .spec.nodeName 来指定特定节点运行 Pod。

2.1、原理机制

• 当为 Pod 指定了具体的 nodeName 后，Kubernetes 调度器将跳过调度过程，直接将 Pod 分配给指定的节点。
• 这种方式通常用于测试目的或者在特殊场景下使用，例如当您需要确保某个 Pod 在特定节点上运行时。

2.2、示例

2.2.1、创建一个DaemonSet资源清单，指定nodeName

cat <<EOF > daemonset-nodename.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-nodename
spec:selector:matchLabels:way: nodenametemplate:metadata:labels:way: nodenamespec:nodeName: k8s-node1  # 指定 nodeNamecontainers:- name: daemon-nodename-containerimage: nginx:latest
EOF

2.2.2、应用 DaemonSet

kubectl apply -f daemonset-nodename.yaml

2.2.3、查看 DaemonSet Pod 的状态

kubectl get pods -l way=nodename -o wide

3、通过标签运行 (nodeSelector)

• nodeSelector 是一种简单的方式，用于指定 Pod 应该运行在具有特定标签的节点上。
• 当在 Pod 模板中定义了 nodeSelector，Kubernetes 调度器会将 Pod 分配到具有相应标签的节点上。

3.1、原理机制

• 需要在节点上设置特定的标签。
• 在 DaemonSet 的 Pod 模板中定义 nodeSelector，指定节点标签。
• Kubernetes 调度器会根据 nodeSelector 将 Pod 分配到符合条件的节点上。

3.2、示例

3.2.1、给 k8s-node1 添加标签

kubectl label nodes k8s-node1 role=worker

3.2.2、创建DaemonSet 资源清单，使用nodeSelector

cat <<EOF > daemonset-nodeselector.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-nodeselector
spec:selector:matchLabels:way: nodeSelectortemplate:metadata:labels:way: nodeSelectorspec:nodeSelector:  # 使用 nodeSelectorrole: workercontainers:- name: daemonset-nodeselector-containerimage: nginx:latest
EOF

3.2.3、应用 DaemonSet

kubectl apply -f daemonset-nodeselector.yaml

3.2.4、查看 DaemonSet Pod 的状态

kubectl get pods -l way=nodeSelector -o wide

3.2.5、删除k8s-node1上的标签

测试完及时删除标签

kubectl label nodes k8s-node1 role-

4、通过亲和力调度 (node Affinity 和 node Anti-affinity)

4.1、Node Affinity (节点亲和性)

4.1.1、原理

• Node Affinity 是一种调度策略，允许定义的 Pod 必须或应该调度到哪些节点上。
• 这种策略分为两类：requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution。
• requiredDuringSchedulingIgnoredDuringExecution 表示必须满足的硬性要求。
• preferredDuringSchedulingIgnoredDuringExecution 表示可选的偏好。

4.1.2、给node-k8s2添加标签

按照节点亲和性原理，pod最终会被调度到k8s-node2这个节点上

kubectl label nodes k8s-node2 role=worker

4.1.3、创建 DaemonSet 资源清单，使用 nodeAffinity

cat <<EOF> daemonset-affinity.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-affinity
spec:selector:matchLabels:way: nodeAffinitytemplate:metadata:labels:way: nodeAffinityspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: roleoperator: Invalues:- workercontainers:- name: daemon-affinity-containerimage: nginx:latest
EOF

4.1.4、应用DaemonSet

kubectl apply -f daemonset-affinity.yaml

4.1.5、查看 DaemonSet Pod 的状态

kubectl get pods -l way=nodeAffinity -o wide

4.2、Node Anti-affinity (节点反亲和性)

4.2.1、原理

• Node Anti-affinity 是一种调度策略，允许您定义 Pod 不应该调度到哪些节点上。
• 这种策略也是分为两类：requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution。
• requiredDuringSchedulingIgnoredDuringExecution 表示必须满足的硬性要求。
• preferredDuringSchedulingIgnoredDuringExecution 表示可选的偏好。

4.2.2、给node-k8s2添加标签

按照节点反亲和性原理，节点不会被调度到k8s-node2上

kubectl label node k8s-node2 ROLE=worker2

4.2.3、创建 DaemonSet 资源清单，使用 node Anti-affinity

cat <<EOF > daemonset-Anti-affinity.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-anti-affinity
spec:selector:matchLabels:way: Anti-affinitytemplate:metadata:labels:way: Anti-affinityspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: ROLEoperator: DoesNotExist- key: ROLEoperator: NotInvalues:- worker2containers:- name: daemonset-anti-affinity-containerimage: nginx:latest
EOF

4.2.4、应用DaemonSet

kubectl apply -f daemonset-Anti-affinity.yaml

4.2.5、查看 DaemonSet Pod 的状态

kubectl get pods -l way=Anti-affinity -o wide

5、污点与容忍度（Tolerations 和 Taints）

• Taints（污点） 是节点上的标记，用于排斥 Pod。
• Tolerations（容忍度） 则是 Pod 上的配置，用于容忍节点上的 taints。

5.1、原理

• 节点可以设置 taints 来排斥 Pod。
• Pod 可以设置 tolerations 来容忍这些 taints。
• Kubernetes 调度器会根据 tolerations 和 taints 的匹配情况来决定 Pod 是否可以被调度到节点上。

5.2、示例

5.2.1、给 k8s-node1 添加 taint

• k8s-node1: 有污点 example.com/taint-key=taint-value:NoSchedule
• k8s-node2: 没有污点

kubectl taint nodes k8s-node1 example.com/taint-key=taint-value:NoExecute

5.2.2、创建 DaemonSet 资源清单

省略了 tolerations 部分。这意味着 DaemonSet 的 Pod 不会容忍任何污点，因此它将不会被调度到带有 example.com/taint-key=taint-value:NoExecute 污点的节点上。

cat <<EOF > daemonset-no-tolerations.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-no-tolerations
spec:selector:matchLabels:way: no-tolerationstemplate:metadata:labels:way: no-tolerationsspec:containers:- name: daemonset-no-tolerations-containerimage: nginx:latest
EOF

5.2.3、应用Daemonset

kubectl apply -f daemonset-no-tolerations.yaml

5.2.4、 查看 DaemonSet Pod 的状态

kubectl get pods -l way=no-tolerations -o wide

五、如何与 DaemonSet 中的 Pod 进行通信

1、 推送（Push）

• 推送模式是指 DaemonSet 中的 Pod 主动将数据发送到其他服务或系统中，如统计数据库或其他后端服务。
• 这种模式不需要外部客户端主动连接到 DaemonSet 中的 Pod。

1.1、实现

• 配置 DaemonSet:
  • 需要在 DaemonSet 中的 Pod 规格中配置相应的逻辑，使其能够主动发送数据。
  • 通常，这涉及到使用像 HTTP 请求、消息队列或其他通信协议来发送数据。

1.2、示例

日志聚合:

• 可以使用像 Fluentd 或 Logstash 这样的工具，配置它们将日志数据推送到像 Elasticsearch 或 Splunk 这样的后端。
• 在 daemonset-tolerations.yaml 文件中，您需要配置容器以发送日志数据：

apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-tolerations
spec:selector:matchLabels:way: tolerationstemplate:metadata:labels:way: tolerationsspec:containers:- name: daemonset-tolerations-containerimage: nginx:latestcommand: ["sh", "-c", "while true; do echo 'Log message'; sleep 10; done | fluentd -t -l /dev/stdin"]volumeMounts:- mountPath: /var/log/nginxname: log-volumevolumes:- name: log-volumehostPath:path: /var/log/nginx

这里我们假设 Fluentd 服务已经配置好，并且 Pod 将日志数据推送给 Fluentd。

2、 NodeIP 和已知端口

• NodeIP 和已知端口是指 DaemonSet 中的 Pod 使用 hostPort，这意味着它们监听在节点的主机端口上。
• 外部客户端可以通过节点的 IP 地址和预先定义的端口来连接到这些 Pod。

2.1、实现

• 配置 DaemonSet:
  • 在 DaemonSet 中的 Pod 规格中暴露 hostPort。
  • 客户端可以通过查询节点列表或通过其他方式获得节点 IP 地址，并使用预先定义的端口进行连接。

2.2、示例

监控系统:

• 假设有一个监控系统，需要从每个节点收集指标。
• 可以配置 DaemonSet 中的每个 Pod 监听在节点的一个特定端口上，比如 9100。
• 在 daemonset-tolerations.yaml 文件中，配置容器以暴露端口：

apiVersion: apps/v1
kind: DaemonSet
metadata:name: daemonset-tolerations
spec:selector:matchLabels:way: tolerationstemplate:metadata:labels:way: tolerationsspec:containers:- name: daemonset-tolerations-containerimage: nginx:latestports:- containerPort: 80hostPort: 9100

• 获取节点ip

kubectl get nodes -o jsonpath='{range .items[*]}{.status.addresses[?(@.type=="ExternalIP")].address}{"\n"}{end}'

3、DNS

• DNS 模式是指创建一个无头服务（Headless Service），它使用与 DaemonSet 中的 Pod 相同的选择器。
• 无头服务会创建一个 DNS 记录，该记录解析为 DaemonSet 中所有 Pod 的 IP 地址。

3.1、实现

• 创建无头服务:
  • 创建一个无头服务，其选择器与 DaemonSet 的选择器相同。
  • 无头服务将自动创建一个 DNS 记录，该记录指向所有匹配的 Pod 的 IP 地址。
  • 客户端可以通过查询 DNS 记录来获取所有 Pod 的 IP 地址列表，并进行通信。

3.2、示例

创建一个无头服务 my-daemonset-service，其选择器与 DaemonSet 相同。

apiVersion: v1
kind: Service
metadata:name: my-daemonset-service
spec:clusterIP: Noneselector:way: tolerationsports:- name: httpport: 80targetPort: 80

• 客户端查询 DNS:
  • 客户端可以通过查询 DNS 记录 my-daemonset-service.default.svc.cluster.local 来获取所有 Pod 的 IP 地址。
  • 可以通过 nslookup 或 dig 命令来查询 DNS 记录：

nslookup my-daemonset-service.default.svc.cluster.local

4、Service

• Service 模式是指创建一个服务，其选择器与 DaemonSet 中的 Pod 相同。
• 客户端可以通过服务名称来访问 DaemonSet 中的任意 Pod。

4.1、实现

• 创建服务:
  • 创建一个服务，其选择器与 DaemonSet 的选择器相同。
  • 服务将自动创建一个 DNS 记录，该记录解析为当前活动的 Pod 的 IP 地址。
  • 客户端可以通过服务名称来访问 Pod。

4.2、示例

• 创建一个服务 my-daemonset-service，其选择器与 DaemonSet 相同。

apiVersion: v1
kind: Service
metadata:name: my-daemonset-service
spec:selector:way: tolerationsports:- name: httpport: 80targetPort: 80

• 客户端访问服务:
  • 客户端可以通过服务名称 my-daemonset-service.default.svc.cluster.local 来访问 DaemonSet 中的任意 Pod。
  • 由于服务是负载均衡的，客户端可能会随机连接到不同的 Pod。