k8s
  • Initial page
  • 序言
  • 前言
    • 发展历史
    • CNCF - 云原生计算基金会简介
    • Kubernetes与云原生应用的概念
  • 概念与原理
    • 基本概念总结
    • 开放接口
      • CRI - Container Runtime Interface
      • CNI - Container Network Interface
      • CSI - Container Storage Interface
    • 核心概念与原理
      • Kubernetes简介
      • Kubernetes架构与原理
      • 核心组件
      • 设计理念
      • 核心组件原理
        • etcd概念与原理
          • Etcd基于RAFT的一致性
          • Etcd v2 与 v3存储
        • kube-apiserver
        • kube-scheduler
        • kube-Controller Manager
        • Kubelet
        • kubectl常用命令
      • kubectl
      • kube-proxy
      • IPVS负载均衡
      • kube-dns
      • Federation-集群联邦
      • kubeadm
    • 资源对象与基本概念解析
    • 资源对象
      • Pod
        • Pod概述
        • Pod解析
        • Pod 的生命周期
        • 探针
        • Init 容器
        • Pause容器
        • Pod 安全策略
        • Pod hook
        • Pod Preset
        • pod其他设置
        • Pod中断与PDB
    • Kubernetes中的网络
      • 图解Kubernetes网络(一)
      • 图解Kubernetes网络(二)
      • 图解Kubernetes网络(三)
      • calico
      • flannel
    • 转发K8S后端服务的四种方式
    • 集群资源对象
      • Node
      • Namespace
      • Label
      • Annotation
      • Taint和Toleration(污点和容忍
      • 垃圾收集
      • Autoscaling
      • Horizontal Pod Autoscaling
        • Metrics-Server
        • Heapster
      • ReplicationController和ReplicaSet
    • 控制器资源对象
      • CronJob
      • Job
      • DaemonSet
      • Deployment
      • StatefulSet
    • 服务发现-资源对象
      • DNS原理讲解
      • Ingress 选型
      • Service
      • Ingress
    • 存储对象
      • ConfigMap
      • Volume
      • Persistent Volume(持久化卷)
      • StorageClass
      • 本地持久化存储
      • Secret
    • 策略对象
      • Resource Quota
      • SecurityContext
    • 身份对象
      • 认证
      • Service Account
      • RBAC——基于角色的访问控制
      • 准入控制
      • Network Policy
    • 资源调度
      • QoS(服务质量等级)
  • 插件扩展
    • Kubernetes的CI/CD
    • Dashboard
    • CoreDNS
    • 监控
      • 概述
      • 第1章 采集
        • Probes
        • Docker Stats
        • cAdvisor
        • Heapster
          • HPA
        • metrics-server
        • custom metrics自定义指标
        • kube-state-metrics
        • node-exporter
        • Prometheus
          • go 自定义metric
          • 本地存储
          • Prometheus概述
          • Prometheus基本架构
          • Prometheus部署方案
          • Prometheus的配置与服务发现
          • PromQL查询解析
          • Prometheus数据可视化
          • Prometheus存储机制
        • Sysdig
        • Untitled
      • 自定义监控
      • Custom-Metrics及Prometheus监控系统
      • grafana各种类型监控-实用
    • 日志
    • 存储
      • Kubernetes Ceph 工作原理详解
    • Metrics
    • GPU
    • Cluster AutoScaler
    • CI/CD
      • 基于DOCKER的CI工具—DRONE
      • DRONE安装指南
      • 如何使用DRONE
      • Drone
      • Jenkins
        • jenkins 集成 keycloak 认证
    • 50个免费的Kubernetes工具盘点
      • Kube集群部署工具
      • 监控工具
      • 测试工具
      • 安全工具
      • 实用的CLI工具
      • 开发工具
      • 无服务器/函数工具
      • 原生服务发现
      • 原生可视化与控制
    • Untitled
  • 领域应用
    • Istio
      • Helm安装
      • 安装并试用Istio service mesh
      • 示例应用部署
      • Bookinfo 应用-
      • 配置请求的路由规则
      • 故障注入
      • 流量转移
      • Istio流量管理实现机制深度解析
      • istio:监控能力介绍
      • Istio 04:Istio性能及扩展性介绍
      • Untitled
  • 实践
    • 大规模集群
    • 高可用
  • k8s运维排查
    • 常用命令
    • Kubernetes之YAML文件
      • yaml文件例子--pod
      • yaml文件例子--rc
    • Kubernetes运维
      • 集群管理
      • 集群与应用监控
      • 日志收集与管理
      • 常见问题定位
      • 权限管理RBAC
    • 排错概览
    • 集群排错
      • kubernetes集群管理常用命令一
    • Pod 排错
    • 网络排错
      • 容器内抓包定位网络问题
    • PV 排错
    • Windows 排错
    • 云平台排错
    • 集群安装脚本
    • 排错工具
    • 常见问题
      • k8s故障解决干货文档链接
      • 记一次Docker/Kubernetes上无法解释的连接超时原因探寻之旅
      • service没有负载均衡
      • kubernetes集群etcd空间配额2G的坑优化
    • K8S--100问
      • 解决 Docker 日志文件太大的问题
      • Kubernetes集群里容器之间的通讯方式
      • k8s 优化
      • lxcfs 在容器内显示容器的 CPU、内存状态
      • kubectl 创建 Pod流程
      • k8s网络-iptables
      • k8s底层网络原理
      • 网络排查
      • kubectl top 和 cadvisor metric ,docker state不一致的问题
      • 容器挂载数据卷的几种情况
      • 容器的终止流程
      • Kubernetes 中如何保证优雅地停止 Pod
      • K8S的apiVersion
      • 如何在Pod中执行宿主机上的命令
      • 创建 Pod 流程
      • k8s主要组件说明
      • 节点网络规划
      • Deployment管理方式
      • pod的分配方式
  • 深入浅出k8s
    • 说明
    • k8s发布策略介绍
    • oom kill原理讲解
    • Kubernetes 的架构设计与实现原理
  • 附录
    • CKA认证
    • 生态圈
    • 资讯快报
      • 2018态势回顾与2019年前景展望
      • Untitled
    • 学习资源
    • 参考文档
    • Kubernetes版本更新日志
      • Kubernetes 1.14 更新日志
      • Kubernetes 1.13 更新日志
      • Kubernetes1.12更新日志
      • Kubernetes1.10更新日志
      • Kubernetes1.11更新日志
  • 思维导图
    • k8s
    • DEVOPS
  • DEVOPS
    • 开源仓库-nexus
      • 一,nexus的安装
      • 二,使用nexus3配置docker私有仓库
      • 三,使用nexus3配置maven私有仓库
      • 四,nexus-3.14.0升级到3.15.2
      • 五,nexus3搭建golang私服
    • vpn
      • openvpn
    • Tcpdump 示例教程
    • Ipsec VPN-centos7使用strangwang搭建vpn
    • yum安装redis及常用指令
    • 数据库
      • mysql表操作
      • mysql 库常用操作及备份还原
      • MySQL 优化实施方案
    • NSQ
      • nsq问题解答
      • 选型
      • docker-compose部署 简单nsq 集群
    • 部署Redis集群
    • zookeeper安装及使用
    • Etcd
      • Untitled
      • Etcd配置
  • k8s系统完整部署
    • CentOS7.5 使用二进制程序部署Kubernetes1.12.2
    • 二进制的方式部署 K8S-1.16 高可用集群
    • CoreOS部署Kubernetes集群
    • EFK
      • 日志-kafka
      • logstash的部署、整合ELK+Filebeat
      • 应用日志收集
      • ES搭建
      • es集群部署
      • ElasticSearch技术原理
      • Elasticsearch操作
      • kibana
      • kibana简单使用
      • 非K8S主机部署Filebat
    • 镜像仓库-Harbor
    • Harbor 2.6.2安装
    • cURL 命令获取本机外网 IP
    • Shell 解析 JSON
    • 制作 gitbook 文档镜像,运行在 K8S 上
    • Kubernetes 之 MySQL 持久存储和故障转移
    • 如何删除etcd上的旧数据
    • Git 实战教程
  • 生活
    • 信合.阳光城
Powered by GitBook
On this page
  • 什么是 DaemonSet?
  • 编写 DaemonSet Spec
  • 仅在相同的 Node 上运行 Pod
  • 如何调度 Daemon Pod
  • 与 Daemon Pod 通信
  • 更新 DaemonSet
  • 滚动更新
  • 回滚
  • init 脚本
  • 裸 Pod
  • 静态 Pod
  • 指定 Node 节点
  • nodeSelector 示例
  • nodeAffinity 示例
  • podAffinity 示例
  1. 概念与原理
  2. 控制器资源对象

DaemonSet

PreviousJobNextDeployment

Last updated 6 years ago

什么是 DaemonSet?

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

使用 DaemonSet 的一些典型用法:

  • 系统程序:运行集群存储 daemon,例如在每个 Node 上运行 glusterd、ceph。

  • 日志收集:在每个 Node 上运行日志收集 daemon,例如fluentd、logstash。

  • 系统监控:在每个 Node 上运行监控 daemon,例如 、collectd、Datadog 代理、New Relic 代理,或 Ganglia gmond。

一个简单的用法是,在所有的 Node 上都存在一个 DaemonSet,将被作为每种类型的 daemon 使用。 一个稍微复杂的用法可能是,对单独的每种类型的 daemon 使用多个 DaemonSet,但具有不同的标志,和/或对不同硬件类型具有不同的内存、CPU要求。

编写 DaemonSet Spec

必需字段

和其它所有 Kubernetes 配置一样,DaemonSet 需要 apiVersion、kind 和 metadata字段。有关配置文件的通用信息,详见文档 、 和 。

DaemonSet 也需要一个 配置段。

Pod 模板

.spec 唯一必需的字段是 .spec.template。

.spec.template 是一个 。 它与 具有相同的 schema,除了它是嵌套的,而且不具有 apiVersion 或 kind 字段。

Pod 除了必须字段外,在 DaemonSet 中的 Pod 模板必须指定合理的标签(查看 )。

Pod Selector

spec.selector 表示一个对象,它由如下两个字段组成:

  • matchExpressions - 允许构建更加复杂的 Selector,可以通过指定 key、value 列表,以及与 key 和 value 列表的相关的操作符。

当上述两个字段都指定时,结果表示的是 AND 关系。

如果指定了 .spec.selector,必须与 .spec.template.metadata.labels 相匹配。如果没有指定,它们默认是等价的。如果与它们配置的不匹配,则会被 API 拒绝。

如果 Pod 的 label 与 selector 匹配,或者直接基于其它的 DaemonSet、或者 Controller(例如 ReplicationController),也不可以创建任何 Pod。 否则 DaemonSet Controller 将认为那些 Pod 是它创建的。Kubernetes 不会阻止这样做。一个场景是,可能希望在一个具有不同值的、用来测试用的 Node 上手动创建 Pod。

仅在相同的 Node 上运行 Pod

如何调度 Daemon Pod

正常情况下,Pod 运行在哪个机器上是由 Kubernetes 调度器进行选择的。然而,由 Daemon Controller 创建的 Pod 已经确定了在哪个机器上(Pod 创建时指定了 .spec.nodeName),因此:

  • DaemonSet Controller 可以创建 Pod,即使调度器还没有被启动,这对集群启动是非常有帮助的。

与 Daemon Pod 通信

与 DaemonSet 中的 Pod 进行通信,几种可能的模式如下:

  • Push:配置 DaemonSet 中的 Pod 向其它 Service 发送更新,例如统计数据库。它们没有客户端。

  • NodeIP 和已知端口:DaemonSet 中的 Pod 可以使用 hostPort,从而可以通过 Node IP 访问到 Pod。客户端能通过某种方法知道 Node IP 列表,并且基于此也可以知道端口。

  • Service:创建具有相同 Pod Selector 的 Service,并使用该 Service 访问到某个随机 Node 上的 daemon。(没有办法访问到特定 Node)

更新 DaemonSet

如果修改了 Node Label,DaemonSet 将立刻向新匹配上的 Node 添加 Pod,同时删除新近无法匹配上的 Node 上的 Pod。

可以修改 DaemonSet 创建的 Pod。然而,不允许对 Pod 的所有字段进行更新。当下次 Node(即使具有相同的名称)被创建时,DaemonSet Controller 还会使用最初的模板。

可以删除一个 DaemonSet。如果使用 kubectl 并指定 --cascade=false 选项,则 Pod 将被保留在 Node 上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将鞥能够通过 Label 匹配识别所有已经存在的 Pod。它不会修改或删除它们,即使是错误匹配了 Pod 模板。通过删除 Pod 或者 删除 Node,可以强制创建新的 Pod。

滚动更新

v1.6 + 支持 DaemonSet 的滚动更新,可以通过 .spec.updateStrategy.type 设置更新策略。目前支持两种策略

  • OnDelete:默认策略,更新模板后,只有手动删除了旧的 Pod 后才会创建新的 Pod

  • RollingUpdate:更新 DaemonSet 模版后,自动删除旧的 Pod 并创建新的 Pod

在使用 RollingUpdate 策略时,还可以设置

  • .spec.updateStrategy.rollingUpdate.maxUnavailable, 默认 1

  • spec.minReadySeconds,默认 0

回滚

v1.7 + 还支持回滚

# 查询历史版本$ kubectl rollout history daemonset <daemonset-name>​# 查询某个历史版本的详细信息$ kubectl rollout history daemonset <daemonset-name> --revision=1​# 回滚$ kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision># 查询回滚状态$ kubectl rollout status ds/<daemonset-name>

init 脚本

很可能通过直接在一个 Node 上启动 daemon 进程(例如,使用 init、upstartd、或 systemd)。这非常好,然而基于 DaemonSet 来运行这些进程有如下一些好处:

  • 像对待应用程序一样,具备为 daemon 提供监控和管理日志的能力。

  • 为 daemon 和应用程序使用相同的配置语言和工具(如 Pod 模板、kubectl)。

  • Kubernetes 未来版本可能会支持对 DaemonSet 创建 Pod 与 Node升级工作流进行集成。

  • 在资源受限的容器中运行 daemon,能够增加 daemon 和应用容器的隔离性。然而这也实现了在容器中运行 daemon,但却不能在 Pod 中运行(例如,直接基于 Docker 启动)。

裸 Pod

可能要直接创建 Pod,同时指定其运行在特定的 Node 上。 然而,DaemonSet 替换了由于任何原因被删除或终止的 Pod,例如 Node 失败、例行节点维护,比如内核升级。由于这个原因,我们应该使用 DaemonSet 而不是单独创建 Pod。

静态 Pod

除了 DaemonSet,还可以使用静态 Pod 来在每台机器上运行指定的 Pod,这需要 kubelet 在启动的时候指定 manifest 目录:

kubelet --pod-manifest-path=/etc/kubernetes/manifests

然后将所需要的 Pod 定义文件放到指定的 manifest 目录中。

注意:静态 Pod 不能通过 API Server 来删除,但可以通过删除 manifest 文件来自动删除对应的 Pod

Replication Controller

指定 Node 节点

DaemonSet 会忽略 Node 的 unschedulable 状态,有两种方式来指定 Pod 只运行在指定的 Node 节点上:

  • nodeSelector:只调度到匹配指定 label 的 Node 上

  • nodeAffinity:功能更丰富的 Node 选择器,比如支持集合操作

  • podAffinity:调度到满足条件的 Pod 所在的 Node 上

nodeSelector 示例

首先给 Node 打上标签

kubectl label nodes node-01 disktype=ssd

然后在 daemonset 中指定 nodeSelector 为 disktype=ssd:

spec:  nodeSelector:    disktype: ssd

nodeAffinity 示例

nodeAffinity 目前支持两种:requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution,分别代表必须满足条件和优选条件。比如下面的例子代表调度到包含标签 kubernetes.io/e2e-az-name 并且值为 e2e-az1 或 e2e-az2 的 Node 上,并且优选还带有标签 another-node-label-key=another-node-label-value 的 Node。

apiVersion: v1kind: Podmetadata:  name: with-node-affinityspec:  affinity:    nodeAffinity:      requiredDuringSchedulingIgnoredDuringExecution:        nodeSelectorTerms:        - matchExpressions:          - key: kubernetes.io/e2e-az-name            operator: In            values:            - e2e-az1            - e2e-az2      preferredDuringSchedulingIgnoredDuringExecution:      - weight: 1        preference:          matchExpressions:          - key: another-node-label-key            operator: In            values:            - another-node-label-value  containers:  - name: with-node-affinity    image: gcr.io/google_containers/pause:2.0

podAffinity 示例

podAffinity 基于 Pod 的标签来选择 Node,仅调度到满足条件 Pod 所在的 Node 上,支持 podAffinity 和 podAntiAffinity。这个功能比较绕,以下面的例子为例:

  • 如果一个 “Node 所在 Zone 中包含至少一个带有 security=S1 标签且运行中的 Pod”,那么可以调度到该 Node

  • 不调度到 “包含至少一个带有 security=S2 标签且运行中 Pod” 的 Node 上

apiVersion: v1kind: Podmetadata:  name: with-pod-affinityspec:  affinity:    podAffinity:      requiredDuringSchedulingIgnoredDuringExecution:      - labelSelector:          matchExpressions:          - key: security            operator: In            values:            - S1        topologyKey: failure-domain.beta.kubernetes.io/zone    podAntiAffinity:      preferredDuringSchedulingIgnoredDuringExecution:      - weight: 100        podAffinityTerm:          labelSelector:            matchExpressions:            - key: security              operator: In              values:              - S2          topologyKey: kubernetes.io/hostname  containers:  - name: with-pod-affinity    image: gcr.io/google_containers/pause:2.0

在 DaemonSet 中的 Pod 模板必需具有一个值为 Always 的 ,或者未指定它的值,默认是 Always。

.spec.selector 字段表示 Pod Selector,它与 或其它资源的 .sper.selector 的原理是相同的。

matchLabels - 与 的 .spec.selector 的原理相同。

如果指定了 .spec.template.spec.nodeSelector,DaemonSet Controller 将在能够匹配上 的 Node 上创建 Pod。 类似这种情况,可以指定 .spec.template.spec.affinity,然后 DaemonSet Controller 将在能够匹配上 的 Node 上创建 Pod。 如果根本就没有指定,则 DaemonSet Controller 将在所有 Node 上创建 Pod。

DaemonSet Controller 并不关心一个 Node 的 字段。

Daemon Pod 关心 ,它们会为没有指定 tolerationSeconds 的 node.alpha.kubernetes.io/notReady 和 node.alpha.kubernetes.io/unreachable 的 Taint,而创建具有 NoExecute 的 Toleration。这确保了当 alpha 特性的 TaintBasedEvictions 被启用,当 Node 出现故障,比如网络分区,这时它们将不会被清除掉(当 TaintBasedEvictions 特性没有启用,在这些场景下也不会被清除,但会因为 NodeController 的硬编码行为而被清除,Toleration 是不会的)。

DNS:创建具有相同 Pod Selector 的 ,然后通过使用 endpoints 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。

在 Kubernetes 1.6 或以后版本,可以在 DaemonSet 上 。

很可能,通过在一个指定目录下编写文件来创建 Pod,该目录受 Kubelet 所监视。这些 Pod 被称为 。 不像 DaemonSet,静态 Pod 不受 kubectl 和 其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver,这使得它们在集群启动的情况下非常有用。 而且,未来静态 Pod 可能会被废弃掉。

DaemonSet 与 非常类似,它们都能创建 Pod,这些 Pod 都具有不期望被终止的进程(例如,Web 服务器、存储服务器)。 为无状态的 Service 使用 Replication Controller,像 frontend,实现对副本的数量进行扩缩容、平滑升级,比之于精确控制 Pod 运行在某个主机上要重要得多。需要 Pod 副本总是运行在全部或特定主机上,并需要先于其他 Pod 启动,当这被认为非常重要时,应该使用 Daemon Controller。

Prometheus Node Exporter
部署应用
配置容器
资源管理
.spec
Pod 模板
Pod
pod selector
RestartPolicy
Job
ReplicationController
Node Selector
Node Affinity
unschedulable
Taint 和 Toleration
Headless Service
执行滚动升级
静态 Pod
Replication Controller