第一部分：Kubernetes资源管理与Pod基础认知

一、前言

Kubernetes（K8s）的核心设计思想是资源抽象，集群内所有可操作对象均被定义为资源，运维和开发人员通过操作各类资源实现集群服务部署、管理与维护。对于秋招云计算、后端运维岗位而言，Pod作为K8s最小调度单元，是面试与实操的核心考点，掌握Pod相关知识是入门K8s的关键。

K8s集群的核心资源协作逻辑：集群通过各类控制器管理Pod，Pod运行业务容器；Service资源实现Pod服务访问，Volume、ConfigMap、Secret等资源实现数据持久化与配置管理，形成完整的容器化服务运行体系。

二、K8s资源管理三大方式

K8s提供三种资源管理模式，适配测试、开发、生产不同场景，三者的优缺点和适用环境是秋招高频面试题。

管理类型	适用环境	核心优点	核心缺点	核心命令
命令式对象管理	测试环境、临时调试	操作简单、上手快速，无需编写配置文件	仅能操作运行中资源，无法审计、跟踪操作记录，无版本管控	kubectl run 直接创建资源
命令式对象配置	开发环境、中小型项目	依托配置文件操作，支持操作审计与跟踪，配置可固化	大型项目配置文件数量多，批量操作繁琐，维护成本高	kubectl create/patch -f 配置文件.yaml
声明式对象配置	开发、生产环境（推荐）	支持目录批量操作，只需定义期望状态，集群自动适配，适配CI/CD	程序异常场景下，问题调试难度相对较高	kubectl apply -f 配置文件.yaml

三、kubectl核心命令体系

kubectl是K8s集群专属命令行工具，是操作集群资源的核心入口，所有集群操作均可通过该工具实现，也是实操笔试必考内容。

3.1 命令通用语法

kubectl [command] [type] [name] [flags]

• command：操作指令，如create、get、delete、edit、explain

• type：资源类型，如pod、deployment、service

• name：资源名称，严格区分大小写

• flags：可选扩展参数，用于定制操作效果

3.2 高频基础命令

# 查看集群版本信息
 kubectl version
 # 查看集群核心服务运行信息 
kubectl cluster-info 
# 查看所有Pod资源 
kubectl get pod 
# 以yaml格式展示指定Pod详细信息 
kubectl get pod Pod名称 -o yaml 
# 查看资源官方配置文档（写YAML必备） 
kubectl explain deployment kubectl explain pod.spec

3.3 命令分类汇总

1. 增删改查命令：create（创建）、edit（在线编辑）、get（查询）、delete（删除）、patch（补丁更新）、explain（查询文档）

2. 运行调试命令：run（运行镜像创建Pod）、expose（暴露资源为Service）、describe（查看资源详细事件，排错核心）、logs（查看容器日志）、exec（进入容器执行命令）、cp（集群内外文件拷贝）

3. 发布扩容命令：rollout（版本管理、回滚）、scale（手动扩缩容）、autoscale（自动扩缩容）

4. 高级运维命令：apply（声明式部署）、label（资源标签管理）、cluster-info（集群信息查询）

四、标签Label核心机制

标签是K8s资源的自定义键值对，是控制器匹配、管理Pod的核心依据，也是服务流量调度的关键，面试高频考察。

4.1 核心实操命令

# 查看Pod及对应标签
kubectl get pods --show-labels
# 新增Pod标签
kubectl label pods nginx app=lee
# 覆盖更新已有标签
kubectl label pods nginx app=webcluster --overwrite
# 删除指定标签（key后加-）
kubectl label pods nginx app-

4.2 核心特性（面试重点）

控制器通过标签筛选匹配Pod，若手动删除Pod的匹配标签，控制器会判定该Pod脱离管理，自动新建Pod维持预设副本数，旧Pod会保留，直至手动删除。

五、小结

1. K8s所有操作均围绕资源展开，Pod是集群最小调度单元，容器无法独立存在；

2. 生产环境优先使用声明式apply部署，测试环境可使用命令式快速调试；

3. Label标签是控制器管理Pod的核心标识，是集群资源调度的基础。

第二部分：Pod核心原理与YAML实战配置

一、Pod核心定义

Pod是K8s集群中最小、可部署、可调度的计算单元，是运行容器的载体。官方类比为豌豆荚，容器为豌豆，一个Pod可包含一个或多个容器。

1.1 Pod核心特性

• 唯一性：每个Pod拥有集群内唯一的IP地址；

• 资源共享：同一Pod内所有容器共享IPC、Network、UTC命名空间，可通过localhost直接通信；

• 生命周期一致：同一Pod内容器同时启动、同时销毁，资源共生共灭。

二、自主式Pod与控制器管理Pod

Pod分为自主式Pod和控制器管理Pod，生产环境严禁使用自主式Pod，二者区别是秋招核心考点。

2.1 自主式Pod（手动创建，生产不推荐）

通过kubectl run或独立YAML文件手动创建，无控制器托管。

优点：配置灵活，可精准自定义Pod参数，适合学习调试、一次性任务、环境验证。

缺点：无自愈、无扩缩容、无版本更新能力，手动维护成本极高，故障后无法自动恢复。

2.2 控制器管理Pod（生产推荐）

通过Deployment、DaemonSet等控制器间接创建管理Pod，是生产环境标准用法。

核心优势：

1. 高可用自愈：Pod故障、删除后，控制器自动重建，维持预设副本数；

2. 弹性扩缩容：支持手动scale扩容缩容，以及HPA自动扩缩容；

3. 版本管控：支持滚动更新、版本回滚，更新过程服务不中断；

4. 服务联动：自动被Service发现，实现负载均衡与流量分发。

三、YAML资源清单核心参数详解

YAML是K8s资源声明式部署的核心载体，所有资源均可通过标准化YAML模板定义，以下为通用核心参数。

参数名称	类型	详细说明
apiVersion	字符串	K8s API版本，Pod默认v1，控制器多为apps/v1，可通过kubectl api-versions查询
kind	字符串	资源类型，如Pod、Deployment、Service
metadata	对象	资源元数据，包含名称、命名空间、标签等基础信息
spec	对象	资源核心配置，定义Pod、容器的运行规则
spec.containers	列表	容器配置列表，可定义单个或多个容器
spec.restartPolicy	字符串	Pod重启策略：Always、OnFailure、Never，默认Always
spec.nodeSelector	对象	节点筛选标签，指定Pod运行的目标节点
spec.hostNetwork	布尔值	是否启用宿主机网络，默认false，启用后共享宿主机网卡

四、高频YAML实战案例

4.1 单容器Pod基础配置

可通过dry-run快速生成模板，无需手动编写基础结构

# 生成YAML模板
kubectl run timinglee --image myapp:v1 --dry-run=client -o yaml > pod.yml

模板核心内容：

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timing
  name: timinglee
spec:
  containers:
  - image: myapp:v1
    name: timinglee

4.2 多容器Pod配置（避坑重点）

同一Pod多容器共享网络端口，禁止部署相同端口服务，会出现端口占用报错。

错误示例（端口冲突）：两个Nginx容器占用80端口，启动失败

正确示例（业务容器+辅助容器）：

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timing
  name: timinglee
spec:
  containers:
  - image: nginx:latest
    name: web1
  - image: busybox:latest
    name: busybox
    command: ["/bin/sh","-c","sleep 1000000"]

4.3 资源限制配置（QoS优先级）

通过limits和requests配置容器资源上下限，影响Pod QoS服务质量优先级：Guaranteed > Burstable > BestEffort

spec:
  containers:
  - image: myapp:v1
    name: myapp
    resources:
      limits:
        cpu: 500m
        memory: 100M
      requests:
        cpu: 500m
        memory: 100M

五、小结

1. Pod是容器的载体，同Pod容器资源共享、生命周期同步；

2. 生产环境必须使用控制器托管Pod，保证高可用与可维护性；

3. 多容器Pod需规避端口冲突，资源限制配置决定Pod调度优先级。

第三部分：Pod生命周期与Init容器深度解析

一、Pod完整生命周期概述

Pod从创建到销毁存在完整生命周期，核心包含：初始化（Init容器运行）、容器启动、探针检测、运行就绪、终止销毁五个阶段。其中Init容器初始化、三大探针机制是秋招面试核心难点。

二、Init初始化容器

2.1 核心特性

Pod可配置多个Init容器，Init容器优先于业务容器启动，且必须全部执行成功后，业务容器才会启动。

独有特性：

• 强制运行至结束，不支持就绪探针；

• 执行失败会触发Pod重启，直至执行成功（restartPolicy为Never除外）；

• 串行执行，多个Init容器按配置顺序依次运行。

2.2 核心应用场景

1. 环境预处理：安装业务依赖工具、初始化配置文件；

2. 依赖检测：等待数据库、注册中心等前置服务就绪；

3. 权限隔离：独立访问Secret等敏感资源，不暴露给业务容器；

4. 镜像轻量化：将工具类、预处理逻辑剥离，精简业务镜像。

2.3 Init容器实战案例

实现前置文件检测，文件生成后启动业务容器

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: initpod
  name: initpod
spec:
  containers:
  - image: myapp:v1
    name: myapp
  initContainers:
  - name: init-myservice
    image: busybox
    command: ["sh","-c","until test -e /testfile;do echo wating for myservice;sleep 2;done"]

实操效果：Init容器持续阻塞，手动生成/testfile文件后，初始化完成，业务容器正常启动。

三、Pod重启策略详解

通过spec.restartPolicy配置，控制Pod容器异常后的重启逻辑，三种策略：

1. Always（默认）：容器无论何种原因终止，自动重启，适合常驻业务服务；

2. OnFailure：仅容器异常退出（非0退出码）时重启，正常退出不重启，适合一次性任务；

3. Never：容器终止后永不重启，适合测试、临时任务场景。

四、QoS服务质量等级

K8s根据Pod资源请求（requests）和限制（limits）配置，划分三种QoS优先级，集群资源不足时，低优先级Pod优先被驱逐：

1. Guaranteed（最高优先级）：requests与limits的CPU、内存配置完全一致；

2. Burstable（中等优先级）：仅配置requests，或requests与limits配置不一致；

3. BestEffort（最低优先级）：未配置任何资源限制与请求。

五、本章小结

1. Init容器是Pod初始化前置组件，串行执行、成功后才启动业务容器；

2. 重启策略适配不同业务场景，常驻服务默认Always；

3. QoS等级决定Pod资源调度优先级与驱逐顺序，生产核心服务建议配置Guaranteed等级。

第四章：Pod三大探针机制（秋招面试高频核心）

一、探针核心概述

探针是kubelet组件对容器执行的周期性健康诊断机制，用于检测容器运行状态，自动处理异常容器，保障服务高可用，是秋招K8s面试必考重难点。

探针检测结果分为三种：成功（容器正常）、失败（容器异常）、未知（检测异常，无操作）。

三大探针类型：存活探针、就绪探针、启动探针。

三种探测方式：HTTPGet请求、TCP端口检测、容器内命令执行。

二、三大探针详解与区别

2.1 存活探针 livenessProbe

核心作用：检测容器是否正常运行，容器卡死、进程异常时触发自愈。

异常处理逻辑：探测失败后，kubelet直接杀死容器，根据重启策略决定是否重建。

适用场景：容器进程卡死、无响应、死循环等无法自愈的异常场景。

2.2 就绪探针 readinessProbe

核心作用：检测容器是否完成初始化、可正常接收业务请求。

异常处理逻辑：探测失败后，不会重启容器，仅将该Pod从Service流量端点中剔除，停止分发流量，等待就绪后重新接入流量。

适用场景：服务启动慢、初始化加载配置、数据库连接等待等启动缓冲场景。

2.3 启动探针 startupProbe

核心作用：专门检测容器应用是否启动完成，适配启动缓慢的应用。

核心特性：容器启动阶段，临时禁用存活、就绪探针，仅执行启动探针；启动探针成功后，其他探针恢复工作；仅启动阶段生效，不做周期性检测。

2.4 三大探针核心区别（面试总结）

• 存活探针：管运行状态，异常杀容器重启；

• 就绪探针：管流量接入，异常剔除流量不重启；

• 启动探针：管启动过程，仅启动阶段生效，保护慢启动应用。

三、探针核心配置参数

• initialDelaySeconds：容器启动后延迟多久开始探测；

• periodSeconds：探测周期，默认10秒；

• timeoutSeconds：探测超时时间，默认1秒。

四、探针实战案例

4.1 存活探针（TCP探测）

检测8080端口是否存活，端口未开放则重启容器

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: liveness
  name: liveness
spec:
  containers:
  - image: myapp:v1
    name: myapp
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 1
      timeoutSeconds: 1

4.2 就绪探针（HTTP探测）

检测指定接口是否就绪，接口404则剔除流量，接口正常后恢复

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: readiness
  name: readiness
spec:
  containers:
  - image: myapp:v1
    name: myapp
    readinessProbe:
      httpGet:
        path: /test.html
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1

五、小结

1. 就绪探针失败不重启Pod，仅剥离流量；存活探针失败直接重启Pod；

2. 启动探针优先级最高，启动阶段禁用其他探针，解决慢启动应用误杀问题；

3. 生产环境建议同时配置存活+就绪探针，兼顾服务自愈与流量精准分发。

总结（秋招核心背诵要点）

1. K8s最小调度单元为Pod，容器不可以独立运行，生产全部使用控制器托管Pod；

2. 资源管理优先使用声明式apply，适配生产CI/CD持续部署；

3. 同Pod多容器共享网络、存储、命名空间，适合主辅容器架构，需规避端口冲突；

4. Init容器串行前置执行，多用于环境初始化、依赖等待；

5. QoS优先级决定集群资源驱逐策略，核心业务需配置Guaranteed级别；

6. 三大探针分工明确，是K8s服务自愈、高可用的核心保障，为面试必考重点。