Pod 是 K8s 里最小的部署和调度单元，不是容器，更像是一个“容器小组”，里面可以装一个或多个容器。这些容器共享 Pod 的网络、存储资源，相当于在同一个“小空间”里工作，能直接通过 localhost 通信。和容器的区别很明显：容器是独立的运行实例，而 Pod 是容器的“载体”，K8s 不会直接调度容器，只会调度 Pod。比如一个应用需要主容器 + 日志收集容器，这两个容器就会放在同一个 Pod 里，统一管理、统一调度，生命周期也保持一致，容器挂了 Pod 可能会重启，而 Pod 被删除，里面的容器也会跟着消失。
K8s 的 Service 主要有 4 种类型，用途各不相同，都是为了解决 Pod 漂移（IP 变化）导致的访问问题。第一种 ClusterIP，默认类型，只在集群内部可用，给 Pod 分配一个集群内唯一的虚拟 IP，供集群内其他服务访问，外部访问不到。第二种 NodePort，在每个节点上开放一个固定端口，外部通过“节点 IP+ 端口”就能访问 Pod，适合测试环境。第三种 LoadBalancer，对接云厂商的负载均衡器，自动分配公网 IP，外部直接通过公网 IP 访问，适合生产环境对外服务。第四种 ExternalName，把 Service 映射到外部域名，比如把数据库 Service 映射到云数据库的域名，不用在 Pod 里写死外部地址，灵活方便。
K8s 自动扩缩容主要靠两种控制器：HPA（水平扩缩容）和 VPA（垂直扩缩容），日常用得最多的是 HPA。HPA 是通过监控 Pod 的 CPU、内存使用率，或者自定义指标（比如 QPS、并发数），当指标达到设定阈值（比如 CPU 使用率超过 80%），就自动增加 Pod 副本数；指标低于阈值，就自动减少副本数，实现“按需扩容、闲时缩容”。VPA 则是调整单个 Pod 的资源配置，比如把 Pod 的 CPU 从 1 核调到 2 核，不用增加副本数，适合单 Pod 性能瓶颈的场景。另外，还可以结合 Cluster Autoscaler，当集群节点资源不够时，自动增加节点；节点空闲时，自动删除节点，实现集群层面的自动扩缩容。
Ingress 相当于 K8s 集群的“入口网关”，用来管理外部访问集群内服务的规则，解决 NodePort 端口多、LoadBalancer 成本高的问题。它本身不是服务，需要配合 Ingress Controller（比如 Nginx-Ingress）才能工作。工作原理很简单：外部请求先访问 Ingress Controller（绑定公网 IP），Ingress 里配置了域名、路径和 Service 的映射规则（比如 xxx.com/api 映射到 api-service），Ingress Controller 根据这些规则，把请求转发到对应的 Service，再由 Service 转发到 Pod。它还支持 HTTPS、路径重写、负载均衡、域名转发，相当于一个“智能路由器”，统一管理集群的外部访问入口。
两者都是用来存储 Pod 的配置信息，核心区别是存储的内容和安全性不同。ConfigMap 用来存非敏感的配置，比如应用的配置文件、环境变量、命令行参数，比如数据库地址、端口号、日志级别，数据是明文存储的，任何人能查看。Secret 用来存敏感数据，比如密码、密钥、Token，数据会经过 Base64 编码（不是加密，只是编码，能解密），默认权限更严格，防止敏感信息泄露。另外，ConfigMap 可以直接挂载为文件或环境变量，Secret 除了这两种方式，还能挂载为密钥文件，或者通过环境变量注入，适合需要保密的配置场景，两者都能实现配置与 Pod 解耦，不用把配置写死在镜像里。
Namespace 就是 K8s 里的“资源隔离文件夹”，用来把集群内的资源（Pod、Service、ConfigMap 等）分成不同的逻辑组，互不干扰。默认有 3 个命名空间：default（默认存放未指定命名空间的资源）、kube-system（K8s 系统组件所在的命名空间）、kube-public（公共资源，所有人可见）。它的核心用途有两个：一是隔离资源，比如开发、测试、生产环境用不同的 Namespace，避免资源命名冲突、误操作（比如删错 Pod）；二是管理资源权限，给不同的 Namespace 分配不同的用户权限，比如开发人员只能操作 dev 命名空间，不能碰 prod 命名空间，提升集群安全性和可管理性，适合多团队、多环境共用一个 K8s 集群的场景。
DaemonSet 是 K8s 的一种控制器，作用是让集群中的每一个（或指定）节点，都运行一个相同的 Pod 副本，而且节点新增时，会自动在新节点上部署这个 Pod；节点删除时，对应的 Pod 也会被删除，保证“节点有则 Pod 有，节点无则 Pod 无”。常见应用场景很明确：一是节点级别的日志收集，比如在每个节点上部署 Fluentd、Filebeat，收集节点和容器的日志；二是节点监控，比如部署 Prometheus Node Exporter，采集每个节点的 CPU、内存、磁盘等指标；三是网络插件，比如 Calico、Flannel，需要在每个节点上运行，保证节点间的网络通信，这些都是需要在所有节点上统一部署的服务，适合用 DaemonSet 管理。
StatefulSet 是用来部署有状态应用的控制器，比如数据库（MySQL、PostgreSQL）、分布式集群（ZooKeeper、Elasticsearch），这类应用需要固定的名称、网络标识、持久化存储，不能随意漂移。它和 Deployment 的核心区别的是：Deployment 部署无状态应用，Pod 名称是随机的，IP 会变，删除重建后身份丢失；StatefulSet 的 Pod 有固定的名称（比如 xxx-0、xxx-1）、固定的网络标识，持久化存储和 Pod 一一对应，删除重建后，还是原来的身份，数据不会丢失。另外，StatefulSet 的更新、扩缩容是有序的（比如先更 xxx-0，再更 xxx-1），Deployment 是无序更新，适合无状态应用（比如 Web 服务、API 服务）。
Service Mesh（服务网格）就是 K8s 集群中“管理服务间通信的专用网络层”，核心是“解耦服务通信和业务逻辑”，不用在应用代码里写任何通信相关的代码（比如重试、限流、监控）。它的结构分数据面和控制面：数据面是 Sidecar 容器（比如 Envoy），和每个 Pod 绑定，所有服务间的请求都经过 Sidecar 转发；控制面（比如 Istio）统一管理所有 Sidecar，配置通信规则。主要作用有：流量管理（路由、负载均衡、灰度发布）、可观测性（监控服务调用、日志、链路追踪）、安全性（服务间 TLS 加密、访问控制），简单说，就是“专门管服务之间怎么通信”，让开发人员专注业务，运维人员专注通信管理。
PV 和 PVC 是 K8s 中用来实现 Pod 数据持久化的两个核心资源，两者是“供需关系”，类比成“仓库和仓库申请单”。PV 是集群管理员提前创建的“持久化存储资源”，比如一块云磁盘、NFS 存储，定义了存储的大小、类型、访问模式，是“供”。PVC 是 Pod 对存储的“申请单”，由开发人员创建，指定需要的存储大小、类型，是“需”。当 PVC 的需求和 PV 的配置匹配时，K8s 会自动将 PV 和 PVC 绑定，Pod 通过 PVC 就能使用 PV 的存储资源。这样做的好处是，开发人员不用关心底层存储的具体实现（是云盘还是 NFS），管理员统一管理存储资源，实现存储和 Pod 解耦，数据不会因为 Pod 删除而丢失。
Affinity（亲和性）和 Anti-Affinity（反亲和性），是用来控制 Pod 调度位置的规则，简单说就是“让 Pod 跑到指定的节点上，或者不跑到指定的节点上”。Affinity 分节点亲和性（Node Affinity）和 Pod 亲和性（Pod Affinity）：节点亲和性是让 Pod 调度到符合条件的节点（比如带“ssd=true”标签的节点）；Pod 亲和性是让两个相关的 Pod 调度到同一个节点或同一个节点组（比如 Web 服务和缓存服务，放一起访问更快）。Anti-Affinity 则相反，让 Pod 不调度到符合条件的节点，或不与某个 Pod 在同一节点（比如数据库 Pod，避免所有副本都在一个节点，防止节点挂了服务中断）。应用场景主要是优化性能、提高可用性、避免资源争抢。
两者都是 K8s 的自动扩缩容工具，核心区别是“扩缩容的方式不同”。HPA 是水平扩缩容，也就是增加或减少 Pod 的副本数，比如 CPU 使用率超标，就多启动几个 Pod 分担压力；使用率低，就关掉几个 Pod 节省资源，不改变单个 Pod 的资源配置（CPU、内存），适合无状态应用（比如 Web 服务），能应对突发流量，也是日常最常用的扩缩容方式。VPA 是纵向扩缩容，也就是调整单个 Pod 的资源配置，比如把 Pod 的 CPU 从 1 核调到 2 核、内存从 1G 调到 2G，不增加副本数，适合有状态应用（比如数据库），或者单 Pod 性能瓶颈、无法横向扩容的场景。两者可以配合使用，实现更灵活的资源管理。
Taints（污点）和 Tolerations（容忍度），是用来控制 Pod 能否调度到某个节点的“黑名单机制”。Taints 是给节点打上的“污点标签”，比如给节点打上“node-role=master”的污点，默认禁止 Pod 调度到这个节点（防止普通 Pod 占用主节点资源）；Tolerations 是给 Pod 配置的“容忍规则”，如果 Pod 有对应污点的容忍度，就能调度到带有该污点的节点上。工作原理很简单：节点有污点，就会“排斥”所有没有对应容忍度的 Pod；只有 Pod 配置了匹配的容忍度，才能“绕过”污点，被调度到该节点。主要用途是隔离节点，比如主节点、GPU 节点，只让特定的 Pod（比如系统组件、需要 GPU 的 Pod）调度上去。
Jobs 和 CronJobs 都是用来运行“一次性或周期性任务”的控制器，区别是任务的执行方式不同。Jobs 用来运行一次性任务，比如数据备份、数据迁移、批量处理，任务执行完成后，Pod 就会变成 Completed 状态，不会再重启，就算 Pod 挂了，Jobs 也会自动重启 Pod，直到任务完成。CronJobs 是在 Jobs 的基础上，增加了“周期性调度”功能，按照 Cron 表达式（比如每天凌晨 3 点、每小时一次）定期执行任务，比如每天凌晨备份数据库、每小时清理日志。两者都适合运行非长期运行的任务，不用手动启动，自动执行、自动管理，避免人工操作失误，适合自动化运维场景。
K8s 的网络策略（Network Policy），就是用来控制 Pod 之间、Pod 与外部之间通信的“防火墙规则”，默认情况下，集群内所有 Pod 都能互相通信，网络策略可以限制这种通信，提升安全性。它通过标签选择器，指定哪些 Pod 可以被访问、哪些 Pod 可以访问别人，还能限制通信的端口和协议。工作原理：网络策略会被网络插件（比如 Calico、Weave）执行，当 Pod 之间有通信请求时，网络插件会检查是否符合网络策略的规则，如果符合就允许通信，不符合就拒绝。比如可以配置“只有 Web 服务 Pod 能访问数据库 Pod，其他 Pod 不能访问”，或者“禁止 Pod 访问外部网络”，主要用于微服务间的访问控制，防止非法访问和横向渗透。
Resource Quotas（资源配额），是用来给命名空间设置“资源使用上限”的机制，防止某个命名空间的资源被耗尽，影响其他命名空间的服务。管理员可以给每个命名空间配置 Resource Quotas，限制该命名空间内所有 Pod 的总 CPU、总内存、总 Pod 数量、总 PV 数量等。比如给 dev 命名空间设置 CPU 上限为 10 核、内存上限为 20G，那么该命名空间内所有 Pod 的 CPU 总和不能超过 10 核，内存总和不能超过 20G，超过后就无法创建新的 Pod。它的核心作用是合理分配集群资源，避免资源滥用，适合多团队、多环境共用一个 K8s 集群的场景，保证每个命名空间都能获得足够的资源，同时不影响全局。
Labels（标签）和 Annotations（注解）都是用来给 K8s 资源（Pod、Service、Node 等）添加元数据的，但用途和特性完全不同。Labels 是“用于选择和筛选资源”的键值对，比如给 Pod 打“app=web、env=dev”的标签，然后通过标签选择器，筛选出所有 env=dev 的 Pod，用于 Service 关联 Pod、Deployment 管理 Pod、网络策略控制通信，是 K8s 中资源关联和筛选的核心。Annotations 是“用于存储资源的附加信息”的键值对，比如资源的创建时间、维护人员、版本信息、文档链接，这些信息不会被 K8s 用于资源选择和调度，只是给用户或运维人员查看、使用，不会影响资源的运行，相当于资源的“备注信息”。
Init Containers（初始化容器），是在 Pod 的主容器启动之前执行的容器，执行完成后就会退出，不会长期运行，主容器只有在所有 Init Containers 都执行成功后，才会启动。它的核心用途是给主容器做初始化准备工作，比如：等待其他服务（比如数据库）启动完成，避免主容器启动后连接不上数据库；拉取主容器需要的配置文件、依赖包；初始化数据库、创建目录、修改权限等。比如一个 Web 服务 Pod，需要先等待数据库 Pod 启动，再拉取配置文件，这些操作就可以放在 Init Containers 里执行，不用在主容器里写复杂的初始化逻辑，实现初始化和业务逻辑解耦，保证主容器启动时，所有依赖都已准备就绪。
Headless Service（无头服务），是一种特殊的 Service，和普通 Service 的核心区别是“没有 ClusterIP（虚拟 IP）”，也不会做负载均衡。普通 Service 会分配一个 ClusterIP，请求访问 Service 时，会自动转发到后端的 Pod，实现负载均衡；而 Headless Service 不会分配 ClusterIP，访问它的域名时，会直接返回后端所有 Pod 的 IP 地址，不会做转发和负载均衡，客户端需要自己决定访问哪个 Pod。它的主要用途是部署有状态应用（比如 ZooKeeper、MySQL 集群），这些应用需要知道集群中其他 Pod 的 IP 地址，通过 Headless Service 的 DNS 解析，就能获取所有 Pod 的 IP，实现集群内的节点发现和通信。
livenessProbe（存活探针）和 readinessProbe（就绪探针），都是用来监控 Pod 状态的工具，核心区别是“监控的目的不同”。livenessProbe 用来判断 Pod 是否“活着”（正常运行），比如检查主容器的进程是否存在、接口是否能访问，如果探测失败，K8s 会认为 Pod 异常，会自动重启该 Pod，避免 Pod“假死”（容器在运行，但应用已经崩溃）。readinessProbe 用来判断 Pod 是否“准备好”（可以接收请求），比如检查应用是否初始化完成、数据库连接是否正常，如果探测失败，K8s 会把该 Pod 从 Service 的后端列表中移除，不再转发请求给它，直到探测成功，避免把请求发给未准备好的 Pod，导致请求失败。
两者都是 Affinity（亲和性）规则，核心区别是“调度的依据不同”，一个是针对节点，一个是针对 Pod。Node Affinity（节点亲和性），是根据节点的标签来调度 Pod，比如让 Pod 调度到带有“disk=ssd”“region=beijing”标签的节点上，只关注节点本身的属性，和其他 Pod 无关。Pod Affinity/Anti-Affinity（Pod 亲和性 / 反亲和性），是根据其他 Pod 的标签来调度当前 Pod，比如让 Web 服务 Pod 和缓存 Pod 调度到同一个节点（亲和性），让数据库的不同副本 Pod 调度到不同节点（反亲和性），关注的是 Pod 之间的关系。简单说，Node Affinity 管“Pod 去哪个节点”，Pod Affinity 管“Pod 和哪个 Pod 在一块”。
Deployment 的滚动更新，是一种“不中断服务”的更新方式，核心是“逐步替换旧 Pod、启动新 Pod”，避免更新过程中服务不可用。它的工作原理：先启动 1 个（或多个，可配置）新 Pod，等待新 Pod 就绪后，再终止 1 个旧 Pod，重复这个过程，直到所有旧 Pod 都被替换成新 Pod。滚动更新可以配置两个关键参数：maxSurge（最多可以超出期望副本数的 Pod 数量，比如期望 3 个，maxSurge=1，最多可以有 4 个 Pod 运行）、maxUnavailable（最多不可用的 Pod 数量，比如 maxUnavailable=1，最多有 1 个 Pod 不可用）。这种方式不会中断服务，更新失败还能快速回滚到旧版本，适合无状态应用的日常更新，是生产环境最常用的更新策略。
两者的使用方式有相似之处（都能挂载为文件或注入环境变量），但核心区别在于“安全配置和使用限制”。ConfigMap 的使用方式比较简单：可以直接挂载为 Pod 内的配置文件（比如把 ConfigMap 里的 app.conf 挂载到 Pod 的 /etc/app 目录），也可以通过环境变量注入到 Pod 中，供应用读取，没有太多安全限制，明文展示，任何人都能查看。Secret 的使用方式更注重安全：除了挂载为文件、注入环境变量，还能挂载为密钥文件（权限为 600，只有 root 能读写），避免敏感信息泄露；另外，Secret 可以通过 Secrets Store CSI Driver 对接外部密钥管理系统（比如 Vault），实现敏感数据的安全存储和自动同步，而 ConfigMap 不支持这种方式，主要用于非敏感配置。
两者都是 K8s 中的存储资源，核心区别是“生命周期和管理方式不同”。Volume（普通卷）是和 Pod 绑定的，生命周期和 Pod 一致，Pod 创建时 Volume 创建，Pod 删除时 Volume 也会被删除，数据会丢失（除非是宿主目录挂载），是“临时存储”，由开发人员在 Pod 定义中直接配置，比如 emptyDir、hostPath。PersistentVolume（PV）是集群级别的持久化存储，生命周期和 Pod 无关，由管理员提前创建，独立于 Pod 存在，Pod 删除后，PV 依然存在，数据不会丢失，是“永久存储”。另外，PV 需要通过 PVC 申请才能使用，而普通 Volume 直接在 Pod 中配置即可，适合不同的存储场景：临时数据用 Volume，持久化数据用 PV+PVC。
K8s 的服务发现，核心是“让 Pod 能通过服务名，自动找到对应的 Service 和后端 Pod，不用记 IP 地址”，主要靠两个机制实现：DNS 和环境变量。第一种是 DNS（最常用），K8s 集群内置了 DNS 服务（比如 CoreDNS），当创建 Service 时，DNS 会自动给 Service 创建一条域名记录（格式：service-name.namespace.svc.cluster.local），Pod 通过这个域名就能访问 Service，DNS 会自动解析 Service 的 ClusterIP，再由 Service 转发到后端 Pod。第二种是环境变量，当 Pod 启动时，K8s 会自动把集群内已存在的 Service 的 IP、端口，以环境变量的形式注入到 Pod 中，Pod 通过读取环境变量就能访问 Service。另外，Headless Service 通过 DNS 返回所有 Pod 的 IP，实现 Pod 级别的服务发现。
Resource Limits（资源限制）和 Requests（资源请求），是用来给 Pod 配置 CPU、内存资源的两个参数，核心作用是“保证 Pod 能获得足够资源，同时不滥用资源”。Requests 是 Pod 启动时，向 K8s 请求的最小资源量，比如 requests.cpu=1 核、requests.memory=1G，K8s 会调度 Pod 到资源充足（至少有 1 核 CPU、1G 内存）的节点上，保证 Pod 能正常启动。Limits 是 Pod 运行时，能使用的最大资源量，比如 limits.cpu=2 核、limits.memory=2G，Pod 的 CPU 使用率不能超过 2 核，内存不能超过 2G，超过后 CPU 会被限流，内存会被 OOM 杀死。简单说，Requests 是“最低保障”，Limits 是“最高上限”，两者配合使用，合理分配集群资源，避免资源争抢和浪费。
两者的更新策略核心区别是“更新顺序和数据安全性”，因为 StatefulSet 部署有状态应用，Deployment 部署无状态应用。Deployment 的更新是“无序更新”，可以同时启动多个新 Pod、终止多个旧 Pod，只要满足 maxSurge 和 maxUnavailable 的限制，更新速度快，适合无状态应用，不用考虑 Pod 的顺序。StatefulSet 的更新是“有序更新”，默认从序号最大的 Pod 开始（比如 xxx-2→xxx-1→xxx-0），只有当前 Pod 更新完成且就绪后，才会更新下一个 Pod，更新过程中，旧 Pod 不会被立即删除，直到新 Pod 就绪，保证数据不丢失。另外，StatefulSet 支持分区更新（只更新部分 Pod），Deployment 不支持，更适合有状态应用的平稳更新。
K8s 跨集群通信，核心是“让不同 K8s 集群的 Pod、Service 能互相访问”，常用的有 3 种方式，各有适用场景。第一种是联邦集群（Kubernetes Federation），把多个集群组成一个联邦，统一管理 Service、ConfigMap 等资源，联邦 Service 会在每个集群创建对应的 Service，实现跨集群访问，适合多集群统一管理的场景。第二种是 VPN/ 专线，给两个集群的节点之间建立 VPN 或专线，打通集群网络，让两个集群的 Pod 处于同一个虚拟网络，直接通过 IP 访问，适合中小规模集群。第三种是 Service Mesh（比如 Istio），通过 Istio 的多集群模式，统一管理跨集群的服务通信，支持流量路由、负载均衡、TLS 加密，适合大规模微服务跨集群部署的场景。另外，还可以通过 Ingress 暴露服务，让其他集群通过公网访问，适合简单的跨集群访问需求。
K8s 管理敏感数据，核心是“避免明文存储，做好权限控制”，主要有 4 种方式，优先用更安全的方案。第一种是 Secret，最基础的方式，把敏感数据 Base64 编码后存储，挂载为文件或注入环境变量，注意 Base64 不是加密，需要配合权限控制（比如限制 Secret 的访问权限）。第二种是 Secrets Store CSI Driver，对接外部密钥管理系统（比如 Vault、阿里云 KMS），敏感数据存储在外部系统，Pod 通过 CSI 驱动动态挂载，不用把敏感数据存到 K8s 中，最安全。第三种是 ServiceAccount Token，用于 Pod 访问 K8s API，通过 Service Mesh 或 RBAC 控制权限，避免手动管理密钥。第四种是加密静态数据，开启 K8s 的静态加密功能，把 etcd 中存储的敏感数据（比如 Secret）加密，防止 etcd 被攻破后数据泄露。
ServiceAccount（服务账户），是 K8s 中给 Pod 提供“身份标识”的资源，用来控制 Pod 访问 K8s API 的权限，和我们平时用的用户账户（比如 kubectl 用的账户）不一样，是给 Pod 用的。每个命名空间默认有一个 default ServiceAccount，Pod 如果不指定 ServiceAccount，就会使用这个默认账户。它的核心用途：一是身份认证，Pod 通过 ServiceAccount 的 Token，向 K8s API 服务器证明自己的身份；二是权限控制，通过 RBAC（角色权限控制），给 ServiceAccount 分配不同的权限（比如只能查看 Pod，不能删除 Pod），Pod 就拥有了对应的权限，比如让 Pod 能调用 K8s API，获取集群内的资源信息、创建 / 删除资源。简单说，ServiceAccount 就是 Pod 的“身份证”，用来控制 Pod 能做什么、不能做什么。
CRD（自定义资源定义），就是允许用户在 K8s 中“自定义新的资源类型”，扩展 K8s 的功能，因为 K8s 默认的资源（Pod、Service、Deployment）不能满足所有业务需求。比如你有一个自定义的应用（比如分布式任务调度系统），需要一种新的资源来管理，就可以通过 CRD 创建一个新的资源类型（比如 Task），之后就能像操作 Pod 一样，用 kubectl create、kubectl get 等命令操作 Task 资源。CRD 本身只是定义资源类型，还需要配合 Custom Controller（自定义控制器），才能实现对自定义资源的管理（比如调度、更新、自愈）。CRD 的核心作用是扩展 K8s 的能力，让 K8s 能适配各种自定义业务场景，比如 Service Mesh、AI 训练任务等。
PodPreset（Pod 预设），是用来“自动给 Pod 注入配置”的资源，不用在每个 Pod 的定义中重复写相同的配置，减少重复工作。它的工作原理：管理员创建 PodPreset，定义好需要注入的配置（比如环境变量、Volume、VolumeMount），并通过标签选择器，指定哪些 Pod 会被注入这些配置。当创建 Pod 时，如果 Pod 的标签和 PodPreset 的标签选择器匹配，K8s 会自动把 PodPreset 中的配置注入到 Pod 中，不用手动在 Pod 中配置。比如多个 Pod 都需要相同的环境变量（比如数据库地址），就可以创建一个 PodPreset，统一注入，后续创建 Pod 时，只要打对应标签，就能自动获得配置，适合多个 Pod 共用相同配置的场景，简化 Pod 配置。
Pod 的优先级，是用来决定“当集群资源不足时，哪个 Pod 会被优先保留，哪个 Pod 会被驱逐”的规则，核心是通过 PriorityClass（优先级类）来配置。首先，管理员创建 PriorityClass，给每个 PriorityClass 设置一个优先级数值（数值越大，优先级越高），比如创建“high-priority”（数值 1000）、“low-priority”（数值 100）。然后，在 Pod 的定义中，通过 priorityClassName 字段，指定该 Pod 使用的 PriorityClass，比如把核心服务的 Pod 设置为 high-priority，普通服务的 Pod 设置为 low-priority。当集群资源不足时，K8s 会优先驱逐优先级低的 Pod，释放资源给优先级高的 Pod，保证核心服务不中断，适合有核心服务和非核心服务的场景。
PDB（Pod 干扰预算），是用来“保护 Pod 不被过多中断”的资源，避免因为主动干扰（比如节点维护、Pod 更新），导致某个服务的可用 Pod 数量过少，影响服务可用性。它的核心作用是设置“最小可用 Pod 数量”或“最大不可用 Pod 数量”，比如给一个有 3 个副本的 Web 服务配置 PDB，设置 minAvailable=2，意味着无论发生什么主动干扰，该服务的可用 Pod 数量都不能少于 2 个，K8s 会保证在中断 Pod 时，至少保留 2 个可用 Pod。PDB 只针对主动干扰（手动删除 Pod、节点排水），不针对被动故障（Pod 崩溃、节点宕机），主要用于保护核心服务，确保服务在维护、更新时依然可用。
HPA（水平 Pod 自动扩缩容）的扩缩容依据，就是各种度量指标，主要分为 3 类，日常最常用前两类。第一类是资源指标（默认支持），包括 CPU 使用率和内存使用率，比如设置 CPU 使用率超过 80% 扩容、低于 20% 缩容，这是最基础、最易配置的指标，不需要额外部署组件。第二类是自定义指标，比如 QPS（每秒请求数）、并发数、请求延迟，这些指标需要通过 Metrics Server + 自定义指标适配器（比如 Prometheus Adapter）获取，适合业务层面的扩缩容（比如根据请求量扩容）。第三类是外部指标，比如云厂商的负载均衡器请求数、消息队列的队列长度，需要对接外部系统获取指标，适合和外部服务联动的场景。HPA 会定期采集这些指标，对比设定阈值，自动调整 Pod 副本数。
K8s 日志管理的核心思路是“容器日志集中收集、统一存储、按需查询”，常用的方案是“日志驱动 + 日志收集器 + 存储 + 查询”的组合。第一步，容器日志输出到 stdout 和 stderr（K8s 推荐方式），容器引擎（Docker、containerd）通过日志驱动，把日志写到节点的本地文件。第二步，在每个节点上部署日志收集器（比如 Fluentd、Filebeat），采集节点上的容器日志，过滤、格式化后，发送到日志存储系统。第三步，日志存储系统（比如 Elasticsearch、Loki）存储日志，支持长期存储和检索。第四步，通过查询工具（比如 Kibana、Grafana），查询、分析日志，设置告警。另外，还可以通过日志聚合工具（比如 EFK、ELK），实现日志的全流程管理，适合大规模集群的日志监控和问题排查。
两者都是用来控制集群资源使用的机制，核心区别是“控制的范围和粒度不同”。Quota（资源配额）是针对“整个命名空间”的，控制的是命名空间内所有 Pod 的总资源上限，比如限制 dev 命名空间的总 CPU 为 10 核、总内存为 20G，防止整个命名空间滥用资源，适合多命名空间的资源管理。LimitRange（限制范围）是针对“命名空间内的单个 Pod 或容器”的，控制的是单个 Pod/ 容器的资源范围，比如设置单个 Pod 的 CPU 请求量最小 0.5 核、最大 2 核，单个容器的内存最小 512M、最大 1G，防止单个 Pod 占用过多资源，或者请求资源过少导致无法正常运行。简单说，Quota 管“整体”，LimitRange 管“个体”，两者配合使用，实现更精细的资源控制。
两者都是用来“保证 Pod 副本数稳定”的控制器，核心作用是维持指定数量的 Pod 副本运行，Pod 挂了就自动重启，ReplicaSet 是 ReplicationController 的“升级版”，现在基本不用 ReplicationController 了。它们的主要区别是“标签选择器的支持不同”：ReplicationController 只支持等式标签选择器（比如 app=web），只能匹配标签完全等于指定值的 Pod；ReplicaSet 支持集合式标签选择器（比如 app in (web, api)），能匹配标签满足集合条件的 Pod，更灵活。另外，ReplicaSet 是 Deployment 的底层实现，Deployment 会自动创建和管理 ReplicaSet，不用手动创建 ReplicaSet，而 ReplicationController 需要手动创建，功能更单一，现在生产环境都用 Deployment+ReplicaSet，替代了 ReplicationController。
使用 Init Containers 初始化 Pod，步骤很简单，在 Pod 的定义中，通过 initContainers 字段配置即可，和配置主容器（containers 字段）类似，但有几个关键注意点。首先，Init Containers 是一个数组，可以配置多个初始化容器，它们会按顺序执行，前一个执行完成后，后一个才会启动，所有 Init Containers 执行成功后，主容器才会启动。其次，配置 Init Containers 的命令（command）或镜像（image），实现初始化逻辑，比如等待数据库启动（用 wget、curl 命令检查数据库端口）、拉取配置文件（用 wget 下载配置）、初始化数据库（执行 sql 脚本）。最后，注意 Init Containers 的资源配置（CPU、内存），可以单独配置，和主容器的资源配置不冲突。比如配置一个 Init Container，等待 MySQL 启动，再启动主容器（Web 服务），确保 Web 服务启动时能正常连接数据库。
两者都是用来运行“非长期运行任务”的控制器，核心区别是“任务的执行方式和周期不同”。Job 是“一次性任务”，创建后就会启动 Pod 执行任务，任务执行完成（Pod 变成 Completed 状态）后，就不会再运行，就算 Pod 挂了，Job 也会自动重启 Pod，直到任务完成，比如数据备份、批量处理。CronJob 是“周期性任务”，基于 Cron 表达式（比如 * * * * * 代表每分钟一次），定期启动 Job 执行任务，任务完成后，Job 会被保留（可配置保留数量），到下一个周期再重新启动新的 Job，比如每天凌晨 3 点备份数据库、每小时清理日志。简单说，Job 是“做一次就停”，CronJob 是“按时间重复做”，根据任务的周期需求选择即可。
Pod 的自动伸缩主要靠两种方式，结合使用能实现更灵活的伸缩，满足不同场景需求。第一种是 HPA（水平 Pod 自动扩缩容），这是最常用的方式，通过监控 Pod 的 CPU、内存使用率，或者自定义指标（QPS、并发数），自动增加或减少 Pod 的副本数，不改变单个 Pod 的资源配置，适合无状态应用（比如 Web 服务），应对突发流量。第二种是 VPA（纵向 Pod 自动扩缩容），通过监控 Pod 的资源使用情况，自动调整单个 Pod 的 CPU、内存配置（比如从 1 核 1G 调到 2 核 2G），不增加副本数，适合有状态应用（比如数据库），或者单 Pod 性能瓶颈的场景。另外，结合 Cluster Autoscaler，当集群节点资源不足时，自动增加节点；节点空闲时，自动删除节点，实现集群层面的自动伸缩，保证 Pod 能正常调度。
Service Mesh（服务网格）的核心功能是“管理服务间的通信”，不用修改应用代码，就能实现各种通信相关的能力，主要有 4 大核心功能。第一，流量管理，比如路由控制（根据请求路径、版本转发流量）、负载均衡（轮询、加权轮询）、灰度发布 / 蓝绿部署（逐步切换流量到新版本）、熔断降级（服务不可用时，避免雪崩）。第二，可观测性，比如监控服务调用的 QPS、延迟、错误率，收集服务调用日志，实现链路追踪（跟踪一个请求的完整路径），方便排查问题。第三，安全性，比如服务间通信 TLS 加密（防止数据窃听、篡改），访问控制（限制哪些服务能访问当前服务），身份认证（验证服务身份）。第四，可配置性，所有功能都通过控制面统一配置，不用重启应用，实时生效，简化运维管理。
Pod 的优先级和抢占机制，是用来“保证核心 Pod 优先获得资源”的机制，分为两个步骤：优先级配置和抢占执行。首先，管理员创建 PriorityClass（优先级类），设置优先级数值（数值越大，优先级越高），然后在 Pod 中指定 priorityClassName，给 Pod 分配优先级。当集群资源充足时，所有 Pod 都能正常调度，优先级不影响；当集群资源不足，无法调度新的高优先级 Pod 时，抢占机制就会触发：K8s 会寻找集群中优先级更低的 Pod，驱逐这些低优先级 Pod，释放资源，然后将高优先级 Pod 调度到对应的节点上。注意，抢占机制只会驱逐“可抢占”的低优先级 Pod，不会驱逐有 PDB 保护的 Pod，避免影响服务可用性，核心是优先保障核心服务的运行。
两者都是用来“控制 Pod 调度到指定节点”的方式，核心区别是“灵活性和功能丰富度不同”。Node Selector（节点选择器）是最简单的调度方式，通过键值对匹配节点标签，比如 Pod 配置 nodeSelector: {disk: ssd}，就只能调度到带有“disk=ssd”标签的节点上，只能做“等于”匹配，没有容错性，比如没有符合条件的节点，Pod 就会一直处于 Pending 状态。Node Affinity（节点亲和性）更灵活，支持“等于、不等于、包含、不包含”等多种匹配规则，还能设置“软亲和性”（preferredDuringSchedulingIgnoredDuringExecution）和“硬亲和性”（requiredDuringSchedulingIgnoredDuringExecution）：硬亲和性必须满足，否则 Pod 无法调度；软亲和性尽量满足，不满足也能调度到其他节点，容错性更强，功能更丰富，现在基本替代了 Node Selector。
配置 Pod 使用特定的网络策略，核心是“通过标签关联 Pod 和网络策略”，步骤很简单，分为两步。第一步，创建 NetworkPolicy（网络策略），在策略中通过 podSelector（Pod 选择器），指定该策略作用于哪些 Pod（比如给策略配置 podSelector: {app: web}，就作用于所有带“app=web”标签的 Pod），然后配置通信规则（比如允许哪些 Pod 访问、禁止哪些 Pod 访问、允许的端口和协议）。第二步，给需要应用该策略的 Pod，打上和网络策略 podSelector 匹配的标签（比如给 Web 服务 Pod 打“app=web”标签），这样网络策略就会自动作用于这些 Pod。注意，网络策略需要网络插件（比如 Calico、Weave）支持才能生效，没有网络插件，网络策略不会起作用，另外，一个 Pod 可以被多个网络策略作用，规则会叠加。
Rolling Update（滚动更新），是 K8s 中 Deployment 和 StatefulSet 的一种“不中断服务”的更新方式，核心是“逐步替换旧 Pod、启动新 Pod”，避免更新过程中服务不可用。它的执行过程（以 Deployment 为例）：1. 管理员触发更新（比如修改镜像版本）；2. Deployment 根据 maxSurge 参数（最多超出期望副本数的 Pod 数量），启动 1 个（或多个）新 Pod；3. 等待新 Pod 启动完成并就绪后，根据 maxUnavailable 参数（最多不可用的 Pod 数量），终止 1 个（或多个）旧 Pod；4. 重复步骤 2 和 3，直到所有旧 Pod 都被替换成新 Pod，更新完成。如果更新过程中出现问题，可以随时回滚到旧版本，保证服务稳定性，是生产环境最常用的更新方式，适合无状态应用和有状态应用。
使用 PV 和 PVC 实现 Pod 数据持久化，分为 3 个步骤，流程清晰，管理员和开发人员分工协作。第一步，管理员创建 PV（持久化存储资源），定义存储的大小、类型（比如 NFS、云盘）、访问模式（比如 ReadWriteOnce，只能被一个 Pod 挂载读写），PV 是集群级别的资源，独立于 Pod 存在。第二步，开发人员创建 PVC（存储申请单），指定需要的存储大小、类型，和 PV 的配置匹配，比如 PVC 申请 10G、ReadWriteOnce 的存储。第三步，K8s 自动将 PVC 和匹配的 PV 绑定，然后在 Pod 的定义中，通过 volumeMounts 和 volumes 字段，将 PVC 挂载到 Pod 中，Pod 就能使用 PV 的存储资源，数据会持久化存储，Pod 删除后，PV 和 PVC 依然存在，数据不会丢失。如果需要删除存储，先删除 Pod，再删除 PVC，最后删除 PV 即可。
Probes（探针）是 K8s 用来“监控 Pod 和容器状态”的工具，通过定期执行检查，判断容器是否正常运行、是否准备好接收请求，主要有 3 种类型，各自用途不同。第一种是 livenessProbe（存活探针），用来检查容器是否“活着”，比如检查容器内的进程是否存在、接口是否能正常访问，如果探测失败，K8s 会自动重启该容器，避免容器“假死”（容器在运行，但应用已崩溃）。第二种是 readinessProbe（就绪探针），用来检查容器是否“准备好”接收请求，比如检查应用是否初始化完成、数据库连接是否正常，如果探测失败，K8s 会把该 Pod 从 Service 的后端列表中移除，不再转发请求，直到探测成功。第三种是 startupProbe（启动探针），用来检查容器是否启动完成，适合启动时间长的应用（比如 Java 应用），启动探针成功后，才会执行存活探针和就绪探针，避免启动过程中被误判为异常。
