从零入门Kubernetes（三节学习笔记）：核心对象、持久化存储与网络基础

本文作者：yanghuajun336
更新时间：2025-12-31

本篇笔记适合Kubernetes入门和有一定实战经验的提升者，内容涵盖核心K8s资源对象（Deployment、StatefulSet等）、持久化卷存储机制、以及Service/Pod/Ingress的网络通信和基础安全要点。

第一章：K8s核心对象进阶——Deployment、StatefulSet、DaemonSet

1. Pod

1.1 概念

  • Pod是Kubernetes中最小的可调度单元
  • 通常包含一个（或极少数几个）高度耦合的容器

1.2 作用与使用场景

  • 跑临时、一次性任务
  • 需要多个协作容器（如主应用+sidecar）
  • 演示实验性容器运行

1.3 示例 YAML

1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

1.4 总结

手动管理Pod很少见，通常用更高级的控制器来管理“Pod副本”的生命周期。

2. Deployment

2.1 概念

  • Deployment 是最常见的无状态应用控制器
  • 管理Pod的副本数、滚动升级、自动重建失败实例

2.2 作用与使用场景

  • 部署Web服务/微服务等无状态应用
  • 轻松水平扩展与升级

2.3 示例 YAML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx:1.25
        ports:
        - containerPort: 80

2.4 升级/Rollback/扩缩容

1
2
3
4
kubectl scale deployment myapp --replicas=5
kubectl rollout restart deployment myapp
kubectl rollout history deployment myapp
kubectl rollout undo deployment myapp

2.5 总结

日常部署无状态服务，几乎都建议用Deployment。

3. StatefulSet

3.1 概念

  • 管理有状态应用（如数据库、Zookeeper）
  • Pod有固定名字、有序启动、唯一存储挂载

3.2 作用与使用场景

  • 需要稳定身份和顺序启动的服务
  • 每个Pod需要独立持久化数据（如MySQL主从、ES分片）

3.3 示例 YAML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql-headless
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

3.4 特点

  • Pod名字如：mysql-0、mysql-1、mysql-2
  • 每个Pod和PVC是一一对应的

4. DaemonSet

4.1 概念

  • 每个（或每类）节点上各运行一个Pod
  • 适合运行守护进程（如日志收集、监控Agent、CNI组件）

4.2 作用与使用场景

  • 节点级Agent（如Prometheus Node Exporter、filebeat、fluentd、calico、CNI）
  • 系统级任务，每加节点自动补1个Pod

4.3 示例 YAML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: exporter
        image: prom/node-exporter
        ports:
        - containerPort: 9100

5. Job 与 CronJob

5.1 Job

  • 用于一次性任务，Pod跑完即销毁（如批处理、迁移脚本）
1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: batch/v1
kind: Job
metadata:
  name: hello-job
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["echo",  "hello"]
      restartPolicy: Never

5.2 CronJob

  • 定时执行Job（类比Linux crontab）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

总结对比表

控制器 适用场景 最大特色
Pod 演示/调试/一次性 最原始，少用，手动管理生命周期
Deployment 无状态服务 滚动升级，扩缩容自动化
StatefulSet 有状态服务 固定Pod身份，专用持久存储
DaemonSet 节点级全局服务 每节点1份，自动补齐
Job 一次性批处理任务 完成即销毁，支持重复
CronJob 定时批处理任务 定时执行，有历史Job管理

第二章：Kubernetes 存储与数据持久化

目录

  1. 存储核心概念总览
  2. PV/PVC 基本用法与场景
  3. StorageClass 动态/静态供应机制
  4. 常见存储方案实践（NFS/HostPath/云盘等）
  5. 存储实战排障和最佳实践

1. 核心概念总览

Kubernetes 不是传统的“单机→挂盘→自动用”模式，而是通过分离“存储声明”（PV）与“应用请求”（PVC），让存储能灵活复用、调度和迁移。

  • PV (PersistentVolume)
    集群管理员预先创建好的“磁盘”（存储资源），声明可以被Pod使用。

  • PVC (PersistentVolumeClaim)
    开发者/用户提交的“我要一个多大、多快、多类型盘”的请求，由 K8s 自动绑定可用 PV。

  • StorageClass
    描述存储类型、性能、供应策略等，配合动态供应器让 K8s 实时创建/删除物理存储。

2. PV/PVC 基本用法举例

场景：一个有状态 App —— MySQL 需要持久保存数据

步骤一：集群管理员创建 PV（静态供应方式）

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce   # 单节点挂载（比如本地盘）
  persistentVolumeReclaimPolicy: Retain
  hostPath:    # Demo环境用，生产需用云盘/NFS等
    path: /mnt/data/mysql

步骤二：业务方声明 PVC（开发者无需关心物理盘）

1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

步骤三：在应用里挂载 PVC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: mysql-pvc

关系链：“我的容器要 data → data 挂载了 PVC → PVC 匹配到了 PV”

3. StorageClass 与动态供应

大部分生产环境（尤其云原生和大集群）不会一个个写 PV，而是“先创建好 StorageClass”，开发者声明 PVC 时自动帮你分配并创建后端存储盘，Pod 销毁，盘可以自动/按需回收。

StorageClass 示例（NFS客户端）

1
2
3
4
5
6
7
8
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: nfs-client
parameters:
  archiveOnDelete: "false"
reclaimPolicy: Retain

使用方式

1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myapp-pvc
spec:
  storageClassName: nfs-client
  accessModes:
    - ReadWriteMany    # NFS支持多Pod多节点同时读写
  resources:
    requests:
      storage: 20Gi

这个 PVC 被创建后，NFS provisioner（或云厂商供应器）帮你自动生成 PV 并绑定。

4. 常见存储方案实践

HostPath（本地盘，测试用）

1
2
hostPath:
  path: /mnt/data/mydemo
  • 特点：节点死了，数据也丢了；只适合测试开发。
  • 不建议生产环境用！

NFS（网络文件系统）

  • 自建 NFS Server 或企业 NAS，适合小中型环境共享数据、多Pod挂载。
  • 需要部署 NFS provisioner 当 StorageClass 动态供应器。

云存储（推荐生产）

  • 如阿里云/腾讯云/华为云/Google/AWS 的云盘存储类产品（csi/cinder/ebs）。
  • 配合云厂商 CSI 插件，创建 StorageClass 自动供应高可用存储盘。

Ceph / GlusterFS / MooseFS

  • 分布式存储，适合弹性高可用和多副本自管理场景。

5. 存储排障与最佳实践

常见问题

  • PVC Pending（大概率是 StorageClass 未配置或存储驱动问题）
  • 容器重建丢数据（通常未正确挂载PVC）
  • 数据漂移、不一致（尝试用本地盘做多节点挂载）

最佳实践

  • 生产环境强烈推荐使用 StorageClass 自动供应（避免手动PV易出错）
  • 给每个有状态App单独分配PVC，且带独立 StorageClass/性能（如SSD/HDD）
  • PV 的回收策略优先用 Retain，手工清理（防止误删持久盘）

总结

  • 无状态部署用 emptyDir 即可，有状态服务要坚持用 PVC→PV→StorageClass 组合
  • 能用动态存储，就坚决不要用静态 PV
  • 数据宝贵？选云盘/高可用分布式存储/NFS供给
    非常棒！我们现在进入第三章：《Kubernetes 网络与安全基础》。

第三章：Kubernetes 网络与安全基础

目录

  1. K8s 网络模型与 Service 详解
  2. Pod IP、Service IP、DNS 机制
  3. CNI 插件（如 Flannel/Calico）简介
  4. Ingress 网关与公网暴露
  5. 基础安全：ServiceAccount、Secret、NetworkPolicy

1. Kubernetes 网络模型与 Service 详解

1.1 Pod 网络

  • 每个 Pod 都拥有全局唯一的 IP（Pod IP）
    • 不同 Node 的 Pod 之间可以直接用 IP 通信（理论同一扁平网段）
    • 由“CNI 插件”实现（比如 Flannel、Calico）
  • 节点和 Pod 也能互相访问

1.2 Service：虚拟集群访问入口

为什么要有Service？

  • Pod 的 IP 会随着重建而变化
  • 需要一种抽象，帮我们生成“稳定访问入口+负载均衡”

常见 Service 类型

  • ClusterIP: 默认，仅集群内可访问，内部负载均衡（如后端DB访问）
  • NodePort: 每个节点开放端口，可通过NodeIP:Port访问（测试、小规模实验室适用）
  • LoadBalancer: 云厂商环境常用，自动分配公网负载均衡器IP（如阿里云SLB、AWS ELB）
  • Headless Service: 不分配 ClusterIP，Pod间直连（常用于 StatefulSet 服务发现）

YAML 示例

1
2
3
4
5
6
7
8
9
10
11
12
# ClusterIP 示例
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

2. Pod IP、Service IP、DNS 机制

  • K8s 集群会为 Service 自动分配“Service ClusterIP”（比如 10.96.0.1），所有请求由 kube-proxy/nftables 透明转发到某个后端Pod。
  • 所有Pod自动带有 nameserver（kubedns/coredns），支持 Service 地址名直连：myapp-svc.default.svc.cluster.local
  • 业务端代码里建议用域名访问 Service，而不是 Pod IP，更耐升级换代。
  • Headless Service（clusterIP: None）+ StatefulSet 场景能让每个 Pod 用“独立DNS名”被其它Pod精确寻址（如：mysql-1.mysql-headless.default.svc.cluster.local）

3. CNI 插件简介

  • K8s 默认不提供网络实现，必须依赖 CNI 插件（Container Network Interface）。
  • 常见插件：
    • Flannel：小型集群、实现简单、兼容性好
    • Calico：支持网络策略（NetworkPolicy）、可公网/私网直连
    • Cilium：高性能、支持BPF、易运维和安全
  • 插件决定哪些网段分配给Pod，节点间如何转发等

4. Ingress 网关和公网暴露

  • Ingress 作用：集群出口流量入口控制器，统一http/https流量，基于域名/路径/证书做路由、证书管理、认证等。
  • 常见 Controller
    • nginx-ingress-controller（最主流）、traefik、Istio IngressGateway
  • 例子场景：多个服务统一暴露 80/443，集群内部通过 Service 按需“反向代理”。

Ingress YAML 示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app
spec:
  rules:
    - host: myblog.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: blog
                port:
                  number: 80

5. 安全基础：ServiceAccount、Secret、NetworkPolicy

5.1 ServiceAccount

  • Pod 运行的“身份”，用于K8s API鉴权授权，详见前述RBAC章节。

5.2 Secret

  • K8s原生的敏感数据管理方案，支持base64加密（但不是强加密）。
1
2
3
4
5
6
7
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  db_pass: YmFzZTY0cGFzc3dvcmQ=    # base64('base64password')
  • 可以挂载为环境变量或文件

5.3 NetworkPolicy

  • 可限制Pod之间/Namespace之间/指定端口/协议的数据访问，默认所有Pod相互可达
  • 配合Calico/Cilium等网络插件生效
1
2
3
4
5
6
7
8
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  • 实现最小访问、零信任网络架构

总结重点

模块 作用 常见实践
Service 对Pod的访问入口/负载均衡 内网互通/暴露端口
DNS 域名发现与服务解耦 固定写Service名
CNI 实现Pod通信与网络隔离/策略 Flannel/Calico/Cilium
Ingress 统一出口与协议层路由/证书/认证 80/443 反代
Secret 敏感数据安全存储 挂载/env/envFrom
NetworkPolicy 粒度级数据包/协议访问限制 开启默认拒绝，再白名单