首页/云/Kubernetes 速查

Kubernetes 速查

kubectl 命令、工作负载与控制器、Service 与 Ingress、配置存储、调度与资源、集群排障：K8s 日常运维速查。

共 307 条更新于 2026-10-12所属领域：云

共 307 条

kubectl 基础

get/describe/logs/exec/apply 等高频操作

kubectl get 查询资源列表热门

列出 Pod/Deployment/Service 等资源摘要信息的高频命令，支持按命名空间与标签筛选，并用 -o 切换输出格式。

kubectl logs 查看容器日志热门

读取容器标准输出日志：支持跟踪实时输出、按时间/行数截取、多容器指定、多 Pod 标签聚合，是应用排障入口。

kubectl describe 查看资源详情与事件热门

展示资源的完整状态：副本数、容器状态、探针、挂载、条件（Conditions），末尾 Events 是排障的起点。

kubectl apply 声明式应用清单热门

把 YAML/JSON 清单提交给集群：不存在则创建、存在则按三方合并策略更新，是 GitOps 与日常发布的基础命令。

kubectl exec 进入容器执行命令热门

在运行中的容器内执行命令或打开交互 shell，用于现场排查网络、DNS、配置挂载与环境变量等运行时问题。

kubectl delete 删除资源

删除资源支持按名称、按清单文件、按标签批量执行；级联策略决定是否连带删除下级对象，是高风险操作里最常用的收尾命令。

kubectl get events 查看事件

事件记录了调度、拉镜像、探针失败、驱逐等关键动作，按时间排序与筛选后是定位「为什么不行」的入口。

kubectl get -o wide 宽格式输出

-o wide 在默认列基础上补充关键定位信息：Pod 显示 IP 与所在节点，节点显示内网 IP 与运行时，Service 显示选择器。

kubectl get -o yaml/json 导出资源

把资源的完整对象（含 spec、status、metadata）导出为 YAML 或 JSON，是备份配置、分析字段结构、改造清单的常用起点。

kubectl rollout status 观察发布进度

阻塞等待一次滚动更新完成并输出进度，直到新版本全部可用或超时；适合发布脚本串行化与人工值守。

kubectl port-forward 本地端口转发

在本机与 Pod/Service 之间建立端口隧道，不经过公网即可访问集群内服务；调试数据库、管理端点、临时验证接口的常用手段。

kubectl top 查看资源用量

显示节点与 Pod 的实时 CPU/内存用量（来自 metrics-server），用于快速定位吃资源的对象，是容量巡检的常用入口。

kubectl get -o jsonpath 提取字段

用 jsonpath 表达式从资源对象中抽取任意字段，适合脚本取值：批量取 Pod 名、查容器镜像、取节点名等。

kubectl rollout restart 滚动重启

以滚动方式重建工作负载的全部 Pod（加入 restartedAt 注解触发模板变更），常用于让新 ConfigMap/Secret 生效。

K8s YAML 清单结构要点

一份清单的骨架：apiVersion/kind/metadata/spec 四段；理解缩进、字段层级与「声明期望状态」的语义，是写对 YAML 的基础。

kubectl logs --previous 查看重启前日志

容器崩溃重启后当前实例日志往往是空的，--previous 读取上一个已终止实例的日志，是 CrashLoopBackOff 排查的关键手段。

kubectl set image 更新容器镜像

不用手改 YAML 直接替换 Deployment/StatefulSet 等模板中的容器镜像，更新即触发滚动发布，是发布流水线的常用一步。

kubectl rollout undo 回滚发布

把工作负载回退到上一个或指定修订版本，回滚同样以滚动方式执行；Deployment 通过切换 ReplicaSet 完成。

kubectl 命名空间查看与切换

命名空间是大多数资源的隔离边界；查资源、执行命令、排查问题时先确认所处命名空间，是 K8s 日常操作的基本功。

kubectl debug 与临时容器

给运行中的 Pod 注入临时容器（ephemeral container）做诊断：镜像里没有 shell、或主容器已崩溃时仍能进入同一命名空间看现场。

kubectl create 命令式创建资源

用命令行参数直接创建资源或快速生成清单草稿：--dry-run=client -o yaml 是生成 YAML 模板的常用手法。

kubectl scale 手动扩缩容

调整 Deployment/StatefulSet/ReplicaSet 副本数，也支持开条件判断（当前副本数匹配才执行），是最直接的容量操作。

kubectl config 管理 kubeconfig 与上下文

kubeconfig 里保存集群、用户、命名空间上下文三要素；用 config 系命令查看、切换与合并多集群配置，是操作多集群的入口。

kubectl -l 标签选择器

用标签表达式批量筛选资源：等值、集合（in/notin）、存在性判断；排障时给一组 Pod 同时看日志/详情全靠它。

kubectl patch 局部修改资源

不重写整个清单，只提交差异字段：默认 strategic merge（对象合并），也可用 --type=json 做精确路径操作。

kubectl --field-selector 字段筛选

按资源字段（而非标签）过滤：查某节点上的 Pod、非 Running 的 Pod、Warning 事件等，是「按属性找对象」的快捷方式。

kubectl get -o custom-columns 自定义表格

自定义列名与取值路径，把关心的字段拼成一张表，比 -o wide 更灵活，适合日常巡检和结果留档。

kubectl edit 在线编辑资源定义

用编辑器直接打开集群中资源的 YAML，保存后即提交更新；适合紧急微调与试探字段，变更不易追溯。

kubectl --dry-run 试运行与预检

不真正落库地执行创建/更新：client 模式本地生成对象，server 模式提交 API 服务走准入校验，是改清单前的安全检查。

kubectl rollout history 查看发布历史

列出工作负载的历史修订版本（revision），配合 --revision 查看某次的 Pod 模板快照，是回滚前的必修课。

kubectl top 没有数据排查

kubectl top 依赖 Metrics API：报 Metrics API not available 或只显示部分节点时，按聚合层、metrics-server、kubelet 三步查。

kubectl api-resources 查询资源清单

列出集群支持的全部资源类型：短名、API 组、是否命名空间级、对应 Kind，写 RBAC 与排障时先确认资源的准确名称。

kubectl label 管理资源标签

给资源打标签/改标签/去标签；标签是选择器（Service、Deployment、NetworkPolicy）关联对象的主要依据，改错直接影响配对。

kubectl cp 与容器互传文件

在本地与容器之间复制文件/目录，基于 tar 实现：日常用来取日志、导配置、塞临时脚本，注意容器内需要有 tar。

kubectl 常用资源缩写速查

日常命令里的资源名缩写对照：po/deploy/svc 等，记住高频缩写能明显加快输入；完整清单用 api-resources 查询。

YAML 多文档与批量应用技巧

单文件用 --- 分隔多个对象、单目录递归应用整个清单集；掌握 apply -f 的目录/URL/标准输入用法，能省去大量重复命令。

kubectl explain 查询字段文档

内置的字段参考手册：按资源路径展开字段含义与类型，--recursive 递归展示子字段，不联网即可对照集群版本查看。

kubectl set env 更新环境变量

直接给工作负载增删改环境变量，支持从 ConfigMap/Secret 批量注入；修改 Pod 模板后会触发一次滚动更新。

kubectl wait 等待资源条件

阻塞等待资源达到指定条件（可用、就绪、删除完成），把「等就绪」从 sleep 猜测变成确定性等待，适合脚本与 CI。

kubectl --sort-by 排序输出

按任意字段排序资源列表：按创建时间找最近创建的 Pod、按重启次数挑异常容器、按节点名聚合查看，巡检结果更直观。

kubectl apply --server-side 服务端应用

由 API Server 以服务端应用（SSA）模式合并字段，用 managedFields 记录各管理者的字段所有权，解决多方协同编辑冲突。

kubectl annotate 管理注解

注解存任意非标识性元数据，很多控制器靠注解驱动行为：Ingress 规则、证书签发、Prometheus 抓取开关都通过注解配置。

kubectl auth can-i 权限自检

回答「当前或指定身份能否执行某操作」，用 --as 模拟其他用户/ServiceAccount，是 403 报错时的常用诊断命令。

kubectl -w 持续观察资源变化

保持连接持续输出资源变更，观察 Pod 调度、滚动更新、删除过程的动态画面；配合 -o 格式可追踪特定字段变化。

kubectl diff 对比清单与现网

把本地清单与集群现状做服务器端对比，发布前确认「将要发生什么变化」，输出风格类似 git diff。

kubectl -v 调试日志级别

输出 kubectl 与 API Server 的交互细节：请求 URL、响应状态、耗时；认证/权限/超时类怪问题用它定位。

kubectl get --raw 直读 API 端点

绕过资源抽象直接读取任意 API 路径原始返回，常用于检查健康端点、聚合 API 与 metrics 端点，是高级排障工具。

kubectl proxy 本地访问 API Server

在本机开一个反向代理端点，自动带上当前 kubeconfig 的认证访问 API Server，便于用 curl/浏览器直接调 REST API 排查。

kubectl kustomize 与 -k 使用

Kustomize 内置在 kubectl：用 base + overlay 结构复用清单，通过 patch 与 namePrefix 等生成器管理多环境差异，无需模板语法。

kubectl rollout pause/resume 暂停发布

暂停滚动发布后继续修改模板（如分批改镜像/环境变量），改完再恢复，可把多次修改合并成一次发布或实现暂停观察的金丝雀。

kubectl version 版本与偏斜检查

查看客户端与服务端版本，确认 kubectl 与集群的版本偏斜（skew）在支持范围内，避免因版本差异出现奇怪行为。

kubectl attach 附加到容器主进程

把本地终端附加到容器中正在运行进程（PID 1）的标准输入输出，观察或输入主进程数据，与 exec 起新进程不同。

kubectl completion 命令补全

为 bash/zsh/fish/PowerShell 启用命令与资源名补全，减少长资源名输入与拼写错误；资源名补全会实时查询集群。

kubectl apply --prune 清理遗留对象

应用清单的同时删除「带指定标签但已不在清单里」的对象，让集群资源与目录严格对齐；用错会删掉不该删的资源。

kubectl replace 整体替换对象

用新对象整体替换现有对象（先删后建语义的更新），处理 apply 难以覆盖的场景；--force 可删除重建用于不可变字段。

kubectl apply view-last-applied 查看应用记录

查看/编辑 apply 记录的 last-applied-configuration 注解，理解三方合并的基线，排查「apply 后字段为什么没变」。

工作负载

Deployment/StatefulSet/DaemonSet/Job 与滚动更新

Deployment 基础与常用操作热门

无状态应用的标准控制器：声明副本数与 Pod 模板，由它维护 ReplicaSet 与滚动发布；日常运维围绕它做发布、扩缩、回滚。

Deployment 滚动更新策略 RollingUpdate

默认发布策略：按 maxSurge/maxUnavailable 控制新旧副本配比，新 Pod 就绪才继续替换，实现不中断发布。

StatefulSet 基础与稳定标识

为有状态应用提供稳定的 Pod 名称、网络标识与独立存储：副本按序创建/删除，适合数据库、队列、协调服务等。

Pod 基础结构与本质

Pod 是最小调度单元：一个或多个共享网络命名空间与存储卷的容器组；生产上一般由控制器（Deployment 等）管理而非裸建。

CronJob 定时任务基础

按 cron 表达式周期性创建 Job：备份、报表、清理等定时作业；理解调度与 Job 模板的关系是使用前提。

Job 一次性任务基础

运行到成功完成的批处理控制器：镜像跑完退出即完成；completions/parallelism 控制要跑几个实例、并行几个。

Pod 生命周期与相位（Phase）

Pod 从创建到终止经过 Pending/Running/Succeeded/Failed/Unknown 相位；相位描述整体状态，具体原因要看容器状态与事件。

DaemonSet 每节点守护进程

保证（符合条件的）每个节点运行一个 Pod：日志收集、监控 agent、CNI/存储插件等基础设施组件的标准载体。

Init 容器（initContainers）

在主容器启动前按顺序逐个运行到成功退出的专用容器：做依赖等待、数据初始化、权限准备；失败会阻塞并重试。

Deployment 状态条件解读

status.conditions 记录 Available 与 Progressing 两类条件及其原因：判断发布是否健康、是否卡死的关键依据。

工作负载控制器选型总览

五类控制器的适用场景对照：无状态用 Deployment、有状态用 StatefulSet、每节点守护用 DaemonSet、批处理用 Job、定时用 CronJob。

优雅终止与 terminationGracePeriodSeconds

删除 Pod 的标准流程：标记 Terminating → 摘除端点 → 发 SIGTERM → 等待宽限期 → SIGKILL；preStop 钩子可在信号前执行收尾。

StatefulSet 与 Headless Service 的 DNS

Headless Service（clusterIP: None）为每个 Pod 提供独立 DNS 记录，客户端可直连具体实例；这是有状态集群互相发现的基础。

imagePullPolicy 拉取策略与生效规则

控制 kubelet 何时拉镜像：Always/IfNotPresent/Never；不写时默认值随镜像 tag 变化，是「改了镜像没生效」的常见根因。

volumeClaimTemplates 存储申领模板

StatefulSet 按模板为每个副本生成独立 PVC（data-db-0、data-db-1…），Pod 重建或迁移后仍挂回同一份数据。

ReplicaSet 副本集合

维持指定数量 Pod 的控制器，通常由 Deployment 自动管理；理解它能看懂发布过程中的新旧 ReplicaSet 交替。

restartPolicy 重启策略

定义容器退出后 kubelet 是否重启：Always（默认）、OnFailure、Never；对 Job/CronJob 与一次性任务影响显著。

revisionHistoryLimit 修订历史保留

控制保留多少个旧 ReplicaSet 供回滚；保留越多可回滚版本越多，也会占用 etcd 与集群对象数量。

command 与 args 覆盖容器启动命令

清单里的 command 覆盖镜像 ENTRYPOINT，args 覆盖 CMD；两者的组合矩阵决定容器最终执行什么，是定制镜像行为的常用手段。

Sidecar 容器与原生 sidecar

辅助容器与主容器同 Pod 协作（日志收集、代理、守护）；较新版本支持 init 容器配 restartPolicy: Always 实现启动顺序可控的原生 sidecar。

工作负载 selector 的不可变约束

apps/v1 下 Deployment/StatefulSet/DaemonSet 的 selector 创建后不可修改，且必须匹配 Pod 模板标签；改选择器只能重建对象。

StatefulSet 更新策略（含 partition 灰度）

RollingUpdate 默认按序号从大到小逐个逆序更新并在每一步等待就绪；partition 可只更新序号 ≥ 分区的 Pod，实现灰度/预热。

Job 失败重试与 backoffLimit

backoffLimit 限制失败重试次数（默认 6），重试间隔按指数退避逐步加倍（从约 10 秒开始，达到上限后固定）；用 restartPolicy 决定重试发生在容器级还是 Pod 级。

Deployment 重建策略 Recreate

先终止全部旧 Pod 再创建新 Pod 的发布方式：存在明确的中断窗口，仅适合无法新旧版本并存的场景。

minReadySeconds 与 progressDeadlineSeconds 调优

minReadySeconds 让 Pod 就绪后再观察一段时间才算可用（过滤秒挂的新版本）；progressDeadlineSeconds 定义发布停滞多久判失败。

Job 并行度与完成数（completions/parallelism）

completions 定义需要成功完成的总次数，parallelism 定义同时在跑的 Pod 数；两者搭配决定「总量与并发」。

DaemonSet 更新策略与滚动参数

RollingUpdate（默认）按 maxUnavailable 逐节点替换；maxUnavailable 可数字或百分比，集群大时控制同时更新的节点数。

ttlSecondsAfterFinished 自动清理任务

任务结束后经过指定秒数自动删除 Job 及其 Pod；让批处理不无限堆积对象，是集群卫生的基础配置。

pod-template-hash 与 ReplicaSet 命名

Deployment 给每个 Pod 模板生成哈希标签，ReplicaSet 用它区分新旧版本；理解命名规则能快速判断 Pod 属于哪次发布。

CronJob 并发策略 concurrencyPolicy

上一次任务还没跑完时下一次调度怎么办：Allow（默认，并发跑）、Forbid（跳过本次）、Replace（停旧起新）。

podManagementPolicy 并行/顺序管理

OrderedReady（默认）保证严格按序启动/删除；Parallel 让所有 Pod 同时创建删除，适合不需要顺序的分布式存储类应用。

StatefulSet 的 PVC 保留策略

persistentVolumeClaimRetentionPolicy 决定缩容或删除 StatefulSet 时自动删除还是保留 PVC：默认全部保留，防止误删数据。

Job 索引模式（completionMode: Indexed）

每个 Pod 获得专属索引（0..completions-1，环境变量 JOB_COMPLETION_INDEX 或注解），适合分片处理数据集。

activeDeadlineSeconds 限制任务总时长

给 Job（或 Pod）设置从启动起的运行时间上限，超时即终止并标记失败；防止批任务挂死占用资源。

CronJob 时区设置 spec.timeZone

较新版本支持为 CronJob 指定 IANA 时区（如 Asia/Shanghai），不再依赖控制面节点时区，跨时区调度更可控。

CronJob 历史保留数量限制

successfulJobsHistoryLimit（默认 3）与 failedJobsHistoryLimit（默认 1）控制保留的已完成/失败 Job 数量，控制对象膨胀。

网络与服务

Service/Ingress/DNS 与网络策略

Service ClusterIP 集群内虚拟 IP热门

默认 Service 类型：分配一个仅集群内可达的虚拟 IP，kube-proxy 把访问该 IP 端口的流量转发到后端 Pod，是无状态服务互访的标准入口。

Ingress 七层入口基础

HTTP/HTTPS 路由规则对象：按域名与路径把请求转发到不同 Service；必须配合 Ingress Controller 才会生效，否则只是存起来的配置。

CoreDNS 服务发现与 DNS 命名规则

集群 DNS 为 Service 与 Pod 提供解析：<svc>.<ns> 短名、FQDN、Headless 的 Pod 级记录；写访问地址与排查解析问题都要用这些规则。

Service NodePort 节点端口暴露

在每个节点上打开同一端口（默认 30000-32767），集群外可通过「任意节点 IP:端口」访问服务；便于测试与小型环境，端口管理成本较高。

Service LoadBalancer 云负载均衡

在支持 LB 的云或安装了 LB 实现的环境中申请外部负载均衡器并绑定服务；云上常用的对外暴露方式。

NetworkPolicy 网络策略基础

以 Pod 为对象的防火墙规则：选择哪些 Pod、允许哪些方向的流量；策略是叠加的允许清单，未放行的默认拒绝。

Service 端口三件套：port/targetPort/nodePort

分清三个端口是写对 Service 的关键：port 是服务入口，targetPort 是容器监听，nodePort 是节点映射；targetPort 默认等于 port。

集群内 DNS 解析失败排查

从一个 Pod 的解析行为入手：先看 Pod 的 resolv.conf 与搜索域，再查 CoreDNS 副本、Service 与上游转发。

Endpoints/EndpointSlice 解读

Endpoints 是 Service 后端的地址清单；EndpointSlice 把后端分片存储（每片默认至多 100 个）并携带就绪状态，是大集群的扩展方案。

Ingress TLS 证书配置

在 Ingress 上配置 TLS：引用同命名空间中的 kubernetes.io/tls 类型 Secret，控制器据此终结 HTTPS 并按 rules.host 提供服务。

kube-proxy 与转发规则排查

Service 不通按层查：Endpoints 是否有就绪后端 → kube-proxy 组件是否正常 → 节点上的转发规则与防火墙是否放行。

Ingress 502 / 503 排查

502 多为控制器连不上后端，503 常是没有就绪后端：先看 Service 的端点，再看 Ingress 控制器日志与后端探针状态。

Service 访问链路：从域名到 Pod

一次集群内访问的完整路径：DNS 解析得到 ClusterIP → 报文到虚拟 IP → kube-proxy 规则改写目标为某后端 Pod → conntrack 记录会话。

ingress-nginx 常用注解

nginx 控制器通过注解精细控制行为：路径重写、请求体大小、超时、后端协议等；注解写错不报错但行为不符合预期。

LoadBalancer 一直 Pending 的排查

LoadBalancer Service 的 EXTERNAL-IP 长期 <pending>：说明没有控制器为它分配外部地址，多见于裸金属/自建集群或云控制器异常。

Ingress pathType 匹配语义

pathType 决定路径匹配方式：Prefix 按路径元素前缀匹配、Exact 精确匹配、ImplementationSpecific 交给控制器解释；写不对会出现意外路由。

默认拒绝策略（default-deny）

零信任起点：先把命名空间全部流量拒绝，再逐条放行必要通信；能用最小放行集合描述清楚业务依赖。

externalTrafficPolicy 源 IP 保留

NodePort/LoadBalancer 的流量分布策略：Cluster（默认，可跨节点转发）与 Local（只转发本节点后端，保留客户端源 IP、少一跳）。

kube-proxy 工作模式（iptables/IPVS）

kube-proxy 负责把 Service 虚拟 IP 落到真实后端；iptables 模式通用、IPVS 模式转发效率更高（较新版本中 IPVS 已标记弃用，选型跟随发行版建议）。

Ingress Controller 做了什么

控制器是让 Ingress 落地的执行者：监听 Ingress/Service/Secret 变化，生成并热加载反向代理配置，同时承载入口流量。

egress 策略下的 DNS 放行

出向默认拒绝后必须显式放行到 kube-dns/CoreDNS 的 53 端口（UDP/TCP），否则域名解析失败会被误判成「网络全挂」。

Service ExternalName 外部域名映射

把集群内的服务名映射到外部 DNS 名称（CNAME 语义），不改应用配置即可指向外部数据库/中间件；不代理流量也不做健康检查。

Headless 与 ClusterIP 的行为差异

Headless（clusterIP: None）不分配虚拟 IP，DNS 直接返回后端 Pod IP；ClusterIP 返回虚拟 IP 由 kube-proxy 转发。两者用途不同。

ndots 与 DNS 解析行为调优

Pod 的 resolv.conf 默认 ndots:5：名称中点数少于 5 时先尝试各 search 域，再试原始名称；这会让外部域名解析多绕几圈，也会造成「外部域名解析慢」。

NetworkPolicy 规则要素（from/to/ports）

一条规则由「方向 + 来源/目的 + 端口」组成：from 管入向、to 管出向，ports 用协议+端口限定；粒度为端口级而非应用层。

CoreDNS 配置（Corefile）定制

CoreDNS 行为由 kube-system/coredns ConfigMap 中的 Corefile 定义：可加 hosts 静态记录、调 forward 上游、开日志插件排查解析问题。

default 命名空间的 kubernetes 服务

每个集群都有 default/kubernetes 这个 Service，指向 API Server；Pod 内通过它或 KUBERNETES_SERVICE_HOST 访问集群 API。

IngressClass 与多控制器选择

IngressClass 标识由哪个控制器处理 Ingress：集群可装多个控制器，用 spec.ingressClassName 指定；设默认类可省略该字段。

CNI 插件与 Pod 网络模型

CNI 负责给 Pod 分配 IP 并打通跨节点通信：Flannel 简单、Calico 走 BGP 且策略能力强、Cilium 基于 eBPF；选型影响性能与可观测性。

NodePort 连通性验证步骤

从集群外验证 NodePort 需要按「服务配置 → 后端就绪 → 节点监听 → 防火墙 → 源端路由」顺序排查，避免盲改。

无选择器 Service 与手动 Endpoints

Service 不写 selector 时不自动管理后端，由你手动维护 Endpoints/EndpointSlice：用于接外部 IP、跨命名空间后端或迁移期桥接。

dnsPolicy 与 dnsConfig 定制

dnsPolicy 决定 Pod 用哪套解析配置（默认 ClusterFirst）；hostNetwork Pod 需要 ClusterFirstWithHostNet；dnsConfig 可追加自定义 nameserver/search。

Ingress 多域名与通配主机

单个 Ingress 可用多条 rules 服务多个域名（含通配域名），配合不同后端实现多站点 Host 路由；共享入口节省资源。

ingress-nginx 金丝雀发布注解

通过 canary 注解把部分流量导到新版本服务：按权重或按请求头/ cookie 分流，无需额外网关。

NetworkPolicy 选择器组合语义

namespaceSelector 与 podSelector 写在同一条目里是 AND（该命名空间内匹配的 Pod），分成多条目是 OR（任一满足即放行）。

NetworkPolicy 依赖的 CNI 能力

策略要真正执行必须由 CNI 插件实现；Calico、Cilium、Antrea 等支持策略，纯 Flannel 默认不执行策略（对象能建但不起作用）。

hostPort、hostNetwork 与 NodePort 区分

三种「占用节点网络」的方式语义不同：hostPort 映射单端口、hostNetwork 共享节点网络栈、NodePort 是 Service 层的节点端口；选错影响调度与安全。

默认拒绝下放行 Ingress 控制器

给业务上默认拒绝策略后，Ingress 控制器到后端的入向流量也要显式放行，否则入口返回 503 且应用毫无请求日志。

对外/对内访问方式选型对照

把 ClusterIP、NodePort、LoadBalancer、Ingress、port-forward 放在一张表里对照：按「谁访问、什么协议、运维成本」选型。

Service 会话保持 sessionAffinity

把同一客户端 IP 的请求尽量固定到同一后端 Pod：ClientIP 模式配合超时时间使用，适用于有本地会话状态的旧应用。

Service 转发与 conntrack 会话表

kube-proxy 依赖内核 conntrack 记录连接映射：表满会导致新连接被丢弃（日志报 'nf_conntrack: table full'），是大流量节点的常见隐患。

Pod CIDR 与节点网段分配

每个节点从集群 Pod 网段分到一块子网（podCIDR），Pod IP 从中分配；规划时要避开节点网段、Service 网段与既有专线网段。

internalTrafficPolicy 集群内就近转发

控制集群内访问 Service 的路径：Cluster（默认，任意后端）与 Local（优先本节点后端），可减少跨节点一跳并提升本地性。

Ingress 默认后端与 404 行为

请求不匹配任何规则时的兜底：控制器自带默认后端（通常返回 404），也可在 Ingress 上指定 defaultBackend 指向自建兜底服务。

ingress-nginx 控制器全局配置

控制器的 ConfigMap 里配置全局参数（请求体上限、SSL 协议、可信代理 IP 等），影响该控制器下所有 Ingress，改动需谨慎评审。

ipBlock 管控外部网段

针对集群外 IP 段做放行/排除（cidr + except）：数据库白名单、第三方 API 出口控制等场景使用，注意与 SNAT 的交互。

MetalLB 与裸金属 LoadBalancer

裸金属集群的 LoadBalancer 实现：从配置的地址池给 Service 分配外部 IP，L2 模式用 ARP/NDP 宣告，BGP 模式与路由器对接。

Service 字段变更注意事项

Service 更新受限：clusterIP 不可变；type 可在 ClusterIP/NodePort/LoadBalancer 间切换但语义有差异；已分配的 nodePort 会尽量保留。

Service 的环境变量注入机制

Pod 启动时 kubelet 会为「先于 Pod 存在的 Service」注入 <大写名称>_SERVICE_HOST/PORT 变量；已知服务名时更推荐用 DNS。

指定与更换 ClusterIP 的规则

ClusterIP 可在创建时从 Service 网段内指定，创建后不可修改；删除重建通常会拿到新 IP，理解这一点对依赖固定 IP 的旧系统很重要。

Gateway API 简介与 Ingress 的关系

Kubernetes 新一代入口/网关标准：GatewayClass、Gateway、HTTPRoute 分角色管理，表达力强于 Ingress；处于逐步普及阶段，选型前确认生态支持。

NodePort 端口范围与分配策略

默认范围 30000-32767，由 apiserver 参数控制；可指定固定 nodePort 也可自动分配，端口是集群级资源需要台账管理。

ClusterIP 为什么 ping 不通

ClusterIP 是 kube-proxy 规则实现的虚拟地址：主要处理「到服务端口的连接」，ICMP 往往不被转发；ping 不通不代表服务不可用。

Service trafficDistribution 就近路由

较新版本支持通过 spec.trafficDistribution 将流量尽量导向同区域/同节点的后端（如 PreferClose），降低跨区延迟；依赖节点拓扑标签。

IPv4/IPv6 双栈 Service 要点

双栈集群中 Service 可同时拥有 IPv4/IPv6 地址，由 ipFamilyPolicy 与 ipFamilies 控制；单栈集群里这些字段按默认行为即可。

配置与存储

ConfigMap/Secret/PV/PVC 与 StorageClass

ConfigMap 创建方式速查

配置数据（非敏感）的键值集合：用命令行从字面量/文件/目录快速创建，或用 YAML 声明维护，注意键名与大小限制。

ConfigMap 注入环境变量（env/envFrom）

把配置以环境变量注入容器：单键用 valueFrom.configMapKeyRef，整集合用 envFrom；注入发生在容器启动时，运行中不更新。

Secret 创建方式（generic/tls/docker-registry）

按用途选择创建子命令：generic 存任意键值、tls 直接吃证书文件、docker-registry 生成镜像仓库凭据；也可用 YAML 声明。

subPath 挂载不接收更新

用 subPath 把单个键挂成文件时，卷内容的后续更新不会同步到容器——这是「改了 ConfigMap/Secret 但容器里还是旧值」的常见根因，需要重建 Pod 或改用目录挂载。

ConfigMap 以卷方式挂载

把 ConfigMap 的键做成文件挂到容器目录，支持 items 挑选与重命名键、指定路径；适合配置文件类数据。

Secret 类型总览

Secret 按用途分类型：Opaque 通用、TLS 证书、dockerconfigjson 镜像仓库凭据、ServiceAccount Token 等；类型决定字段校验与消费方式。

PV 与 PVC 绑定机制

PVC 是使用者的申请（容量、访问模式、StorageClass），PV 是实际的存储对象；控制器按条件把两者绑定，Pod 只通过 PVC 名引用卷。

PVC 一直 Pending 排查

Pending 的常见原因：没有匹配 PV、类不存在、制备器报错、WaitForFirstConsumer 等待调度；按事件逐项定位。

ConfigMap 更新后的生效行为

更新 ConfigMap 后：卷挂载（非 subPath）会分钟级同步且应用需自行重读；环境变量注入不更新；immutable 则完全禁止修改。

emptyDir 临时卷与容器间共享

Pod 生命周期内的临时目录：容器重启数据保留、Pod 删除即清空；多容器共享同一 emptyDir 是 sidecar 模式的常用手段。

StorageClass 动态制备

声明「用哪个制备器、什么参数」的模板：PVC 引用后由外部制备器自动创建 PV，免去手工建卷；参数键值随驱动不同。

Secret 以卷方式挂载

把 Secret 键落成文件挂给容器（默认权限 0644，可按需收紧到 0440/0400）；便于证书、配置文件类凭据使用。

hostPath 挂载节点目录

直接挂载节点上的路径（如 /var/log、/dev），用于采集节点日志或访问设备；对调度与权限有强约束，能用 local PV 或 CSI 替代时优先替代。

存储访问模式解读

RWO/ROX/RWX/RWOP 描述挂载语义而不是权限开关：是否支持由存储驱动决定，共享文件系统支持 RWX，块存储多数只支持 RWO。

imagePullSecrets 拉取私有镜像

私有仓库凭据存在 docker-registry 类型 Secret 中，通过 Pod 的 imagePullSecrets 或 ServiceAccount 交给 kubelet。

kubernetes.io/tls 类型 Secret

承载 TLS 证书与私钥的标准类型：键固定为 tls.crt 与 tls.key，供 Ingress 与网关引用；kubectl 可直接生成。

K8s 存储对象全景

理清 Volumes（Pod 内声明）、PV/PVC（供给与申请）、StorageClass/CSI（供给方式）的分工与调用链，排障时不迷路。

Secret 的 data 与 stringData

data 需要 base64 编码、stringData 直接写明文（写入时自动转 data）；读取时永远看 data（base64）。

Secret 注入环境变量

用 valueFrom.secretKeyRef 或 envFrom.secretRef 把凭据注入变量；环境变量可见于进程环境与部分运行时接口，敏感场景优先卷挂载。

Downward API 注入 Pod 元数据

把 Pod 名称、命名空间、IP、节点名、资源限制等通过环境变量暴露给容器，无需访问 API Server；日志打标与自注册脚本常用。

PVC 扩容

在 StorageClass 开启 allowVolumeExpansion 的前提下，改大 PVC 的 requests.storage；文件系统扩展可能需要重启 Pod 才完成。

Secret 与 ConfigMap 选用对比

两者结构几乎一样（键值 + 环境变量/卷注入），差异在定位与安全语义：Secret 值以 base64 存储、可配静态加密与更严的 RBAC，敏感数据走 Secret。

RWO 卷跨节点挂载冲突

云盘类 RWO 卷同一时刻只能被一个节点挂载：两个副本被调度到不同节点时，第二个会卡在 ContainerCreating，并出现 Multi-Attach 报错。

卷挂载失败（FailedMount）排查

FailedMount 与 FailedAttachVolume 说明卷没准备好：按 CSI/云盘侧、PV 与 PVC 绑定、Secret 与 ConfigMap 引用三类分开看。

ServiceAccount Token 卷投影

1.24 起不再为每个 ServiceAccount 自动创建长期 Token Secret；工作负载改用 projected serviceAccountToken 获取带过期时间的短期令牌，由 kubelet 轮换。

默认 StorageClass 与标记

只有被标为默认的类才会给「未写 storageClassName 的 PVC」动态供卷；多类并存时一般只保留一个默认，行为更可预期。

PV 回收策略 Delete/Retain

PV 释放后的处置方式：Delete 连底层存储一起删；Retain 保留数据但 PV 变为 Released，需要人工清理后重建或恢复可用。

存储故障的事件排查路径

挂载与附着问题几乎都能在事件里找到原文：FailedAttachVolume、FailedMount、FailedScheduling 各自指向不同层。

挂载点会遮蔽目录原有内容

把卷挂到容器里已有文件的目录时，原内容被遮蔽而不是合并：nginx 的 /etc/nginx/conf.d、应用的 conf 目录都常踩这个点。

volumeBindingMode 与拓扑感知

Immediate 在 PVC 创建时立即供卷；WaitForFirstConsumer 等 Pod 调度后再供卷，避免卷与节点拓扑不匹配导致 Pod 卡住。

PV 生命周期状态流转

Available → Bound → Released → Failed：理解状态含义，才能判断卷还在不在、数据能否复用、下一步该处理哪个对象。

fsGroup 解决挂载目录权限

Pod 级 securityContext.fsGroup 让 kubelet 调整卷的属组并赋予组读写位，解决非 root 容器写不进卷的问题。

配置变更触发滚动更新（checksum 模式）

把配置内容哈希写进 Pod 模板注解：配置一变模板即变，Deployment 自动滚动重建 Pod，规避 env/subPath 不传播的问题。

projected 卷合并多来源

把 ConfigMap、Secret、Downward API、ServiceAccount Token 合并到同一个挂载目录，减少容器里的卷数量；同名文件按 sources 顺序后者覆盖前者。

PVC 删除保护与使用中删除

带 kubernetes.io/pvc-protection finalizer 的 PVC 在仍被 Pod 使用时不会真正删除，会停在 Terminating；先停工作负载再删卷。

local 卷与本地 PV

把节点本地磁盘以 local 卷暴露，配合 nodeAffinity 固定调度；吞吐与延迟占优，但不具备跨节点冗余，节点故障时数据不可用。

VolumeSnapshot 卷快照

CSI 快照 API（snapshot.storage.k8s.io/v1）：用 VolumeSnapshotClass + VolumeSnapshot 对 PVC 打快照，由存储侧提供能力。

local ephemeral storage 配额

容器可写层、日志与 emptyDir 占用节点本地存储，可用 requests/limits 约束；超限会被驱逐（Evicted: ephemeral-storage）。

emptyDir 的 Memory 介质

medium: Memory 用 tmpfs 提供内存盘，适合高速缓存的临时数据；其用量计入容器内存限制，需要与 memory limit 一起规划。

NFS 卷挂载

直接在 Pod 里声明 nfs 卷（server + path），多节点共享读写；所有节点需要能访问 NFS 服务并具备挂载工具。

从快照恢复 PVC

用 dataSource 指定快照让新 PVC 重建内容；请求容量不能小于快照容量，storageClassName 需与快照类兼容。

Downward API 卷形式

把标签、注解等以文件形式挂进容器并周期同步；适合需要感知自身标签变化的场景，节点名、Pod IP 这类字段则只能走环境变量形式。

volumeMode：文件系统与裸块设备

PV/PVC 的 volumeMode 默认 Filesystem（挂载成目录）；Block 直接把块设备交给容器，供数据库等自行管理文件系统。

CSI 驱动与存储接入

主流存储通过 CSI 驱动接入：集群侧部署驱动组件（控制器 + 节点 DaemonSet），StorageClass 中写驱动名；旧 in-tree 云盘插件逐步迁移到 CSI。

卷的只读挂载

volumeMounts.readOnly 让容器无法写挂载点：防误写配置文件、防污染共享数据；ConfigMap/Secret 卷本身只读。

把拉取凭据挂到 ServiceAccount

ServiceAccount 的 imagePullSecrets 会被该账号下所有 Pod 自动继承，比逐个工作负载配置更省事、更一致。

docker-registry 类型 Secret 结构

docker-registry Secret 的内容与 ~/.docker/config.json 同构：auths 下按仓库地址存 base64 的「用户:密码」，排障时可解码核对。

多个 Pod 共享同一 PVC 的边界

能否共享取决于访问模式与调度位置：RWO 需同节点、RWX 可跨节点；并发写的一致性靠应用或文件锁，K8s 不做保证。

配置内容的体积上限与替代方案

单个 ConfigMap/Secret 约 1MiB；env 注入还会把整体带入进程环境。大配置、二进制、多环境差异文件应换承载方式。

ConfigMap 不可变（immutable）

设置 immutable: true 后禁止任何修改：可减少 kubelet 监听开销并防误改；代价是变更必须删除重建。

PVC 用 selector 绑定指定 PV

PVC 可通过 matchLabels/matchExpressions 只与带相应标签的 PV 绑定，用于复用预置盘或隔离不同类型的存储。

envFrom 键名规则与无效键处理

envFrom 注入时键名必须是合法的环境变量名（C 标识符风格）；不合法键会被跳过，并产生事件提示而不是报错。

可选引用 optional 与缺失行为

默认引用不存在的 ConfigMap/键会让容器无法启动（ConfigMapKeyRef 报错）；给引用加 optional: true 可容忍缺失。

ConfigMap 二进制数据 binaryData

binaryData 存放 base64 编码的非文本内容（小图标、证书片段等）；与 data 并存，键名不能重复。

调度与资源

资源配额、亲和性、探针与弹性伸缩

requests 与 limits 的分工

requests 供调度装箱并参与 QoS 判定；limits 落到 cgroup 成为硬约束：CPU 超限被节流、内存超限被杀。

OOMKilled：容器内存超限被杀

退出码 137 且 lastState 显示 OOMKilled，表示容器内存超过 limit 被内核杀掉；须先区分容器级超限与节点级内存枯竭。

livenessProbe 存活探针

检测进程是否卡死：失败达阈值后 kubelet 重启容器；只应检测自身健康，把可恢复的慢判定为死会引发重启风暴。

readinessProbe 就绪探针

决定 Pod 是否进入 Service 后端列表：失败时摘流但不重启，恢复后自动回列；是滚动更新不掉线的关键。

CPU 单位：核与毫核 m

CPU 以核为单位、以 m（千分之一核）为精度：500m = 0.5 核，100m 是常见的小请求粒度；调度按 requests.cpu 精确加和。

内存单位：Mi/Gi 与十进制写法

内存支持十进制（M/G）与二进制（Mi/Gi）单位，Mi 是常用写法；内存不可压缩，超出 limit 直接被内核杀掉。

HPA 水平自动扩缩容

基于指标自动调整工作负载副本数：扩缩有计算周期与稳定窗口，不是实时跟随；min/max 与目标利用率的账要先算清。

污点与容忍

污点是节点侧「拒绝调度」的声明（key=value:Effect），容忍是 Pod 的豁免；与亲和性方向相反，互为补充。

QoS 级别与驱逐顺序

Guaranteed / Burstable / BestEffort 由 requests 与 limits 的关系推导；节点资源压力下按 BestEffort → Burstable → Guaranteed 顺序驱逐。

nodeAffinity 与 required/preferred

比 nodeSelector 更细：required 是硬约束（不满足不调度），preferred 是加权软偏好；支持 In/NotIn/Gt/Lt 等操作符。

podAntiAffinity 打散部署

让同标签的 Pod 互不同域：多副本跨节点、跨可用区打散的标准手段；硬反亲和遇到节点不足会造成 Pending。

调度只看 requests

调度器用 requests 做过滤与打分，limits 不参与装箱；requests 虚低会让节点「看起来」空闲，超卖与争抢多源于此。

CPU 节流：没有退出码的降速

CPU 超过 limit 不会杀容器，而是按 CFS 周期节流：表现为延迟毛刺、QPS 上不去；高负载下的「慢」先查节流。

ResourceQuota 限制命名空间总量

对命名空间内所有 Pod 的 requests/limits 求和设上限，并可按对象数量设限；触顶后新 Pod/对象会被拒绝创建。

PodDisruptionBudget 保障自愿中断

声明「自愿中断时的可用底线」：节点排水、滚动维护会尊重 PDB；但抢占、节点故障这类非自愿中断不受其保护。

nodeSelector 简单节点选择

用节点标签精确挑选目标节点：写法直白，多个键之间是 AND；运行后不会因标签变化而迁移。

topologySpreadConstraints 均匀分布

按拓扑域控制副本分布（maxSkew、whenUnsatisfiable、minDomains）：比反亲和更可控地表达「尽量均匀」。

HPA 依赖 metrics-server

资源指标型 HPA 从 metrics-server 取数：它未安装或异常时，kubectl top 与 HPA 会同时失效；先查 APIService 与组件状态。

调度器工作流程（过滤 + 打分）

两个阶段：Filter 筛选可行节点（资源、亲和、污点、卷拓扑），Score 给候选节点打分，得分高者中标并绑定。

探针方式：httpGet/exec/tcpSocket/gRPC

四种探测执行方式各有取舍：HTTP 语义清晰、exec 灵活但有开销、TCP 只验证端口、gRPC 面向 gRPC 服务。

LimitRange 给命名空间设默认资源

在命名空间里定义 LimitRange：为未写 resources 的容器补默认 requests/limits，并约束单容器上下限，避免 BestEffort 容器遍地。

HPA 不扩容的排查顺序

按「指标 → 当前副本 → 上限 → 目标值」逐层核对：指标 Unknown、已达 maxReplicas、就绪副本不足，都表现为「不动」。

requests 小于 limits 的超卖空间

limits 大于 requests 时节点会超卖：日常按 requests 装箱，突发时借用空闲资源；但借用不可靠，争抢时一起变慢。

HPA 扩缩行为调优（behavior）

扩容求快、缩容求稳：behavior 分别控制 scaleUp/scaleDown 的策略与稳定窗口，避免指标毛刺引发副本抖动。

podAffinity 就近部署

让新 Pod 与指定标签的 Pod 落在同一拓扑域（同节点或同可用区）：缓存聚合、减少跨节点流量的常用手段。

startupProbe 启动探针

为慢启动应用争取时间：启动探针通过前，liveness 与 readiness 都不执行；通过后移交常规探针。

三种 effect 的区别

NoSchedule 影响新调度，PreferNoSchedule 是软偏好，NoExecute 还会驱逐不容忍的存量 Pod；变更强度依次加大。

调度约束手段选型对照

nodeSelector、nodeAffinity、podAffinity、taints、topologySpread 的语义与粒度不同：按「谁挑谁」和硬软程度选择组合。

探针的常见坑位清单

探针属配置错误重灾区：依赖写进 liveness、端口路径笔误、周期过密、终止期与 preStop 互相干扰。

内存限制与运行时参数配合

运行时按容器 limit 做自适应：JVM 读 cgroup 设定堆上限（MaxRAMPercentage 可微调），Go 1.19+ 提供 GOMEMLIMIT 软限，避免堆外尖峰撞上 OOMKilled。

HPA 期望副本数的计算逻辑

公式：期望副本 = ceil(当前副本 × 当前指标 / 目标指标)；理解后能解释「为什么扩到这个数」，而不是线性加一。

PriorityClass 与 Pod 优先级

用 PriorityClass 声明优先级数值（越大越优先）：调度队列先高后低，资源紧张时高优先级可抢占低优先级 Pod。

探针参数速查

各参数决定探针节奏与灵敏度：最坏发现时间约等于 failureThreshold ×（periodSeconds + timeoutSeconds）。

按对象数量设配额

除计算资源外还可限制对象个数（pods、jobs.batch、services.nodeports、persistentvolumeclaims 等），防止单个命名空间刷爆集群资源。

ResourceQuota 与 LimitRange 分工

一个管命名空间「总量」，一个管「单个对象与默认值」：配额控制整体上限，LimitRange 补默认并约束单容器，组合使用才完整。

自定义指标与外部指标 HPA

除 CPU/内存外，HPA 可通过 custom.metrics.k8s.io / external.metrics.k8s.io 使用 QPS、队列深度等指标，需要部署指标适配器。

PDB 与驱逐 API 的配合

kubectl drain 走 Eviction API：受 PDB 限制时按 allowed disruptions 逐个放行；长时间阻塞会体现在事件与等待提示里。

用数据校准 requests/limits

上线前压测、上线后按监控回归：requests 参考稳态 P95 用量，limits 按峰值与运行时特性放大，避免长期拍脑袋。

扩展资源与 GPU 调度

CPU/内存之外的设备资源（nvidia.com/gpu 等）由 Device Plugin 上报；申请时 requests 与 limits 必须相等且为整数。

常用 topologyKey 与节点标签

拓扑域由节点标签决定：hostname 是节点级、zone/region 是机房级；调度与存储卷拓扑都依赖这些标准标签。

配额作用域 scopes

scopes 让配额只覆盖某类 Pod：Terminating/NotTerminating 区分是否设了 activeDeadlineSeconds，BestEffort/NotBestEffort 按 QoS 区分，用于分级管控。

可分配资源与系统预留

调度容量以 Allocatable 为准而不是 Capacity：kubelet 预留（kube-reserved/system-reserved）与驱逐阈值会从节点总量中扣减。

VPA：垂直调整资源请求

VerticalPodAutoscaler 依据历史用量给出 requests 建议并可自动写回；适合难估资源的稳定服务，与 HPA 的 CPU 指标同时使用会互相干扰。

节点自动扩缩容（Cluster Autoscaler 思路）

Pod 因资源不足 Pending 时增加节点、节点长期低压时缩容；与 HPA 分工不同：HPA 调副本数，CA 调节点数。

偏好策略的权重与打分

preferred 条目带 weight（1-100）参与节点打分：多个偏好累加，只有硬约束不满足才会让 Pod 卡住。

抢占：高优先级挤走低优先级

高优先级 Pod 调度失败时，调度器尝试驱逐节点上低优先级的 Pod 腾位；被抢占方收到 Preempted 事件，反复发生即出现饥饿。

tolerationSeconds 与驱逐宽限

容忍可携带 tolerationSeconds：节点打上 NoExecute 污点后，Pod 会保留指定秒数再被驱逐，为优雅下线留时间。

HPA 与 VPA 分工组合

常见组合：HPA 按业务指标扩副本，VPA 用 Off 模式只提供 requests 参考（不自动改）；两者都自动时会打架。

KEDA 事件驱动伸缩

KEDA 在 HPA 之上提供事件源驱动伸缩（队列长度、Kafka lag 等），并支持缩到 0 副本；需要部署 KEDA 控制器与对应伸缩对象。

直接指定 spec.nodeName

跳过调度器把 Pod 直接绑到节点：适合调试与特殊场景；没有资源检查与抢占保护，写错节点名会一直 Pending。

SchedulingGates 暂停调度

schedulingGates 让 Pod 创建后停在 SchedulingGated 状态，由外部控制器移除门后才进入调度：适合先备好资源再放行。

RuntimeClass 选择容器运行时

RuntimeClass 把运行时抽象成名字（runc、gVisor、Kata 等）：Pod 用 runtimeClassName 指定，兼顾隔离强度与性能取舍。

集群运维与排障

节点管理、事件分析与常见异常处置

‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌