Kubernetes 核心概念与实战入门

1. 为什么需要编排#

单机 Docker（或 Compose）在生产会立刻暴露以下局限：

• 故障自愈：--restart=always 能拉起崩溃的容器，但节点整机宕机时容器不会漂移到其他机器。
• 水平扩缩容：docker compose up --scale 只能单机扩副本，跨节点分发要自己写脚本。
• 服务发现与负载均衡：容器重建后 IP 会变，多副本之间缺少稳定的虚拟地址、DNS 名字与统一入口。
• 滚动发布与回滚：Compose 默认”停旧起新”，做不到按比例灰度，也做不到一条命令回滚。
• 配置与密钥：环境变量散落在多个 compose 文件，无法统一注入与轮转。
• 资源隔离与存储编排：多容器抢 CPU/内存缺少调度层配额，Pod 漂移后数据卷也无法跟着走。

Kubernetes（简称 K8s）把这些能力抽象成声明式 API：你只描述期望状态（desired state），控制器持续把实际状态（actual state）拉回期望。这与 docker run 的命令式思路有本质区别——K8s 关心的是”持续稳定在某个状态”。

要解决的问题可以概括为：调度、自愈、扩缩容、服务发现、负载均衡、配置管理、密钥管理、存储编排、滚动发布、批处理、多租户隔离。

2. 集群架构#

集群分为控制平面（Control Plane）与工作节点（Worker Node）。

3. 核心对象逐个讲#

1
apiVersion: v1
2
kind: Pod
3
metadata: { name: web-with-sidecar, labels: { app: web } }
4
spec:
5
  restartPolicy: Always
6
  containers:
7
    - name: web
8
      image: nginx:1.27
9
      volumeMounts: [{ name: logs, mountPath: /var/log/nginx }]
10
    - name: log-shipper
11
      image: busybox:1.36
12
      command: ["sh", "-c", "tail -F /logs/access.log"]
13
      volumeMounts: [{ name: logs, mountPath: /logs }]
14
  volumes:
15
    - name: logs
16
      emptyDir: {}

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata: { name: web }
4
spec:
5
  replicas: 3
6
  selector:
7
    matchLabels: { app: web }
8
  strategy:
9
    type: RollingUpdate
10
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
11
  template:
12
    metadata:
13
      labels: { app: web }
14
    spec:
15
      containers:
16
        - name: web
17
          image: nginx:1.27
18
          ports: [{ containerPort: 80 }]
19
          resources:
20
            requests: { cpu: 100m, memory: 128Mi }
21
            limits: { cpu: 500m, memory: 256Mi }

1
apiVersion: v1
2
kind: Service
3
metadata: { name: web }
4
spec:
5
  type: ClusterIP
6
  selector: { app: web }
7
  ports: [{ port: 80, targetPort: 80 }]

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata: { name: web-ingress }
4
spec:
5
  ingressClassName: nginx
6
  tls:
7
    - hosts: ["sakura-hu.top"]
8
      secretName: sakura-tls
9
  rules:
10
    - host: sakura-hu.top
11
      http:
12
        paths:
13
          - path: /
14
            pathType: Prefix
15
            backend: { service: { name: web, port: { number: 80 } } }
16
          - path: /api
17
            pathType: Prefix
18
            backend: { service: { name: api, port: { number: 8080 } } }

1
apiVersion: v1
2
kind: ConfigMap
3
metadata: { name: web-config }
4
data:
5
  APP_ENV: production
6
  nginx.conf: |
7
    server {
8
      listen 80;
9
      location / { root /usr/share/nginx/html; }
10
    }
11
---
12
apiVersion: v1
13
kind: Secret
14
metadata: { name: db-secret }
15
type: Opaque
16
data:
17
  username: cm9vdA==        # echo -n 'root' | base64
18
  password: c2VjcmV0MTIz

1
spec:
2
  containers:
3
    - name: web
4
      image: nginx:1.27
5
      envFrom: [{ configMapRef: { name: web-config } }]
6
      env:
7
        - name: DB_PASSWORD
8
          valueFrom: { secretKeyRef: { name: db-secret, key: password } }
9
      volumeMounts: [{ name: config-vol, mountPath: /etc/nginx/conf.d }]
10
  volumes:
11
    - name: config-vol
12
      configMap:
13
        name: web-config
14
        items: [{ key: nginx.conf, path: default.conf }]

1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata: { name: data-pvc }
4
spec:
5
  accessModes: ["ReadWriteOnce"]
6
  storageClassName: standard
7
  resources: { requests: { storage: 10Gi } }
8
---
9
# 在 Pod 中引用该 PVC
10
spec:
11
  volumes:
12
    - name: data
13
      persistentVolumeClaim: { claimName: data-pvc }

4. kubectl 常用命令#

查看、诊断与操作：

1
kubectl get pods -n prod -o wide                 # 列表，带节点/IP
2
kubectl get deploy,svc,ing -n prod               # 一次看多种资源
3
kubectl describe pod web-abc -n prod             # 详细事件（排查第一站）
4
kubectl logs web-abc -n prod -f --tail=100       # 实时日志
5
kubectl exec -it web-abc -n prod -- sh           # 进入容器
6
kubectl top pod -n prod                          # 资源占用（需 metrics-server）
7
kubectl apply -f deploy.yaml                     # 声明式创建/更新（推荐）
8
kubectl delete -f deploy.yaml                    # 按清单删除
9
kubectl scale deploy/web --replicas=5 -n prod    # 手动扩缩容
10
kubectl port-forward svc/web 8080:80 -n prod     # 本地转发调试
11
kubectl cp prod/web-abc:/etc/nginx/nginx.conf ./nginx.conf
12
kubectl get events -n prod --sort-by=.metadata.creationTimestamp

常用参数：

不确定资源怎么写时，先用 kubectl create deploy web --image=nginx --dry-run=client -o yaml 生成骨架，再改成声明式文件。

5. YAML 清单规范#

每个清单至少有四个顶层字段：apiVersion、kind、metadata、spec（部分对象用 data / rules 替代 spec）。

常见 apiVersion 与 kind 对应：

书写注意：缩进用空格不要用 Tab，同级字段缩进必须一致；列表项用 -；字符串里的 : 或特殊字符建议加引号；一个文件可用 --- 分隔多个对象。

查字段最快的方式不是搜索引擎，而是 apiserver 自带的文档：

1
kubectl explain deploy.spec.strategy.rollingUpdate
2
kubectl explain pod.spec.containers.lifecycle --recursive
3
kubectl api-resources   # 所有资源及短名
4
kubectl api-versions    # 所有 API 组版本

6. 滚动更新与回滚实战#

把 web 这个 Deployment 的镜像从 1.27 升到 1.28：

1
kubectl get deploy web -n prod -o jsonpath='{.spec.template.spec.containers[0].image}'   # 记录当前版本
2
kubectl set image deploy/web web=nginx:1.28 -n prod    # 更新镜像，触发滚动更新
3
kubectl rollout status deploy/web -n prod              # 观察新 RS 扩容、旧 RS 缩容
4
kubectl get rs -n prod -l app=web                      # 查看两个 RS 的副本数变化

kubectl set image 本质是修改 spec.template，Deployment controller 因此创建新 ReplicaSet，并按 maxSurge / maxUnavailable 逐步扩新缩旧。过程中可以随时暂停：

1
kubectl rollout pause  deploy/web -n prod    # 先滚一部分，观察指标与错误率
2
kubectl rollout resume deploy/web -n prod    # 没问题再恢复

暂停常用于金丝雀思路。更规范的做法是用两个 Deployment 或引入 Argo Rollouts / Flagger。出问题时回滚：

1
kubectl rollout history deploy/web -n prod                 # 所有 revision
2
kubectl rollout history deploy/web -n prod --revision=3    # 某个 revision 的细节
3
kubectl rollout undo deploy/web -n prod                    # 回到上一个可用版本
4
kubectl rollout undo deploy/web -n prod --to-revision=1    # 回到指定 revision

两点补充：给 revision 加可读备注用 kubectl annotate deploy/web kubernetes.io/change-cause="upgrade nginx to 1.28"；rollout undo 的实现是把旧 ReplicaSet 的 Pod 模板重新写回 Deployment，会再生成一个新 revision——不是”回到过去”，而是”用旧模板再滚一次”。

7. 健康检查#

三种探针职责不同：

1
spec:
2
  containers:
3
    - name: web
4
      image: nginx:1.28
5
      startupProbe:
6
        httpGet: { path: /, port: 80 }
7
        failureThreshold: 30
8
        periodSeconds: 10
9
      livenessProbe:
10
        httpGet: { path: /healthz, port: 80 }
11
        initialDelaySeconds: 10
12
        periodSeconds: 10
13
        failureThreshold: 3
14
      readinessProbe:
15
        httpGet: { path: /ready, port: 80 }
16
        periodSeconds: 5
17
        failureThreshold: 2

三种探测方式：httpGet（返回 200-399 视为成功，最常用）、tcpSocket（端口能连上即成功）、exec（命令退出码为 0 即成功）。关键参数：initialDelaySeconds（首检延迟）、periodSeconds（周期）、timeoutSeconds（超时）、successThreshold（连续成功几次算就绪）、failureThreshold（连续失败几次算失败）。

两个经典翻车场景：

1. 探针太激进反复重启。 应用冷启动要 60 秒，initialDelaySeconds 只给 5 秒，liveness 阈值又小，容器刚启动就被判”死了”并重启，陷入 CrashLoopBackOff。正确做法是用 startupProbe 兜住启动期，让 liveness 在启动完成后才开始计时。
2. 没配 readinessProbe，流量打到未就绪 Pod。 容器一 Running 就进 Endpoints，但应用还在加载缓存或连数据库，用户直接 500。正确做法是给 readiness 一个能真实反映”可服务”的检查点。

反过来说，livenessProbe 也不该依赖外部依赖（比如数据库）：数据库抖一下会让所有 Pod 被判死并同时重启，造成雪崩。记住：“我活着”用 liveness，“我能干活”用 readiness。

8. 资源管理#

• requests：调度依据，也是 cgroup 的 cpu.shares 参考。调度器把 Pod 放到”剩余可分配 requests 足够”的节点。
• limits：运行上限。CPU 超限被节流（throttle），内存超限直接 OOMKilled。

1
resources:
2
  requests: { cpu: 250m, memory: 256Mi }
3
  limits:   { cpu: 500m, memory: 512Mi }

单位：CPU 的 1 = 1 个核心，1000m = 1 核，250m = 0.25 核，CPU 是可压缩资源；内存 Mi = 1024×1024 字节，M = 1000×1000 字节，Gi 同理，内存是不可压缩资源，超了只能杀。

QoS 等级由 requests/limits 的配置方式决定：

节点内存压力大时，kubelet 按 BestEffort → Burstable → Guaranteed 的顺序驱逐；同一等级内，超出 requests 越多的越先被驱逐。

实践建议：requests 按稳态占用设置，limits 按峰值容忍设置，两者别相等（失去弹性）也别差太多（突发就被节流）；关键服务设 Guaranteed，批处理设 Burstable 即可。排障方面：kubectl describe pod 出现 Last State: Terminated, Reason: OOMKilled 说明内存超限，结合 kubectl top pod 与容器内真实曲线判断是 limits 太小还是内存泄漏；CPU 节流则看 cgroup 的 cpu.stat 中 nr_throttled / throttled_time。

9. 自动扩缩容#

HorizontalPodAutoscaler（HPA）根据指标自动调整 Deployment / StatefulSet / ReplicaSet 的副本数，只做水平扩缩（加减副本），不改 resources。原理是 HPA controller 每 15 秒（默认）拉一次指标，计算 期望副本数 = ceil(当前副本数 × 当前指标 / 目标指标)，再更新 Deployment 的 replicas。

1
apiVersion: autoscaling/v2
2
kind: HorizontalPodAutoscaler
3
metadata: { name: web-hpa, namespace: prod }
4
spec:
5
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: web }
6
  minReplicas: 2
7
  maxReplicas: 10
8
  metrics:
9
    - type: Resource
10
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 60 } }
11
    - type: Resource
12
      resource: { name: memory, target: { type: Utilization, averageUtilization: 75 } }
13
  behavior:
14
    scaleDown: { stabilizationWindowSeconds: 300 }

要点：

• HPA 依赖 metrics-server 提供 CPU/内存指标。没装会报 unable to get metrics，kubectl top 也无法工作。
• averageUtilization: 60 指所有 Pod 的平均 CPU 使用率相对 requests 达到 60% 时扩容，因此必须设置 requests，否则无法计算百分比。
• 自定义指标（QPS、队列长度）需要 Prometheus Adapter 或 KEDA，通过 custom / external metrics API 暴露。
• behavior.stabilizationWindowSeconds 是缩容冷却窗口，防止指标抖动导致副本数上下横跳。
• 节点层面还需扩容：Cluster Autoscaler（云上）或 Karpenter 在 Pod 因资源不足 Pending 时增加节点。
• 垂直方向有 VPA，但调整 requests 需要重建 Pod，与 HPA 用在同一指标上会互相打架。

10. Helm：包管理#

原生 YAML 的问题是同一套应用要部署到多个环境，镜像 tag、副本数、域名都不同，只能复制多份或手工改，容易漂移。Helm 用模板 + 变量解决，并提供版本化的发布管理。

Chart 目录结构：

1
mychart/
2
├── Chart.yaml          # 元信息：name、version、appVersion、依赖
3
├── values.yaml         # 默认变量
4
├── charts/             # 子 Chart（依赖）
5
└── templates/
6
    ├── deployment.yaml
7
    ├── service.yaml
8
    ├── _helpers.tpl    # 可复用的模板片段
9
    └── NOTES.txt       # 安装后提示信息

模板渲染与对应的 values.yaml：

1
# templates/deployment.yaml（节选）
2
apiVersion: apps/v1
3
kind: Deployment
4
metadata:
5
  name: {{ include "mychart.fullname" . }}
6
spec:
7
  replicas: {{ .Values.replicaCount }}
8
  template:
9
    spec:
10
      containers:
11
        - name: {{ .Chart.Name }}
12
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
13
          resources:
14
            {{- toYaml .Values.resources | nindent 12 }}
15
---
16
# values.yaml
17
replicaCount: 3
18
image: { repository: nginx, tag: "1.28" }
19
resources:
20
  requests: { cpu: 100m, memory: 128Mi }
21
  limits: { cpu: 500m, memory: 256Mi }

常用命令：

1
helm create mychart                              # 生成骨架
2
helm template mychart -f values-prod.yaml        # 本地渲染，不安装（调试首选）
3
helm install web ./mychart -n prod --create-namespace
4
helm upgrade web ./mychart -n prod -f values-prod.yaml
5
helm rollback web 2 -n prod                      # 回滚到第 2 个 revision
6
helm list -n prod && helm history web -n prod    # 查看已发布与发布历史
7
helm uninstall web -n prod
8
helm lint ./mychart                              # 静态检查

自己写一个简单 Chart 的要点：

1. Chart.yaml 里 version 是 Chart 版本，appVersion 是应用版本，两者独立。
2. 所有可变量都放进 values.yaml，模板里用 .Values.xxx 引用，不要硬编码。
3. 用 _helpers.tpl 定义 fullname、labels 等公共片段，避免重复；注意缩进陷阱，配合 nindent / indent / toYaml 使用。
4. 先用 helm template 在本地渲染检查，确认输出无误再 install；敏感值不要写进 values.yaml，用 --set 或外部 Secret 注入。

Helm 3 相比 Helm 2 移除了 Tiller，权限直接走调用者的 kubeconfig，默认更安全。

11. 本地实践#

用 kind 起一个本地集群，并部署第一个应用：

1
brew install kind kubectl                   # 安装
2
kind create cluster --name dev              # 创建集群（默认单节点）
3
kubectl cluster-info --context kind-dev && kubectl get nodes
4

5
kubectl create deployment hello --image=nginx:1.28 --dry-run=client -o yaml > hello.yaml
6
kubectl expose deployment hello --port=80 --type=NodePort --dry-run=client -o yaml >> hello.yaml
7
kubectl apply -f hello.yaml
8
kubectl rollout status deploy/hello && kubectl get pods,svc
9
kubectl port-forward svc/hello 8080:80      # kind 里用 port-forward 或 Ingress 访问
10
curl -I http://localhost:8080
11
kubectl delete -f hello.yaml && kind delete cluster --name dev

若要在 kind 里验证 Ingress，还需额外安装 ingress-nginx，并给节点配置 extraPortMappings 映射 80/443。

12. 生产必备#

• 命名空间隔离：按团队或环境划分 Namespace，配合 ResourceQuota 与 LimitRange 限制总量与默认值。
• RBAC 最小权限：用 Role/RoleBinding（命名空间级）或 ClusterRole/ClusterRoleBinding（集群级）精确授权，别把 cluster-admin 发给服务账号。
• NetworkPolicy：默认所有 Pod 互通；一旦某 Pod 被任意策略选中，就变成”默认拒绝 + 显式放行”。生产建议先做默认拒绝入站，再逐条开放。
• 镜像拉取密钥：私有仓库用 kubernetes.io/dockerconfigjson 类型的 Secret，挂到 ServiceAccount 的 imagePullSecrets 上。
• PodDisruptionBudget：声明自愿中断时至少保留几个可用副本（如 minAvailable: 2），防止节点维护时把服务全部驱逐。
• 日志与监控：指标用 Prometheus + Grafana，日志用 Loki（或 ELK），链路用 OpenTelemetry；采集走 sidecar 或 DaemonSet，应用只输出到 stdout。
• 其他：镜像别用 latest tag；配好探针；设置 terminationGracePeriodSeconds 并处理 SIGTERM 优雅退出；用 topologySpreadConstraints 打散副本；给关键命名空间设 PriorityClass。

13. 什么时候不该用 K8s#

K8s 强大但要付代价：学习曲线陡、组件多、网络与存储抽象复杂、排障链路长、需要有人持续维护。以下情况值得认真考虑替代方案：

• 团队小、没有专职运维：一两个人维护集群的隐性成本很高，直接用托管容器服务能少踩坑。
• 单机就扛得住：流量不大、可用性要求不苛刻时，Docker Compose 足够。
• 只是定时任务或简单 API：Serverless（云函数、Cloud Run、Cloudflare Workers）零运维，按调用计费。
• 需要精细调度但不是容器场景：Nomad 更简单，适合混合编排容器与普通进程；边缘与资源受限环境可用 k3s、KubeEdge。

成本权衡要算三笔账：人力账（谁维护集群与升级）、资源账（控制平面与系统组件自身占用，托管集群按节点收费）、机会成本（时间花在 K8s 还是业务上）。一个经验法则是：如果容器数量少于十几个、没有强制的多租户隔离与弹性需求，先别上 K8s。

14. 面试高频问题#

Pod 和容器的区别？ 容器是最小运行单元，Pod 是最小调度单元。一个 Pod 可含多个容器，共享网络命名空间与 Volume，共享生命周期，容器间可用 localhost 互访，端口不能重复。

Deployment 和 StatefulSet 的区别？ Deployment 面向无状态应用：Pod 可互换、随机名字、不需要稳定存储、支持并行滚动更新。StatefulSet 面向有状态应用：Pod 名字稳定有序（db-0、db-1）、网络标识稳定（配合 Headless Service）、每个 Pod 有独立 PVC、按顺序创建与删除。

Service 如何实现负载均衡？ Service 通过 label selector 选中 Pod，Endpoints controller 把就绪 Pod 的 IP 写入 Endpoints，kube-proxy 在节点上把 ClusterIP 的流量按 iptables/IPVS 规则分发到后端。默认是四层转发；ClusterIP 是虚拟 IP，不绑定网卡，只存在于节点规则中。

三种探针的区别？ liveness 决定”要不要重启”，readiness 决定”要不要接流量”，startup 决定”启动是否完成（用于抑制前两者）”。

滚动更新的原理？ 改 spec.template 后 Deployment 创建新 ReplicaSet，按 maxSurge/maxUnavailable 逐步扩新缩旧；新 Pod 通过 readiness 后才接流量，全部就绪后旧 RS 缩到 0（保留历史以便回滚）。rollout undo 即把旧 RS 的模板写回。

requests 和 limits 的区别？ requests 参与调度、决定 QoS 与驱逐优先级；limits 是运行硬上限，CPU 超限被节流，内存超限被 OOMKilled。

Pod 一直 Pending 怎么排查？ 看 kubectl describe pod 的 Events。常见原因：资源不足无法满足 requests、节点有 Taint 且缺少 Toleration、nodeSelector/affinity 不匹配、PVC 未绑定、超过 ResourceQuota。

CrashLoopBackOff 怎么排查？ 用 kubectl logs --previous 看上次崩溃日志，kubectl describe pod 看退出码与原因（OOMKilled / 探针失败 / 命令写错 / 配置缺失）。退出码 137 通常是 OOMKilled 或 SIGKILL。

Service 和 Ingress 的区别？ Service 工作在一到四层，暴露 IP + 端口，通常对应一个后端；Ingress 工作在七层，按域名/路径路由到不同 Service，还能统一管理 TLS。

ConfigMap 更新后为什么没生效？ 环境变量方式在容器启动时已固化，不会随 ConfigMap 更新，必须 kubectl rollout restart；Volume 挂载方式则由 kubelet 周期性同步。

15. 命令与资源对象速查表#

常用命令：

资源对象：

字段速查最常见的几项：spec.replicas（期望副本数）、spec.selector（选择后端 Pod 的 Label）、spec.template（Pod 模板）、spec.strategy.rollingUpdate（maxSurge / maxUnavailable）、spec.containers[].resources（requests / limits）、spec.nodeName（Pod 绑定的节点）、restartPolicy（Always / OnFailure / Never）、terminationGracePeriodSeconds（优雅退出宽限期）。