Kubernetes 基础与部署运维

• 卷挂载与环境变量挂载的机制
• 卷挂载的 kubelet 轮询更新与文件变化
• Spring Boot 的 @ConfigurationProperties 与 RefreshScope 热更新

以卷挂载时，kubelet 会定期同步 ConfigMap/Secret 到容器内的文件，文件内容变化后，Spring Boot 可通过 @ConfigurationProperties 配合 RefreshScope，或监听文件变化（如 Spring Cloud Config Monitor）实现配置热更新，无需重启容器。以环境变量挂载时，环境变量在容器启动时固定，进程运行期间无法感知外部变更，只能通过重启容器或整 Pod 重建生效。因此卷挂载支持热更新，环境变量挂载不具备热更新能力。

热更新能力差异源于"文件可被外部更新"与"环境变量启动即固定"的本质区别。卷挂载适合需要热更新的配置，环境变量适合启动时固定的配置。

• cgroup 限流与 HotSpot 容器感知
• CPU limits 影响 GC 线程数与并行度
• requests/limits 与调度优先级、QoS

HotSpot 通过容器感知（cgroup-based）读取容器可用的 CPU 与内存，自动调整堆大小、GC 线程数、并行度等默认值。CPU limits 决定 GC 线程数与 JIT 并行编译线程数，若 limits 过小，GC 并发度受限制；内存 limits 决定默认堆上限（-XX:MaxRAMPercentage 基于容器内存）。requests 是调度依据，limits 是运行时上限；requests 与 limits 不同时 QoS 为 Burstable，调度优先级低于 Guaranteed，OOM 驱逐时优先被驱逐。

正确设置 requests/limits 让 JVM 感知正确资源，避免堆过大被 OOM 或 GC 线程过多。JDK 的容器感知默认值基于这些配置。

• readiness 判断业务可用、liveness 判断进程存活
• Spring Boot Actuator 的 health 端点
• 探针配置与 failureThreshold

readiness 探针用于判断"业务是否可用"，失败时 kubelet 把 Pod 从 Service Endpoints 摘除，不重启容器；liveness 探针判断"进程是否存活/可恢复"，失败时 kubelet 重启容器。Spring Boot Actuator 通过 /actuator/health 暴露健康状态，默认返回 UP/DOWN，可结合 readiness 与 liveness 分组（如 readiness 组包含依赖健康检查、liveness 组只检查 JVM 存活）分别配置探针，实现"依赖失败让业务下线但进程不重启、进程挂掉才重启"的语义。

二者语义关键：readiness 管流量，liveness 管生命周期。区分配置可避免依赖故障导致容器被反复重启。

• requests/limits 与 JVM 堆内存识别
• JDK 容器感知（-XX:MaxRAMPercentage）
• JDK 25 的默认容器感知

Pod 的 limits 定义容器内存上限，JVM 通过容器感知读取该上限，默认堆大小按 -XX:MaxRAMPercentage（默认 25%）计算，避免堆超过容器上限导致 OOMKilled。requests 作为调度与服务保障依据，不直接决定 JVM 堆。JDK 25 加强容器感知，能更准确识别 cgroup 内存与 CPU，默认值基于容器配额而非宿主机。合理配置 limits 让 JVM 相应调整堆，requests 保证调度资源。

堆内存与容器 limits 的关系是 Java 容器化常见坑：limits 太小会 OOM，太大而 requests 不足则调度不稳定。JDK 容器感知默认值随版本演进更准确。

• Sidecar 容器的生命周期管理
• 多容器 Pod 的日志/代理/监控
• 与 Java Agent 注入、日志采集的配合

Kubernetes 1.33 将 Sidecar 容器（原生 sidecar）转为 GA（自 1.29 起默认启用），支持独立的生命周期管理（如自启动、与主容器同时终止），使 multi-container Pod 更可靠。Spring Boot 应用可用 Sidecar 模式承载日志采集（Filebeat）、服务代理（Envoy）、监控（Prometheus exporter）等辅助容器，与主应用容器协作。原生 Sidecar 解决了传统 sidecar 需要在主容器退出前手动终止的问题，提升多容器 Pod 的优雅性。

Sidecar 是"辅助容器伴随主容器"的部署模式，GA 后生命周期管理更自动。对 Spring Boot 而言，把横切关注点（日志/代理/监控）隔离到 sidecar 保持主容器专注。

• scheduling gates 的调度门控
• 启动钩子（PostConstruct）的阶段
• 调度与启动的关系

scheduling gates（schedulingGates 字段，由 PodSchedulingReadiness 特性门控提供，K8s 1.30 起 GA）是 K8s 的调度门控机制，允许在 Pod 真正调度前通过添加/移除 gate 控制调度时机，与 Spring Boot 的启动钩子（PostConstruct）属于不同层：gate 控制"何时被调度到节点"，PostConstruct 控制"应用启动后何时执行初始化"。两者在实践中可能配合，例如先满足调度门控再启动应用，确保依赖就绪。但它们是正交概念，一个在调度层，一个在应用层。

理解分层：scheduling gates（调度门控）与应用启动钩子（PostConstruct）职责不同，前者管状态调度，后者管业务初始化，不应混淆。

• Deployment 的资源的配置（镜像/副本/探针）
• 环境变量与 ConfigMap/Secret 注入
• 滚动更新与优雅停机

Spring Boot 4.x 在 K8s 中的 Deployment 模板应包含：镜像与版本（可追溯）、.spec.replicas 副本数、resources（requests/limits）、readinessProbe/livenessProbe（指向 Actuator 健康端点）、env 从 ConfigMap/Secret 注入配置、strategy（滚动更新 maxSurge/maxUnavailable）、terminationGracePeriodSeconds（配合优雅停机）。模板还应注入 spring.profiles.active 等环境变量，并通过 management.endpoint.health.probes 暴露探针端点。

Deployment 模板是应用与 K8s 的契约，覆盖配置注入、探针、资源、更新策略、优雅停机，保证应用在 K8s 中可靠运行。

• HPA 基于资源指标/自定义指标
• KEDA 基于事件（Kafka lag）的扩缩
• 消费线程与副本数的关系

HPA 基于 CPU 或自定义指标扩缩副本；KEDA（Custom Pod Autoscaler）支持基于事件源（如 Kafka consumer lag）扩缩，当 lag 超过阈值时增加副本，lag 归零时缩容。对 Spring Boot 消费者应用，副本数应与 Kafka 分区数匹配（每个副本消费部分分区），否则增加副本无法提升消费吞吐。KEDA 的 ScaledObject 声明触发源与阈值，配合 HPA 或独立扩缩。

事件驱动扩缩关键是"指标与业务吞吐相关"（lag 反映积压），并考虑分区数上限。缩容到零需处理冷启动。

• K8s Service DNS 解析与负载均衡
• JVM DNS 缓存（TTL）对地址刷新
• OpenFeign 的负载均衡与重试

K8s 中 OpenFeign 通过 Service 域名解析为 ClusterIP，JVM 默认缓存 DNS 记录（networkaddress.cache.ttl 默认可能为 30s 或更长），若缓存过期时间过长，Service 端点的变化（Pod 重建、IP 变动）不能及时反映，导致调用失败。工程上应设置合理的 DNS TTL（如 30s），并让 OpenFeign 配合 Spring Cloud LoadBalancer 从 Service 端点列表做负载均衡，华为/阿里云环境常需调整 networkaddress.cache.ttl 与 cache.negative.ttl。

DNS 缓存策略影响 Service 流量感知的时效性。缓存过久会放大故障转移延迟，是 K8s 中 Spring Cloud 调用的常见配置坑。

• OpenTelemetry Operator 的自动注入
• Java Agent 的字节码增强
• 与 Spring Boot 4.0 的兼容性

OpenTelemetry Operator 通过注入 Java Agent（-javaagent）自动为应用添加遥测（trace/metrics），无需改代码。自动注入基于字节码增强，与 Spring Boot 4.0 的兼容性取决于 Agent 版本是否支持该 Spring Boot/框架版本，以及 JDK 版本（JDK 25 需 Agent 支持）。兼容矩阵需关注：Agent 版本、JDK 版本、Spring Boot 版本、以及是否启用虚拟线程等特性。升级 Spring Boot 或 JDK 时需同步验证 Agent 兼容性。

自动注入降低接入成本，但字节码增强与框架版本耦合，兼容性是升级时的关键验证点。

• fabric8 的 KubernetesClient
• 与 Spring Boot 的集成
• 资源创建/查询/事件监听

fabric8 提供 KubernetesClient，可用于创建/查询/更新 K8s 资源、监听事件、执行 exec/logs 等。Spring Boot 应用可通过 @ConfigurationProperties 注入连接配置，用 fabric8 的 fluent API 操作资源。常见场景：应用启动时创建资源、读取 ConfigMap/Secret、watch 事件、与 HPA 集成等。fabric8 比官方 client 更贴合 Spring 生态，支持客户端缓存与事件监听。

fabric8 是 Spring Boot 与 K8s 交互的常用客户端，fluent API 简洁，适合应用内程序化操作 K8s 资源。

• Virtual Threads 与传统线程的堆栈内存差异
• Spring Boot 4.0 对虚拟线程的支持
• Pod 内存 footprint 与配额

Virtual Threads 由 JVM 管理，栈内存分配在堆上、随线程终止自动回收，相比 OS 线程（默认 1MB 栈）占用更少，因此高并发场景下启用虚拟线程可显著降低 Pod 内存 footprint（原生线程被虚拟线程替代，等效并发能力提升而内存占用下降）。Spring Boot 4.0 支持启用虚拟线程（如 spring.threads.virtual.enabled），使 Tomcat 等用虚拟线程处理请求。实测中，同类并发下虚拟线程 Pod 的 RSS 明显低于传统线程池，但需注意虚拟线程大量创建时仍会带来堆内存占用与调度开销。

虚拟线程的好处是"并发成本低"，内存 footprint 降低是主要收益，但应评估实际并发模型与 GC 影响。

• runAsNonRoot 禁止 root 运行
• readOnlyRootFilesystem 只读根文件系统
• capabilities drop 移除特权

这三个安全上下文设置收紧 Java 容器：runAsNonRoot: true 要求容器以非 root 用户运行，securityContext.runAsUser 指定 UID；readOnlyRootFilesystem: true 使根文件系统只读，防止写入恶意文件，需为临时目录挂载空卷（如 /tmp）；capabilities.drop 移除多余 Linux capabilities（如 ALL），减少内核权限面。三者配合降低容器被攻破后的横向与提权风险，符合 Pod Security Standards 的 restricted 策略。

安全上下文是容器隔离的基础，Java 应用需注意只读根文件系统下临时文件/缓存目录的挂载需求。

• startupProbe 的成功抑制 liveness
• 启动缓慢的阈值设置
• failureThreshold 与 periodSeconds

startupProbe 在启动期间运行，成功前会抑制 liveness 探针（期间 liveness 不执行），避免启动慢的应用因 liveness 超时被误重启。就绪探针（readiness）在 startup 成功前也保持未就绪，不进入流量。对启动缓慢的 Spring Boot 服务，应设置合理的 periodSeconds、failureThreshold 与 timeoutSeconds，使启动检查窗口足够长（如 300s）。启动后 startup 探针自动停止，交给 liveness/readiness 接管。

startupProbe 解耦"启动期"与"运行期"的存活检查，是慢启动应用不被误杀的关键配置。

• topologySpreadConstraints 的拓扑分布
• Pod 反亲和避免同节点
• 无法满足时的调度行为

topologySpreadConstraints 将 Pod 按拓扑域（如 zone、node）均匀分布，PodAntiAffinity 避免关键 Pod 落在同一节点/区域，提升容错。调度器优先满足约束，但当无法满足时，topologySpreadConstraints 的 whenUnsatisfiable 可设为 DoNotSchedule（不调度）或 ScheduleAnyway（尽量满足但可强行调度），PodAntiAffinity 的 preferredDuringScheduling 则尽量满足而不强制。工程师需根据弹性需求选择"硬约束"或"软约束"。

约束的"硬/软"决定调度行为：硬约束失败不调度，软约束尽力而为。需权衡可用性与调度成功率。

• Job 一次性任务、CronJob 定时任务
• 与 Spring Batch 的集成
• 幂等、重试与失败处理

K8s Job 用于一次性批处理，CronJob 按 cron 定时触发，都可运行 Spring Boot 批处理任务。最佳实践：Job 的并行度与 completions、backoffLimit 控制重试；Spring Batch 的重复执行（restart）需保证幂等（JobInstance 唯一）；CronJob 的 concurrencyPolicy 控制并发/跳过；批处理失败时用 Job 状态与 Spring Batch 的 step 重试恢复。任务完成即 Pod 退出，适合无状态批处理。

Job/CronJob 提供调度与生命周期管理，Spring Batch 提供批处理语义，二者结合需处理幂等、重试与并发。

• 尾延迟（P99）的排查
• 容器节流（CPU throttling）
• GC、节点压力、网络、探针的多源分析

排查尾延迟需建立多维度证据链：CPU throttling（cgroup 限流导致调度延迟）看 kubectl top 与 cgroup 统计；GC 暂停看 JVM GC 日志与 metrics；节点压力看节点 CPU/内存/磁盘（kubectl describe node）；网络延迟看 Service/网络插件指标；探针事件看 kubectl get events 与 Pod 重启记录。将这些指标对齐到同一时间线，定位是持续还是偶发、是节流还是 GC 还是网络，从而闭环定位。

尾延迟是综合问题，单一指标无法定位。对齐时间线、关联多源指标，才能区分根因（节流/GC/网络/调度）。

• /proc 的进程与内存信息（meminfo、cpuinfo）
• /sys 的 cgroup 与设备信息
• 容器视角 vs 宿主机视角

/proc 提供进程级信息（/proc/meminfo、/proc/cpuinfo、/proc/<pid>/status、/proc/<pid>/stat），JVM 通过它读取内存与 CPU；/sys/fs/cgroup 提供容器配额（CPU/内存限制）。诊断价值在于：确认 JVM 看到的容器资源（cgroup 限制）是否正确，判断是否被节流、内存是否到上限。Linux 5.x 后 /proc 与 /sys 已做容器视角隔离，但早期版本需注意 host 视图与容器视图差异。

/proc 与 /sys 是 JVM 与诊断工具获取容器资源的来源，理解其语义能判断 JVM 配置是否正确。

• A/B 测试的目标与分桶
• 灰度发布的目标与流量控制
• 二者组合使用

A/B 测试的目标是"验证版本/功能的效果差异"，通过用户分桶（随机/特征分组）把用户分到不同版本，用统计学指标（转化率、点击率）评估哪个版本更优；灰度发布的目标是"控制风险发布"，逐步把流量从小比例放量到全量，优先保障稳定性与回滚能力。二者可组合：用灰度发布控制流量暴露范围，在其中用 A/B 分桶比较不同版本的用户指标，既控制风险又验证效果。

A/B 关注"效果对比"，灰度关注"风险控制"。组合使用让发布既安全又数据驱动。

• BuildKit 的构建能力
• 并行构建与缓存
• 与经典 Build 的差异

DOCKER_BUILDKIT=1 启用 Docker BuildKit 构建器，相比经典构建器提供：更高效的并行构建、改进的层缓存（BuildKit 缓存）、安全构建（无需 root 守护进程的直接构建）、支持多阶段构建的更好优化、--mount 等高级功能。对 Java 镜像构建，BuildKit 能利用层缓存加速依赖层复用，减少构建时间。现代 Docker 默认已启用 BuildKit。

BuildKit 是新一代构建引擎，重点是并行与缓存优化。启用后多阶段构建与缓存命中更高效。

• maxSurge 额外实例数
• maxUnavailable 不可用实例数
• 资源不足导致滚动停滞

maxSurge 定义滚动发布中可超出期望副本数的额外实例数（如 25%），maxUnavailable 定义滚动中允许不可用的最大实例数（如 0 表示不中断）。二者共同保证滚动期间可用性与容量。若集群资源不足，无法创建 maxSurge 的额外 Pod，滚动会停滞（新 Pod pending），导致发布无法推进；此时需调整 maxSurge/maxUnavailable 或扩容节点。

滚动发布是"先增后删"或"先删后增"的平衡，资源不足时额外 Pod 无法调度，发布停滞是常见问题。

• HPA 的利用率 = 实际使用/requests
• requests 是利用率分母
• 稳定窗口（stabilizationWindow）与指标延迟

HPA 计算 CPU 利用率时用"实际使用量 / requests 值"，因此 requests 是利用率的分母，设置过小会导致利用率虚高、过快扩容；设置过大则利用率偏低、扩容不积极。启动时 Pod 尚未就绪，CPU 指标会抖动，需用 behavior 的 stabilizationWindowSeconds 稳定扩缩，避免指标延迟或启动抖动导致频繁扩缩。合理设置 requests 与稳定窗口能避免扩缩震荡。

HPA 的利用率定义依赖 requests，requests 既影响调度也影响扩缩。稳定窗口平滑指标波动，避免抖动。

• Helm 的模板化与依赖管理
• Kustomize 的 overlay 与基座
• 二者的取舍

Helm 用模板（values.yaml + Chart 模板）参数化部署，支持版本管理、依赖管理（子 Chart）、回滚，适合复杂或多环境通过 values 覆盖；Kustomize 用 base/overlay 方式，通过 patch 修改 YAML，无需模板语言，纯声明式，适合对已有 YAML 做增量覆盖。工程上：Helm 适合"作为应用包分发、需参数化与版本化"，Kustomize 适合"直接操作 GitOps 的 YAML、需保持原始清单"。二者也可配合 Argo CD 使用。

Helm 是"模板包"，Kustomize 是"增量补丁"。选择取决于是否需要模板化参数与复杂的值管理。

• Ingress 的 host/path 路由
• TLS 证书配置
• 与 Service 的映射

Ingress 通过 rules 定义按 host 与 path 的路由，把请求转发到对应 Service；tls 段配置域名与证书（Secret 存放证书），实现 HTTPS。Ingress Controller（如 Nginx）实现这些规则，管理入口流量。工程上可配置 path 类型（Prefix/Exact）、重写、TLS 终止（termination）在 Ingress 层完成，后端 Service 用 HTTP。TLS 证书需管理生命周期（轮换）。

Ingress 是集群入口的路由与控制层，TLS 终止与域名路由是其核心职责。证书管理是运维重点。

• 优雅停机的三阶段时序
• readiness 失败摘除端点
• preStop 等待与 SIGTERM 处理

K8s 优雅停机的理想时序：先让 readiness 探针失败（或主动置为不健康），使 Pod 从 Service Endpoints 摘除，不再接收新流量；再通过 preStop 钩子等待（如 sleep）让在途请求处理完成；最后收到 SIGTERM，Spring Boot 开始优雅停机（server.shutdown=graceful 等待在途请求完成）。terminationGracePeriodSeconds 是总宽限期，超时则 SIGKILL。编排好这三者顺序可避免请求丢失。

避免请求丢失的关键是"先摘流量、再等处理、最后停止"。preStop sleep 弥补端点摘除与 SIGTERM 之间的延迟。

• NetworkPolicy 的网络层隔离
• Spring Cloud Gateway 的应用层路由
• 分层防御

NetworkPolicy 在网络层（L3/L4）基于 IP/端口控制 Pod 间流量，是"网络防火墙"；Spring Cloud Gateway 在应用层（L7）做路由、鉴权、限流，是"应用网关"。二者分层：NetworkPolicy 先做横向的流量隔离（谁可以访问谁），Gateway 做纵向的出入站控制与业务逻辑。分层防御让网络层兜底、应用层精细控制，即使应用层被绕过，网络层仍限制流量。

分层是纵深防御：网络层管连接，应用层管业务。NetworkPolicy 默认拒绝可提升隔离强度。

• KEDA 基于事件指标、HPA 基于资源指标
• 缩容到零的冷启动
• 冷启动与就绪延迟

HPA 基于资源指标（CPU/内存）或外部指标，扩缩与资源利用率挂钩；KEDA 基于事件源（Kafka lag、队列长度、HTTP 请求）扩缩，更贴近业务吞吐。缩容到零时，Pod 被完全移除，来流量时需重新创建 Pod，产生冷启动延迟（镜像拉取、JVM 启动、Spring 上下文初始化、就绪等待）。处理冷启动需要：预热（镜像缓存）、优化启动（AOT/分层）、合理设置就绪阈值、避免对延迟敏感的应用缩容到零。

事件驱动比资源指标更贴合业务，但缩容到零带来冷启动。需权衡节省成本与延迟要求。

• ServiceAccount Token 投影
• Config Client 拉取配置与凭证
• 兼容性与配置

K8s 1.30 通过 projected ServiceAccount Token（短期、绑定受众与过期时间）挂载到 /var/run/secrets/tokens，比长期 Secret 更安全。Spring Cloud Config Client 若需从 Config Server 拉取配置，需自定义认证方式（如用投影 Token 通过 HTTP 头或客户端证书），与 Config Server 的认证机制兼容。需确保 Config Server 支持 Token 认证、客户端能读取投影 Token 文件，并处理 Token 自动轮换。

投影 Token 提升安全性，但客户端需适配其读取与轮换机制。兼容性取决于 Config Server 的认证方式。

• Gateway API 的 GatewayClass/Gateway/Route
• 与 Ingress 的差异
• Spring Cloud Gateway 的适配

K8s Gateway API 用 GatewayClass、Gateway、HTTPRoute 等资源取代 Ingress，提供更细粒度的路由、策略与跨 namespace 支持。迁移到 Spring Cloud Gateway 时，需把 Ingress 的规则映射为 Gateway API 的 HTTPRoute，把鉴权、限流、重写等策略映射到 Gateway API 的 Policy 或由 Spring Cloud Gateway 的过滤器实现。适配工作包括：路由规则迁移、策略收敛、TLS 配置、以及观测与兼容性验证。

Gateway API 是标准化的"网关抽象"，Spring Cloud Gateway 作为实现可与 Gateway API 对接，迁移需规则映射与策略对齐。

• Guaranteed/Burstable/BestEffort
• 与 requests/limits 的关系
• 驱逐优先级

Pod 的 QoS 由 requests/limits 决定：Guaranteed（requests==limits 且都设置）、Burstable（至少设置一部分 requests）、BestEffort（都不设置）。QoS 等级决定节点资源不足时的驱逐顺序：BestEffort 最先被驱逐，Burstable 其次，Guaranteed 最后。Guaranteed 优先级最高且最稳定，适合关键服务；BestEffort 弹性但易被驱逐。

QoS 是资源管理的核心，决定 Pod 的稳定性与驱逐优先级。生产关键服务应配置 Guaranteed。

• 各 Service 类型的访问范围
• ClusterIP 集群内访问
• NodePort/LoadBalancer/Ingress 的外网暴露

Service 类型决定访问方式：ClusterIP 只在集群内提供稳定的虚拟 IP 访问；NodePort 在每个节点上开放一个端口，可通过节点 IP:端口从集群外访问；LoadBalancer 由云厂商创建外部负载均衡器，把流量转到 Service；Ingress 不是 Service 类型，而是独立资源，通过 Ingress Controller 基于 host/path 路由到 Service，是最灵活的入口。选择取决于是否需要集群外访问及访问层级。

Service 提供稳定的服务发现，类型决定暴露方式。Ingress 在 Service 之上做 L7 路由。

• HPA 的指标采集与计算
• 期望副本数计算
• 扩缩容策略与稳定窗口

HPA 通过 metrics API 采集 Pod 的指标（CPU/内存/自定义），按"期望副本数 = 当前副本数 × (当前指标值 / 目标指标值)"计算，调整 Deployment 的副本数。支持 minReplicas/maxReplicas 限制、behavior 的扩缩容策略、stabilizationWindowSeconds 稳定窗口。HPA 需要 metrics-server 提供基础指标，Pod 需配置 requests 供利用率计算。

HPA 是 K8s 原生的水平扩缩容，基于利用率计算副本数。稳定窗口与策略避免扩缩震荡。

• NetworkPolicy 的 podSelector/ingress/egress
• 默认拒绝与白名单
• CNI 支持

NetworkPolicy 通过 podSelector 选择目标 Pod，用 ingress/egress 规则声明允许的入站/出站流量（来源/目的 IP、端口、命名空间）。实现"默认拒绝"（不声明则拒绝）加白名单隔离。它依赖 CNI 插件（如 Calico、Cilium）实现数据面，若 CNI 不支持 NetworkPolicy 则策略不生效。合理配置可限制 Pod 间横向流量，是安全隔离与最小权限的基础。

NetworkPolicy 是"网络层白名单"，默认拒绝能收紧隔离。需确认 CNI 支持并验证策略生效。

• PV/PVC 的绑定关系
• StorageClass 动态供给
• 有状态应用的持久化

PVC 是"持久化存储的请求"，PV 是"实际存储卷"，PVC 通过匹配 PV 或 StorageClass 动态供给绑定。StorageClass 提供动态创建 PV（如云盘、NFS），无需预先创建 PV。有状态应用（数据库、消息队列）通过 PVC 持久化数据，Pod 重建后数据保留。PVC 与 Pod 生命周期解耦，数据不随 Pod 删除而丢失。

PV/PVC 把"存储请求"与"实际存储"解耦，StorageClass 动态供给简化管理。有状态存储依赖 PVC。

• PSS 的 privileged/baseline/restricted 三级
• 准入控制（Pod Security Admission）
• 与容器安全强化

PSS 定义三个安全等级：privileged（无限制）、baseline（默认安全基线）、restricted（严格限制）。通过 Pod Security Admission 在 namespace 上配置 enforce、audit、warn 策略，控制不符合等级的 Pod 被拒绝/告警。restricted 要求非 root、只读根文件系统、禁止新增 capabilities 等，是 Java 容器安全强化的目标。PSS 替代了旧 PodSecurityPolicy。

PSS 是安全准入标准，restricted 最严格。结合 runAsNonRoot、readOnlyRootFilesystem 等满足基线。

• Role/ClusterRole、RoleBinding/ClusterRoleBinding
• 资源与动作的授权
• 最小权限

RBAC 用 Role/ClusterRole 定义一组权限（对哪些资源、哪些动作：get/list/watch/create 等），RoleBinding/ClusterRoleBinding 把角色绑定到用户/ServiceAccount。Role 限定在单个 namespace，ClusterRole 跨 namespace/集群级。RBAC 控制 API 访问权限，应遵循最小权限，为 ServiceAccount 分配必要权限，避免过度授权。

RBAC 是 K8s 的授权模型，控制"谁可以对什么资源做什么"。最小权限是安全基线。

• etcd 是集群状态存储
• 备份（etcdctl snapshot）
• 恢复与可用性

etcd 存储集群全部状态（资源、配置），其备份是灾难恢复的关键。用 etcdctl snapshot save 生成快照，定期备份；恢复时用 etcdctl snapshot restore 恢复，并确保所有 kube-apiserver 停止以一致恢复。高频备份、异地存储、恢复演练是保障集群可恢复性的实践。etcd 本身也建议冗余（多节点）。

etcd 是"控制面数据库"，备份恢复决定集群灾难恢复能力。恢复需一致性与版本匹配。

• exec 进入容器执行命令
• logs 查看容器日志
• port-forward 端口转发

kubectl exec 在容器内执行命令，用于调试与进入容器；kubectl logs 查看容器标准输出日志（-f 跟踪），排障主用；kubectl port-forward 把本地端口转发到 Pod 端口，用于本地访问集群内服务或调试。三者是日常排障与调试的基础命令，需注意 exec 的权限与安全。

这三个命令覆盖"进入、看日志、访问"的调试场景，是 kubectl 的常用排障工具。

• 事件记录资源生命周期
• 排障信息（调度失败、探针失败）
• 事件查看与过滤

kubectl get events 展示集群中的事件（调度、拉取镜像、探针失败、容器重启、资源不足等），是排障的重要线索。事件能显示"为什么 Pod 未就绪"、"为什么会重启"、"为何调度失败"等，配合 kubectl describe 查看详细事件。按类型/原因过滤可快速定位问题。

事件是"发生了什么"的日志，是排障的第一手信息。与 describe、logs 结合形成完整排障链。

• rollout 的版本历史
• rollback 回滚
• 与发布策略

Deployment 的每次更新会生成 revision，kubectl rollout history 查看历史版本，kubectl rollout undo 回滚到指定版本（默认上一版本），kubectl rollout status 查看发布进度。回滚基于 revision 机制，是发布失败时的快速回退手段。需注意回滚只回滚 Pod 配置，数据库变更需另行处理。

rollout 提供版本化发布与回滚，是"快速还原"能力。回滚不当会导致配置与数据不一致，需谨慎。

• kubectl top node/pod 查看资源使用
• metrics-server 提供数据
• 资源监控与排障

kubectl top node / kubectl top pod 显示节点与 Pod 的 CPU/内存使用量，依赖 metrics-server 采集。资源监控用于判断资源是否充足、是否超限、扩容依据。更完整的监控需搭配 Prometheus 等采集指标。kubectl top 是快速查看当前资源使用的工具，适合排障与容量评估。

kubectl top 依赖 metrics-server 的实时指标，是快速查看资源占用的入口，完整监控需指标系统。

• 三种探针的语义
• 探针类型（httpGet/exec/tcp）
• 配置参数

liveness 判断进程是否存活，失败则重启容器；readiness 判断业务是否就绪，失败则移出 Service 端点；startup 判断启动是否完成，成功前抑制 liveness。探针可用 httpGet（HTTP 请求）、exec（执行命令）、tcpSocket 三种方式。每个探针可配置 initialDelaySeconds、periodSeconds、timeoutSeconds、failureThreshold。三探针配合实现"启动慢不被误杀、就绪才进流量、死亡才重启"。

三探针各司其职，是应用可靠性的关键。startup 慢启动、readiness 流量、liveness 生命周期。

• NetworkPolicy 依赖 CNI 数据面
• 不支持 CNI 的策略失效
• 默认拒绝的验证

NetworkPolicy 是 API 层面的声明，实际数据面由 CNI 插件（Calico、Cilium 等）实现。若 CNI 不支持 NetworkPolicy（如某些简单 CNI），策略不会限制流量，表现"无效"。验证默认拒绝策略：创建只允许少量入站流量的策略，用网络工具（如 curl、nc）从其他 Pod 测试连通性，确认被拒绝，同时确认允许的流量正常。验证需在真实网络环境进行。

NetworkPolicy 的"声明"与"执行"分离，执行依赖 CNI。验证是确认策略真正生效的手段。

• QoS 与驱逐顺序
• kubelet 驱逐 vs 内核 OOM
• OOMKilled 的触发层

节点资源不足时，kubelet 按 QoS 驱逐：BestEffort 最先、Burstable 其次、Guaranteed 最后（仅在极端情况下）。OOMKilled 由内核 OOM killer 触发：当容器所用内存超过 cgroup 内存限制时，内核 OOM killer 杀死容器进程，容器状态显示 OOMKilled。二者区别：kubelet 驱逐是"节点级资源压力"，内核 OOM 是"容器超过 cgroup 限制"。Guaranteed 因内存限制过小仍可能被 OOMKilled。

驱逐是 kubelet 的节点级决策，OOMKilled 是内核的容器级决杀。理解两层可区分"节点压力"与"容器超限"。

• Pod 各阶段状态
• 阶段与容器状态的关系
• 排障

Pod 生命周期阶段：Pending（已创建但未调度或容器未启动）、Running（至少一个容器运行）、Succeeded（所有容器正常退出）、Failed（至少一个容器异常退出）、Unknown（状态无法获取）。阶段反映 Pod 整体状态，与容器状态（Waiting/Running/Terminated）相关。排障时根据阶段判断是调度问题（Pending）、运行问题（Running+失败）还是退出问题。

阶段是 Pod 的宏观状态机，容器状态更细。理解阶段可快速定位是调度、运行还是退出问题。

• requests 调度保证
• limits 运行上限
• 与 QoS、驱逐

requests 是调度时申请的资源量，调度器保证节点能提供 requests 的资源，是"预留"；limits 是运行时的资源上限，超过会被节流（CPU）或 OOM（内存）。requests 决定调度与 QoS，limits 决定运行时上限。合理设置：requests 体现真实需求，limits 防止失控，二者相等即 Guaranteed QoS。

requests/limits 是资源治理的核心，requests 管调度、limits 管运行。设置不当会导致资源浪费或 OOM。

• 明文环境变量注入的风险
• 投射式令牌（projected token）
• 外部密钥系统（Vault）

Secret 以明文环境变量注入的风险：环境变量可被容器内进程与调试工具读取、易在日志/审计中泄露、Secret 变更不生效（重启才变）、无轮换与审计细粒度。投射式令牌提供短期、绑定受众的凭据，自动轮换；外部密钥系统（Vault）集中管理密钥，支持动态凭据、访问审计、细粒度权限，应用通过 SDK 拉取，避免把明文写进环境变量。这些改善凭据的安全与生命周期。

明文环境变量把凭据暴露在进程空间，投射式令牌与 Vault 提供短期、受控、可审计的凭据管理。

• Argo Rollouts 的金丝雀策略
• Prometheus 指标分析
• 自动回滚

Argo Rollouts 用 Rollout 资源定义金丝雀发布策略（如先 10% 流量，观察指标后逐步放量），配合 AnalysisTemplate 定义 Prometheus 查询指标（如错误率、P99 延迟），当指标超阈值时自动回滚到稳定版本。Spring Boot 应用暴露 Prometheus 指标（Actuator + micrometer），Argo Rollouts 分析这些指标决定继续放量或回滚，实现"指标驱动、自动决策"的灰度发布。

Argo Rollouts 把金丝雀发布与指标分析自动化，是渐进式交付的可观测化。指标是回滚决策依据。

• StatefulSet 的稳定身份
• 有序部署与 PVC
• 适用场景

StatefulSet 用于有状态应用（数据库、消息队列、ZooKeeper 等），提供稳定网络身份（固定 Pod 名）、稳定存储（每副本绑定 PVC）、有序部署与缩容。它保证 Pod 顺序启动/终止、每个副本有独立持久化的存储，适合需要稳定身份与数据存储的应用。与此相对，Deployment 适合无状态应用。

StatefulSet 的"稳定身份+稳定存储"是针对有状态应用的特性，代价是复杂度高、缩容需谨慎。

• 稳定网络身份
• 有序更新
• PVC 与节点绑定

StatefulSet 的稳定网络身份（名为 pod-0、pod-1…）让有状态应用能按固定地址通信，分布式组件（如集群节点发现）依赖它；有序更新（按序启动/缩容）保证有状态应用在变更时保持一致性。持久卷（PVC）不与 Pod 自动跟随迁移，因为 PVC 绑定到某个节点的存储（如云盘），Pod 被调度到其他节点时，PVC 不一定可访问，需使用支持跨节点访问的存储（如 NFS、云存储）才能迁移。

稳定身份解决"地址可预期"，有序更新保证"状态一致"，而 PVC 的节点绑定决定数据迁移能力。

• --severity 按严重级别过滤
• .trivyignore 忽略特定漏洞
• 误报管理

Trivy 的 --severity 指定扫描的漏洞严重级别（如 CRITICAL,HIGH），只报告这些级别的漏洞；.trivyignore 列出要忽略的漏洞 ID（如不可达、无利用场景、已由其他方式缓解），用于管理误报。工程实践上，用 --severity 控制门禁阈值，用 .trivyignore 记录确认为误报或可接受的漏洞（附原因），定期审查，避免忽略真实风险。

severity 过滤是"门槛"，trivyignore 是"白名单"。误报管理需记录原因并定期复审，防止掩盖真实漏洞。

• cron 的触发精度与限制
• 分布式场景的单点/重复执行问题
• 分布式调度（xxl-job/Quartz/Elastic-jobs）

cron 表达式精度到分钟，且只能定义触发时间，无法保证分布式场景下的"只执行一次"（多个实例会重复触发）。在分布式部署中，定时任务需分布式调度（如 xxl-job、Quartz + 分布式锁、Elastic Job）来保证：任务只在一个实例执行（分片/选举）、失败重试、可观测。分布式调度补充了 cron 在"分布式一致性、调度精度、失败处理"上的不足。

cron 是"时间触发"，分布式调度是"分布式下的一致性执行"。关键问题是避免重复执行与保证失败处理。

• nerdctl 是 containerd 的 CLI
• 与 Docker CLI 的兼容
• 使用场景

nerdctl 是 containerd 的官方 CLI，命令与 Docker CLI 高度兼容（nerdctl run、nerdctl build 等），支持 containerd 的镜像、容器、卷管理，并支持 BuildKit、nerdctl compose。它用于不依赖 Docker 守护进程的环境（如 RKE2、K3s、containerd 原生环境），提供类 Docker 体验。兼容性上多数常用命令可用，但部分高级功能与 Docker 有差异。

nerdctl 是"无 Docker 环境的类 Docker CLI"，因 containerd 的普及而常用。需注意与 Docker 的功能差异。

• Ephemeral Containers 的临时容器
• 在线诊断与 jcmd 注入
• 安全与权限

Ephemeral Containers（临时容器）可在已有 Pod 中临时加入调试容器，不重启原容器，适合在线诊断：在 Java 应用容器中注入 jcmd、jmap、Arthas 等诊断工具，或共享进程命名空间查看 JVM 状态。最佳实践：诊断容器应与主容器共享 PID/进程命名空间，具备必要权限；诊断需谨慎（jmap 可能触发停顿），并遵循安全与审计要求。临时容器用于排障，不随 Pod 重启。

临时容器是"不侵入原进程的在线诊断手段"，适合 Java 应用 JVM 排障。需注意诊断工具副作用与权限。

• 各工作负载类型的适用场景
• 无状态 vs 有状态
• 一次性 vs 常驻

Deployment 适合无状态 Spring Boot 服务（可多副本、滚动更新）；StatefulSet 适合有状态组件（数据库、有状态缓存）；DaemonSet 适合每节点必须运行的组件（日志采集、监控 Agent）；Job 适合一次性批处理任务；CronJob 适合定时批处理。取舍依据：应用是否无状态、是否需要稳定身份、是一次性还是常驻、是否每节点运行。

选择工作负载类型取决于应用的性质（无状态/有状态、常驻/一次性、每节点/多副本）。

• readiness 失败摘流量不重启
• 依赖故障处理
• 优雅降级

readiness 失败只把 Pod 从 Service 端点移除，不重启容器，这一语义适合处理依赖故障：当依赖（数据库、下游服务）不可用时，该实例的 readiness 探针失败，流量被摘除，避免继续接收请求导致失败蔓延，但容器保持运行，等待依赖恢复后自动恢复就绪。这实现了"优雅降级"——不是靠重启，而是靠暂停接收流量，配合本地缓存或降级逻辑减少影响。

readiness 的"摘流量不重启"语义是优雅降级的基础。依赖恢复后自动重新接入流量，避免重启风暴。

• K8s 探针层
• 应用健康接口（Actuator）
• 多层次检查

健康检查分多层：K8s 探针层（liveness/readiness/startup）在集群层面管理容器生命周期与流量；应用健康接口层（Spring Boot Actuator /actuator/health）暴露应用与依赖的健康状态；还有业务层（自定义健康检查、依赖探活）。多层配合：探针调用应用健康接口判断可用性，应用健康接口聚合依赖状态，业务层做更深的功能验证。多层次让"进程、应用、依赖、业务"都有健康可见性。

健康检查是"分层可见性"，从进程到业务各层都有检查。探针是外壳，健康接口是内容，业务检查是深度的补充。

• 投射式令牌的短期性
• 受众（audience）绑定
• 过期时间配置

投射式 ServiceAccount 令牌是短期的、绑定受众（audience）的令牌，自动轮换，相比旧的长期 Secret 减少泄露窗口与凭据滥用风险。它通过 tokenFile 挂载，配置 audience（期望的受众，如 API server、外部服务）与 expirationSeconds（过期时间，如 1 小时）。令牌到期后自动轮换，而旧 Secret 长期有效、无轮换。受众绑定确保令牌只能用于指定服务。

短生命周期、受众绑定、自动轮换是投射式令牌的核心安全优势，显著降低凭据泄露风险。

• 日志采集器（Filebeat/Fluentd）
• 日志存储与查询（Loki/ELK）
• 云原生日志架构

日志收集架构通常分采集、存储、查询三层。采集层用 Filebeat/Fluentd 等采集容器日志并转发；存储层用 Loki（类 Prometheus 的标签式日志存储，与 Grafana 集成）或 ELK（Elasticsearch）等；查询层用 Grafana/Kibana。Filebeat 轻量高效，Fluentd 功能丰富支持插件；Loki 以标签索引、成本低，适合云原生；ELK 支持全文检索。工程上常组合使用。

云原生日志强调"采集-存储-查询"分层，Loki 与 Grafana 集成是云原生常用选择，ELK 更偏全文检索。

• 滚动发布的渐进更新
• 零停机与可回滚
• 取舍（版本并存、兼容性）

滚动发布渐进替换旧版本 Pod，保持服务可用，零停机，且可随时回滚。工程取舍：滚动期间新旧版本并存，需保证向后兼容（数据库 schema、API 兼容）；控制 maxSurge/maxUnavailable 平衡速度与可用性；滚动速度快则风险高、慢则发布慢。适合无状态、可兼容的微服务；对版本不兼容或需要切换的发布，需结合其他策略。

滚动发布是"渐进替换"，优势是零停机与快速回滚，代价是版本并存需兼容。权衡在于速度与风险。

• Runbook 的标准化步骤
• 部署与回滚流程
• 应急与文档化

部署与回滚的 Runbook 是标准化的操作手册，包含：部署前置检查、部署步骤、验证步骤（健康检查、指标）、回滚条件与步骤、升级与降级的具体命令、责任人。Runbook 让团队按统一流程执行，减少人为失误，快速响应故障。工程实践上，Runbook 应随发布自动化更新、纳入版本管理、定期演练，关键操作（如回滚）要预演。

Runbook 是"可执行的运维资产"，把部署/回滚的隐性知识文档化并标准化，是故障响应的保障。

• Feature Flag 的开关控制
• 灰度发布与回滚
• 与业务协同

Feature Flag 用开关控制功能的启用/禁用，无需重新部署即可发布、回滚功能。应用场景：灰度发布（按用户/比例开启）、快速回滚（关闭功能）、A/B 测试、环境差异化。工具可用 LaunchDarkly 等商业平台或自研（配置中心 + 数据库/内存）。工程实践：Flag 需命名规范、清理过期 Flag、控制 Flag 数量，避免技术债。

Feature Flag 把"发布"与"部署"解耦，实现功能级控制。需管理 Flag 生命周期避免累积。

• Service 与 Ready 端点
• EndpointSlice 的分片
• 大规模服务性能

Service 通过 Endpoints（或 EndpointSlice）维护后端 Pod 列表，只把流量发送到 ready 状态的 Pod（readiness 探针通过的端点）。EndpointSlice 替代旧 Endpoints，把大量端点按大小分片（默认 100 个/片），改善大规模服务下的性能与可扩展性，减少单对象过大导致的问题。它支持按拓扑提示（topology-aware）路由。

"只路由到 ready 端点"是 Service 的健康路由，EndpointSlice 分片解决大规模端点管理性能。

• preStop 钩子
• terminationGracePeriodSeconds 宽限期
• SIGTERM 与 SIGKILL

Pod 终止时，kubelet 先执行 preStop 钩子（如等待在途请求），然后发送 SIGTERM 给主容器（Spring Boot 优雅停机），整个流程在 terminationGracePeriodSeconds（默认 30s）内完成。若超过宽限期容器仍未退出，kubelet 发送 SIGKILL 强制终止，进程被立即杀死（可能丢失在途请求）。因此优雅停机需在宽限期内完成，必要时调大宽限期。

preStop（准备）、SIGTERM（优雅停机）、宽限期（总时间）、SIGKILL（强制兜底）构成完整终止时序。

• 金丝雀的渐进放量
• 流量比例与指标评估
• 与回滚

金丝雀发布先把新版本部署到少量实例（如 10% 流量），观察指标（错误率、延迟）确认正常后，再逐步放量到全量。核心是"小范围验证 + 渐进放量"，若指标异常则回滚到稳定版。相比蓝绿的"全量切换"，金丝雀风险更低、更精细，但发布周期更长。实现可用 Argo Rollouts、Istio 流量权重或 service mesh。

金丝雀是"渐进式灰度"，以指标为决策依据。需注意版本并存与流量分配的一致性。