Java面试题52：一文深入了解Kubernetes 核心资源对象

一、引言

Kubernetes（简称 K8s）作为容器编排领域的事实标准，已经成为现代云原生应用开发和部署的基石。它通过声明式 API 和自动化管理，解决了容器化应用在大规模部署、运维和扩展过程中的各种挑战。

在 Kubernetes 的世界里，"万物皆对象"。所有的集群操作和应用管理都是通过操作各种资源对象来实现的。理解这些核心资源对象的原理、特性和使用方法，是掌握 Kubernetes 的关键，也是技术面试中最常考察的内容。

二、Kubernetes 资源对象基础

2.1 什么是资源对象

Kubernetes 资源对象是集群中的持久化实体，用于描述集群的期望状态（Desired State）。Kubernetes 控制平面（如 kube-controller-manager、kube-scheduler）会持续监控这些资源对象，通过 "调和（Reconciliation）" 过程将集群的实际状态（Actual State）调整为期望状态。

2.2 资源对象的核心属性

所有 Kubernetes 资源对象都通过 YAML 或 JSON 格式定义，且包含以下 5 个核心字段：

字段名	作用说明	示例值
`apiVersion`	资源所属的 API 版本	`v1`、`apps/v1`、`networking.k8s.io/v1`
`kind`	资源对象的类型	`Pod`、`Deployment`、`Service`
`metadata`	对象的元数据，包括名称、命名空间、标签、注解等	`name: nginx-pod`、`namespace: default`
`spec`	对象的期望状态，描述希望对象具有的特征	`replicas: 3`、`image: nginx:latest`
`status`	对象的当前实际状态，由系统填充，只读	`phase: Running`、`readyReplicas: 3`

2.3 资源对象的分类

Kubernetes 资源对象按功能可分为五大类：

工作负载资源：管理应用的运行方式和生命周期
服务发现与负载均衡资源：解决应用的网络访问问题
配置与存储资源：管理应用的配置和数据持久化
集群级资源：定义集群本身的配置和权限
元数据资源：配置其他资源的行为

三、工作负载类资源

工作负载资源是 Kubernetes 中最核心的资源类型，用于定义和管理容器化应用的部署、运行和扩展。

3.1 Pod：最小部署单元

Pod 是 Kubernetes 中最小、最简单的对象，也是所有其他工作负载的基础单元。它表示集群上一组正在运行的容器。

核心特性

资源共享：同一 Pod 内的所有容器共享网络命名空间（同一个 IP 地址和端口）、存储卷和运行声明
生命周期一致：Pod 内任意容器故障，可能导致整个 Pod 重启（取决于重启策略）
短暂性：Pod 是 "一次性" 的，一旦被删除就不会自动恢复，通常由控制器管理

Pod 的组成

一个 Pod 通常包含：

主容器：运行应用的主要业务逻辑
Init 容器：在主容器启动前运行，用于初始化工作
边车（Sidecar）容器：辅助主容器完成额外功能（如日志收集、监控、网络代理）

Pod 的生命周期

Pod 的生命周期包括以下几个阶段：

Pending：Pod 已被创建，但容器尚未全部启动
Running：所有容器都已启动，且至少有一个容器正在运行
Succeeded：所有容器都已成功完成并退出
Failed：所有容器都已退出，且至少有一个容器异常退出
Unknown：无法获取 Pod 的状态

健康检查探针

Kubernetes 提供三种探针来检查容器的健康状态：

存活探针（Liveness Probe）：检测容器是否正在运行，失败则重启容器
就绪探针（Readiness Probe）：检测容器是否准备好接收请求，失败则从 Service 中移除
启动探针（Startup Probe）：检测容器是否启动完成，适用于启动慢的应用

3.2 Deployment：无状态应用管理

Deployment 是管理无状态应用的核心控制器，它通过管理 ReplicaSet 来确保指定数量的 Pod 副本始终运行，并提供滚动更新、回滚、扩缩容等功能。

工作原理

Deployment 不直接管理 Pod，而是通过创建和管理 ReplicaSet 来间接管理 Pod。当你更新 Deployment 的 Pod 模板时，Deployment 会创建一个新的 ReplicaSet，并逐步将旧 ReplicaSet 中的 Pod 替换为新的 Pod。

核心功能

副本管理：确保指定数量的 Pod 副本始终运行
滚动更新：零停机更新应用，支持配置更新速度
回滚：一键回滚到之前的版本
扩缩容：手动或自动调整 Pod 副本数量

滚动更新策略

Deployment 支持两种更新策略：

RollingUpdate（默认）：逐步替换旧版本 Pod，确保服务不中断
Recreate：先删除所有旧版本 Pod，再创建新版本 Pod，会导致服务短暂中断

3.3 StatefulSet：有状态应用管理

StatefulSet 是专门用于管理有状态应用的工作负载控制器。与 Deployment 不同，StatefulSet 为每个 Pod 维护一个稳定的、唯一的标识Kubernetes。

核心特性

稳定的网络标识 ：Pod 名称格式为<name>-<序号>（如 mysql-0、mysql-1），且拥有固定的 DNS 名称
稳定的持久化存储：每个 Pod 绑定独立的 PVC，即使 Pod 被删除，PVC 依然存在
有序的部署和扩展：按序号 0 到 N-1 逐一创建 Pod，前一个 Pod 就绪后才创建下一个
有序的删除和缩容：按序号 N-1 到 0 逐一删除 Pod

与 Deployment 的对比

特性	Deployment	StatefulSet
目标应用	无状态应用（如 Web 服务器、API）	有状态应用（如数据库、Kafka）
Pod 身份	动态、可替换（如 app-xxxx-yyyy）	稳定、唯一（如 web-0、web-1）
网络标识	不稳定，通过 ClusterIP Service 访问	稳定，通过 Headless Service 直接访问
存储	共享或临时	每个 Pod 独立 PVC
部署 / 扩容	并发创建所有 Pod	按序号逐一创建
缩容 / 删除	并发删除所有 Pod	按序号逐一删除
更新策略	灵活，支持多种策略	有序，默认按序号逐一更新

Headless Service

StatefulSet 通常与 Headless Service 配合使用。Headless Service 不分配 ClusterIP，而是为每个 Pod 创建 DNS 记录，使 Pod 可以通过固定的域名相互访问。

3.4 DaemonSet：守护进程集

DaemonSet 确保集群中所有（或指定）节点上都运行一个 Pod 副本。当有新节点加入集群时，DaemonSet 会自动在该节点上创建 Pod；当节点被移除时，DaemonSet 会自动删除该节点上的 Pod。

典型使用场景

部署集群存储守护进程（如 ceph-osd、glusterd）
部署日志收集守护进程（如 Fluentd、Logstash）
部署监控守护进程（如 Prometheus Node Exporter）
部署网络插件（如 Calico、Flannel）

3.5 Job 与 CronJob：任务管理

Job

Job 用于运行一次性任务，它创建一个或多个 Pod，并确保指定数量的 Pod 成功完成。当 Pod 成功完成后，Job 不会再创建新的 Pod。

CronJob

CronJob 用于运行周期性任务，它基于 Cron 表达式调度 Job 的执行。CronJob 会在指定的时间创建 Job，由 Job 负责运行具体的任务。

四、服务发现与负载均衡类资源

4.1 Service：服务抽象

Service 是 Pod 的抽象层，解决了 Pod 动态变化导致的访问问题。它为一组具有相同功能的 Pod 提供一个稳定的网络入口和负载均衡能力。

核心功能

服务发现：通过标签选择器关联一组 Pod，生成虚拟 IP（ClusterIP）或域名
负载均衡：将请求分发到关联的 Pod 上（默认轮询策略）
端口映射：将 Service 端口映射到 Pod 的容器端口

Service 类型

Kubernetes 支持以下几种 Service 类型：

类型	说明	使用场景
ClusterIP（默认）	仅在集群内部可访问，分配一个集群内部的虚拟 IP	服务间通信
NodePort	在每个节点上开放一个固定端口，通过`NodeIP:NodePort`访问	外部测试、临时访问
LoadBalancer	使用云服务商提供的负载均衡器，分配一个外部 IP	生产环境外部访问
ExternalName	将 Service 映射到一个外部域名	访问集群外部服务

kube-proxy 的工作模式

kube-proxy 是运行在每个节点上的网络代理，负责实现 Service 的负载均衡功能。它支持三种工作模式：

userspace 模式：最早的模式，kube-proxy 在用户空间监听一个端口，将流量转发到后端 Pod。性能较差，已基本被淘汰。
iptables 模式：默认模式，kube-proxy 通过配置 Linux 内核的 iptables 规则来实现流量转发。性能较好，但当 Service 数量较多时，iptables 规则会变得非常庞大，影响性能。
ipvs 模式：基于 Linux 内核的 IPVS（IP Virtual Server）模块实现，专门用于负载均衡。性能最好，支持多种负载均衡算法，适合大规模集群。

4.2 Ingress：入口控制器

Ingress 是集群的 HTTP/HTTPS 入口，实现 7 层负载均衡。它允许你通过域名和路径将外部请求转发到集群内的不同 Service。

核心功能

基于域名的虚拟主机：将不同域名的请求转发到不同的 Service
基于路径的路由：将同一域名下不同路径的请求转发到不同的 Service
TLS/SSL 终止：统一处理 HTTPS 证书，后端 Service 可以使用 HTTP
流量控制：支持限流、熔断等高级功能

Ingress 控制器

Ingress 资源本身只是一组路由规则，需要配合 Ingress 控制器才能实际工作。常见的 Ingress 控制器有：

Nginx Ingress Controller（官方推荐）
Traefik
HAProxy Ingress
Istio Gateway（服务网格）

五、配置与存储类资源

5.1 ConfigMap：配置管理

ConfigMap 用于存储非敏感的配置信息，如配置文件、环境变量、命令行参数等。它实现了配置与应用的解耦，使应用不需要重新构建镜像就可以修改配置。

使用方式

作为环境变量注入容器
作为命令行参数传递给容器
作为文件挂载到容器内的目录

5.2 Secret：密钥管理

Secret 用于存储敏感信息，如密码、令牌、证书等。与 ConfigMap 类似，但 Secret 采用 Base64 编码存储，比 ConfigMap 更安全。

Secret 类型

Opaque：通用的 Secret 类型，存储任意数据
kubernetes.io/dockerconfigjson：存储 Docker 镜像仓库的认证信息
kubernetes.io/tls：存储 TLS 证书和私钥
kubernetes.io/service-account-token：由 Kubernetes 自动创建，用于 ServiceAccount 的认证

5.3 持久化存储

Kubernetes 提供了完整的持久化存储解决方案，包括 Volume、PersistentVolume（PV）、PersistentVolumeClaim（PVC）和 StorageClass。

Volume

Volume 是 Pod 级别的存储，生命周期与 Pod 相同。当 Pod 被删除时，Volume 也会被删除。常见的 Volume 类型有：

emptyDir：临时存储，Pod 删除后数据丢失
hostPath：将节点上的文件或目录挂载到 Pod 中
nfs：将 NFS 共享目录挂载到 Pod 中
configMap/secret：将 ConfigMap 或 Secret 作为文件挂载到 Pod 中

PersistentVolume（PV）与 PersistentVolumeClaim（PVC）

PV：集群级别的存储资源，由管理员预先创建或通过 StorageClass 动态生成，代表实际的存储设备
PVC：用户对存储的请求，类似于 Pod 消耗节点资源，PVC 消耗 PV 资源Kubernetes

PV 与 PVC 的绑定逻辑

PV 和 PVC 由 Kubernetes 自动匹配，遵循以下三个条件：

存储类型匹配：PVC 的 storageClassName 必须与 PV 的 storageClassName 完全一致
访问模式兼容：PVC 请求的 accessModes 必须是 PV 支持的 accessModes 子集
容量满足：PVC 请求的 storage 必须≤PV 的 capacity.storage

StorageClass

StorageClass 用于动态供给 PV。它定义了存储的类型和参数，当用户创建 PVC 时，Kubernetes 会根据 StorageClass 自动创建对应的 PV 并绑定。

六、集群级资源

6.1 Namespace：命名空间

Namespace 用于将集群划分为多个虚拟集群，实现资源的隔离和管理。不同 Namespace 中的资源名称可以相同，但资源本身是隔离的。

常用 Namespace

default：默认命名空间，未指定 Namespace 的资源都创建在这里
kube-system：Kubernetes 系统组件所在的命名空间
kube-public：所有用户都可以读取的命名空间，通常用于公共资源
kube-node-lease：存储节点租约信息，用于节点健康检查

6.2 Node：节点

Node 是 Kubernetes 集群中的工作节点，可以是物理机或虚拟机。每个 Node 上运行着 kubelet、kube-proxy 和容器运行时等组件，负责管理 Pod 的生命周期和网络通信。

6.3 RBAC：基于角色的访问控制

RBAC（Role-Based Access Control）是 Kubernetes 的权限管理系统，它通过角色和角色绑定来控制用户或服务账户对集群资源的访问权限Kubernetes。

RBAC 的四个核心资源

Role：定义在特定命名空间内的权限集合
ClusterRole：定义集群级别的权限集合，可以访问所有命名空间的资源和集群级资源
RoleBinding：将 Role 绑定到特定的主体（用户、组、服务账户），使其在特定命名空间内拥有 Role 定义的权限
ClusterRoleBinding：将 ClusterRole 绑定到特定的主体，使其在整个集群范围内拥有 ClusterRole 定义的权限Kubernetes

权限规则

RBAC 的权限规则是纯加法的，没有 "拒绝" 规则。如果一个主体被多个角色绑定，那么它拥有这些角色所有权限的并集。

七、元数据类资源

7.1 HorizontalPodAutoscaler（HPA）：水平 Pod 自动扩缩容

HPA 用于根据 CPU、内存使用率或自定义指标自动调整 Pod 的副本数量。它可以根据应用的负载情况，自动增加或减少 Pod 副本，提高资源利用率和应用的可用性。

7.2 LimitRange：资源限制范围

LimitRange 用于为命名空间内的 Pod 和容器设置默认的资源请求和限制。它可以防止用户创建没有资源限制的 Pod，避免资源被过度消耗。

7.3 ResourceQuota：资源配额

ResourceQuota 用于限制命名空间内的资源使用总量。它可以限制命名空间内可以创建的 Pod、Service、PVC 等资源的数量，以及 CPU、内存等计算资源的总使用量。

八、高频面试题与解答

基础概念题

Q1: 什么是 Pod？为什么 Kubernetes 要引入 Pod 概念，而不是直接管理容器？

A: Pod 是 Kubernetes 中最小的部署单元，是一组紧密关联的容器的集合。Kubernetes 引入 Pod 概念主要有以下原因：

解决容器间的协作问题：有些应用需要多个容器紧密协作，如主应用 + 日志收集器、主应用 + 网络代理等。这些容器需要共享网络和存储，Pod 提供了这样的环境。
统一管理容器的生命周期：Pod 内的所有容器具有相同的生命周期，一起创建、一起销毁，便于统一管理。
抽象容器的运行环境：Pod 为容器提供了统一的运行环境，屏蔽了底层容器运行时的差异。
提高调度效率：将多个紧密关联的容器打包成一个 Pod 进行调度，比单独调度多个容器更高效。

Q2: 简述 Pod 的生命周期。

A: Pod 的生命周期包括以下几个阶段：

Pending：Pod 已被 API Server 创建，但尚未被调度到节点上，或者镜像正在拉取中。
Running：Pod 已被调度到节点上，所有容器都已创建，且至少有一个容器正在运行。
Succeeded：所有容器都已成功完成并退出，且不会再重启。
Failed：所有容器都已退出，且至少有一个容器异常退出（退出码不为 0）。
Unknown：由于某种原因无法获取 Pod 的状态，通常是由于节点与 API Server 失去联系。

Q3: Deployment、StatefulSet 和 DaemonSet 的区别是什么？各适用于什么场景？

A: 这三种控制器的主要区别和适用场景如下：

控制器	特点	适用场景
Deployment	管理无状态应用，Pod 是等价的、可替换的，支持滚动更新和回滚	Web 服务器、API 服务、微服务等无状态应用
StatefulSet	管理有状态应用，Pod 有固定的身份和存储，有序部署和扩展	数据库（MySQL、PostgreSQL）、消息队列（Kafka、RabbitMQ）、分布式存储等有状态应用
DaemonSet	在每个节点上运行一个 Pod 副本，节点加入或离开时自动创建或删除 Pod	日志收集、监控、网络插件等需要在所有节点上运行的守护进程

网络相关题

Q4: Service 是如何工作的？kube-proxy 的三种模式有什么区别？

A: Service 通过标签选择器关联一组 Pod，为它们提供一个稳定的虚拟 IP（ClusterIP）和端口。当客户端访问 Service 时，kube-proxy 会将请求转发到后端的 Pod 上。

kube-proxy 的三种模式区别如下：

userspace 模式：kube-proxy 在用户空间监听一个端口，将流量转发到后端 Pod。性能较差，因为流量需要经过用户空间和内核空间的多次切换。
iptables 模式：kube-proxy 通过配置 Linux 内核的 iptables 规则来实现流量转发。性能比 userspace 模式好，因为流量转发完全在内核空间完成。但当 Service 数量较多时，iptables 规则会变得非常庞大，影响性能。
ipvs 模式：基于 Linux 内核的 IPVS 模块实现，专门用于负载均衡。性能最好，支持多种负载均衡算法（轮询、加权轮询、最小连接数等），适合大规模集群。

Q5: 什么是 Headless Service？它有什么作用？

A: Headless Service 是一种特殊的 Service，它不分配 ClusterIP，也不提供负载均衡功能。它的spec.clusterIP字段设置为None。

Headless Service 的主要作用是：

为 StatefulSet 提供稳定的网络标识 ：StatefulSet 中的每个 Pod 都可以通过pod-name.service-name.namespace.svc.cluster.local这样的域名访问。
客户端自己实现负载均衡：客户端可以通过 DNS 查询获取所有后端 Pod 的 IP 地址，然后自己实现负载均衡逻辑。
直接访问 Pod：不需要通过 Service 的负载均衡，直接访问特定的 Pod。

存储相关题

Q6: 简述 PV、PVC 和 StorageClass 的关系。

A: PV、PVC 和 StorageClass 是 Kubernetes 持久化存储体系中的三个核心概念，它们的关系如下：

PV（PersistentVolume）：是集群中的一块存储资源，由管理员预先创建或通过 StorageClass 动态生成。它代表了底层的实际存储设备，如 NFS 共享、云硬盘等。
PVC（PersistentVolumeClaim）：是用户对存储的请求。用户在使用存储时，不需要关心底层存储的具体实现，只需要创建一个 PVC，声明所需的存储大小和访问模式。
StorageClass：用于动态供给 PV。它定义了存储的类型和参数，当用户创建 PVC 时，如果指定了 StorageClass，Kubernetes 会自动创建对应的 PV 并与 PVC 绑定。

简单来说，PV 是 "存储资源"，PVC 是 "存储申请单"，StorageClass 是 "存储模板"。

Q7: ConfigMap 和 Secret 有什么区别？

A: ConfigMap 和 Secret 都是用于存储配置信息的资源，但它们有以下区别：

存储内容不同：ConfigMap 用于存储非敏感的配置信息，如配置文件、环境变量等；Secret 用于存储敏感信息，如密码、令牌、证书等。
编码方式不同：ConfigMap 存储的是明文；Secret 存储的是 Base64 编码的数据（注意：Base64 不是加密，只是编码，仍然可以被解码）。
使用场景不同：ConfigMap 适用于存储普通的配置信息；Secret 适用于存储需要保密的信息。
Kubernetes 处理方式不同：Kubernetes 对 Secret 有特殊的处理，如避免将 Secret 写入磁盘、在传输过程中加密等。

高级题

Q8: 什么是 QoS 类？Kubernetes 有哪几种 QoS 类？它们是如何划分的？

A: QoS（Quality of Service）类是 Kubernetes 为 Pod 划分的服务质量等级，用于在资源不足时决定哪些 Pod 应该被优先驱逐。

Kubernetes 有三种 QoS 类：

Guaranteed（保证级）：Pod 中的所有容器都设置了 CPU 和内存的 requests 和 limits，且 requests 等于 limits。这类 Pod 的优先级最高，只有在它们使用的资源超过 limits 时才会被驱逐。
Burstable（突发级）：Pod 中至少有一个容器设置了 CPU 或内存的 requests，但不是所有容器都设置了 limits，或者 requests 不等于 limits。这类 Pod 的优先级次之，在资源不足时，会在 BestEffort 类 Pod 之后被驱逐。
BestEffort（尽力级）：Pod 中的所有容器都没有设置 CPU 和内存的 requests 和 limits。这类 Pod 的优先级最低，在资源不足时会被最先驱逐。

Q9: 简述 RBAC 的四个核心资源及其作用。

A: RBAC 的四个核心资源及其作用如下：

Role：定义在特定命名空间内的权限集合。它包含一组规则，每个规则指定了可以对哪些资源执行哪些操作。
ClusterRole：定义集群级别的权限集合。与 Role 不同，ClusterRole 是集群范围的，可以访问所有命名空间的资源和集群级资源（如 Node、PV 等）。
RoleBinding：将 Role 绑定到特定的主体（用户、组、服务账户），使其在特定命名空间内拥有 Role 定义的权限。
ClusterRoleBinding：将 ClusterRole 绑定到特定的主体，使其在整个集群范围内拥有 ClusterRole 定义的权限。

Q10: 什么是滚动更新？Deployment 的滚动更新是如何实现的？

A: 滚动更新是一种零停机更新应用的方式，它逐步替换旧版本的 Pod 为新版本的 Pod，确保在更新过程中服务始终可用。

Deployment 的滚动更新实现过程如下：

当用户更新 Deployment 的 Pod 模板时，Deployment 控制器会创建一个新的 ReplicaSet。
新的 ReplicaSet 开始创建新版本的 Pod，同时旧的 ReplicaSet 开始删除旧版本的 Pod。
Deployment 控制器会根据配置的maxUnavailable和maxSurge参数来控制更新的速度：
- maxUnavailable：更新过程中最多允许多少个 Pod 不可用
- maxSurge：更新过程中最多允许比期望副本数多多少个 Pod
当所有旧版本的 Pod 都被替换为新版本的 Pod 时，滚动更新完成。

如果在更新过程中发现新版本有问题，可以通过回滚操作将 Deployment 恢复到之前的版本。