Kubernetes（k8s）快速回顾

最新推荐文章于 2026-06-17 09:06:34 发布

原创最新推荐文章于 2026-06-17 09:06:34 发布 · 369 阅读

8 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#kubernetes

Kubernetes 专栏收录该内容

1 篇文章

订阅专栏

文章目录

Kubernetes 快速复习指南

Kubernetes 快速复习指南

适用于有一定基础但太久没用的开发者，快速唤醒记忆，以面试/实战为导向。

一、概述

Kubernetes（简称 K8s）是容器编排平台，用于自动化管理容器应用。
它负责容器的部署、调度、扩缩容、自愈、运维，屏蔽底层服务器差异，实现应用弹性运行、高可用与统一管控，是当下云原生应用的主流运行底座。

1.1 架构

Master 与 Worker

角色	说明
Master（控制平面）	集群的大脑，负责调度、状态维护、API 响应。
Worker（工作节点）	真正跑容器的地方，运行应用 Pod。

前置环境

在 Master 和 Worker 安装 k8s 前，需预先安装：

容器运行时（CRI，Container Runtime Interface）：如 containerd（推荐）、CRI-O、Docker Engine（v1.24+ 已不再直接支持 Docker，通过 cri-dockerd 桥接）。负责启动 Pod 中的应用。
网络插件（CNI，Container Network Interface）：如 Calico、Flannel、Cilium、Weave，负责 Pod 之间的网络连通和网络策略。
kubelet 和 kubeadm 和 kubectl：核心命令行工具。

k8s 架构图

请添加图片描述

Master 各组件详解

组件	作用
etcd	分布式键值存储。保存所有集群数据（Pod、Service、ConfigMap 等资源的状态）。
kube-api-server	所有组件（包括 kubectl）都通过它通信。提供 RESTful API，负责认证、鉴权、准入控制、验证请求并写入 etcd。
kube-scheduler	负责将新创建的 Pod 分配到合适的 Worker 节点。基于资源需求、亲和性、污点容忍等策略决策。
kube-controller-manager	运行各种资源控制器，确保资源实际状态逼近期望状态。
cloud-controller-manager	可选组件。与云厂商（AWS/GCP/Azure）的 API 集成，管理云资源。

Worker 各组件详解

组件	作用
kubelet	运行在每个 Worker 上。监听 API Server 的 Pod 分配，确保 Pods 和容器健康运行。向 API Server 汇报节点和 Pod 状态。与 CRI 交互创建/删除容器。
kube-proxy	维护节点上的网络规则（iptables/IPVS）。实现 Service 的负载均衡和 Pod 间通信。
Pod	最小部署单元，包含一个或多个容器。同一个 Pod 中的容器共享 IP、端口、Volume，通过 localhost 通信。

Cloud Provider API

K8s 可以通过 cloud-controller-manager 组件，调用各大云厂商的 Cloud Provider API（如 AWS EC2、Azure、GCP、阿里云、腾讯云），实现对云资源的自动化管理，包括：节点生命周期、负载均衡、网络路由、云存储卷等。

1.2 命令行工具

工具	作用
kubeadm	集群初始化和管理工具。`kubeadm init` 初始化 Master，`kubeadm join` 让 Worker 加入集群。
kubectl	K8s 命令行客户端，通过调用 kube-api-server 管理集群中各类资源。

1.3 资源 Resource

Resource（资源） 是 Kubernetes 中所有可被管理的对象，K8s 遵循万物皆资源的设计思想。我们可以通过 命令行 或 YAML/JSON 配置文件 声明资源的期望状态，集群会自动完成状态调和，让实际状态与期望状态保持一致。

资源的分类

命名空间资源（Namespaced Resource）：归属于某个 Namespace，用于隔离资源。常见的命名空间资源：Pod、Deployment、StatefulSet、DaemonSet、ReplicaSet、Job / CronJob、Service、ConfigMap、Secret、PersistentVolumeClaim (PVC)、Ingress

集群资源（Cluster-scoped Resource）：不属于任何 Namespace，全局唯一。常见的集群资源：Node、Namespace、PersistentVolume (PV)、StorageClass

资源的声明方式

命令行：直接使用 kubectl 命令创建/删除资源，适合调试和临时操作。

kubectl run nginx --image=nginx
kubectl expose pod nginx --port=80

资源文件：预先编写 YAML/JSON 文件，通过 kubectl apply -f 执行。

编写资源文件 myPod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      ports:
        - containerPort: 80

执行资源文件：

kubectl apply -f myPod.yaml

二、资源详解

2.1 工作负载类资源（Workload Resources）

Pod

Pod 是 Kubernetes 中最小的部署与调度单元。一个 Pod 可包含单个或多个容器，同一 Pod 内的容器共享网络命名空间（共用同一个 IP 与端口空间）和存储卷。Pod 属于命名空间级资源。

Pod 是 临时性 的，且本身不具备自愈能力。实际生产环境中，一般不会直接创建 Pod，而是借助 Deployment、StatefulSet 等上层控制器进行统一管理。

ReplicaSet

ReplicaSet 用于保证集群中始终运行指定数量的 Pod 副本。当 Pod 被删除、异常崩溃时，ReplicaSet 会自动创建新 Pod 完成替换，维持副本数稳定。ReplicaSet 属于命名空间级资源。

实际生产环境中，一般不会直接创建ReplicaSet，而是借助 Deployment 间接管理，极少单独使用。

Deployment

Deployment 是主流无状态应用控制器，通过管理 ReplicaSet 间接控制 Pod，具备滚动更新、版本回滚、副本扩缩容能力，属于命名空间级资源，是生产环境使用频率最高的工作负载资源。

无状态应用：应用自身不持久化本地数据，如：静态资源服务、API 网关，业务服务等。

滚动更新：升级应用时采用分批替换策略，新旧 Pod 短暂共存，逐步完成全量更新，实现服务零停机发布。

StatefulSet

StatefulSet 专门用于管理有状态应用，典型场景包括 MySQL、ZooKeeper、Kafka、Redis 集群等。属于命名空间级资源。

相较于 Deployment，它具备两大核心能力：

稳定网络标识：Pod 拥有有序、固定的主机名与域名，集群节点间可稳定互相访问；
独立持久化存储：每个 Pod 绑定专属存储卷，Pod 删除重建后依旧挂载原有数据卷，数据不会丢失。

有状态应用：Pod 具备唯一性，运行状态、本地数据、集群角色均与 Pod 强绑定，Pod 之间无法等价替换。这类应用对启动顺序、网络地址、数据持久性都有严格要求。

DaemonSet

DaemonSet 保证集群中每个节点或指定节点上仅运行一个 Pod 副本。当新节点加入集群时，会自动创建对应 Pod；节点下线移除时，也会自动清理关联 Pod，属于命名空间级资源。

经典场景：日志采集、节点监控、网络插件（Calico、Cilium 的 Agent）

Job / CronJob

Job：用于运行一次性任务，属于命名空间级资源。任务异常时会有限次数重试。常用于批处理、数据迁移、一次性脚本执行等场景。

CronJob: 基于标准 cron 表达式，定时创建并执行 Job，属于命名空间级资源。继承 Job 的重试规则，支持自定义执行周期。常用于定时数据备份、日志清理、定期报表生成、周期性运维任务。

2.2 服务发现与负载均衡类资源（Networking Resources）

Service

为一组 Pod 提供固定访问入口，实现服务发现与负载均衡，屏蔽 Pod IP 动态变化的问题，属于命名空间级资源。可根据业务选择不同类型，适配集群内部通信、外部访问等场景。

Service 类型：

ClusterIP（默认）：仅集群内部可访问，用于服务间互相调用，是最常用类型。
NodePort：开放节点端口，外部可通过「节点 IP + 端口」访问服务。
LoadBalancer：依托云厂商负载均衡器，依赖cloud-controller-manager。
ExternalName：将集群内服务映射到集群外部的第三方服务地址。

Ingress

Ingress 提供集群外部 HTTP/HTTPS 访问入口，实现基于域名、路径的路由转发与负载均衡，统一管理外部访问规则。必须依赖 Ingress Controller 才能生效，属于命名空间级资源。

通常和 Service 搭配使用，Service 提供集群内部固定访问入口，属于四层流量转发；Ingress 提供统一的外部 HTTP/HTTPS 入口，基于域名和路径路由到后端 Service，实现多服务共用一个访问入口，是生产环境外部访问的标准方式。

2.3 存储类资源（Storage Resources）

PersistentVolume (PV)

PV 由管理员预先配置，代表一块真实的存储空间（如云盘、NFS、Ceph）。用于持久化保存数据，Pod 删除后数据依然存在，独立于 Pod 生命周期之外。属于集群资源，非命名空间资源。

访问模式：

ReadWriteOnce（RWO）：只能被一个节点挂载读写。
ReadOnlyMany（ROX）：可以被多个节点同时读，但不能写。适合静态资源、配置文件共享。
ReadWriteMany（RWX）：可以被多个节点同时挂载读写。

PersistentVolumeClaim (PVC)

PVC 是用户/业务向集群申请存储的凭证。只需声明需要的存储大小、访问模式，系统会自动匹配符合条件的 PV 并绑定，Pod 通过挂载 PVC 使用持久化存储。属于命名空间资源。

PV 和 PVC 的关系：

管理员预先设置 → PV（物理存储设备）
用户/业务申请使用  → PVC（存储申请） → 匹配 PV → Pod 使用 PVC

StorageClass

StorageClass 集群级资源，用于实现动态供给 PV。无需管理员提前创建 PV，PVC 发起存储申请时，会通过它自动创建并绑定 PV，简化存储运维，是生产环境主流方案。属于集群资源，非命名空间资源。

可对接不同存储后端（云盘、Ceph、NFS 等），也能划分存储类型（高速盘、普通盘）。

2.4 配置与安全类资源（Config & Security Resources）

ConfigMap

ConfigMap 用于存储非敏感的配置信息（如配置文件、环境变量、启动参数），然后将配置数据注入到 Pod 中，让配置和容器分离，方便修改、统一管理。属于命名空间级资源。

Secret

Secret 专门存储敏感数据，如密码、密钥、令牌、证书等。数据以 Base64 编码存储（非加密，仅简单防明文展示），属于命名空间级资源。相比 ConfigMap 安全性更高，用于保护隐私信息。

三、调度

3.1 什么是调度

调度是将 Pod 分配给合适的 Worker 节点的过程，由 kube-scheduler 完成。调度策略在资源文件中配置即可。

调度流程：

Pod 创建（未调度状态，nodeName 为空）。
kube-scheduler 通过 过滤（Predicates / Filtering） 选出符合条件的节点。
再通过 打分（Priorities / Scoring） 选出最优节点。
将 Pod 绑定到该节点（写入 spec.nodeName）。
该节点的 kubelet 收到通知，通过 CRI 创建容器。

3.2 调度策略

nodeSelector

最简单的节点选择器，通过节点标签精准匹配，Pod 只调度到带指定标签的节点。

nodeAffinity

节点亲和性选择器。支持丰富运算符（In、NotIn、Exists、DoesNotExist、Gt、Lt），分硬性规则（必须满足）和软性偏好（尽量满足）。生产环境中常用。

podAffinity

Pod 亲和性选择器。让当前 Pod 和指定 Pod 调度到同一区域 / 节点。用于关联应用部署在一起，提升访问效率。

podAntiAffinity

Pod 反亲和性选择器。让当前 Pod 不和指定 Pod 部署在同一区域 / 节点。用于打散副本、避免单点故障，实现高可用。

Taints & Tolerations

Taints（污点）：给节点设置的排斥规则，没有对应容忍的 Pod 绝对不能调度到该节点。
Tolerations（容忍）：在 Pod 上设置可以容忍的污点，当节点的污点和容忍的污点相同时，可以在该节点上创建。

四、Pod 生命周期与探针

4.1 生命周期

Pod 状态流转：

Pending → Running → Succeeded / Failed
              ↓
          Unknown

状态	说明
Pending	Pod 已提交，但尚未被调度，或正在拉取镜像。
Running	Pod 已调度到节点上，容器至少有一个在运行。
Succeeded	Pod 中的所有容器正常退出（退出码 0）。
Failed	Pod 中至少一个容器以非 0 退出码退出。
Unknown	API Server 无法获取 Pod 状态（通常是节点故障或网络问题）。

容器重启策略（restartPolicy）：

Always：始终重启（默认）。
OnFailure：仅失败时重启。
Never：从不重启。

4.2 探针（Probes）

探针是 kubelet 定期对容器执行的健康检查。

三种探测方式：

方式	说明
HTTP GET	向容器的指定路径发送 HTTP GET 请求，2xx/3xx 表示健康。
TCP Socket	尝试连接容器的指定 TCP 端口，连接成功表示健康。
Exec Command	在容器内执行命令，退出码 0 表示健康。

livenessProbe（存活探针）

判断容器是否还活着。如果探测失败，kubelet 会根据重启策略判断是否重启容器。

readinessProbe（就绪探针）

判断容器是否准备好接收流量。如果探测失败，Service 会将该 Pod 从 Endpoint 列表移除。

startupProbe（启动探针）

判断容器是否已完成启动。用于启动缓慢的容器（如 Java 应用）。探测成功前，livenessProbe 和 readinessProbe 不会启动。

三种探针的适用场景对比：

探针	失败后果	典型用途
livenessProbe	重启容器	检测死锁、内存泄漏导致的僵死
readinessProbe	从 Service 移除	控制流量接入（应用启动慢、需要加载数据）
startupProbe	重启容器	启动极慢的应用（Java JVM、Legacy App）

五、组件协作流程（以 Deployment 为例）

1. 用户执行 kubectl apply -f deployment.yaml
                        │
                        ▼
2. kube-api-server ──► etcd（保存 Deployment 对象）
   ◄── 返回成功
                        │
                        ▼
3. kube-controller-manager 中的 Deployment Controller
   检测到新的 Deployment 资源
   └── 创建对应的 ReplicaSet 对象（写入 api-server → etcd）
                        │
                        ▼
4. ReplicaSet Controller（也是 kube-controller-manager 中的一部分）
   检测到新 ReplicaSet，发现期望副本数为 3
   └── 创建 3 个 Pod 对象（写入 api-server → etcd）
                        │
                        ▼
5. Pod 状态为 Pending（未调度，spec.nodeName 为空）
                        │
                        ▼
6. kube-scheduler
   └── 通过 Filtering + Scoring 选出最优 Worker 节点
   └── 通过 api-server 将 nodeName 写入 Pod spec
                        │
                        ▼
7. 选中节点的 kubelet（通过 API Server Watch 机制检测到 Pod 分配）
                        │
                        ▼
8. kubelet 调用 CRI（containerd）
   └── 拉取镜像 ──► 创建容器 ──► 启动容器
                        │
                        ▼
9. kubelet 调用 CNI（Calico/Cilium 等）
   └── 为 Pod 分配 IP ──► 配置网络
                        │
                        ▼
10. kubelet 配置 Pod 中声明的 Volume
                         │
                         ▼
11. kubelet 启动探针检查（如果声明了 probe）
    └── readinessProbe 成功后，Pod 变为 Ready
                         │
                         ▼
12. kube-proxy 检测到新 Pod 就绪
    └── 更新节点上的 iptables/IPVS 规则
    └── Service 将流量路由到此 Pod

完整链路总结：

kubectl → API Server → etcd
  → Controller Manager (Deployment → ReplicaSet → Pod)
  → Scheduler (绑定 Node)
  → kubelet (调用 CRI + CNI 创建 Pod)
  → kube-proxy (更新网络规则)