IT面试题|麻瓜面试

本模块聚焦 Kubernetes 核心概念与组件，涵盖集群架构、Pod、工作负载、服务发现、配置管理和高可用机制，全面考察候选人对 K8s 核心知识的掌握程度。

Q1: Kubernetes是什么？核心架构组件有哪些？「🟡 中级」

考察点：考察 K8s 基础架构知识，筛掉只会用 kubectl 跑命令、对集群整体架构没有清晰认知的人。

参考答案：

Kubernetes（简称 K8s）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用，提供服务发现、负载均衡、存储编排、自动扩缩容、自愈等能力。
K8s 采用 Master-Node 架构，分为控制平面（Master）和工作节点（Node）。

控制平面（Master 节点）组件：

kube-apiserver：
- K8s 的 API 网关，所有组件的统一入口，提供 RESTful API。
- 负责认证、授权、准入控制，是唯一与 etcd 交互的组件。
- 水平扩展，无状态设计。
etcd：
- 分布式键值存储，保存集群的所有状态数据（配置、状态、元数据）。
- 是集群的"大脑"，数据一致性由 Raft 协议保证。
- 生产环境至少 3 节点组成集群保证高可用。
kube-scheduler：
- 调度器，负责为新创建的 Pod 选择合适的 Node 节点运行。
- 调度过程：过滤（Filter）→ 打分（Score）→ 选择最优节点。
- 支持自定义调度器和调度策略。
kube-controller-manager：
- 控制器管理器，运行各种控制器循环，不断将当前状态调向期望状态。
- 包含：Node Controller、Deployment Controller、Endpoint Controller、ServiceAccount Controller 等。
- 每个控制器都是一个控制循环（Watch → Compare → Act）。
cloud-controller-manager（可选）：
- 对接云厂商 API 的控制器，实现负载均衡、路由、存储等云资源管理。

工作节点（Node 组件）：

kubelet：
- 节点上的 Agent，负责管理本节点上的 Pod 生命周期。
- 从 apiserver 获取 Pod 清单，确保 Pod 中的容器正常运行。
- 上报节点状态和 Pod 状态到 apiserver。
kube-proxy：
- 实现 Service 的网络代理和负载均衡。
- 维护节点上的网络规则（iptables / IPVS），实现 Service 到 Pod 的流量转发。
容器运行时（Container Runtime）：
- 负责运行容器，如 containerd、CRI-O 等。
- 通过 CRI（Container Runtime Interface）与 kubelet 交互。

K8s 架构概览：
┌─────────────────────────────────────────────────┐
│                  Master Node                    │
│  ┌──────────┐  ┌───────┐  ┌──────────┐         │
│  │ API Server│◄─│ Sched │  │ Ctrl Mgr │         │
│  └────┬─────┘  └───┬───┘  └────┬─────┘         │
│       │            │           │               │
│       ▼            ▼           ▼               │
│  ┌───────────────────────────┐                 │
│  │           etcd            │                 │
│  └───────────────────────────┘                 │
└─────────────────────────────────────────────────┘
                         │
┌─────────────────────────┼───────────────────────┐
│                  Worker Node                    │
│  ┌─────────┐  ┌────────────┐  ┌──────────────┐ │
│  │ kubelet │  │ kube-proxy │  │   containerd  │ │
│  └────┬────┘  └────────────┘  └──────┬───────┘ │
│       │                              │         │
│       └──────────────┬───────────────┘         │
│                      ▼                         │
│               Pods (Containers)                │
└────────────────────────────────────────────────┘

追问延伸：

kube-apiserver 为什么是无状态的？它怎么处理并发和一致性？
etcd 为什么要用 Raft？Raft 协议的基本原理是什么？
kube-scheduler 的调度流程具体是怎样的？有哪些调度算法？

Q2: Pod是什么？和容器有什么关系？「🟢 校招/初级」

考察点：考察 Pod 这个 K8s 最核心概念的理解，筛掉把 Pod 和容器混为一谈的人。

参考答案：

Pod 定义：Pod 是 Kubernetes 中最小的调度和部署单元，代表集群中一个运行中的进程。
Pod 和容器的关系：
- Pod 是容器的"封装"，一个 Pod 可以包含一个或多个容器。
- 单容器 Pod 是最常见的模式，Pod 是容器的一层包装。
- 多容器 Pod 中的容器共享网络命名空间（同一个 IP 和端口空间）、存储卷、UTS 命名空间。
为什么需要 Pod 而不直接调度容器？
- 容器是单进程模型，现实中常有"辅助容器"的需求（如日志收集、配置同步、流量代理）。
- Pod 将紧密耦合的多个容器打包为一个调度单元，保证它们始终在同一节点上运行。
Pause 容器（Infra 容器）：
- 每个 Pod 都有一个 Pause 容器（也叫 Infra 容器），它持有 Pod 的网络命名空间和共享资源。
- 业务容器加入到 Pause 容器的网络命名空间中，实现网络共享。
- Pause 容器非常轻量，几乎不消耗资源。
Pod 生命周期：
- Pending：Pod 已创建但尚未调度到节点，或镜像正在拉取。
- Running：Pod 已绑定到节点，至少有一个容器在运行。
- Succeeded：所有容器正常退出（退出码 0），不会重启。
- Failed：所有容器已终止，至少有一个容器异常退出（非 0 退出码）。
- Unknown：无法获取 Pod 状态（通常是节点失联）。
Pod 重启策略（restartPolicy）：
- Always：总是重启（默认），适合长期运行的服务。
- OnFailure：失败时重启，适合批处理任务。
- Never：从不重启，适合一次性任务。

多容器 Pod 模式：
┌─────────────────────────────┐
│           Pod               │
│  ┌──────┐   ┌──────┐       │
│  │ App  │   │Sidecar│      │
│  │(主业务)│   │(辅助) │      │
│  └──┬───┘   └──┬───┘       │
│     └─────┬────┘           │
│           ▼                │
│   共享网络 / 存储卷         │
│  (Pause 容器持有命名空间)   │
└─────────────────────────────┘

追问延伸：

多容器 Pod 的常见设计模式有哪些？（Sidecar、Ambassador、Adapter）
Pod 的 IP 是怎么分配的？Pod 重建后 IP 会变吗？
Init Container 是什么？有什么用途？

Q3: Deployment和StatefulSet的区别？「🟡 中级」

考察点：考察工作负载的理解和选型能力，筛掉分不清无状态和有状态应用部署差异的人。

参考答案：

Deployment：用于部署无状态应用，是最常用的工作负载。
StatefulSet：用于部署有状态应用，如数据库、分布式存储等。

特性	Deployment	StatefulSet
应用类型	无状态应用	有状态应用
Pod 名称	随机后缀（如 `web-7d5f8-xxxxx`）	有序命名（如 `web-0`、`web-1`、`web-2`）
网络标识	不稳定，Pod 重建后 IP 变化	稳定的 DNS 名称（`web-0.service.ns.svc.cluster.local`）
存储	所有 Pod 共享或各自独立，PVC 不绑定	每个 Pod 有独立且稳定的 PVC，Pod 重建后仍挂载原 PVC
部署顺序	同时创建 / 滚动更新	有序部署（0→1→2），有序删除（2→1→0）
扩缩容	无序并行	按序号顺序进行
Service	普通 Service（ClusterIP 等）	需要 Headless Service（无 ClusterIP）来提供 DNS 解析
更新策略	滚动更新、蓝绿、金丝雀	滚动更新、OnDelete、分区更新（按序号）

Deployment 的核心能力：
- 声明式更新：修改 YAML 自动触发滚动更新。
- 版本管理：通过 ReplicaSet 保留历史版本，支持回滚。
- 滚动更新策略：可配置 maxSurge 和 maxUnavailable。
StatefulSet 的核心能力：
- 稳定的网络身份：每个 Pod 有固定的 DNS 名称。
- 稳定的持久化存储：每个 Pod 对应独立的 PVC，通过 volumeClaimTemplates 自动创建。
- 有序部署和扩展：按序号依次创建，确保启动顺序。
- 适用场景：MySQL 主从、Redis 集群、Kafka、ZooKeeper、etcd 等有状态服务。

StatefulSet 网络标识示例：
Pod: web-0 → DNS: web-0.nginx.default.svc.cluster.local
Pod: web-1 → DNS: web-1.nginx.default.svc.cluster.local
Pod: web-2 → DNS: web-2.nginx.default.svc.cluster.local

每个 Pod 有独立的 PVC：
web-0 → pvc-www-web-0
web-1 → pvc-www-web-1
web-2 → pvc-www-web-2

追问延伸：

什么是 Headless Service？为什么 StatefulSet 需要它？
StatefulSet 的滚动更新可以指定只更新一部分 Pod 吗？（分区更新 partition）
DaemonSet 和 Job/CronJob 又是什么？分别适合什么场景？

Q4: K8s的Service有几种类型？分别是什么？「🟡 中级」

考察点：考察服务发现和流量入口知识，筛掉对 Service 类型和用途混淆不清的人。

参考答案：

Service 是 Kubernetes 中定义的一组 Pod 的访问方式，提供稳定的网络入口，实现服务发现和负载均衡。
Service 通过 Label Selector 选择后端 Pod，Pod IP 变化不影响 Service 访问。

四种 Service 类型：

ClusterIP（默认）：
- 分配一个集群内部的虚拟 IP，只能在集群内部访问。
- 适用于集群内部服务之间的通信。
- kube-proxy 通过 iptables/IPVS 规则将流量转发到后端 Pod。
NodePort：
- 在 ClusterIP 基础上，在每个 Node 上开放一个静态端口（默认范围 30000-32767）。
- 通过 NodeIP:NodePort 可以从集群外部访问服务。
- 适用于开发测试环境，或简单的对外暴露场景。
LoadBalancer：
- 在 NodePort 基础上，通过云厂商提供的负载均衡器暴露服务。
- 云厂商自动创建外部 LB，将流量转发到各节点的 NodePort。
- 适用于公有云环境的生产对外服务。
- 每个 Service 一个 LB，成本较高。
ExternalName：
- 将 Service 映射到一个外部 DNS 名称，返回 CNAME 记录。
- 不分配 ClusterIP，也不代理任何流量，相当于在集群 DNS 中起了个别名。
- 适用于访问集群外部服务的场景（如外部数据库）。

Service 类型对比：
外部流量 → LoadBalancer → NodePort → ClusterIP → Pod
                    ↑           ↑         ↑
                   公网       节点端口    集群内

ExternalName → CNAME → 外部域名（如 db.example.com）

补充知识点：
- Service 的负载均衡默认是 Round Robin（iptables 模式下是随机）。
- sessionAffinity: ClientIP 可以实现会话保持。
- Headless Service（clusterIP: None）不分配虚拟 IP，直接返回 Pod IP 列表，用于 StatefulSet。

追问延伸：

kube-proxy 的 iptables 模式和 IPVS 模式有什么区别？各有什么优缺点？
Service 是怎么找到后端 Pod 的？（Endpoint / EndpointSlice）
ClusterIP 是虚拟 IP，它是怎么实现流量转发的？

Q5: Ingress是什么？和Service有什么关系？「🟡 中级」

考察点：考察入口流量管理和七层路由知识，筛掉只知道 Service 不知道 Ingress、对七层和四层区别不清的人。

参考答案：

Ingress 定义：Ingress 是 K8s 中管理外部访问集群内部服务的 API 对象，提供七层（HTTP/HTTPS）路由能力。
和 Service 的关系：
- Service 是四层（TCP/UDP）负载均衡，提供稳定的内部访问入口。
- Ingress 工作在七层，在 Service 之上提供更丰富的路由规则，它本身不直接代理流量，而是定义路由规则。
- Ingress 需要配合 Ingress Controller 才能生效，Controller 负责解析 Ingress 规则并实现流量转发。
Ingress 的核心功能：
- 基于域名的虚拟主机：同一个 IP 下根据不同域名转发到不同服务。
- 基于路径的路由：同一域名下根据 URL 路径转发到不同后端。
- TLS 终止：集中管理 SSL 证书，在 Ingress 层完成 HTTPS 解密。
- 负载均衡：对后端 Service 的 Pod 进行流量分发。
常见 Ingress Controller：
- Nginx Ingress：最常用，基于 Nginx，功能丰富，社区活跃。
- Traefik：Go 语言实现，原生支持 K8s，自动服务发现，配置简洁。
- Istio Gateway：服务网格方案的入口网关，功能更强大。
- Kong / APISIX：API 网关类，插件生态丰富。

流量路径：
用户 → DNS → LB → Ingress Controller → Service → Pod
                (七层路由/ TLS终止)    (四层)

Ingress 规则示例：
api.example.com/app   → service-app:80
api.example.com/api   → service-api:80
admin.example.com     → service-admin:80

Ingress 资源示例：

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

追问延伸：

Ingress Controller 是怎么工作的？它如何感知 Ingress 规则变化？（Watch API + 动态生成配置）
Nginx Ingress 和 Traefik 怎么选？各有什么特点？
Ingress 和 Gateway API 有什么关系？Gateway API 是什么？

Q6: K8s的配置管理方式？ConfigMap和Secret 「🟡 中级」

考察点：考察配置管理知识，筛掉不会用 K8s 原生配置管理、把配置硬编码在镜像里的人。

参考答案：

Kubernetes 提供了专门的配置管理机制，将配置与镜像解耦，实现一次构建多环境部署。
ConfigMap：
- 用于存储非敏感的配置数据，如配置文件、环境变量、命令行参数。
- 数据以键值对形式存储，值可以是字符串，也可以是整个配置文件内容。
- 以 Volume 挂载或以环境变量方式注入到 Pod 中。
- Volume 挂载的 ConfigMap 支持热更新（约 60 秒延迟），环境变量方式不支持热更新。
Secret：
- 用于存储敏感数据，如密码、密钥、Token、证书等。
- 数据以 base64 编码存储（注意不是加密，只是编码）。
- 同样支持 Volume 挂载和环境变量注入。
- Secret 默认以明文存储在 etcd 中，生产环境应启用 etcd 加密。
- 特殊类型：docker-registry（镜像仓库凭据）、tls（证书）、service-account-token。

使用方式对比：

yaml

# 环境变量注入
env:
- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: db.host
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: app-secret
      key: db.password

# Volume 挂载
volumeMounts:
- name: config-volume
  mountPath: /etc/config
- name: secret-volume
  mountPath: /etc/secret
  readOnly: true
volumes:
- name: config-volume
  configMap:
    name: app-config
- name: secret-volume
  secret:
    secretName: app-secret

最佳实践：
- 敏感数据用 Secret，非敏感用 ConfigMap。
- 优先使用 Volume 挂载而非环境变量（环境变量容易泄露到日志、进程信息中）。
- 不要将 Secret 提交到代码仓库。
- 生产环境启用 etcd 静态加密。
- 考虑使用外部密钥管理系统（Vault、AWS Secrets Manager）与 K8s 集成。

追问延伸：

Secret 是 base64 编码的，这安全吗？生产环境如何加强 Secret 安全？
ConfigMap 热更新的原理是什么？为什么环境变量方式不能热更新？
什么是 Immutable ConfigMap/Secret？有什么好处？
除了 ConfigMap 和 Secret，还有哪些配置管理方案？（Helm values、Kustomize、配置中心 Apollo/Nacos）

Q7: K8s的健康检查和自愈机制？「🟡 中级」

考察点：考察高可用和运维知识，筛掉不了解 K8s 自愈能力、不会设计健康检查的人。

参考答案：

K8s 提供了完善的健康检查（Probe）机制和自愈能力，确保应用稳定运行。

三种探针（Probe）：

livenessProbe（存活探针）：
- 判断容器是否存活（是否在运行）。
- 探测失败则 kubelet 会杀死容器，并根据重启策略决定是否重启。
- 用于检测死锁、进程挂起等无法自动恢复的故障。
readinessProbe（就绪探针）：
- 判断容器是否就绪（是否可以对外提供服务）。
- 探测失败则将该 Pod 从 Service 的 Endpoints 中移除，不再接收流量。
- 不会重启容器，只用于流量控制。
- 用于应用启动预热、依赖未就绪、负载过高时暂时摘除流量。
startupProbe（启动探针）：
- 判断应用是否启动完成。
- 启动探针成功后，才会由 livenessProbe 接管存活检测。
- 用于启动慢的应用，避免被 livenessProbe 误杀。
- 启动探针失败后会重启容器。

探测方式：
- exec：在容器内执行命令，退出码 0 表示成功。
- httpGet：发送 HTTP GET 请求，200-399 状态码表示成功。
- tcpSocket：尝试建立 TCP 连接，成功表示健康。
关键参数：
- initialDelaySeconds：初始延迟，容器启动后多久开始探测。
- periodSeconds：探测周期，多久探测一次。
- timeoutSeconds：超时时间。
- successThreshold：成功阈值，连续成功多少次才算健康。
- failureThreshold：失败阈值，连续失败多少次才算不健康。

自愈机制：

Pod 级自愈：容器崩溃自动重启（restartPolicy）；节点故障时，Deployment 等控制器会在其他节点重建 Pod。
Deployment 滚动更新：更新过程中逐步替换旧 Pod，保证服务不中断；更新失败自动停止并保留可用副本。
节点故障自愈：Node 失联超过一定时间（默认 5 分钟），控制器会将该节点上的 Pod 标记为终止，并在健康节点上重新创建。
HPA 自动扩缩容：根据 CPU/内存或自定义指标自动调整 Pod 副本数。

yaml

# 探针配置示例
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 3
startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

追问延伸：

livenessProbe 和 readinessProbe 应该怎么设计？配置不当会有什么问题？
Pod 处于 CrashLoopBackOff 状态是什么原因？怎么排查？
K8s 的节点失联后，Pod 是怎么迁移的？具体过程是什么？

Q1: Kubernetes是什么？核心架构组件有哪些？ 「🟡 中级」 ​

Q2: Pod是什么？和容器有什么关系？ 「🟢 校招/初级」 ​

Q3: Deployment和StatefulSet的区别？ 「🟡 中级」 ​

Q4: K8s的Service有几种类型？分别是什么？ 「🟡 中级」 ​

Q5: Ingress是什么？和Service有什么关系？ 「🟡 中级」 ​

Q6: K8s的配置管理方式？ConfigMap和Secret 「🟡 中级」 ​

Q7: K8s的健康检查和自愈机制？ 「🟡 中级」 ​

Q1: Kubernetes是什么？核心架构组件有哪些？「🟡 中级」

Q2: Pod是什么？和容器有什么关系？「🟢 校招/初级」

Q3: Deployment和StatefulSet的区别？「🟡 中级」

Q4: K8s的Service有几种类型？分别是什么？「🟡 中级」

Q5: Ingress是什么？和Service有什么关系？「🟡 中级」

Q6: K8s的配置管理方式？ConfigMap和Secret 「🟡 中级」

Q7: K8s的健康检查和自愈机制？「🟡 中级」