K8s -Daemonset,kube-proxy,service,statefulset

一、核心概念与使用场景

本质：确保每个符合条件的节点上都运行一个特定的 Pod 实例。当有新节点加入集群时，DaemonSet 会自动在新节点上创建 Pod；当节点被删除时，对应的 Pod 也会被垃圾回收。

典型使用场景：

日志收集：如 Fluentd、Filebeat，采集每个节点上容器和系统的日志。
监控代理：如 Prometheus Node Exporter、Datadog agent，采集节点指标。
网络插件：如 Calico、Flannel、Cilium，需要在每个节点上配置网络规则或虚拟设备。
存储插件：如 Ceph RBD、GlusterFS，管理节点上的存储卷挂载。
节点维护操作 ：如节点修复、证书轮换等一次性任务（常配合 hostPID 和特权模式）。

二、调度策略（重点理解）

DaemonSet 默认会忽略节点的 unschedulable 状态 （即 kubectl cordon 的节点），依然会调度 Pod。它会使用自己的调度逻辑，但可以通过以下方式控制调度行为：

配置方式	说明
`nodeSelector`	只调度到拥有特定标签的节点
`nodeAffinity`	更灵活的节点亲和性，支持 `requiredDuringScheduling` 等
`tolerations`	允许 Pod 调度到有污点（Taints）的节点（如 master 节点）

关键点：

默认情况下，DaemonSet 不会调度到 master 节点，因为 master 通常有 node-role.kubernetes.io/master:NoSchedule 污点。若需要运行 master 上，需添加对应的 toleration。
调度器行为：DaemonSet 的 Pod 由 DaemonSet Controller 直接创建，绕过默认调度器（但 kubelet 会监听并启动）。因此，PodSpec 中最好不要设置 schedulerName，否则可能导致调度异常。

示例：在 master 和普通节点上运行 DaemonSet

yaml

复制代码

tolerations:
  - key: node-role.kubernetes.io/master
    effect: NoSchedule

三、更新策略

DaemonSet 支持两种更新策略，通过 spec.updateStrategy.type 指定：

策略	行为	适用场景
`RollingUpdate`（默认）	逐个节点更新 Pod，可控制 `maxUnavailable`（默认 1）	常规场景，保证服务不中断
`OnDelete`	只有手动删除 Pod 后才会创建新 Pod	需要精细控制更新时机或验证新版本

滚动更新参数 （仅 RollingUpdate 策略）：

maxUnavailable：更新期间最多有多少个节点不可用。可以是绝对数或百分比（如 30%）。设置过大会影响服务能力，过小则更新慢。

回滚：kubectl rollout undo daemonset/<name>，类似 Deployment。

四、资源隔离与访问节点资源

DaemonSet 常用于直接操作节点资源，因此需要配置：

hostNetwork ：使用宿主机网络栈（端口与宿主机共享）。设置后，spec.containers.ports 会直接绑定到节点 IP。
hostPID / hostIPC：共享宿主机进程和 IPC 命名空间（谨慎使用）。
privileged ：特权模式（可执行几乎所有宿主机操作，如 kubectl 挂载文件系统）。
volumeMounts ：挂载宿主机目录（如 /var/log、/var/lib/docker、/proc）。

安全提醒：赋予这些权限时需严格评估，避免容器逃逸风险。

五、与 Deployment 的关键区别

特性	DaemonSet	Deployment
Pod 副本数	每个节点最多一个，不可修改 replicas	可自由设置 replicas
调度策略	节点维度，自动覆盖所有匹配节点	集群维度，按资源/亲和性调度
滚动更新	按节点逐个更新	按 replicas 比例更新
典型用途	节点级基础设施	无状态应用（Web、API 等）

六、常见问题和最佳实践

1. Pod 卡在 Pending 状态？

检查节点是否有污点（kubectl describe node），未加 toleration 会阻止调度。
检查资源是否充足（CPU/Memory），DaemonSet Pod 同样受 LimitRange 和 ResourceQuota 限制。
检查 nodeSelector 或 nodeAffinity 是否匹配任何节点。

2. 滚动更新时 Pod 被驱逐但未重建？

检查 maxUnavailable 设置是否小于等于1且节点数较少（如单节点集群），更新会卡住。
检查 Pod 是否有 terminationGracePeriodSeconds 过长的进程，导致删除超时。

3. 如何在部分节点上运行 DaemonSet？

使用 nodeSelector 或 nodeAffinity 限定节点范围。不要在 DaemonSet 中设置 replicas（会忽略）。

4. DaemonSet Pod 重启策略？

restartPolicy 必须是 Always（默认），因为 DaemonSet 期望 Pod 持续运行。

5. 与 Headless Service 配合 ：通常不需要暴露 DaemonSet 到 Service，但若需直接访问节点上的 Pod（例如监控抓取），可以使用 Headless Service 配合 endpoints（或手动配置）。

七、快速命令参考

bash

复制代码

# 创建 DaemonSet（从 yaml）
kubectl apply -f daemonset.yaml

# 查看状态
kubectl get ds -n <namespace>
kubectl describe ds <name>

# 查看 Pod 分布
kubectl get pods -o wide -l app=<label>

# 更新镜像（滚动更新）
kubectl set image ds/<name> <container>=<new-image>

# 回滚
kubectl rollout undo ds/<name>

# 暂停/恢复更新
kubectl rollout pause ds/<name>
kubectl rollout resume ds/<name>

总结记忆口诀

节点一个 Pod，守护常驻跑。
副本不许改，标签很重要。
母机资源用，污点要容忍。
滚动按节点，回滚立马好。

一、什么是 kube-proxy？

kube-proxy 是 Kubernetes 集群中负责维护节点网络规则 的核心组件。当你在集群中创建一个 Service 来为一组 Pod 提供稳定的访问入口时，kube-proxy 会负责在所有节点上设置相应的转发规则，确保访问 Service 的流量被正确分发到健康的 Pod 上。

二、工作原理：监听 API Server，更新本地规则

每个节点上的 kube-proxy 进程都会持续监听 Kubernetes API Server，实时获取 Service 和 EndpointSlice 的变化。一旦监听到有 Service 被创建、删除，或者其后端 Pod 的 IP 发生了变化，kube-proxy 就会立即在节点上更新相应的转发规则（例如 iptables 或 IPVS 规则），确保流量始终可以被正确地转发到可用的 Pod 上，从而实现服务发现和负载均衡。

三、三种工作模式详解及选型

kube-proxy 通过不同的模式来实现流量转发，不同的模式在性能、功能和运维复杂度上各有侧重。

特性	iptables 模式	IPVS 模式	nftables 模式
核心原理	利用 Linux 内核的 iptables 功能，为每个 Service 设置大量的 NAT 规则链。	利用 Linux 内核专为负载均衡设计的 IPVS 模块，通过哈希表实现高效转发。	使用新一代的 nftables 框架，旨在统一和替代 iptables，规则集更为简洁高效。
查找算法	规则链匹配，时间复杂度 O(n)*	哈希表查找，时间复杂度 O(1)	查找性能优于 iptables
负载均衡算法	仅支持随机转发	支持 rr, lc, sh, dh 等多种高级调度算法	丰富，可类比 IPVS
大规模场景性能	随着 Service 数量增加，性能显著下降。社区建议 Service 数少于 3000	高性能，适合大规模集群	高性能，有望成为未来主流
排障与可见性	`iptables-save` 查看、跟踪规则链直观	需学习 `ipvsadm` 等新命令	需学习 `nft` 新命令
状态	当前默认模式	稳定，推荐用于大规模集群	v1.29+ Alpha

(O(n) 指的是算法复杂度随规则数量的增长而线性增长，在大规模服务下会导致明显的网络延迟)

如何选择模式

中小规模集群 ：从默认的 iptables 模式开始，简单可靠，能满足基本需求。
大规模或高并发集群 ：强烈建议切换到 IPVS 模式，以解决 iptables 模式的性能瓶颈。
关注点 ：nftables 模式作为未来趋势，值得关注，但目前尚不成熟。

四、生产环境性能优化与参数调优 (IPVS 模式)

在生产环境中，对 kube-proxy 进行调优是保障集群网络稳定性的关键。

1. 内核参数调优 (`sysctl`)

net.ipv4.vs.conn_reuse_mode ：最重要的参数之一。建议在内核版本 >= 5.9 的节点上，不要由 kube-proxy 修改，让内核使用其默认值（通常是 1）。社区和厂商的修复均建议使用高版本内核来从根本上解决问题，以避免连接复用导致流量被转发到已销毁 Pod 的 Bug。

2. 连接跟踪 (Conntrack) 调优

高并发场景下，连接跟踪表是常见瓶颈。

--conntrack-max-per-core ：每个 CPU 核心的最大连接跟踪数，默认 32768。
--conntrack-min ：连接跟踪表的最小条目数，默认 131072。
--conntrack-tcp-timeout-established ：已建立的 TCP 连接空闲超时，默认为 24h。

3. 高级调度算法配置

你可以在 Service 的 Annotation 中指定调度算法，例如：

ipvs.scheduler: "sh"：启用源地址哈希算法，实现基于客户端 IP 的会话保持。
ipvs.scheduler: "lc"：启用最少连接算法，将请求分发给当前活跃连接数最少的 Pod。

五、高可用与故障排查

高可用机制

kube-proxy 作为 DaemonSet 部署，其高可用性由 Kubernetes 自身保证。API Server 是无状态的，因此某个 kube-proxy Pod 的故障只会影响它所在的节点。

常见故障与排查思路

连接失败/1秒延迟 (IPVS 模式) ：通常由conn_reuse_mode导致。解决方案是升级节点内核至 4.19+ （推荐 5.9+），并检查内核参数设置。
规则更新失败 (iptables 模式) ：kube-proxy 需要写入 iptables 规则。xtables.lock 锁文件缺失或权限问题会导致操作失败。
Pod 滚动更新时连接异常 ：这是由于客户端所在节点的 kube-proxy 规则更新慢于 Pod 销毁。可以为 Pod 添加一个 preStop Hook，让 Pod 在真正销毁前先等待一段时间，以确保其他节点的 kube-proxy 完成规则更新。

总结

kube-proxy 是 Kubernetes 集群网络的基石，可以把它想象成一个灵活、高效的"软件负载均衡器集群"。在理解其工作原理后，生产实践中可以遵循以下原则：

中小集群 ：从 iptables 模式开始。
大规模集群 ：优先选择 IPVS 模式。
高并发场景 ：关注 conn_reuse_mode 等内核参数的配置。
日常运维 ：善用 iptables-save、ipvsadm -Ln 等命令进行排障。
技术演进 ：保持对 nftables 模式的关注。

在了解了 DaemonSet 和 kube-proxy 之后，Service 就是连接这两者的关键桥梁。如果说 kube-proxy 是一个个网络规则配置的执行者，那么 Service 就是这些规则所服务的**"统一访问入口"**。

与 DaemonSet 在每个节点固定运行一个 Pod 不同，Service 的核心价值在于为一组动态变化的 Pod 提供一个固定的 IP 地址 和DNS 域名，实现服务发现和负载均衡。

一、为什么需要 Service？

Pod 具有"临时性"：

IP 地址动态分配，一旦重建就会改变。
访问 Pod 的 IP 地址不稳定。
无法对多个副本 Pod 进行负载均衡。

Service 通过标签选择器（Label Selector） 识别一组 Pod，无论这些 Pod 如何动态变化，客户端都不需要关心，Service 会自动感知变化，提供稳定访问入口。

二、四种 Service 类型

spec.type 决定了 Service 的访问方式，这是 Service 最核心的配置。

类型	访问范围	关键特点	适用场景
ClusterIP （默认）	仅在集群内部	分配一个内部虚拟 IP，只在集群内可访问。	集群内服务间的通信，如前端调用后端 API。
NodePort	集群外部	在每个节点上开放一个静态端口，通过 `节点IP:端口` 从外部访问。	适用于开发测试环境，或临时对外暴露服务。
LoadBalancer	集群外部	在 NodePort 的基础上，自动创建云厂商的外部负载均衡器，分配公网 IP。	生产环境对外暴露服务的主流方式。
ExternalName	集群外部	通过 `spec.externalName` 将 Service 映射到一个外部的 DNS 域名（如 `api.example.com`）。	无代理地将集群内服务指向外部服务。

三、两种负载均衡策略

Service 提供了两种简单的流量分发策略：

RoundRobin （默认）：轮询模式，将请求依次发给每个后端 Pod。
sessionAffinity：ClientIP ：基于客户端 IP 的会话保持，将来自同一客户端的请求始终转发到同一个 Pod，以维持会话状态。超时时间通过 sessionAffinityConfig.clientIP.timeoutSeconds 设置，默认 10800 秒。

四、背后的工作机制

当你创建 Service 时，Kubernetes 控制平面会做两件重要的事情：

创建 EndpointSlice ：Service 会持续监控匹配的 Pod 状态。当 Pod 的 IP 地址发生变化时，系统会自动创建或更新同名的 EndpointSlice 对象，它存储了当前所有健康 Pod 的 IP 和端口列表。
生成网络规则 ：节点上的 kube-proxy 组件会实时监听 Service 和 EndpointSlice 的变化，并在每个节点上更新网络规则，将发往 Service IP 的流量转发到 EndpointSlice 中记录的某个 Pod IP 上。

五、代理模式对比

kube-proxy 有两种主要的工作模式来生成这些规则：

特性	iptables 模式	IPVS 模式
性能	规则为链表，复杂度 O(n)。适合 Service 数量较少的集群（建议 < 1000）。	基于哈希表，查找复杂度 O(1)，性能高，适合大规模集群。
连通性	集群内部 ClusterIP 地址无法 ping 通。	集群内部 ClusterIP 地址可以 ping 通（v1.27+ 集群除外）。
负载均衡算法	随机平等的选择算法。	支持 `rr`（轮询）、`lc`（最少连接）、`sh`（源地址哈希）等 10+ 种算法。

六、高级模式与场景

除了标准的用法，Service 还有一些高级模式：

Headless Service ：通过设置 clusterIP: None，Service 将不再分配虚拟 IP。客户端通过 DNS 解析会直接获得所有后端 Pod 的 IP 列表，适用于需要自行选择 Pod 的场景，如 StatefulSet。
无选择器的 Service ：如果 selector 为空，Kubernetes 不会自动创建 EndpointSlice，需要手动创建一个同名的 EndpointSlice 来指向外部的服务 IP 或不在本集群内的 Pod，常用于对接外部数据库或跨集群访问。
多端口 Service ：一个 Service 可以定义多个端口映射，只需确保每个端口有唯一的 name 即可。

七、Service 与 Ingress 的区别

需要注意的是，Service 通常工作在 OSI 模型的第 4 层（TCP/UDP），而 Ingress 工作在第 7 层（HTTP/HTTPS）。

Ingress ：更像一个"七层路由规则"，需要配合 Ingress Controller（如 Nginx）实现，可以根据域名、URL 路径等将流量路由到不同的 Service。
关系：Ingress 不是 Service 的替代品，而是它的"上层建筑"。Ingress 的请求流量，最终仍需要交给某个 Service（通常是 ClusterIP 类型）来处理。

八、安全与资源隔离

网络策略（NetworkPolicy） ：Service 只负责"转发流量"，而 NetworkPolicy 负责"允许/拒绝流量"。可以创建 NetworkPolicy 来定义哪些 Pod 可以访问某个 Service 的特定端口，实现微隔离。

九、Service 与 Pod 对比（误区澄清）

特性	Service	Pod
生命周期	持久化，删除重建才能改变 ClusterIP	临时，被控制器删除重建后 IP 会变化
IP 地址	ClusterIP 一旦分配，删除 Service 前几乎不变	Pod IP 是动态、临时的
作用	为动态 Pod 提供稳定访问入口，服务发现与负载均衡	运行实际应用的实体
直接替换对象	ClusterIP 类型 Service 可作为直接的访问目标	不应作为客户端直接访问的目标

十、生产环境最佳实践

明确访问范围 ：根据服务的访问者决定类型。集群内部使用 ClusterIP ；对外暴露首选 LoadBalancer （生产）或 Ingress ；NodePort 仅测试或特殊场景使用。
优雅关闭与排空 ：为 Pod 设置 terminationGracePeriodSeconds，并在 Service 对应的 Pod 中配置 preStop Hook，确保 Pod 被销毁时连接已排空，避免服务中断。
选择合适的代理模式 ：大规模集群（Service 数量 > 1000）建议启用 IPVS 模式以提升性能。
管理网络策略：为关键 Service 配置 NetworkPolicy，遵循最小权限原则，明确来源 Pod 的访问权限。
统一命名规范：为 Service 和其选择的 Pod 使用清晰的标签，方便管理和排查。

一、核心价值：为什么需要 StatefulSet？

Deployment 管理的 Pod 具有以下特点（不适用于有状态应用）：

Pod 名称随机（如 myapp-xxx-yyy），重建后名称改变。
Pod 的存储卷不持久化，重启后数据丢失。
Pod 的启动/销毁顺序不固定。
Pod 没有独立的网络标识，对外不可区分。

StatefulSet 专门解决这些问题，为有状态应用（如数据库、消息队列、分布式存储）提供：

稳定的 Pod 名称 （如 mysql-0、mysql-1）
稳定的网络标识（通过 Headless Service 提供固定 DNS A 记录）
顺序启停和滚动更新（从 0 到 N-1 有序）
持久化存储（每个 Pod 有自己独立的 PVC）

二、StatefulSet 的三大核心特性

1. 稳定的 Pod 身份（网络标识）

StatefulSet 中的 Pod 具有唯一且稳定的序号，从 0 到 N-1。即使 Pod 被删除重建，它的名称、主机名和对应的 DNS 地址都不会改变。

Pod 名称 ：<statefulset-name>-<ordinal>（如 redis-0, redis-1）
DNS 地址 ：<pod-name>.<headless-service-name>.<namespace>.svc.cluster.local
- 例如 redis-0.redis-hs.default.svc.cluster.local 始终指向 redis-0 这个 Pod（无论它重建后 IP 如何变化）

这种稳定的 DNS 标识是 StatefulSet 与普通 Service 最大的不同，它允许 Pod 之间相互发现和连接。

2. 顺序、优雅的部署和扩缩容

部署/扩容（从 0 到 N-1） ：严格按序号顺序创建 ，只有当前一个 Pod 处于 Running and Ready 状态后，才会创建下一个 Pod。
缩容（从 N-1 到 0） ：严格按序号逆序删除，最后一个 Pod 完全终止后，才删除前一个。
更新：支持两种更新策略，且可以配置分区更新（见后文）。

这保证了像 etcd、ZooKeeper 这类需要成员资格确认的分布式系统可以安全地逐个加入或退出集群。

3. 稳定的持久化存储

每个 Pod 可以关联一个独立的 PersistentVolumeClaim（PVC） 。StatefulSet 中的 volumeClaimTemplates 字段会为每个 Pod 自动生成一个 PVC：

redis-0 → PVC redis-data-redis-0
redis-1 → PVC redis-data-redis-1
当 Pod 被删除或重新调度时，PVC 和 PV 不会删除，新 Pod 会重新绑定到原有的 PVC，从而恢复数据。

注意：删除 StatefulSet 时，PVC 默认不会自动删除（需要手动清理），这是为了保护数据。

三、StatefulSet 规范详解（关键字段）

yaml

复制代码

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql-hs          # 必须指定，关联的 Headless Service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:          # 关键：每个 Pod 独立 PVC
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi
  updateStrategy:                # 更新策略
    type: RollingUpdate
    rollingUpdate:
      partition: 2               # 分区更新：只更新序号 >= 2 的 Pod

必需字段：

serviceName：指定管理此 StatefulSet 的 Headless Service 名称，用于生成 Pod 的 DNS 记录。
volumeClaimTemplates：每个 Pod 的 PVC 模板（可选，但推荐用于有状态应用）。
podManagementPolicy：默认为 OrderedReady（顺序启停）；可选 Parallel（并行启停，加快操作但可能破坏顺序依赖）。

四、更新策略：细粒度控制

StatefulSet 支持两种更新策略，并允许通过 partition 实现金丝雀发布。

策略	行为	适用场景
`RollingUpdate`（默认）	按序号逆序滚动更新（N-1 到 0），并且更新一个 Pod 后需等待其 Running and Ready 才更新下一个。	常规更新，尽量保证服务不中断。
`OnDelete`	StatefulSet 不自动更新 Pod。只有手动删除某个 Pod 后，重建的新 Pod 才会使用新模板。	需要完全手动控制更新时机。

分区更新（RollingUpdate 下的高级特性）：

设置 partition: N，则只有序号 ≥ N 的 Pod 会被更新，序号 < N 的 Pod 保持旧版本。
用途：实现金丝雀发布（先更新一部分 Pod 验证），或暂停更新（设置 partition 为较大值如 replicas 数量）。

五、与 Deployment 的关键区别

特性	StatefulSet	Deployment
Pod 标识	固定名称（`-0`, `-1`, ...）	随机后缀（`-xxx-yyy`）
网络标识	通过 Headless Service 提供稳定 DNS	无稳定 DNS，Pod IP 变化
存储	每个 Pod 独立 PVC，数据持久化	通常使用临时存储或共享存储（无状态）
启停顺序	顺序（从 0 到 N-1 创建，逆序删除）	并行（无序）
更新策略	顺序逆序更新，支持分区控制	并行更新（可配置 maxSurge/maxUnavailable）
使用场景	数据库、消息队列、分布式协调服务	Web 应用、API 网关、无状态微服务

六、常见问题与生产最佳实践

1. StatefulSet 是否可以修改 Pod 的某些字段？

部分字段不可变，例如 spec.serviceName、volumeClaimTemplates 中的存储大小（需要手动扩容 PVC）。修改 replicas、template 中的镜像等是允许的。

2. 扩容时新 Pod 无法启动？

检查 PVC 模板是否匹配存储类、是否有足够的 PV 供应。新 Pod 会尝试创建新的 PVC，如果存储类不支持动态分配或配额不足会 Pending。

3. 删除了某个 Pod（如 `redis-1`），为什么会自动重建但 PVC 还在？

StatefulSet 确保 Pod 与其 PVC 一一对应，重建的 redis-1 会重新绑定到原来的 PVC redis-data-redis-1，数据得以保留。不要手动删除 PVC，除非你确定要销毁数据。

4. 如何安全地缩容并释放存储？

缩容到 2 个副本：StatefulSet 会删除 redis-2 的 Pod，但 PVC 不会自动删除。如果需要彻底清理数据，需要手动删除 PVC（确保业务已不再需要）。

5. Headless Service 必须存在？

是的，必须在创建 StatefulSet 之前创建好对应的 Headless Service，否则 StatefulSet 无法为 Pod 提供稳定的 DNS 记录。Service 的 clusterIP: None。

6. 优雅终止与数据一致性

对于数据库，配置 terminationGracePeriodSeconds（如 60s）并实现 preStop Hook 来优雅关闭（如执行 FLUSH TABLES 或通知集群节点离开），防止数据损坏。

7. 无序启动（Parallel 模式）使用场景

当你的应用不需要启动顺序时（例如所有 Pod 完全对等且无依赖），可以设置 podManagementPolicy: Parallel 来加速部署和重启。但这会失去顺序保证，请谨慎。

七、总结与记忆要点

StatefulSet 是为有状态应用 量身打造的控制器，核心在于身份、存储、顺序三大稳定性的保证。它与 Deployment 各司其职：

需要 稳定的网络名 、独立的持久存储 、有序部署 → 选择 StatefulSet
其它情况 → 优先选择 Deployment

快速排查三步骤：

确认 Headless Service 是否存在且 clusterIP: None。
检查 PVC 是否创建成功、存储类是否正常。
观察 Pod 启动顺序是否符合预期（kubectl get pods -w）。

掌握了 StatefulSet，你就能够将数据库、消息队列等有状态应用自信地迁移到 Kubernetes 上，享受平台带来的弹性与自动化能力。

K8s -Daemonset,kube-proxy,service,statefulset

一、核心概念与使用场景

二、调度策略（重点理解）

三、更新策略

四、资源隔离与访问节点资源

五、与 Deployment 的关键区别

六、常见问题和最佳实践

七、快速命令参考

总结记忆口诀

一、什么是 kube-proxy？

二、工作原理：监听 API Server，更新本地规则

三、三种工作模式详解及选型

如何选择模式

四、生产环境性能优化与参数调优 (IPVS 模式)

1. 内核参数调优 (sysctl)

2. 连接跟踪 (Conntrack) 调优

3. 高级调度算法配置

五、高可用与故障排查

高可用机制

常见故障与排查思路

总结

一、为什么需要 Service？

二、四种 Service 类型

三、两种负载均衡策略

四、背后的工作机制

五、代理模式对比

六、高级模式与场景

七、Service 与 Ingress 的区别

八、安全与资源隔离

九、Service 与 Pod 对比（误区澄清）

十、生产环境最佳实践

一、核心价值：为什么需要 StatefulSet？

二、StatefulSet 的三大核心特性

1. 稳定的 Pod 身份（网络标识）

2. 顺序、优雅的部署和扩缩容

3. 稳定的持久化存储

三、StatefulSet 规范详解（关键字段）

四、更新策略：细粒度控制

五、与 Deployment 的关键区别

六、常见问题与生产最佳实践

1. StatefulSet 是否可以修改 Pod 的某些字段？

2. 扩容时新 Pod 无法启动？

3. 删除了某个 Pod（如 redis-1），为什么会自动重建但 PVC 还在？

4. 如何安全地缩容并释放存储？

5. Headless Service 必须存在？

6. 优雅终止与数据一致性

7. 无序启动（Parallel 模式）使用场景

七、总结与记忆要点

1. 内核参数调优 (`sysctl`)

3. 删除了某个 Pod（如 `redis-1`），为什么会自动重建但 PVC 还在？