Kubernetes 入门

从单机 Docker 到集群 1/8

在单台机器上，docker run 加一个 Compose 文件，能解决绝大多数问题。真正逼你上集群的只有四件事，而且全都发生在「机器不止一台」这个前提下。

K8s 恰好把这四件事做成了平台的默认能力

先把 Docker 概念翻译成 K8s 术语（这张表最省时间）

真正让人卡住的往往是这一层：你在 Docker 里熟悉的东西，在 K8s 里不仅换了名字，有时还被拆成了两个对象。

最小单元：Pod 2/8

K8s 里没有「容器」这个最小调度单位。取而代之的是 Pod：一个或多个共享网络命名空间与存储卷的容器集合。它是调度、扩缩、重建的最小颗粒。

为什么要凭空多出这一层？

因为有些进程天生就该待在一起、共享同一个 localhost：主应用和它的日志采集 sidecar、或者必须读写同一份本地文件的辅助进程。同一个 Pod 内的容器共享 IP 和端口空间，直接 localhost 互访——这在 Docker 里得靠同一网络加 --network container: 才勉强做到。

但请记住：单容器 Pod 才是常态。绝大多数业务就是一个 Pod 一个容器，不必为了「用上这个特性」硬塞 sidecar。

先跑起来，再谈声明式

# 快速试一个 Pod（学习 / 验证用；生产不要这么写）
kubectl run demo --image=nginx:1.27-alpine

kubectl get pods
kubectl get pod demo -o wide      # 额外看到所在节点与 Pod IP
kubectl describe pod demo
kubectl logs demo
kubectl exec -it demo -- sh

# 用完删掉
kubectl delete pod demo

对应的声明式写法是一个 kind: Pod 的 YAML。注意这里只是演示 Pod 本身长什么样，生产里几乎不会这么写——你会写 Deployment（见第 3 节）：

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
    - name: web
      image: nginx:1.27-alpine
      ports:
        - containerPort: 80

kubectl apply -f pod.yaml

四个救命命令：卡住时按这个顺序来

K8s 上的排障，九成时间花在这四个命令上。顺序也很重要——从外往内一层层看。

工作负载三件套 3/8

你不会直接管 Pod，而是选一个控制器来管。Deployment / StatefulSet / DaemonSet 这三者覆盖了绝大多数场景——选错类型是新手最常见的结构性错误，因为它后期很难改。

滚动更新与回滚：这是 Deployment 最值钱的能力

# 换镜像即触发滚动更新（无需手写新 YAML）
kubectl set image deployment/web web=nginx:1.27.1-alpine

kubectl rollout status deployment/web     # 盯着滚动过程，卡住会告诉你卡在哪
kubectl rollout history deployment/web    # 看历史版本

# 出问题了，一条命令回滚
kubectl rollout undo deployment/web
kubectl rollout undo deployment/web --to-revision=2   # 回滚到指定版本

注意「更新」和「回滚」在 K8s 里是同一套机制：都是改期望状态、然后由控制器滚动过去。所以回滚不需要备份、不需要手工切流量，速度和新发布一样。

副本数与 HPA 的关系

YAML 里的 replicas 是你写死的固定副本数。它之上还有一层 HPA（Horizontal Pod Autoscaler），能按 CPU / 内存使用率自动增减副本。三个容易踩的点：

网络与服务暴露 4/8

先回答一个必问的问题：为什么不能直接访问 Pod？因为 Pod 是「一次性」的——它重建一次就换一个 IP。你没法把变化的 IP 写进配置里，也没法做负载均衡。

所以 K8s 引入了 Service：一组 Pod 的稳定虚拟 IP + 固定 DNS 名。后端 Pod 怎么换、换多少，都跟调用方无关——这一点和 Docker 里「容器 IP 会变」是同一类问题的同一类解法。

四层递进：从集群内到公网

Ingress 的心智模型：就是你已经会的反向代理

如果你已经理解「Caddy / nginx 在前面收 HTTPS，再按域名或路径转发到后面不同的服务」，那你已经理解 Ingress 了。K8s 只是把这套配置变成了集群里的对象：Ingress 写路由规则，Ingress Controller（ingress-nginx / Traefik / Caddy 等）负责真正执行。

# Ingress：把 api.example.com 转发到后端 Service api
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  rules:
    - host: dockerlab.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

配置与存储 5/8

Compose 里「写几个环境变量、挂两个目录」的事，在 K8s 里对应的是一套对象体系。先看对照，再看具体写法。

配置对象怎么写

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-config
data:
  APP_ENV: production
  nginx.conf: |
    server {
      listen 80;
      location / { root /usr/share/nginx/html; }
    }
---
apiVersion: v1
kind: Secret
metadata:
  name: db-credential
type: Opaque
stringData:                    # stringData 会自动 base64，省去手工编码
  MYSQL_ROOT_PASSWORD: change-me

在工作负载里引用它们

spec:
  containers:
    - name: web
      image: nginx:1.27-alpine
      envFrom:
        - configMapRef:              # 整个 ConfigMap 变成环境变量
            name: web-config
      env:
        - name: MYSQL_ROOT_PASSWORD       # 单个键注入，更可控
          valueFrom:
            secretKeyRef:
              name: db-credential
              key: MYSQL_ROOT_PASSWORD
      volumeMounts:
        - name: conf
          mountPath: /etc/nginx/conf.d
  volumes:
    - name: conf
      configMap:
        name: web-config

端到端跑通：把一个 Docker 镜像部署上去 6/8

前面都是概念，这一节把它们串成一条能真跑起来的链路。假设你本地已经有一个构建好的镜像，并且推到了镜像仓库（下面用 nginx:1.27-alpine 代表示例，换成你自己的镜像即可）。

① 完整 YAML（Deployment + Service，可直接复制）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1            # 最多多起 1 个
      maxUnavailable: 0       # 一个都不许先停 → 真正零中断
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:            # 调度依据：Scheduler 按这个挑节点
              cpu: 100m
              memory: 64Mi
            limits:              # 上限：超了会被 OOMKilled / 限流
              cpu: 500m
              memory: 256Mi
          readinessProbe:       # 就绪才接流量
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:        # 不活了就重启
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web                # 靠标签找到上面那组 Pod
  ports:
    - port: 80              # Service 自己的端口
      targetPort: 80        # 容器里的端口
  type: ClusterIP

② 应用并验证

kubectl apply -f web.yaml

kubectl get pods -l app=web -o wide
kubectl get svc web
kubectl describe deployment web
kubectl rollout status deployment/web

# 本地打开 http://localhost:8080 看效果
kubectl port-forward svc/web 8080:80

③ 做一次滚动更新，再回滚

# 换镜像版本 → 自动滚动更新（maxUnavailable: 0，全程不停机）
kubectl set image deployment/web web=nginx:1.27.1-alpine
kubectl rollout status deployment/web

# 假设新版本有问题，一条命令回到上一版
kubectl rollout undo deployment/web
kubectl rollout status deployment/web

# 用完清理
kubectl delete -f web.yaml

本地练手：kind / minikube / k3s 怎么选 7/8

K8s 不必先买三台服务器。本地就能起一个真集群，把上面那套 YAML 跑通。三种方案各有明确适用面。

kind — 最干净的本地验证

前提是本机已经有 Docker（kind 自己没有运行时）。起得快、销毁彻底，是本地反复试 YAML 的首选。

kind create cluster --name demo
kubectl cluster-info --context kind-demo
kind delete cluster --name demo

minikube — 对新手最友好

driver 支持面最广（docker / podman / hyperkit / virtualbox / none），自带 dashboard 和一堆 addon。代价是默认资源占用比 kind 略高。

minikube start --cpus=2 --memory=4096
minikube dashboard              # 打开可视化面板
minikube addons enable ingress
minikube delete

k3s — 轻到可以上生产

单个二进制，把 containerd、Traefik、ServiceLB、本地存储全打了进去。它不只是练手工具——小服务器、边缘、IoT 生产环境用它的很多。

# 先下载看清楚再执行，不要直接 curl | sh
curl -sfL https://get.k3s.io -o install.sh
less install.sh
sudo sh install.sh

kubectl get nodes            # k3s 会自动写好 kubeconfig
sudo k3s-uninstall.sh

什么时候不该上 K8s 8/8

这一节可能是全页最该读的一节。网上讲 K8s 的文章几乎都在教「怎么用」，很少有人讲「什么时候别用」——但选型的失误，代价比用错一个命令大得多。

先看一张判据表

K8s 只是开始，不是终点

上了 K8s 之后，下面这些「配套工程」一件都不会少：

托管 ≠ 什么都不用管

注意第三行：托管只是把控制面这一块接了过去，工作负载怎么设计、网络怎么规划、存储怎么选、日志怎么收——一件都不会少。把「上了托管版」当成「从此不用运维」，是很多团队踩过的坑。

继续往下走