Kubernetes DaemonSet、StatefulSet与Service（自用笔记）

**一、**DaemonSet (DS)

1.1****定义与特点

核心特性：确保集群中每个节点运行且仅运行一个Pod副本

|----------|---------------------------------|
| 特性 | 说明 |
| 调度方式 | 创建Pod副本时不经过调度器，强制分布 |
| 动态性 | 新增节点自动创建Pod，移除节点自动删除Pod |
| Master限制 | Master节点有污点(Taint)，普通Pod默认无法调 度 |

1.2****工作流程

1.3 DaemonSet vs Deployment

|---------|---------------|------------------|
| 对比页 | DaemonSet | Deployment |
| 副本分布 | 每个节点仅一个Pod | 随机调度，可能多Pod在同一节点 |
| 调度方式 | 不经过调度器 | 通过调度器调度 |
| 典型场景 | 运维组件 | 业务应用 |

1.4YAML结构

yaml

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: nginx-daemonset
    spec:
      selector:
         matchLabels:
           app: nginx
      updateStrategy:           # 滚动更新策略
         type: RollingUpdate
      template:
        metadata:
           labels:
             app: nginx
        spec:
           containers:
           - name: nginx
              image: nginx:1.14

1.5典型应用场景

1.节点日志收集（如Filebeat、Fluentd）
2.节点资源监控（如Node Exporter）
3.存储守护进程（如Ceph OSD）

1.6自愈能力验证

|---------|-----------------------------|
| 操作 | 结果 |
| 手动删除Pod | DaemonSet控制器自动重建，保持每个节点一个副本 |
| 新增节点 | 自动创建Pod副本 |
| 移除节点 | 自动删除对应Pod |

二、StatefulSet（STS）

2.1****有状态服务定义

需要管理客户端状态、启动顺序和数据持久化的服务
如：MySQL主从、Redis集群、ZooKeeper
核心需求：
Pod名称不能随机变化（涉及主从识别）
数据目录需区分
启停顺序固定

2.2 StatefulSet****特点

|----------|----------------------------------|
| 特点 | 说明 |
| 固定标识 | Pod名称永久不变（如 web-0, web-1, web-2） |
| 有序性 | 启动从小到大(0→1→2)，停止从大到小 (2→1→0) |
| 独立存储 | 每个Pod拥有独立的持久化存储卷 |

2.3有状态VS无状态

|------------|--------------------------------------|-----------------------------|
| 特性 | 无状态服务 (Deployment/DaemonSet) | 有状态服务 (StatefulSet) |
| Pod名称 | 随机生成，不固定 | 固定有序（web-0, web-1...） |
| Pod IP | 可变 | 可变（通过域名访问） |
| 启停顺序 | 无要求 | 严格有序 |
| 存储 | 共享或无存储 | 独立持久化存储 |
| 网络标识 | 通过Service统一访问 | 需要Headless Service |

三、Service

3.1Service的作用

Service是一个逻辑概念，聚合相同标签的Pod，提供统一入口地址
解决的问题：
1.Pod IP易变，无法直接依赖
2.需要稳定的访问入口

3.2 DNS****解析机制

K8s内部DNS（CoreDNS）：
为每个Service生成域名
Pod内 /etc/resolv.conf 配置nameserver
域名格式：
<service-name>.<namespace>.svc.cluster.local
解析流程：
Pod访问service-name → CoreDNS解析 → Service ClusterIP → 转发到后端Pod

3.3Service四种类型

|------------------|----------|------------------------|----------------|
| 类型 | 访问范围 | 特点 | 适用场景 |
| ClusterIP | 集群内部 | 默认类型，分配虚拟 IP | 内部服务通信 |
| NodePort | 外部访问 | 每个节点开放端口 (30000-32767) | 测试环境、暴露少量 服务 |
| ExternalName | 集群内部 | 映射到外部域名 (CNAME) | 访问外部服务 |
| LoadBalancer | 外部访问 | 依赖云厂商LB | 生产环境、需要外部 LB支持 |

NodePort****配置示例

yaml

    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-service
    spec:
      type: NodePort
      selector:
         app: nginx
      ports:
      - port: 80
        targetPort: 80
        nodePort: 30080       # 指定端口，不指定则自动分配

NodePort缺点：端口数量有限(30000-32767）
ExternalName****配置示例

yaml

    apiVersion: v1
    kind: Service
    metadata:
      name: external-service
    spec:
      type: ExternalName
      externalName: api.example.com

四、Kube-proxy工作模式

4.1****三种模式对比

|---------------|-------------------|----------------|------------------|---------|
| 模式 | 原理 | 优点 | 缺点 | 推荐度 |
| Userspace | kube-proxy充当 四层LB | 稳定性好 | 效率低 | 已淘汰 |
| IPtables | 生成IPtables规 则 | 效率高 | 不支持灵活LB算 法，失败不重试 | 默认模式 |
| IPV | 生成IPVS规则， 内核级LB | 性能极高，支持 多种LB算法 | 需额外配置 | 生产推荐 |

4.2切换到IPVS****模式

bash

    # 1. 所有节点加载内核模块
    modprobe ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack

    # 2. 安装ipvsadm工具
    yum install -y ipvsadm

    # 3. 修改kube-proxy ConfigMap
    kubectl edit configmap kube-proxy -n kube-system
    # 将 mode: "" 改为 mode: "ipvs"

    # 4. 删除kube-proxy Pod使其重启
    kubectl delete pod -n kube-system -l k8s-app=kube-proxy

    # 5. 验证IPVS规则
    ipvsadm -Ln

4.3IPVS支持的负载均衡算法

|--------------------------|--------|
| 算法 | 说明 |
| rr (Round Robin) | 轮询 |
| lc (Least Connections) | 最少连接 |
| dh (Destination Hashing) | 目标地址哈希 |
| sh (Source Hashing） | 源地址哈希 |

**五、**Headless Service

5.1定义

yaml

    apiVersion: v1
    kind: Service
    metadata:
       name: headless-service
    spec:
       clusterIP: None # 关键：不分配ClusterIP
       selector:
          app: nginx
       ports:
       - port: 80

5.2与普通Service****的区别

|---------------|------------------|----------------------|
| 特性 | 普通Service | Headless Service |
| ClusterIP | 分配虚拟IP | None |
| DNS记录 | 一个A记录指向ClusterIP | 每个Pod一个A记录 |
| 访问方式 | 只能访问Service | 可直接访问每个Pod |

5.3 Pod****域名格式

<pod-name>.<service-name>.<namespace>.svc.cluster.local
示例：web-0.nginx-service.default.svc.cluster.local

5.4配合StatefulSet

StatefulSet必须关联Headless Service

原因：
1.每个Pod获得固定域名
2.即使Pod重建、IP变化，域名不变
3.满足有状态服务对稳定网络标识的需求
验证：

bash

    # 解析Pod域名
    nslookup web-0.nginx-service.default.svc.cluster.local

    # 返回Pod的IP（非Service IP）

六、总结与面试重点

6.1****核心区别

|-----------------|----------|----------|----------|
| 控制器 | 状态类型 | 调度方式 | 典型场景 |
| Deployment | 无状态 | 调度器调度 | 业务应用 |
| DaemonSet | 无状态 | 不经调度器 | 运维组件 |
| StatefulSet | 有状态 | 有序调度 | 数据库集群 |

6.2Service类型选择

集群内部通信 → ClusterIP
测试环境暴露服务 → NodePort
访问外部服务 → ExternalName
生产环境暴露服务 → LoadBalancer

6.3 Kube-proxy****模式

面试必答：
1.IPVS是生产推荐模式
2.原因：性能高、支持多种LB算法
3.切换方式：修改ConfigMap + 重启Pod

6.4****故障排查思路

Service无法访问排查路径：

1. 检查Service Endpoints → kubectl get endpoints
2. 检查Pod状态 → kubectl get pods
3. 检查kube-proxy日志 → kubectl logs -n kube-system
4. 检查IPtables/IPVS规则 → iptables -t nat -L / ipvsadm -Ln

关键记忆点：

1.DaemonSet：每节点一个Pod，不经调度器
2.StatefulSet：Pod名称固定，有序启停，配合Headless Service
3.Service四种类型：ClusterIP / NodePort / ExternalName / LoadBalancer
4.Kube-proxy三种模式：Userspace(淘汰) / IPtables(默认) / IPVS(推荐)