Kubernetes 入门实战：从 Pod 到 Deployment 的完整指南

Kubernetes 已成为容器编排的事实标准。但"部署一个 Nginx"和"真正用好 K8s"之间，隔着对工作负载、网络、存储与声明式理念的系统理解。本文从最小概念出发，逐步构建起可用的集群应用。

一、为什么需要 Kubernetes

单机 Docker 解决的问题是"环境一致性"，K8s 解决的问题是规模化编排：

• 自动调度：容器该跑在哪台机器、内存不够如何驱逐；
• 自动伸缩：流量大了自动加副本，小了自动缩；
• 自动恢复：容器挂了自动重启，节点挂了自动迁移；
• 服务发现与负载均衡：天然集成 DNS 与反向代理。

核心思想是声明式：你描述"想要的最终状态"（Deployment 期望 3 个副本），控制器持续调谐，让现实逼近期望。

二、核心对象：从 Pod 到工作负载

2.1 Pod：最小调度单元

Pod 是一个或多个容器的组合，共享网络命名空间与存储卷。Pod 本身是"一次性"的——直接创建 Pod 无法享受自动恢复，所以几乎从不直接使用 Pod，而是通过工作负载控制器管理。

2.2 Deployment：无状态应用的标配

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v1.2.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi

关键配置解读：

• replicas: 3：期望副本数，滚动更新/故障恢复都以它为基准；
• readinessProbe（就绪探针）：就绪前不接入流量，滚动更新零中断；
• resources.requests/limits：requests 用于调度决策，limits 用于资源上限——不设 limits 的容器可能耗尽节点内存。

2.3 滚动更新与回滚

kubectl set image deployment/api-server api=registry.example.com/api:v1.3.0
kubectl rollout status deployment/api-server
kubectl rollout undo deployment/api-server   # 一键回滚到上一版本

三、Service 与网络模型

3.1 Service：稳定的访问入口

Pod 的 IP 是漂移的，Service 提供稳定的虚拟 IP 与 DNS 名称：

apiVersion: v1
kind: Service
metadata:
  name: api-svc
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

集群内其他服务可通过 api-svc:80 访问，DNS 自动解析到后端的 Pod 集合。

3.2 Ingress：对外暴露的统一网关

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

Ingress 控制器（Nginx Ingress / Traefik）负责把域名+路径路由到对应 Service，统一处理 TLS 与限流。

四、ConfigMap 与 Secret：配置分离

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  MAX_CONN: "100"

---
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:
  DB_PASSWORD: "s3cr3t"

# 在 Deployment 中引用
envFrom:
  - configMapRef: { name: app-config }
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef: { name: db-secret, key: DB_PASSWORD }

原则：镜像不可变，配置可注入。同样的镜像配合不同 ConfigMap 即可跑在不同环境。

五、存储：从 emptyDir 到 PVC

| 存储类型 | 生命周期 | 适用 | |----------|----------|------| | emptyDir | 随 Pod 生灭 | 临时缓存、日志中转 | | hostPath | 随节点 | 单节点调试 | | PersistentVolumeClaim | 独立于 Pod | 数据库等持久化数据 |

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 20Gi

六、常用运维命令速查

kubectl get pods -o wide                # 查看 Pod 与所在节点
kubectl logs -f pod/api-server-xxx      # 跟踪日志
kubectl exec -it pod/api-server-xxx -- sh   # 进入容器
kubectl describe pod api-server-xxx     # 排查事件的黄金命令
kubectl get events --sort-by=.lastTimestamp   # 集群事件
kubectl top nodes                       # 节点资源使用率

排查套路：Pod 起不来先看 describe 的事件；网络不通先确认 Service 的 selector 是否匹配 Pod 标签；镜像拉取失败先检查 imagePullPolicy 与仓库凭证。

结语

Kubernetes 的入门门槛不在命令，而在心智模型：把一切当作"声明期望 + 控制器调谐"。理解了 Pod 的生命周期、Deployment 的滚动策略、Service 的稳定入口这三角，你就能安全地把应用跑上集群。建议从本地 minikube 起步，把每个对象都亲手 apply 一遍，再逐步引入探针、资源限制与 Ingress——规模化的可靠性，正是从这些细节中长出来的。