学完 Docker 学什么？Kubernetes 核心概念入门与和 Docker 的关系

学完 Docker 之后，最常见的疑问是：“我已经会用 Docker 了，还需要学 Kubernetes 吗？”

直接回答：如果你想做运维而不是只玩个人项目——必须学。而且学 Kubernetes 之后，你会发现 Docker 学的那些东西根本没白费，Kubernetes 是建立在它们之上的。

Docker 解决了什么问题，又留下了什么问题

Docker 让“打包应用、到处运行”变得简单。但它有一个核心限制：Docker 是单机工具。

Docker 能做的：
  在一台服务器上运行多个容器
  通过 docker compose 管理多个容器的启动顺序
  
Docker 做不好的：
  多台服务器上的容器如何协调？
  容器挂了如何自动重启并迁移到其他节点？
  应用流量如何在多个容器实例间负载均衡？
  容器资源如何根据负载自动扩缩容？
  如何实现零停机滚动更新？
  如何统一管理 100 台服务器上的 1000 个容器？

这些问题，就是 Kubernetes 要解决的。

Kubernetes 是什么

Kubernetes（简称 K8s）是一个容器编排平台：它自动化地管理容器的部署、扩缩容、故障恢复和滚动更新，让你把一组服务器当成一个统一的资源池来使用。

没有 K8s 的运维（手工模式）：
  服务器A 跑 api-v1（手工启动）
  服务器B 跑 api-v1（手工启动）
  服务器C 跑 db（手工启动）
  
  服务器A 宕机？手工重启或手工在服务器D 启新容器
  流量增大？手工在新服务器再起几个容器
  更新版本？逐台停旧容器、启新容器（有停机时间）

有 K8s 的运维（自动化模式）：
  声明：我需要 3 个 api 实例，资源至少 1G 内存
  K8s 自动：找到合适的节点、启动容器、监控状态
  
  节点宕机？K8s 自动在其他节点重新调度
  流量增大？HPA 自动扩容到 10 个实例
  更新版本？滚动更新，无停机，失败自动回滚

K8s 和 Docker 的关系

这是最容易让人困惑的地方。

常见误解：学了 K8s 就不用 Docker 了

实际情况：
  Kubernetes 编排容器，容器由容器运行时运行
  容器运行时可以是：
    containerd（K8s 1.24+ 默认）← 实际上就是 Docker 的核心
    Docker（旧版 K8s，现已不推荐直接用）
    CRI-O

所以：Dockerfile、镜像构建、Harbor 仓库——这些全部都还要用
K8s 只是在"如何运行容器"这一步做了替换，但镜像还是一样的

比喻：
  Docker = 制造并单独驾驶汽车
  K8s = 一个调度中心，管理城市里所有汽车的行驶路线、加油、停靠
  汽车本身（镜像/容器）没变，只是管理方式升级了

K8s 最核心的 5 个概念

不用背所有资源对象，先把这 5 个搞清楚，就能做 80% 的日常工作。

1. Pod — 最小调度单位

# Pod 是 K8s 中最小的部署单元
# 一个 Pod 里可以有一个或多个容器（通常一个）
# Pod 有独立的 IP，同 Pod 内的容器共享网络和存储

apiVersion: v1
kind: Pod
metadata:
  name: api-pod
spec:
  containers:
  - name: api
    image: harbor.company.com/backend/api:v1.2.3
    ports:
    - containerPort: 8000
    resources:
      requests:
        memory: "256Mi"
        cpu: "0.5"
      limits:
        memory: "512Mi"
        cpu: "1"

2. Deployment — 管理多个 Pod 副本

# Deployment 声明"我要运行 N 个这样的 Pod"
# 负责：创建副本、滚动更新、自动恢复（Pod 挂了重新创建）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3        # 始终保持 3 个副本
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # 更新时最多 1 个不可用
      maxSurge: 1          # 更新时最多多出 1 个
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: harbor.company.com/backend/api:v1.2.3
        ports:
        - containerPort: 8000

# 常用操作
kubectl apply -f deployment.yaml     # 创建/更新
kubectl get deployments              # 查看所有 Deployment
kubectl rollout status deployment/api   # 查看更新状态
kubectl rollout undo deployment/api     # 回滚上一版本
kubectl scale deployment/api --replicas=5  # 扩容

3. Service — 稳定的访问入口

# Pod 的 IP 是不固定的（重建后 IP 变化）
# Service 提供稳定的访问入口，自动对多个 Pod 负载均衡

apiVersion: v1
kind: Service
metadata:
  name: api-svc
spec:
  selector:
    app: api       # 转发给所有带 app=api 标签的 Pod
  ports:
  - port: 80       # Service 端口
    targetPort: 8000  # Pod 端口
  type: ClusterIP  # 只在集群内访问（默认）
  # type: NodePort # 通过节点 IP:端口 从集群外访问
  # type: LoadBalancer # 云厂商提供外部负载均衡器

4. Ingress — HTTP 路由规则

# Ingress 定义 HTTP/HTTPS 的路由规则
# 根据域名/路径把流量转发到不同的 Service

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80
  - host: www.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

5. ConfigMap / Secret — 配置和密钥管理

# ConfigMap：非敏感配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  DB_HOST: "mysql.default.svc.cluster.local"

---
# Secret：敏感信息（Base64 编码存储，实际生产用 Vault）
apiVersion: v1
kind: Secret
metadata:
  name: api-secrets
type: Opaque
data:
  DB_PASSWORD: c3VwZXJzZWNyZXQ=  # base64("supersecret")
  JWT_KEY: bXlqd3RrZXk=          # base64("myjwtkey")

# 在 Deployment 中引用
spec:
  containers:
  - name: api
    envFrom:
    - configMapRef:
        name: api-config
    - secretRef:
        name: api-secrets

搭建实验环境（本地学习）

不需要买服务器，本机就能跑 K8s：

# 方案1：minikube（官方推荐的本地 K8s）
# 适合 macOS/Linux/Windows，有 Docker Desktop 就能用

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

minikube start --cpus=4 --memory=8192
minikube status

# 安装 kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   1m    v1.31.0

# 方案2：k3s（轻量版，适合 Linux 虚拟机）
# 适合服务器或 Linux 虚拟机，资源占用更少
curl -sfL https://get.k3s.io | sh -
kubectl get nodes

# 方案3：Kind（用 Docker 容器模拟 K8s 节点）
# 适合 CI 或想模拟多节点的场景
go install sigs.k8s.io/kind@latest
kind create cluster --config kind-config.yaml

K8s 的学习顺序

Week 1-2：概念层
  K8s 架构（控制平面 + 工作节点）
  核心资源对象（上面的 5 个）
  kubectl 常用命令
  → 目标：能部署一个简单的 Web 应用

Week 3-4：进阶配置
  存储（PV/PVC，持久化数据库）
  网络（Ingress + TLS 证书）
  资源限制（requests/limits）
  探针（livenessProbe/readinessProbe）
  → 目标：部署一个完整的三层应用（Nginx+API+DB）

Week 5-6：运维操作
  集群维护（节点管理/etcd 备份）
  故障排查（kubectl logs/describe/exec）
  滚动更新和回滚
  HPA 自动扩缩容
  → 目标：能处理生产中常见的故障场景

Week 7-8：备考 CKA
  做题练习（Killer.sh 是最好的练习平台）
  重点：考试是实操，不是选择题

小结

Docker 是地基，Kubernetes 是在地基上盖起来的大楼。学 Docker 的时候打好基础，学 K8s 的时候你会发现很多概念都是一脉相承的：镜像还是那个镜像，网络隔离还是用 namespace，存储还是 volume——只是管理的规模和方式变了。

把本站 Docker 30 篇学完，再来啃 K8s，路径是顺的。