Kubernetes 基础面试题

Kubernetes 采用 Master-Worker 架构：

控制平面（Control Plane）：

• kube-apiserver：集群网关，所有组件交互的唯一入口，唯一直接读写 etcd 的组件。提供认证、授权、准入控制机制。
• etcd：分布式键值存储，基于 Raft 共识算法保证强一致性，存储集群全部元数据与状态信息。
• kube-scheduler：为新创建的 Pod 选择最合适的 Node，通过预选（Predicates）+ 优选（Priorities）两阶段决策。
• kube-controller-manager：运行一系列控制器（ReplicaSet、Deployment、Node、Endpoint 等），通过调和循环驱动集群状态向期望状态收敛。
• cloud-controller-manager：对接云厂商 API，管理云资源（LoadBalancer、Node 管理等）。

工作节点（Worker Node）：

• kubelet：节点代理，管理 Pod 生命周期（创建/销毁容器），执行健康检查（Liveness/Readiness/Startup Probe），上报节点状态。
• kube-proxy：网络代理，维护 Service 的负载均衡规则（iptables/ipvs/IPVS 模式），实现四层流量转发。
• 容器运行时（CRI）：Containerd、CRI-O 等，负责实际运行容器。

1. 用户通过 kubectl（或 API 调用）向 kube-apiserver 提交 Pod 创建请求。
2. kube-apiserver 进行认证、授权、准入控制验证，将 Pod 资源写入 etcd。
3. etcd 通知 kube-apiserver 产生 Create 事件。
4. kube-scheduler 通过 Watch 机制发现未调度（nodeName 为空）的 Pod，执行预选+优选算法，选定目标节点。
5. kube-scheduler 将 Pod 与 Node 的绑定关系回写至 etcd。
6. 目标节点的 kubelet 通过 Watch 发现分配给本节点的 Pod。
7. kubelet 调用 CNI 插件配置网络，调用 CRI 运行时拉取镜像并启动容器，调用 CSI 插件挂载存储卷。
8. kubelet 执行探针检查，确认容器运行正常。
9. kubelet 将 Pod 状态（Running）回写至 kube-apiserver → etcd。

Pod 是 Kubernetes 的最小部署单元，包含一个或多个共享网络命名空间、存储卷和资源约束的容器。

原因：

• 网络共享：同一 Pod 的容器共享 IP 和端口空间，通过 localhost 通信，无需额外服务发现。
• 存储共享：Pod 级别的 Volume 可被所有容器挂载。
• 原子调度：Pod 中的所有容器始终调度到同一节点，要么全部启动，要么全部终止。
• 生命周期耦合：适合 Sidecar 模式（如日志采集、代理转发等辅助容器与主容器共存）。

• ClusterIP（默认）：集群内虚拟 IP，仅集群内部可访问，自动负载均衡到后端 Pod。
• NodePort：在每个节点开放一个静态端口（30000–32767），外部通过 NodeIP:NodePort 访问。
• LoadBalancer：调用云厂商创建外部负载均衡器，自动将流量导入 Service。
• ExternalName：将 Service 映射到外部 DNS 名称，不创建代理规则，返回 CNAME 记录。
• Headless Service：clusterIP: None，不分配虚拟 IP，直接返回后端 Pod IP 列表，适用于 StatefulSet 的有状态发现。

Service 工作在四层（TCP/UDP），提供 Pod 的负载均衡与抽象访问入口。 Ingress 工作在七层（HTTP/HTTPS），提供基于域名和路径的路由规则、TLS 终止、虚拟主机等能力，需要 Ingress Controller 来实现。

两者是互补关系：Ingress 将外部流量路由到 Service，Service 再将流量负载均衡到后端 Pod。

• ConfigMap：存储非敏感配置信息（配置文件、环境变量、命令行参数），以键值对形式存储。
• Secret：存储敏感信息（密码、Token、证书），数据以 Base64 编码存储，etcd 中建议启用加密存储。

两者均可通过环境变量注入或 Volume 挂载的方式提供给 Pod 使用。Secret 在 etcd 级和数据传输过程中应启用加密。

PV 是集群中由管理员预置或通过 StorageClass 动态供给的存储资源。 PVC 是用户对存储资源的请求声明，指定所需容量、访问模式（ReadWriteOnce/ReadOnlyMany/ReadWriteMany）。

PVC 绑定 PV 后，Pod 通过引用 PVC 来使用存储资源。这种机制实现了存储供给与消费的解耦。

控制器模式基于声明式 API 和调和循环（Reconcile Loop）：

1. 用户通过 API Server 写入资源的期望状态（如 Deployment 的 replicas: 3）。
2. 控制器通过 Watch 机制持续监听资源的变化。
3. 调和循环读取当前状态，与期望状态对比，执行操作（创建/删除/更新 Pod）。
4. 重复以上步骤，直到当前状态与期望状态一致。

这种模式是实现 Kubernetes 自愈能力（自我修复）的核心机制。

预选阶段（过滤不满足条件的节点）：

• PodFitsResources：节点剩余资源是否满足 Pod 请求。
• PodFitsHost：检查 nodeName 匹配。
• PodFitsHostPorts：端口冲突检查。
• PodSelectorMatches：节点标签是否匹配 nodeSelector。
• PodToleratesNodeTaints：容忍是否匹配污点。
• MatchInterPodAffinity：Pod 亲和/反亲和检查。

优选阶段（对候选节点打分排序）：

• LeastRequestedPriority：资源使用率越低得分越高（倾向负载低的节点）。
• BalancedResourceAllocation：CPU 和内存资源越均衡得分越高。
• ImageLocalityPriority：节点本地已有目标镜像，权重更高。
• SelectorSpreadPriority：同一 Service 的 Pod 尽量分散到不同节点（容灾）。
• NodeAffinityPriority：节点亲和性计算的分数。

污点标记在节点上，表示该节点不应接受特定 Pod 调度。三个效果：

• NoSchedule：不调度新 Pod。
• PreferNoSchedule：尽量不调度。
• NoExecute：驱逐已有不匹配的 Pod。

容忍标记在 Pod 上，表示 Pod 可以（或能够）容忍具有特定污点的节点。 生产实践：控制平面节点打污点防止业务 Pod 调度上去，专用硬件节点（GPU 节点）打污点防止非 GPU Pod 占用。

Deployment 的 rolling update 策略通过两个参数控制速率：

• maxUnavailable：更新过程中最多允许不可用的 Pod 数量（绝对数或百分比，默认 25%）。
• maxSurge：更新过程中最多允许超过期望副本数的 Pod 数量（默认 25%）。

流程：先启动新版本 Pod → 等待就绪 → 终止旧版本 Pod，依次替换。 健康检查（Readiness Probe）确保新 Pod 能正常服务后才继续下一批替换。

• Liveness Probe（存活探针）：检测容器是否正常运行，失败时 kubelet 根据 restartPolicy 重启容器。
• Readiness Probe（就绪探针）：检测容器是否可接收流量，失败时 Service 会将 Pod 从 Endpoints 中移除。
• Startup Probe（启动探针）：在启动阶段检测容器是否启动完成，成功后才启用 Liveness/Readiness 探针。适用于启动较慢的应用，防止在启动阶段被误判为异常重启。

三种实现方式：HTTP GET 请求、TCP 端口检查、在容器中执行命令（exec）。

Namespace 将单个物理集群划分为多个虚拟集群，实现逻辑隔离。主要功能：

• 资源隔离：Pod、Service、PVC 等资源按 Namespace 划分。
• 命名隔离：不同 Namespace 中的资源可以重名。
• 配额管控：ResourceQuota 限制 Namespace 的资源使用量，LimitRange 设置 Pod 的默认资源限制。
• 网络策略：NetworkPolicy 控制 Namespace 间或 Namespace 内的流量。
• RBAC：Role 和 RoleBinding 限定到 Namespace 级别。

HorizontalPodAutoscaler（HPA）基于 CPU、内存利用率或自定义指标动态调整 Pod 副本数。

工作流程：

1. HPA 定期从 Metrics Server 或自定义 API 获取指标数据。
2. 计算目标副本数 = ceil(当前副本数 × (当前指标值 / 目标指标值))。
3. 更新 Deployment 或 StatefulSet 的 replicas 字段。
4. Deployment Controller 负责实际执行扩缩容。

• 生产环境部署 3 或 5 节点奇数集群，避免脑裂。
• Raft 共识算法要求写操作必须得到多数节点确认。
• 关键运维操作：
  • 定期快照备份：ETCDCTL_API=3 etcdctl snapshot save <file>。
  • 后端空间压缩：etcdctl compact <revision>，配合 defrag 回收碎片。
  • 设置 --quota-backend-bytes 限制存储空间，防止 etcd 写满导致集群不可用。

• Role / ClusterRole：定义一组操作权限（verbs: get/list/watch/create/update/delete）和资源（pods/services/…）。
• RoleBinding / ClusterRoleBinding：将 Role/ClusterRole 绑定到 User、Group 或 ServiceAccount。
• Role 和 RoleBinding 限定到 Namespace，ClusterRole 和 ClusterRoleBinding 作用于集群级别。

Static Pod 不由 API Server 管理，由 kubelet 直接通过本地目录（默认 /etc/kubernetes/manifests）中的 YAML 文件创建和管理。kubelet 会监控这些文件的变化，自动调整 Pod 状态。

使用场景：

• 部署控制平面组件（API Server、Scheduler、Controller Manager）通常以 Static Pod 方式运行。
• 节点级系统组件，需要与节点生命周期强绑定。

Kubernetes 网络模型的核心要求（各 CNI 插件必须满足）：

• 每个 Pod 拥有独立 IP。
• 所有 Pod 可以在无需 NAT 的情况下与其他 Pod 直接通信。
• 所有节点可以在无需 NAT 的情况下与所有 Pod 通信。
• Pod 内部容器共享网络命名空间（通过 localhost 通信）。

• ServiceAccount 是 Kubernetes 管理的资源，用于 Pod 进程向 API Server 认证。每个 Namespace 自动创建一个 default ServiceAccount。
• 普通用户由外部 CA 管理，Kubernetes 不存储用户对象。

Pod 通过挂载 ServiceAccount 的自动挂载 Token（绑定到被投射的卷中）来访问 API Server。Kubernetes 1.24 后取消自动创建 Secret，改用 TokenRequest API 提供时限 Token。

1. Pod 进入 Terminating 状态，API Server 从 Endpoints 中移除该 Pod。
2. preStop Hook 被执行（如有配置）。
3. SIGTERM 信号发送给 Pod 中的主进程（PID 1）。
4. Kubernetes 等待 terminationGracePeriodSeconds（默认 30 秒）内进程正常退出。
5. 超时后发送 SIGKILL 强制终止。
6. Pod 从 API Server 中删除。

• userspace 模式（已弃用）：流量在用户空间代理转发，性能较差，不推荐使用。
• iptables 模式（默认）：使用 iptables NAT 规则实现四层负载均衡。规则数随 Service 和 Pod 数量线性增长，大规模集群下规则更新存在性能瓶颈。
• IPVS 模式：使用 Linux 内核 IP Virtual Server 模块，在内核空间做负载均衡。支持多种调度算法（rr、wrr、lc、sh 等），性能更好，适合大规模集群。需节点加载 ip_vs 内核模块。

• 控制平面优先：先升级控制平面组件，后升级工作节点。
• 版本号规则：x.y.z，升级中版本号的限制 —— kubelet 版本不得高于 kube-apiserver 版本（最多比 kube-apiserver 低两个小版本）。
• 升级方式：kubeadm 升级（标准工具）逐节点升级，或托管集群（云厂商）由平台方管理。
• 关键检查：升级前需确认 API 弃用变更、测试 Pod 驱逐机制、验证 etcd 备份完整。