Kubernetes（K8s）系统学习指南

zfqzfx

610人浏览 · 2026-03-16 11:14:11

zfqzfx · 2026-03-16 11:14:11 发布

一、什么是 Kubernetes？

K8s 是 Google 开源的容器编排平台，解决 Docker 在多机器、大规模场景下的管理难题。

Docker vs K8s 核心能力对比：

能力	Docker（单机）	Kubernetes（集群）
容器管理	手动 `docker run`	声明式，自动调度
故障恢复	手动重启	自动故障自愈
扩缩容	手动 `--scale`	自动水平扩缩容（HPA）
多机器	不支持	原生多节点集群
服务发现	手动配置	内置 DNS + Service
滚动更新	手动操作	原生支持，零停机
负载均衡	需要外部工具	Service 内置
配置管理	环境变量 / 文件	ConfigMap / Secret

二、整体架构

K8s 集群由两种角色组成：Control Plane（控制面） 和 Worker Node（工作节点）。

在这里插入图片描述

kubectl ──→ Control Plane                    Worker Node
             ┌──────────────────┐            ┌──────────────────────┐
             │ API Server       │ ──────────→ │ kubelet              │
             │ etcd             │            │ kube-proxy            │
             │ Scheduler        │            │ Container Runtime     │
             │ Controller Mgr   │            │  Pod  Pod  Pod        │
             └──────────────────┘            └──────────────────────┘
                                              Worker Node（多个）
                                              ┌──────────────────────┐
                                              │ kubelet / kube-proxy  │
                                              │  Pod  Pod  Pod        │
                                              └──────────────────────┘

Control Plane 四大组件：

API Server：集群唯一入口，所有操作都通过它，负责鉴权、验证、持久化到 etcd
etcd：分布式 KV 数据库，存储集群所有状态，是最关键的组件（挂了就全挂）
Scheduler：监听未调度的 Pod，根据资源、亲和性等策略决定调度到哪个 Node
Controller Manager：持续对比实际状态和期望状态，负责"补差"——Pod 挂了自动重建

Worker Node 三大组件：

kubelet：每个节点的"代理"，负责管理本节点所有 Pod 的生命周期
kube-proxy：维护节点网络规则，实现 Service 的负载均衡转发
Container Runtime：实际运行容器的引擎，如 containerd、CRI-O

三、核心资源对象

K8s 用"资源对象"描述一切，所有资源都通过 YAML 文件声明。
在这里插入图片描述

Deployment（管理无状态应用）
    │ 创建和管理
    ↓
ReplicaSet（维持 Pod 副本数）
    │ 创建
    ├──→ Pod（容器 A，共享网络/存储）
    ├──→ Pod（容器 B，共享网络/存储）
    └──→ Pod（容器 C，共享网络/存储）
              ↑ Label Selector 关联
Service（统一暴露入口，稳定 IP + DNS）

核心资源速查表：

资源	作用	典型用途
`Pod`	最小调度单位，封装容器	极少直接使用，通过上层资源管理
`Deployment`	管理无状态应用副本	Web 服务、API 服务
`StatefulSet`	管理有状态应用，Pod 有固定标识	数据库、消息队列
`DaemonSet`	每个 Node 运行一个 Pod	日志收集、监控 Agent
`Job`	一次性任务，完成即退出	数据迁移、批处理
`CronJob`	定时任务	定时备份、清理
`Service`	为一组 Pod 提供稳定访问入口	所有需要被访问的服务
`Ingress`	HTTP/HTTPS 路由规则	对外暴露 HTTP 服务
`ConfigMap`	存储非敏感配置	应用配置文件
`Secret`	存储敏感数据	密码、Token、证书
`PersistentVolume`	集群存储资源	持久化存储
`PersistentVolumeClaim`	申请存储资源	Pod 挂载持久化存储
`Namespace`	集群资源隔离	多环境、多团队隔离
`HorizontalPodAutoscaler`	自动水平扩缩容	根据 CPU/内存自动扩容

四、Pod 调度流程

当执行 kubectl apply -f deployment.yaml，背后发生了什么：

在这里插入图片描述

kubectl apply
    │
    ↓
API Server（①鉴权验证 ②写入 etcd）
    │
    ↓ Controller Manager 监听到新 Deployment
    ↓ 创建 ReplicaSet → 创建 Pod（状态：Pending）
    │
    ↓ Scheduler 监听到 Pending 的 Pod
    ↓ 过滤不满足条件的 Node（资源不足、污点等）
    ↓ 对满足条件的 Node 打分，选出最优
    ↓ 将 Pod 绑定到目标 Node（写入 etcd）
    │
    ↓ 目标 Node 的 kubelet 监听到 Pod 绑定事件
    ↓ 调用 Container Runtime 拉取镜像
    ↓ 启动容器，执行健康检查
    │
    ↓ Pod 状态变为 Running
    ↓ kube-proxy 更新路由规则
    ↓ Service 开始将流量转发到新 Pod

关键设计： 所有组件通过 Watch etcd 异步驱动，互相解耦。API Server 不主动推送，各组件自己监听感兴趣的事件变化。

五、Service 网络与服务发现

在这里插入图片描述

5.1 Service 类型

ClusterIP（默认）           NodePort                LoadBalancer
─────────────────          ──────────────          ────────────────────
仅集群内部访问              暴露到 Node 端口          云厂商创建外部负载均衡
Pod ← Service              NodeIP:30080             公网 IP → NodePort
内部 DNS 解析               → Service → Pod          → ClusterIP → Pod
适合：内部服务互访           端口范围 30000-32767     适合：生产对外暴露
如 db / cache              适合：开发测试             AWS/GCP/阿里云等

5.2 服务发现

同一 Namespace 内，可以直接用服务名访问：

# web 服务连接 mysql 服务
DB_HOST: mysql          # 直接用 Service 名
DB_PORT: "3306"

# 跨 Namespace 访问
DB_HOST: mysql.production.svc.cluster.local

DNS 格式：<service-name>.<namespace>.svc.cluster.local

5.3 Endpoints

Service 通过 Label Selector 动态关联 Pod，当 Pod 创建/销毁时，Endpoints 自动更新：

# Service 选择带 app=web 标签的所有 Pod
selector:
  app: web

六、常用 YAML 配置详解

6.1 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: production
  labels:
    app: web
spec:
  replicas: 3                          # 期望副本数
  selector:
    matchLabels:
      app: web                         # 关联带此标签的 Pod
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                      # 更新时最多多出 1 个 Pod
      maxUnavailable: 0                # 更新时不允许有不可用的 Pod
  template:                           # Pod 模板
    metadata:
      labels:
        app: web                      # Pod 标签，必须匹配 selector
    spec:
      containers:
        - name: web
          image: myapp:v1.2.3         # 生产环境用明确版本
          ports:
            - containerPort: 3000
          env:
            - name: NODE_ENV
              value: production
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:         # 从 Secret 读取密码
                  name: db-secret
                  key: password
          resources:
            requests:
              cpu: "100m"             # 调度依据（1核=1000m）
              memory: "128Mi"
            limits:
              cpu: "500m"             # 上限，超出被限速/OOM
              memory: "512Mi"
          livenessProbe:              # 存活探针：失败则重启容器
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:             # 就绪探针：失败则从 Service 移除
            httpGet:
              path: /ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5
      imagePullSecrets:
        - name: registry-secret      # 拉取私有镜像的凭证

6.2 Service

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: production
spec:
  selector:
    app: web                         # 关联 Pod
  ports:
    - protocol: TCP
      port: 80                       # Service 端口
      targetPort: 3000               # 转发到 Pod 的端口
  type: ClusterIP                    # 默认，仅集群内访问

6.3 两种探针的区别

	`livenessProbe`	`readinessProbe`
失败后动作	重启容器	从 Service 摘除（不重启）
用途	检测容器是否卡死	检测容器是否准备好接流量
典型场景	进程死锁、内存泄漏	启动初始化、依赖连接中

七、滚动更新与自愈机制

这是 K8s 最核心的生产价值——零停机更新和自动故障恢复：

在这里插入图片描述

滚动更新策略由 maxSurge（最多多出几个新 Pod）和 maxUnavailable（最多几个不可用）控制，保证全程至少有一定数量的 Pod 在提供服务。更新过程中如果新 Pod 健康检查失败，K8s 会自动暂停更新，执行 kubectl rollout undo 即可一键回滚。

7.1 滚动更新过程

更新前：[Pod v1] [Pod v1] [Pod v1]
             ↓ kubectl set image / kubectl apply
滚动中：[Pod v2] [Pod v1] [Pod v1] [Pod v1-终止]
             ↓ 新 Pod 就绪后再替换下一个
滚动中：[Pod v2] [Pod v2] [Pod v1]
             ↓
更新完：[Pod v2] [Pod v2] [Pod v2]
全程服务可用，不会有全部下线的瞬间

# 更新镜像（触发滚动更新）
kubectl set image deployment/web web=myapp:v1.3.0

# 查看更新状态
kubectl rollout status deployment/web

# 查看更新历史
kubectl rollout history deployment/web

# 回滚到上一版本
kubectl rollout undo deployment/web

# 回滚到指定版本
kubectl rollout undo deployment/web --to-revision=2

7.2 自愈机制

K8s 的 Controller Manager 持续运行"协调循环"：

期望状态（etcd 里的声明）：replicas=3
实际状态（集群中运行的）：replicas=2（有一个 Pod 崩溃）
         ↓ Controller 检测到差距
         ↓ 自动创建新 Pod 补充到 3 个
         ↓ 重新满足期望状态

健康检查触发自愈：

livenessProbe 失败 → kubelet 重启容器
Node 宕机 → Controller 在其他 Node 重建 Pod
Pod 被手动删除 → ReplicaSet 立即补充新 Pod

八、存储：PV / PVC / StorageClass

在这里插入图片描述

8.1 概念关系

Pod ──→ PVC（我需要 10Gi 可读写存储）
              │ 绑定
              ↓
             PV（实际的存储资源）
              │
              ↓
         存储后端（NFS / 云盘 / Ceph）

StorageClass（动态供应）
PVC 创建时自动创建对应的 PV，无需手动预先创建

PVC 解耦了应用和存储实现：换存储后端（如从 NFS 迁移到云盘）不需要修改 Pod 配置。

8.2 PVC 示例

# 申请存储
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes:
    - ReadWriteOnce           # RWO：只能被一个 Node 挂载
  storageClassName: fast-ssd  # 使用哪个 StorageClass
  resources:
    requests:
      storage: 10Gi

# 在 Pod 中使用
volumes:
  - name: data
    persistentVolumeClaim:
      claimName: mysql-data
containers:
  - volumeMounts:
      - mountPath: /var/lib/mysql
        name: data

Access Mode 类型：

模式	简称	说明
`ReadWriteOnce`	RWO	一个 Node 读写（最常用）
`ReadOnlyMany`	ROX	多个 Node 只读
`ReadWriteMany`	RWX	多个 Node 读写（需要 NFS/Ceph 支持）

九、Ingress —— 统一流量入口

Ingress 提供 HTTP/HTTPS 层的路由，一个 Ingress 替代多个 LoadBalancer，节省云资源成本。
在这里插入图片描述

外部 HTTPS :443
      │
      ↓
Ingress Controller（nginx / Traefik）
TLS 终止 + 路由规则匹配
      │
      ├── /api/*  ──→ api-service（ClusterIP）──→ Pods
      ├── /       ──→ web-service（ClusterIP）──→ Pods
      └── /static ──→ static-service（ClusterIP）──→ Pods

Ingress YAML 示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/cluster-issuer: letsencrypt-prod  # 自动申请 SSL 证书
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - myapp.example.com
      secretName: myapp-tls          # TLS 证书存在 Secret 里
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 3000

十、配置与密钥管理

10.1 ConfigMap —— 非敏感配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  NODE_ENV: production
  LOG_LEVEL: info
  config.json: |                     # 可以存整个配置文件
    {
      "timeout": 30,
      "maxRetries": 3
    }

在 Pod 中使用 ConfigMap：

# 方式一：作为环境变量
envFrom:
  - configMapRef:
      name: app-config

# 方式二：挂载为文件
volumes:
  - name: config
    configMap:
      name: app-config
containers:
  - volumeMounts:
      - mountPath: /app/config
        name: config

10.2 Secret —— 敏感数据

# 创建 Secret（自动 base64 编码）
kubectl create secret generic db-secret \
  --from-literal=password=mysecretpassword \
  --from-literal=username=admin

# 从文件创建（如 TLS 证书）
kubectl create secret tls myapp-tls \
  --cert=tls.crt \
  --key=tls.key

# 在 Pod 中使用 Secret
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

注意：Secret 只是 base64 编码，不是加密。生产环境推荐使用 Sealed Secrets 或外部密钥管理系统（Vault、AWS Secrets Manager）。

十一、自动扩缩容（HPA）

HPA（HorizontalPodAutoscaler）根据 CPU/内存指标自动调整 Pod 副本数。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2                     # 最少副本数
  maxReplicas: 10                    # 最多副本数
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70     # CPU 超过 70% 时扩容
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

扩缩容逻辑：

当前 CPU 使用率 > 70%  →  扩容（增加 Pod）
当前 CPU 使用率 < 70%  →  缩容（减少 Pod，不低于 minReplicas）
扩容冷却：默认 3 分钟
缩容冷却：默认 5 分钟（避免频繁抖动）

十二、常用命令速查

集群信息

kubectl cluster-info              # 查看集群信息
kubectl get nodes                 # 查看节点列表
kubectl describe node <node-name> # 节点详情（资源使用情况）
kubectl top nodes                 # 节点 CPU/内存使用

资源管理

# 创建/更新资源
kubectl apply -f deployment.yaml
kubectl apply -f ./k8s/           # 应用整个目录

# 查看资源
kubectl get pods                  # 查看 Pod
kubectl get pods -n production    # 指定 Namespace
kubectl get pods -o wide          # 显示节点信息
kubectl get all                   # 查看所有资源

# 详情
kubectl describe pod <pod-name>   # Pod 详情（含事件，排查问题必备）
kubectl describe deployment web

# 删除
kubectl delete -f deployment.yaml
kubectl delete pod <pod-name>

调试排查

# 查看日志
kubectl logs <pod-name>
kubectl logs -f <pod-name>        # 实时跟踪
kubectl logs <pod-name> -c <container-name>  # 多容器 Pod 指定容器

# 进入容器
kubectl exec -it <pod-name> -- bash
kubectl exec -it <pod-name> -c <container> -- sh

# 端口转发（本地调试）
kubectl port-forward pod/<pod-name> 8080:3000
kubectl port-forward svc/web 8080:80

# 查看事件（排查调度失败等问题）
kubectl get events --sort-by='.lastTimestamp'

滚动更新

kubectl set image deployment/web web=myapp:v2
kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web

扩缩容

kubectl scale deployment web --replicas=5
kubectl autoscale deployment web --min=2 --max=10 --cpu-percent=70

十三、学习路径建议

阶段	目标	关键内容
阶段 1 · 入门	本地跑起第一个应用	minikube / kind 安装，kubectl 基本命令，Deployment + Service
阶段 2 · 核心对象	掌握常用资源	ConfigMap / Secret / PVC / Ingress / HPA
阶段 3 · 生产实践	生产环境配置	健康检查、资源限制、滚动更新、命名空间隔离
阶段 4 · 监控运维	可观测性	Prometheus + Grafana，日志收集（EFK/Loki）
阶段 5 · 进阶	深入机制	RBAC 权限、NetworkPolicy、Operator 模式、Helm

推荐本地环境：

# minikube（最简单）
brew install minikube
minikube start
kubectl get nodes

# kind（用 Docker 模拟多节点）
brew install kind
kind create cluster --config multi-node.yaml

推荐资源：