集群架构与组件

• etcdctl 的端点、证书鉴权参数
• 健康检查与成员列表
• 快照备份与恢复的完整流程

在现代 etcd（v3）中，etcdctl 通过 gRPC 对接。健康检查用 endpoint health 与 endpoint status；成员管理用 member list、member add、member remove；键值操作是 put、get、del、watch；快照用 snapshot save 与 snapshot restore。K8s 场景需带 transport 安全参数（--cacert、--cert、--key）和 --endpoints。快照恢复时用 snapshot restore 从备份重建数据目录，再以 etcd 正常方式启动，恢复后需重新添加到集群成员。

考点是常用的运维命令与快照恢复的完整流程。注意 v3 与 v2 命令差异，以及恢复时数据目录需清空、wal 与 snapshot 会重新生成。

• informer 的 list/watch 与本地缓存
• workqueue 的事件驱动与去重
• reconcile 计算期望状态与当前状态的差异

控制环三步：1）informer 通过 List+Watch 从 API Server 获取对象并维护本地缓存，注册事件回调；2）回调把对象放入 workqueue（RateLimitingQueue），队列去重、指数退避重试；3）worker 从队列取出 key，调用 reconcile 函数，读取当前状态并对比期望状态，执行创建/更新/删除以达到期望状态。多 worker 并发处理，控制器通过 Leader Election 保证单副本活动。

核心是 informer 提供事件驱动、workqueue 提供限速与去重、reconcile 保证幂等。这与 client-go 的 controller 框架一致，是所有自定义控制器（Operator）的基础。

• 调度队列与调度周期
• 预选（filter/scheduling cycle）与优选（score）
• 绑定（binding）与异步绑定

流程：1）scheduler 用 informer 监听未调度的 Pod（nodeName 为空）；2）通过调度队列（SchedulingQueue 带 priority 与抢占）选出待调度 Pod；3）调度周期：先跑 pre-filter、filter（预选，选出可行节点，如资源、亲和、污点容忍），再 score（优选，按扩展点打分，如 LeastRequested、NodeAffinity、拓扑），汇总权重选最优节点；4）binding 周期：将 Pod 绑定到节点（写 Pod 的 spec.nodeName），并运行 reserve、permit、prebind、bind、postbind 扩展点；5）bind 完成后 kubelet 在节点上启动 Pod。若无可调度节点，Pod 进入 Pending 并可能触发抢占（preemption）。

核心是 filter（硬约束，决定可行域）与 score（软约束，选最优）两阶段。调度周期与绑定周期分离，绑定异步执行避免阻塞。

• PLEG 的定时轮询与事件生成
• 事件如何驱动 Pod 状态 reconcile
• PLEG 卡死（PLEG is not healthy）的危害

PLEG 周期性调用容器运行时（如 CRI）的接口获取容器状态列表，与上次缓存对比，生成事件（ContainerStarted/Stopped/Changed 等）放入事件 channel。kubelet 的 podWorkers 收到事件后对对应 Pod 执行 reconcile：重新计算 Pod 状态、更新 status、处理容器生命周期。若 PLEG 卡住（运行时无响应），会停止生成事件，导致 Pod 状态不回写、心跳异常，kubelet 会报 "PLEG is not healthy"，最终节点标记 NotReady 并触发 Pod 驱逐。

PLEG 是 kubelet 感知容器变化的桥梁，通过轮询+事件生成实现"事件驱动"。排查 PLEG 卡死通常看容器运行时异常、磁盘/网络问题。

• FlowSchema 将请求归类到优先级
• PriorityLevelConfiguration 的并发配额与排队
• 请求排队、超时与拒绝策略

APF 取代旧的 --max-requests-inflight 全局限流，提供更细粒度公平。FlowSchema 通过匹配规则（subject、resource、verb 等）将请求归入某 PriorityLevel；PriorityLevelConfiguration 定义该级别并发（nominalConcurrencyShares 分配）与队列（queues、handSize、queueLengthLimit）。请求超过并发配额进入队列，队列满则按过期时间拒绝（429/apierror）。APF 通过公平队列保证低优先级请求不被饿死，同时用分片（每个 apiserver 独立配额）保证多副本时整体公平。

核心是"分类+公平排队"。FlowSchema 负责路由，PriorityLevelConfiguration 负责资源与队列。排障时看 apiserver 的 apiserver_flowcontrol 指标与 Rejected 原因。

• deprecation 生命周期（alpha/beta/GA、移除时间）
• 各组件何时移除已弃用 API 等
• 迁移前检查与升级规划

Kubernetes API 先进入 alpha（可能随时改动）、beta（提供），再 GA（stable）。弃用后该 API 版本会保留相当长时间（通常 GA 后至少 12 个月或在后续三版本）才移除。规划迁移：1）升级前用 kubectl convert、kubectl get --show-managed-fields 或 API 探测脚本找出仍在使用已弃用 API 的资源；2）将资源迁移到新版本 API（如 apps/v1beta1 → apps/v1）；3）按版本兼容矩阵逐级升级集群，先升级控制面再升级节点；4）用审计确认无弃用调用。官方会提供 Deprecated API Migration Guide。

核心是"早规划、早迁移、逐级升级"。弃用 API 不会立即消失，给足迁移窗口，但需在升级前清理。

• 升级顺序（control plane → worker）
• 组件版本兼容（kubelet/kube-proxy 与 apiserver 的版本差）
• 单节点升级的维护（drain、cordon）

标准顺序：先升级 control plane 各组件（kubeadm apiserver、controller-manager、scheduler、etcd），再升级 worker 节点。原因：kubelet 允许比 apiserver 低一个次版本（如 apiserver v1.30 可接受 kubelet v1.29），反之不保证。先升级 control plane 后，低版本 worker 仍可工作，再逐批升级 worker。每个 worker 升级前 cordon+drain 排空 Pod，升级后 uncordon。逐批进行，每次验证。回滚时先降级 worker 再降 control plane。

核心是"控制面先行、kubelet 版本兼容下界、逐批 rollout"。这是 kubeadm 升级的标准流程。

• quorum 与容错数（N/2+1）
• 3 vs 5 的故障容忍
• 写性能与延迟

etcd 用 Raft 协议，quorum 为多数派（N/2+1）。3 节点可容忍 1 个失败（2/3 存活即可），5 节点可容忍 2 个失败（3/5 存活）。5 etcd 故障容忍更强，但每次写请求需同步到更多节点，写延迟略高、网络开销更大。大型集群（较多 apiserver 与高写入）倾向 5 etcd 以保障稳定性；中小集群 3 etcd 足够且成本低。etcd 成员越多，扩容与故障后恢复也更复杂。

核心是 quorum 与容错数。3 vs 5 是"容错 vs 性能/成本"的权衡，取决于集群规模与写入压力。

• apiserver 前端负载均衡（LB/keepalived）
• etcd 成员在 control plane 上的分布
• 滚动升级时 leader 选举与迁移

多 control plane 时，apiserver 通过前端负载均衡（如云 LB、Nginx、keepalived 虚拟 IP）暴露给 kubelet 与客户端。etcd 成员通常与 control plane 节点共置（stacked etcd），也可外部独立部署。扩缩容顺序：扩容时先加 etcd 成员（member add 并启动新节点，参与 quorum），再接入 apiserver 并加入 LB 后端；缩容时先从 LB 摘掉 apiserver，再停 apiserver，最后移除 etcd 成员（member remove，保证剩余 quorum 完好）。滚动升级时，leader 自动迁移：先升级副本，旧 leader 退位后其余成员选举新 leader。

核心是"增删成员需保 quorum"与"先接入后摘除"。etcd 成员增删必须保证任意时刻剩余节点满足 quorum，否则可能脑裂或数据丢失。

• member add 与启动新节点
• learner 的角色与好处
• learner 提升为 voting member 的条件

扩容：用 etcdctl member add 注册新成员（或不带 --peer-urls 的联合添加），拿到启动参数后启动新 etcd 进程，它会通过 peer 同步数据。为避免新节点加入时影响 quorum，可先以 learner 角色加入：learner 只接收数据、不参与投票与 quorum，因此加入不会降低集群容错。learner 数据追平后，用 etcdctl member promote <id> 将其提升为 voting member；提升条件是新节点已追上 Raft 日志（与 leader 数据基本一致），否则提升会失败。缩容用 member remove，移除后需保证剩余成员满足 quorum。

learner 是安全扩容的关键，避免"一次性加入拉数据导致 quorum 不稳定"。提升需数据追平。

• local-path-provisioner 的原理
• 默认 StorageClass 与节点绑定
• 限制（单节点、数据不跨节点）

k3s 默认部署 local-path-provisioner，它监听本地目录（默认 /var/lib/rancher/k3s/storage）下的 PVC。当 PVC 请求动态供给时，provisioner 在目标节点上创建目录，并创建绑定该节点的 local PV，PV 使用 nodeAffinity 绑定到创建目录的节点。Pod 调度到该节点后通过 hostPath 挂载。限制：数据只在单节点，Pod 无法跨节点迁移（数据不在该节点则无法调度）；无跨节点复制、无高可用；节点故障数据丢失。

核心是"每个节点本地目录 + 节点亲和绑定"。适合测试/边缘/单节点，不适合多副本有状态应用。

• 服务端证书与私钥的配置
• 证书链与 CA 配置
• 证书轮换

apiserver 通过 --tls-cert-file 指定服务端证书（含完整证书链），--tls-private-key-file 指定对应私钥。证书需包含 apiserver 的域名与各 IP（SAN），用于客户端（kubelet、kubectl、Controller 组件）验证。还可配置 --client-ca-file 指定用于验证客户端证书的 CA。证书轮换时替换文件并重启 apiserver（或使用动态证书重载）。kubeadm 部署会在 /etc/kubernetes/pki 下管理这些证书。

核心是服务端证书+私钥+CA 三者配合。SAN 覆盖必须完整，否则客户端无法验证主机名。

• 参数含义与默认值
• 与只读请求限流的区别
• 超限行为的处理

--max-mutating-requests-inflight 限制 apiserver 同时处理的变更（写）请求数量，默认 200。超过限额的请求会被排队等待，若等待时间过长会返回 429（Too Many Requests）或超时。它与 --max-requests-inflight（只读请求）分开限制。该参数属于全局粗粒度限流，新版本推荐用 APF（API Priority and Fairness）做更细粒度的限流。

核心是"写请求并发上限"。调高可提升写吞吐但增加内存/CPU 压力，调低可保护 apiserver 稳定性。

• 参数含义与默认值
• 与变更请求限流的区别
• 超限处理

--max-requests-inflight 限制同时处理的非变更（只读，如 get/list/watch）请求数量，默认 400。超过限额的请求排队，队列满或等待超时返回 429。它对 GET/LIST/WATCH 等读操作生效，与写请求的 --max-mutating-requests-inflight 分开。实际生产中可调大只读并发以应对大量 list/watch 流量，但需注意内存与 etcd 压力。

核心是"读请求并发上限"。监控该参数可避免 list 风暴导致 apiserver 过载。

• issuer 的含义与要求
• 相关参数（audience、key-file）
• Token 校验与 OIDC

--service-account-issuer 指定了 ServiceAccount Token 的签发者标识（一个 URL，如 https://kubernetes.default.svc.cluster.local），是 JWT 的 iss 字段。它还配合 --service-account-key-file（签发用公钥验证）、--service-account-signing-key-file（signing key）、--api-audiences（audience）。该配置用于生成 bound service account token（有时间限制、绑定 Pod 的 JWT），也是 OIDC discovery 的基础。ServiceAccount Admission Controller 与 kubelet 使用该 token 认证。

核心是 issuer + signing key + audience 三者组成签发配置。issuer 需稳定，避免轮换后 token 校验失败。

• apiserver 作为客户端访问 kubelet
• 证书与 CA 配置
• 安全作用

apiserver 需要访问 kubelet 的 /pods、/stats、/exec 等接口（日志、exec、metrics、转发）。为此它作为客户端需提供证书：--kubelet-client-certificate 指定客户端证书，--kubelet-client-key 指定私钥，--kubelet-certificate-authority 指定用来验证 kubelet 服务端证书的 CA。kubelet 通过 --client-ca-file 验证 apiserver 客户端证书。kubeadm 会生成 kubelet-client 证书并配置。这样 apiserver→kubelet 的通信是双向 TLS 认证。

核心是 apiserver 作为客户端、kubelet 作为服务端之间的双向 TLS。配置错误会导致 pod logs/exec 失败。

• bootstrap token 的发现与认证
• TLS bootstrap 证书申请
• kubelet 注册到集群

kubeadm join 流程：1）用 kubeadm token create 生成 bootstrap token（含 secret 存放于 kube-system）；2）新节点用 token 与 --discovery-token-ca-cert-hash 发现集群并验证 apiserver CA；3）通过 bootstrap token 认证向 apiserver 发起 CSR，申请 client 证书（kubelet 的 TLS bootstrap）；4）控制器（approver）批准 CSR，签发证书；5）kubelet 用签发后的证书生成 kubeconfig，注册 Node 对象，开始运行。bootstrap token 是临时凭证，主要用于首次引导，之后 kubelet 用长期证书。

核心是"临时 token 引导 + 证书签发 + 节点注册"。bootstrap token 的 CA 校验（sha256 哈希）防止中间人攻击。

• memory manager 作用与拓扑感知
• 与 CPU manager 配合
• 预留与实际分配

kubelet 的 memory manager（memoryManager 特性，与 CPU manager 的 static 模式配合）用于为 Guaranteed QoS 且指定了内存的 Pod 预留内存，支持 NUMA 拓扑感知。它根据 Pod 的 requests 为容器分配内存节点（NUMA socket），并保证这些内存不被其他 Pod 抢占。通过 --memory-manager-policy=Static 启用。配合 CPU manager 的 static 策略，可实现内存与 CPU 在同一 NUMA 节点的亲和，提升性能（适合高性能计算、DPDK 等）。

核心是"static 策略 + NUMA 拓扑感知的预留"。仅对 Guaranteed QoS 且显式声明资源生效。实际内存在分配 NUMA 节点后由运行时管理。

• cgroup v2 与 v1 的差异
• memory/CPU 管理
• 统计来源（PSI、cgroup 文件）

cgroup v2 统一了 cgroup 层级（单一层级树），所有资源控制器统一挂在统一 cgroup 下。kubelet 通过 CRI 让运行时（如 containerd）基于 cgroup v2 创建 Pod/容器 cgroup。v2 下内存统计用 memory.events、memory.peak，CPU 用 cpu.stat，压力用 memory.pressure/PSI。kubelet 的资源统计（cAdvisor）从 cgroup v2 读取。v2 的优势：无 cgroup v1 的多层级问题、支持内存与交换精细控制、支持 PSI 压力停滞信息（用于驱逐判定）。

核心是"cgroup v2 统一层级 + 压力停滞信息"。新版本 K8s 已默认 cgroup v2（Kubernetes >= 1.31 移除 cgroup v1 支持）。

• --shutdown-grace-period 参数
• 关停期间 Pod 的终止
• critical pods（static pods）优先

kubelet 支持优雅节点关停：当检测到系统关停（如 systemd 关机信号）时，kubelet 在 --shutdown-grace-period（默认 0，可配置）时间内优雅终止 Pod，按优先级顺序终止（先终止 normal Pod，再 critical/static Pod），并优先给 critical pods 更长的时间（--shutdown-grace-period-critical-pods）。这确保节点关停时工作负载能干净退出，数据落盘。关机后 Pod 由控制器在别的节点重建。

核心是"节点关停时按优先级优雅终止 Pod"。critical pods 是 static 或 critical 注解的 Pod，最后终止。

• 参数含义（磁盘使用率阈值）
• 触发机制
• 回收策略

kubelet 定期检查容器镜像占用的磁盘。--image-gc-high-threshold（默认 85%）与 --image-gc-low-threshold（默认 80%）是磁盘使用率百分比。当镜像磁盘使用率超过 high 阈值时触发镜像 GC，开始删除未使用镜像，直到使用率降到 low 阈值以下。只删除未被任何容器使用的镜像（按最近使用时间优先）。该机制与容器 GC（--maximum-dead-containers）配合。

核心是"高阈值触发、低阈值停止"。这是防止节点磁盘被镜像占满的关键。

• Ansible inventory 与 playbook
• 组件与网络插件选择
• 升级流程

Kubespray 是基于 Ansible 的 Kubernetes 集群部署工具。通过 inventory 文件定义节点分组（kube_control_plane、etcd、kube_node），用 Group vars 配置版本、网络插件（Calico/Flannel/Cilium）、容器运行时等。运行 ansible-playbook cluster.yml 部署集群。升级用 ansible-playbook upgrade-cluster.yml，可分批滚动升级。它支持裸机与云上部署，自动化程度高。

核心是"Ansible 驱动、inventory 声明节点、playbook 编排"。适合已管理 Ansible 的环境。