Kubernetes 模式：守护进程服务模式

「【只做懂你de云原生干货知识共享】」

Kubernetes 模式：守护进程服务模式

什么是守护进程？

守护进程是在后台运行的进程。通常，守护进程不会向用户产生可见的输出；它不接受输入。守护进程用于执行后台作业。

例如，在 Linux 中，我们使用 httpd 来响应 HTTP 请求，使用 sshd 授予远程用户安全的远程 shell 访问权限。

我们还有几个不接受用户输入的内核守护进程；它们的存在是为了执行内核正常运行所需的内务管理和其他基本任务。有时，用户可能会创建或安装他们。例如，logrotated是一个流行的 Linux 守护进程，它根据用户定义的设置定期将旧日志文件归档到可配置路径中。另一个例子是日志采集器（filebeat，fluentd等）定期将日志发送到日志聚合服务（如 ELK 堆栈）以进行分析和关联。

我们需要 Kubernetes 集群中的守护进程吗？Kubernetes 通常被称为“数据中心操作系统”。正如我们刚刚讨论的，操作系统需要守护进程来执行用户不（也不应该）与之交互的后台作业。因此，在 Kubernetes 中，更高级别的控制器，如部署需要持续监控正在运行的 Pod 的数量，以便它根据需要生成或杀死 Pod。这样的任务需要通过一个守护进程运行：一个不需要用户交互的后台进程，它一直在运行，主要由 Kubernetes 引擎本身管理。Kubernetes 管理员可能还需要守护进程在运行的节点上执行任务。为此，Kubernetes 提供了 DaemonSet 资源。与 Deployment、ReplicaSet 或 StatefulSet 一样，DaemonSet 创建和管理 Pod。但是，这些 Pod 被配置为可以在所有集群节点上运行。

为什么不直接在节点上安装守护进程？

因为集群不是这样工作的，直接安装在节点上的守护进程不是由 Kubernetes 管理的，而是由节点的操作系统控制并向其报告。您需要对守护程序配置进行的任何更改都需要在每个节点上执行。如果守护进程停止工作或报告错误，Kubernetes 不会为您做任何事情。如果守护进程失败，您需要配置操作系统或某些第三方工具以重新启动守护进程。但是，Kubernetes 不是为这类任务设计的吗？这就是为什么您最好使用 DaemonSet 的原因。

示例：用于日志收集的 Fluentd Daemonset 以下是官方 fluentd daemonset 定义文件的精简版：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
 name: fluentd
 namespace: kube-system
 labels:
   k8s-app: fluentd-logging
   version: v1
spec:
 template:
   metadata:
     labels:
       k8s-app: fluentd-logging
       version: v1
   spec:
     nodeSelector:
       env: prod
     containers:
     - name: fluentd
       image: fluent/fluentd-kubernetes-daemonset:elasticsearch
       volumeMounts:
       - name: varlog
         mountPath: /var/log
       - name: varlibdockercontainers
         mountPath: /var/lib/docker/containers
         readOnly: true
     terminationGracePeriodSeconds: 30
     volumes:
     - name: varlog
       hostPath:
         path: /var/log
     - name: varlibdockercontainers
       hostPath:
         path: /var/lib/docker/containers

让我们仔细看看这个定义的关键组成部分：

第 1-8 行指定了任何 Kubernetes 控制器具有的常见细节：识别该控制器的 API 版本、控制器类型 (DaemonSet)，以及具有该控制器所持有的名称和标签的元数据。

第 9-14 行：我们定义生成的 Pod 将具有的标签。

第 15-17 行：这个 DaemonSet 只需要在生产节点上运行（标记为 env=prod）。nodeSelector 通过只选择带有 env=prod 标签的节点来运行 Pod 来帮助我们解决这个问题。

第 18-20 行定义了此 Pod 使用的容器详细信息。容器运行 fluentd 镜像并命名为 fluentd。

第 21-26 行指定容器可以访问的卷。DaemonSet 通常用于在节点上运行任务，而不是一般的应用程序。因此，我们在这里有两卷：

/var/log 卷提供对系统日志的流畅访问，这些日志通常在 Linux 系统上的此路径中找到。如果您想收集不同的日志或您的系统将其日志存储在其他位置，您应该更改此路径。/var/lib/docker/containers 还可以流畅地访问主机上的容器及其日志。

第 27 行 - 文件的结尾定义了容器使用的卷源。通常，DaemonSet 使用 hostPath 卷类型来访问节点上的文件和目录。

DaemonSet 与 ReplicaSet 有何不同？

DaemonSets 和 ReplicaSets 可能看起来非常相似。但是，它们有几个显着差异：

DaemonSets 在每个节点上运行一个 Pod。这可以根据您所需的场景使用 nodeSelector 或 taints 和 tolerations 进行限制。ReplicaSet 通过选择最合适的节点来运行 Pod 来工作。它并不能保证每个节点都在运行 Pod。

DaemonSets Pod 不需要调度程序来运行。每个 Pod 都已经指定了 nodeName 参数。这使得 DaemonSets 非常适合运行 Kubernetes 系统守护进程。

DaemonSets 创建的 Pod 被 Kubernetes 区别对待。例如，它们比其他 Pod 具有更高的优先级；调度程序不会驱逐它，依此类推。

DaemonSet Pod 访问模式

大多数情况下，您不需要与 DaemonSet 产生的 Pod 进行通信。这些 Pod 主要用于后台任务、内务管理、日志聚合等。但是，如果您确实想向 Pod 发送 HTTP 请求并检查响应怎么办？例如，自定义日志收集 Pod 可能有一个健康或状态端点，显示有关它已经处理的日志数量的信息，是否存在错误等。让我们探索您拥有的不同选择：

创建一个传统的 Service并将 Pod 选择器设置为与 DaemonSet 使用的选择器相同。这种方法的缺点是您总是会从随机节点获得响应。

创建一个使用与 DaemonSet 相同的 Pod 选择器但不公开 IP 地址的无头服务。Headless 服务返回一个它匹配的 Pod 的 IP 地址列表。由您（或您正在使用的客户端软件）来解析响应并选择合适的 Pod 进行通信。

对 DaemonSet Pod使用hostPort选项。使用 hostPort，您可以通过节点的 IP 地址访问 Pod。中间没有服务层。这种方法有一个明显的缺点，因为您受限于节点上端口的可用性。您可以在小型或开发环境中使用此方法。

总结

当您使用 Kubernetes 时，您需要改变看待基础设施的方式。由于您的应用程序 - 及其所有方面 - 在由 Kubernetes 管理的集群内运行，因此与节点几乎没有耦合。在本文中，我们解释了如何通过 DaemonSet 运行通常安装并在节点上运行的守护进程。

DaemonSet 的外观和行为很像 ReplicaSet，它生成 Pod 并确保它们始终运行。但是，DaemonSet 的不同之处在于它们将它们的 Pod 部署到集群中的每个节点（除非您使用 nodeSelector 或 taints 和 tolerations）。另外，由 DaemonSets 创建的 Pods 被区别对待。它们不会被从节点驱逐，并且它们具有更高的优先级。

DaemonSets 最流行的使用场景是日志收集。许多日志聚合产品提供 DaemonSet 模板，用于通过 DaemonSet 在节点上运行其客户端守护程序。