好的，各位观众老爷，程序员界的少男少女们，欢迎来到今天的“Kubernetes DaemonSet 深度应用：集群范围服务部署”特别节目！我是你们的老朋友，人称BUG制造机，debug小能手的程序猿小明。 今天咱们不谈风花雪月，只聊硬核技术！
准备好了吗？ Let’s dive in! 🚀
开场白：DaemonSet，你这磨人的小妖精！
话说在云原生的大舞台上，Kubernetes可谓是当之无愧的C位明星。它像一位技艺精湛的魔术师，将容器玩转于股掌之间。然而，即使是再强大的魔术师，也需要一些得力助手来完成那些看似不起眼，却至关重要的任务。
今天我们要聊的DaemonSet，就是这样一位默默奉献的幕后英雄。它就像一位尽职尽责的管家，确保集群中的每个节点都运行着特定类型的Pod，守护着整个集群的健康与安全。
你可能会问： “小明， DaemonSet这名字听起来就有点高冷，感觉很难搞啊！”
别怕！其实DaemonSet并没有你想象的那么可怕。它就像一位外表严肃，内心温柔的大叔，只要你掌握了正确的使用方法，它就会成为你集群管理中最可靠的伙伴。
第一幕：DaemonSet的前世今生
要理解DaemonSet的妙用，我们先来回顾一下它的诞生背景。
在没有DaemonSet之前，如果我们想在每个节点上运行一个服务，比如日志收集器、监控代理等，通常需要手动部署，或者编写复杂的脚本来完成。这种方式不仅效率低下，而且容易出错。想象一下，当你需要管理成百上千个节点时，手动部署简直就是一场噩梦！😱
为了解决这个问题，Kubernetes的开发者们推出了DaemonSet。DaemonSet的设计初衷很简单： 确保集群中的每个节点都运行一个指定的Pod副本。
它就像一位勤劳的园丁，负责在每个节点上种下一颗种子（Pod），并确保这些种子茁壮成长。无论你新增了多少节点，DaemonSet都会自动在新节点上部署相应的Pod，让你无需再为手动部署而烦恼。
第二幕：DaemonSet的庐山真面目
DaemonSet本质上是一种Kubernetes资源对象，用于定义需要在每个节点上运行的Pod。它由以下几个关键部分组成：
- Selector： 用于指定DaemonSet管理的Pod的标签选择器。只有符合标签的Pod才会被DaemonSet管理。
- Template： 定义Pod的模板，包括容器镜像、资源需求、环境变量等。
- UpdateStrategy： 定义更新Pod的策略，例如滚动更新或重建。
下面是一个简单的DaemonSet的YAML示例：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-elasticsearch
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd
image: k8s.gcr.io/fluentd-elasticsearch:1.20
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
- name: config-volume
mountPath: /etc/fluent/config.d
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: config-volume
configMap:
name: fluentd-elasticsearch字段解释：
| 字段 | 描述 |
|---|---|
apiVersion |
指定API版本，这里是apps/v1，表示使用了Kubernetes的Apps API的V1版本。 |
kind |
指定资源类型，这里是DaemonSet，表示这是一个DaemonSet资源对象。 |
metadata |
包含关于DaemonSet的元数据，例如名称、命名空间和标签。 |
name |
DaemonSet的名称，这里是fluentd-elasticsearch。 |
namespace |
DaemonSet所属的命名空间，这里是kube-system，表示该DaemonSet运行在kube-system命名空间中。通常，系统级别的服务会部署在这个命名空间。 |
labels |
用于标识DaemonSet的标签，这里使用了k8s-app: fluentd-elasticsearch，可以方便地通过标签选择器来管理和查询该DaemonSet。 |
spec |
定义DaemonSet的期望状态，包括选择器、Pod模板和更新策略。 |
selector |
用于指定DaemonSet管理的Pod的标签选择器，只有符合标签的Pod才会被DaemonSet管理。 |
matchLabels |
指定匹配的标签，这里要求Pod必须包含name: fluentd-elasticsearch标签才能被DaemonSet管理。 |
template |
定义Pod的模板，包括容器镜像、资源需求、环境变量、存储卷等。 |
metadata |
包含Pod的元数据，例如标签。 |
labels |
用于标识Pod的标签，这里使用了name: fluentd-elasticsearch，与DaemonSet的selector中的matchLabels相匹配，确保DaemonSet能够管理这些Pod。 |
spec |
定义Pod的期望状态，包括容器列表、容忍度、终止宽限期和存储卷。 |
tolerations |
定义Pod对污点的容忍度。污点是Node上的一个属性，用于标记节点不应该运行某些类型的Pod。这里使用了node-role.kubernetes.io/master的容忍度，允许Pod运行在Master节点上。 |
containers |
定义Pod中运行的容器列表，每个容器都有自己的名称、镜像、资源限制和挂载点。 |
name |
容器的名称，这里是fluentd。 |
image |
容器使用的镜像，这里是k8s.gcr.io/fluentd-elasticsearch:1.20，表示使用了Google Container Registry中的fluentd-elasticsearch镜像的1.20版本。 |
resources |
定义容器的资源限制和请求，包括CPU和内存。 |
limits |
定义容器可以使用的资源上限，这里限制了内存使用上限为200Mi。 |
requests |
定义容器启动时请求的资源量，这里请求了100m的CPU和200Mi的内存。Kubernetes会根据这些请求来调度Pod到合适的节点上。 |
volumeMounts |
定义容器内部的挂载点，用于将存储卷挂载到容器的指定目录。 |
name |
存储卷的名称，与volumes字段中定义的存储卷名称相对应。 |
mountPath |
容器内部的挂载路径，例如/var/log表示将varlog存储卷挂载到容器的/var/log目录。 |
terminationGracePeriodSeconds |
定义Pod终止时的宽限期，单位为秒。当Pod被删除时，Kubernetes会先向Pod发送一个SIGTERM信号，给应用程序一个优雅退出的时间。如果在宽限期内应用程序没有退出，Kubernetes会强制杀死该Pod。 |
volumes |
定义Pod使用的存储卷列表，包括主机路径卷和配置映射卷。 |
name |
存储卷的名称，与volumeMounts字段中的name相对应。 |
hostPath |
定义主机路径卷，用于将主机上的目录或文件挂载到Pod中。 |
path |
主机上的目录或文件路径，例如/var/log表示将主机上的/var/log目录挂载到Pod中。 |
configMap |
定义配置映射卷，用于将ConfigMap中的配置数据挂载到Pod中。 |
name |
ConfigMap的名称，这里是fluentd-elasticsearch，表示将名为fluentd-elasticsearch的ConfigMap中的数据挂载到Pod中。 |
这段YAML定义了一个名为fluentd-elasticsearch的DaemonSet，它会在每个节点上运行一个Fluentd Pod，用于收集日志并将其发送到Elasticsearch。
第三幕：DaemonSet的十八般武艺
DaemonSet的用途非常广泛，它可以用于部署各种集群范围的服务，例如：
- 日志收集： 使用Fluentd、Logstash等工具收集集群中的日志，并将其发送到集中式存储系统。
- 监控代理： 使用Prometheus Exporter、Datadog Agent等工具收集集群中的监控数据，并将其发送到监控系统。
- 网络插件： 使用Calico、Flannel等工具为集群提供网络功能。
- 存储插件： 使用Ceph、GlusterFS等工具为集群提供持久化存储。
- 安全代理： 使用Falco等工具监控集群中的安全事件。
总而言之，只要你需要在每个节点上运行一个服务，DaemonSet就是你的不二之选。👍
第四幕：DaemonSet的进阶技巧
掌握了DaemonSet的基本用法，我们再来探索一些进阶技巧，让你的DaemonSet更加强大。
-
使用Node Affinity和Tolerations：
默认情况下，DaemonSet会在所有节点上部署Pod。但有时我们可能只想在特定类型的节点上运行DaemonSet Pod。这时，可以使用Node Affinity和Tolerations来实现。
-
Node Affinity： 允许你根据节点的标签来选择节点。例如，你可以使用Node Affinity来指定DaemonSet Pod只能运行在具有特定硬件配置的节点上。
-
Tolerations： 允许Pod容忍节点的污点（Taints）。污点是节点上的一个属性，用于标记节点不应该运行某些类型的Pod。例如，你可以使用Tolerations来允许DaemonSet Pod运行在Master节点上。
-
-
使用UpdateStrategy进行滚动更新：
当我们需要更新DaemonSet的Pod模板时，可以使用UpdateStrategy来控制更新过程。Kubernetes提供了两种UpdateStrategy：
-
RollingUpdate： 滚动更新会逐步更新DaemonSet的Pod，一次更新一个或多个Pod，直到所有Pod都更新完成。这种方式可以最大限度地减少服务中断时间。
-
OnDelete： 只有在手动删除旧的Pod后，才会创建新的Pod。这种方式适用于对服务中断时间不敏感的场景。
-
-
使用Resource Quotas和Limit Ranges：
为了防止DaemonSet Pod过度消耗资源，可以使用Resource Quotas和Limit Ranges来限制DaemonSet Pod的资源使用。
- Resource Quotas： 限制命名空间中所有资源的总体使用量。
- Limit Ranges： 限制命名空间中每个Pod或容器的资源使用范围。
-
使用HostPort和HostNetwork：
有时，DaemonSet Pod需要直接访问主机上的网络接口或端口。这时，可以使用HostPort和HostNetwork来实现。
-
HostPort： 将容器的端口映射到主机的端口。
-
HostNetwork： 使Pod直接使用主机的网络命名空间。
-
第五幕：DaemonSet的实战演练
说了这么多理论，不如来点实际的。我们来演示一个使用DaemonSet部署Fluentd日志收集器的例子。
-
创建ConfigMap：
首先，我们需要创建一个ConfigMap来存储Fluentd的配置文件。
apiVersion: v1 kind: ConfigMap metadata: name: fluentd-config namespace: kube-system data: fluentd.conf: | <source> @type tail path /var/log/containers/*.log pos_file /var/log/fluentd-containers.log.pos tag kubernetes.* read_from_head true </source> <filter kubernetes.**> @type kubernetes_metadata </filter> <match kubernetes.**> @type elasticsearch host elasticsearch.kube-system.svc.cluster.local port 9200 index_name fluentd-${tag_parts[1]}-${Time.now.strftime("%Y.%m.%d")} include_tag_key true tag_key @log_name flush_interval 5s </match> -
创建DaemonSet：
接下来，我们创建一个DaemonSet来部署Fluentd Pod。
apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: kube-system spec: selector: matchLabels: app: fluentd template: metadata: labels: app: fluentd spec: containers: - name: fluentd image: fluent/fluentd:v1.14.6-1.0 volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true - name: fluentd-config mountPath: /etc/fluentd/config volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers - name: fluentd-config configMap: name: fluentd-config -
部署DaemonSet：
使用kubectl命令部署DaemonSet。
kubectl apply -f fluentd-config.yaml kubectl apply -f fluentd-daemonset.yaml -
验证DaemonSet：
使用kubectl命令查看DaemonSet的状态。
kubectl get daemonsets -n kube-system你应该看到类似如下的输出：
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE AGE fluentd 3 3 3 3 3 1m这表示DaemonSet已经成功部署，并且在所有节点上都运行着Fluentd Pod。
第六幕：DaemonSet的常见问题与解决方案
在使用DaemonSet的过程中，你可能会遇到一些问题。下面是一些常见问题及其解决方案：
- DaemonSet Pod无法启动： 检查Pod模板中的镜像是否存在，资源需求是否合理，以及Node Affinity和Tolerations是否配置正确。
- DaemonSet Pod无法更新： 检查UpdateStrategy是否配置正确，以及是否有足够的资源来创建新的Pod。
- DaemonSet Pod无法访问主机资源： 检查HostPort和HostNetwork是否配置正确，以及是否有权限访问主机资源。
第七幕：DaemonSet的未来展望
随着云原生技术的不断发展，DaemonSet的应用场景也将越来越广泛。未来，我们可以期待DaemonSet在以下方面发挥更大的作用：
- 边缘计算： 在边缘节点上部署DaemonSet Pod，实现边缘数据的采集、处理和分析。
- 物联网： 在物联网设备上部署DaemonSet Pod，实现设备管理、数据传输和远程控制。
- 安全防护： 在每个节点上部署安全代理，实时监控集群中的安全事件，并及时采取措施。
尾声：DaemonSet，你值得拥有！
好了，各位观众老爷，今天的“Kubernetes DaemonSet 深度应用：集群范围服务部署”特别节目就到这里了。希望通过今天的讲解，你对DaemonSet有了更深入的理解。
DaemonSet就像一位默默奉献的幕后英雄，它在集群中扮演着至关重要的角色。只要你掌握了正确的使用方法，它就会成为你集群管理中最可靠的伙伴。
记住，技术的世界是充满乐趣的，只要你保持好奇心，不断学习，你就能成为一名优秀的云原生工程师！
下次再见！ 👋