Docker 与 Kubernetes 容器化指南¶

适用人群：希望理解容器镜像、本地多服务环境和 Kubernetes 集群编排的开发者与运维人员
前置要求：掌握 Linux、网络和 YAML 基础，理解进程、端口和持久化数据
最后更新：2026-07-21

Docker 解决的是“如何把应用及其运行环境做成可重复交付的镜像，并在一台主机上运行容器”；Kubernetes 解决的是“如何在多台机器组成的集群中持续维持期望状态”。二者不是竞争关系：Docker 构建的 OCI 镜像可以由 Kubernetes 集群中的 containerd 等运行时启动，但 Kubernetes 并不依赖 Docker Engine。

本章压缩低频 Docker 参数，以一个 Web 应用为主线掌握镜像、容器、数据、网络和 Compose；后半部分详细解释 Kubernetes 的控制循环、资源对象、发布、调度、存储、网络、安全和排错。阅读完成后，既能在本地快速查询命令，也能理解为什么生产编排不能简单地“多运行几个 docker run”。

1. 容器到底隔离了什么¶

容器不是轻量虚拟机。虚拟机包含独立内核，容器中的进程共享宿主机内核，只通过 Linux namespace 获得隔离的进程、网络、挂载点和主机名视图，通过 cgroup 获得 CPU、内存和 I/O 限制，再叠加只读镜像层与可写容器层形成文件系统。

flowchart TB
    subgraph VM["虚拟机"]
      A1["应用"] --> G1["Guest OS 与独立内核"]
      G1 --> H1["Hypervisor / Host"]
    end
    subgraph CT["容器"]
      A2["容器进程 A"] --> K["共享宿主机内核"]
      A3["容器进程 B"] --> K
      K --> H2["Host OS"]
    end

镜像是不可变的文件系统和运行元数据，容器是镜像启动后的进程实例，Registry 是存储和分发镜像的服务。镜像名通常写成：

registry.example.com/team/api:1.4.2

标签便于人阅读，但标签可能被重新指向；要求强可重复时使用镜像 digest。容器被删除后，其可写层也被删除，因此数据库等状态必须放在外部存储或 volume 中。

容器提供隔离，不自动提供完整安全。容器进程仍共享内核，挂载 Docker socket 几乎等同于给予宿主机管理权限，--privileged 会大幅削弱隔离。生产环境需要非 root 用户、只读文件系统、能力裁剪、资源限制、镜像扫描和及时更新。

2. Docker 的最小工作流¶

安装 Docker Desktop 或 Docker Engine 后先确认客户端、服务端和 Compose 插件：

docker version
docker info
docker compose version
docker run --rm hello-world

运行一个 Nginx：

docker run --name web -d -p 8080:80 nginx:alpine
docker ps
curl http://127.0.0.1:8080
docker logs web
docker exec -it web sh
docker stop web
docker rm web

docker run 常用参数：

参数	作用
`--name NAME`	指定可读容器名
`-d`	后台运行
`--rm`	停止后自动删除，适合临时任务
`-it`	保持输入并分配终端
`-p HOST:CONTAINER`	发布容器端口到宿主机
`-e KEY=VALUE`	注入环境变量
`--env-file FILE`	从文件读取环境变量
`-v` / `--mount`	挂载 volume 或目录
`--network NAME`	加入指定网络
`--memory` / `--cpus`	限制资源
`--restart`	设置 Engine 级重启策略

端口映射 -p 8080:80 表示访问宿主机 8080 转发到容器 80。容器内服务必须监听 0.0.0.0，如果只监听容器自己的 127.0.0.1，映射后仍无法访问。

观察容器时按以下顺序查询：

docker ps -a
docker logs --tail 100 -f web
docker inspect web
docker stats
docker port web

容器启动后立即退出，通常不是 Docker “崩溃”，而是容器主进程结束。先查看状态和日志，不要盲目增加重启策略。

3. 用 Dockerfile 构建可重复镜像¶

Dockerfile 描述镜像如何从基础镜像逐层构建。下面用一个 Python HTTP 应用展示核心结构：

FROM python:3.12-slim

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

WORKDIR /app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY src/ ./src/

RUN useradd --create-home --uid 10001 appuser \
    && chown -R appuser:appuser /app
USER appuser

EXPOSE 8000
CMD ["python", "-m", "src.app"]

docker build -t demo-api:1.0 .
docker run --rm -p 8000:8000 demo-api:1.0

变化较少的依赖描述文件先复制，源码后复制，可以提高构建缓存命中率。COPY 只复制构建上下文中的文件，因此需要 .dockerignore：

.git/
.venv/
__pycache__/
.env
tests/
site/

多阶段构建¶

编译工具不必留在运行镜像中。多阶段构建在前一阶段编译，在后一阶段只复制产物：

FROM node:22-alpine AS build
WORKDIR /src
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /src/dist/ /usr/share/nginx/html/

这减少镜像体积和攻击面。不要仅为“层数更少”把所有逻辑写进一条难维护的 RUN；优化重点是稳定缓存、移除构建依赖和避免无关文件。

构建与运行安全¶

使用可信基础镜像，并定期重建以获得安全更新。
版本标签应明确；关键发布可以固定 digest。
不在 Dockerfile、构建参数或镜像层中写入秘密。
使用非 root 用户，按需开启只读根文件系统。
扫描 OS 包和语言依赖，但扫描结果仍需结合可利用性判断。
为进程正确处理 SIGTERM；不要用会吞掉信号的 shell 包装启动命令。

docker history demo-api:1.0
docker image inspect demo-api:1.0
docker build --pull --no-cache -t demo-api:1.0 .

4. 数据和网络：容器不是一座孤岛¶

Volume 与 bind mount¶

命名 volume 由 Docker 管理，适合数据库数据；bind mount 映射宿主机路径，适合开发源码和显式配置。

docker volume create pgdata

docker run -d --name db \
  -e POSTGRES_PASSWORD=local-demo-only \
  --mount type=volume,src=pgdata,dst=/var/lib/postgresql/data \
  postgres:17

docker volume inspect pgdata

docker run --rm \
  --mount type=bind,src="$PWD",dst=/work,readonly \
  alpine ls -la /work

删除容器不会自动删除命名 volume。执行 docker compose down -v 或 docker volume prune 前必须确认数据已备份。Volume 不是备份；备份需要独立副本、保留策略和恢复演练。

用户自定义网络¶

同一个自定义 bridge 网络中的容器可以用容器名解析，不要依赖动态 IP：

docker network create app-net
docker run -d --name redis --network app-net redis:alpine
docker run --rm --network app-net redis:alpine redis-cli -h redis ping

容器访问另一个容器时使用对方的容器端口，不使用宿主机发布端口。发布端口用于让网络外部进入；容器间通信只需要共享网络。

5. Docker Compose：一台主机上的应用编排¶

Compose 用一个 YAML 文件描述多容器应用，适合本地开发、集成测试和单机部署。它能声明服务、网络、volume、健康检查和依赖关系，但不提供 Kubernetes 那样的多节点调度与集群控制循环。

services:
  api:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://app:app@db:5432/app
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health')"]
      interval: 10s
      timeout: 3s
      retries: 5
    restart: unless-stopped

  db:
    image: postgres:17
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: app
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  pgdata:

docker compose config
docker compose up -d --build
docker compose ps
docker compose logs -f api
docker compose exec api sh
docker compose run --rm api python -m pytest
docker compose down

depends_on 只管理启动顺序和声明的健康条件，应用仍应在数据库暂时不可用时进行有限重试。密码示例只适用于本地环境，生产秘密应由部署平台管理。

多份 Compose 文件可表达环境差异，但不要把所有生产编排需求强行堆进 Compose。需要多主机故障恢复、滚动发布、按负载扩缩、细粒度权限和声明式集群管理时，应评估 Kubernetes 或其他编排器。

6. 为什么需要容器编排¶

在一台主机上，Docker Engine 能重新启动退出容器；当应用跨越多台机器时，还要决定容器放在哪个节点、节点失效后迁移到哪里、如何提供稳定地址、怎样滚动更新、如何管理配置与身份，以及如何根据负载增加副本。这就是编排器解决的问题。

工具	适合场景	主要特点
Docker Compose	开发、CI、单机服务	简单直接，不是多节点集群编排器
Docker Swarm	Docker 原生的小型集群	学习成本低，生态和扩展能力较小
HashiCorp Nomad	多种工作负载和较简洁调度	架构相对简单，常与 Consul/Vault 配合
Kubernetes	云原生平台、复杂生产集群	生态完整，能力强，运维复杂度也最高

选择 Kubernetes 不应只因为流行。几个稳定服务运行在一台主机时，Compose 加可靠备份和监控可能更经济。Kubernetes 的价值在于大量工作负载、团队共享平台、弹性、可移植控制面和丰富扩展生态；代价是控制面、网络、存储、权限和升级都需要专业治理。

7. Kubernetes 的核心：声明状态并持续纠偏¶

用户不直接命令 Kubernetes “启动三个容器并永远不出错”，而是提交期望状态：某 Deployment 应有三个副本。控制器持续比较期望状态与实际状态，如果 Pod 少了就创建，多了就删除。这种 reconcile loop 是 Kubernetes 最重要的思想。

flowchart LR
    U["kubectl / CI"] --> A["API Server"]
    A --> E["etcd：集群状态"]
    A --> C["Controller Manager"]
    A --> S["Scheduler"]
    C -->|"比较期望与实际"| A
    S -->|"选择节点"| N["Worker Node"]
    N --> K["kubelet"]
    K --> R["容器运行时"]
    K --> A

控制平面主要组件：

组件	责任
API Server	所有资源读写和认证授权的入口
etcd	保存集群期望与实际状态的关键数据
Scheduler	为未调度 Pod 选择节点
Controller Manager	运行 Deployment、Node 等控制器

工作节点主要运行 kubelet 和容器运行时。集群网络由 CNI 插件实现，Service 转发通常由 kube-proxy 或支持等价能力的数据平面实现。Kubernetes API 是中心，kubectl 只是其中一个客户端。

本地学习可使用 kind、minikube、k3d 或 Docker Desktop 提供的集群。生产集群优先使用云托管服务或经过验证的发行版，不应把单机教学集群直接当生产架构。

kubectl version --client
kubectl cluster-info
kubectl get nodes -o wide
kubectl config get-contexts
kubectl config current-context

在执行任何写操作前确认 context，避免把测试命令应用到生产集群。

8. Kubernetes 对象和 YAML 的共同结构¶

几乎所有资源都包含四个顶层字段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
  namespace: demo
  labels:
    app.kubernetes.io/name: demo-api
spec: {}

apiVersion 和 kind 决定资源类型，metadata 提供名称、命名空间、标签和注解，spec 描述期望状态，status 由控制器写入实际状态。不要手工编辑 status。

kubectl apply -f deployment.yaml
kubectl get deployment demo-api -n demo -o yaml
kubectl explain deployment.spec
kubectl diff -f deployment.yaml
kubectl delete -f deployment.yaml

apply 是声明式更新；diff 在变更前展示差异。资源应存入 Git 并通过评审发布，而不是只保存在操作者 shell 历史中。

标签用于选择资源，注解保存不参与选择的元数据。选择器是对象之间关联的基础，修改时必须谨慎。

9. Pod、Deployment 与工作负载控制器¶

Pod 是 Kubernetes 最小调度单位，可以包含一个或多个共享网络和 volume 的容器。业务主容器通常一 Pod 一个；紧密协作的 sidecar 可放在同一 Pod。Pod 是可替换实例，不应把数据和身份绑定到随机 Pod 名称。

直接创建 Pod 缺少副本和滚动更新管理。无状态长期服务使用 Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
  namespace: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: api
          image: registry.example.com/team/demo-api:1.4.2
          ports:
            - name: http
              containerPort: 8000
          envFrom:
            - configMapRef:
                name: demo-api-config
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
          startupProbe:
            httpGet:
              path: /health/startup
              port: http
            periodSeconds: 2
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            periodSeconds: 10

三种探针语义不同：

探针	失败后行为	应回答的问题
startup	启动完成前屏蔽其他探针	应用是否已经完成启动
readiness	从 Service 后端移除 Pod	当前是否能接收新流量
liveness	重启容器	进程是否陷入不可恢复状态

不要让 liveness 依赖外部数据库，否则数据库故障会触发所有应用容器重启，扩大事故。readiness 可以反映必要依赖，但要防止短暂抖动引发流量震荡。

其他工作负载控制器：

控制器	用途
StatefulSet	需要稳定网络身份、顺序或独立存储的有状态副本
DaemonSet	每个符合条件的节点运行一个实例，如日志采集器
Job	执行到成功结束的一次性任务
CronJob	按计划创建 Job

数据库能否运行在 Kubernetes 中取决于团队存储、备份和恢复能力，不是换成 StatefulSet 就自动获得高可用。

10. Service、Ingress 与服务发现¶

Pod IP 会变化，Service 通过稳定虚拟 IP 和 DNS 名称选择一组 Pod：

apiVersion: v1
kind: Service
metadata:
  name: demo-api
  namespace: demo
spec:
  selector:
    app: demo-api
  ports:
    - name: http
      port: 80
      targetPort: http
  type: ClusterIP

同命名空间可以访问 http://demo-api，跨命名空间可使用 demo-api.demo.svc.cluster.local。Service selector 必须匹配 Pod label：

kubectl get service,endpoints,endpointslices -n demo
kubectl get pods -n demo -l app=demo-api --show-labels

Service 类型：

类型	用途
ClusterIP	仅集群内部访问，默认类型
NodePort	在每个节点开放端口，常作为底层机制
LoadBalancer	由云或负载均衡实现提供外部地址
ExternalName	DNS 别名，不创建代理后端

HTTP/HTTPS 外部入口通常使用 Ingress 或 Gateway API。Ingress 资源只有安装对应 Ingress Controller 后才生效；Gateway API 提供更细的角色分离和路由模型，也需要实现控制器。

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

TLS 证书、真实客户端 IP、超时和请求大小等行为依赖入口控制器，必须查看所选实现文档。

11. ConfigMap、Secret 与配置边界¶

ConfigMap 保存非敏感配置，Secret 保存敏感字节。Secret 的值通常只是 base64 编码，不等于加密；生产集群要启用 etcd 静态加密、严格 RBAC，并根据需要集成外部秘密管理系统。

apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-api-config
  namespace: demo
data:
  LOG_LEVEL: info
  FEATURE_X: "false"

apiVersion: v1
kind: Secret
metadata:
  name: demo-api-secret
  namespace: demo
type: Opaque
stringData:
  DATABASE_PASSWORD: replace-me

不要把真实 Secret 明文提交到 Git。示例值只用于说明结构。环境变量适合小型配置；大量文件配置可以挂载 volume。配置更新后，环境变量不会自动刷新到已有进程，通常需要触发 rollout；挂载文件虽可更新，应用也必须支持重新加载。

kubectl create configmap demo-api-config \
  --from-literal=LOG_LEVEL=info \
  --dry-run=client -o yaml

kubectl create secret generic demo-api-secret \
  --from-literal=DATABASE_PASSWORD='value' \
  --dry-run=client -o yaml

命令会把敏感值留在 shell 历史和进程参数中，真实环境优先使用受控流水线或秘密管理集成。

12. 存储：PV、PVC 与 StorageClass¶

容器文件系统和 emptyDir 都随 Pod 生命周期变化。需要持久数据时，应用通过 PersistentVolumeClaim（PVC）申请存储，StorageClass 通常负责动态创建实际卷。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uploads
  namespace: demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: standard

spec:
  template:
    spec:
      containers:
        - name: api
          volumeMounts:
            - name: uploads
              mountPath: /app/uploads
      volumes:
        - name: uploads
          persistentVolumeClaim:
            claimName: uploads

访问模式描述卷的挂载能力，不直接保证应用支持多副本并发写。块存储常只能被一个节点读写；共享文件和对象存储有不同语义与性能。删除 PVC 是否删除真实数据由 StorageClass reclaim policy 决定。

快照不是完整备份策略。数据库备份还需应用一致性、异地副本、保留、加密和恢复演练。

13. 调度、资源与弹性¶

Scheduler 根据资源请求、节点选择、亲和性、污点和拓扑约束为 Pod 选择节点。requests 用于调度和资源保证，limits 限制容器上限。

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    memory: 512Mi

1000m CPU 等于一个 CPU 核的计算配额。内存超过 limit 通常导致 OOMKilled；CPU 超过 limit 通常被节流。完全不设置 requests 会让调度器低估负载，随意设置过大又浪费集群容量。应根据实际 P95/P99 使用量与压测调整。

节点选择示例：

nodeSelector:
  workload: general

更复杂放置使用 node affinity、pod affinity/anti-affinity、topology spread constraints 和 taints/tolerations。不要用硬亲和把应用绑定到单个节点，否则会削弱故障恢复。

HorizontalPodAutoscaler 根据 CPU、内存或自定义指标调整副本：

kubectl autoscale deployment demo-api \
  -n demo --cpu-percent=70 --min=3 --max=20
kubectl get hpa -n demo

HPA 依赖资源 requests 和指标管道。扩容不是瞬时的，应用启动时间、指标延迟、下游容量和缩容稳定窗口都会影响效果。节点容量不足时还需要 Cluster Autoscaler 或云平台等价能力。

14. 滚动发布、回滚和可用性¶

更新 Deployment 镜像会创建新 ReplicaSet 并滚动替换 Pod：

kubectl set image deployment/demo-api \
  api=registry.example.com/team/demo-api:1.4.3 \
  -n demo

kubectl rollout status deployment/demo-api -n demo --timeout=5m
kubectl rollout history deployment/demo-api -n demo
kubectl rollout undo deployment/demo-api -n demo

回滚只能恢复 Deployment 模板，不能自动回滚数据库迁移、消息格式和外部副作用。发布设计应保持前后版本兼容，数据库采用 expand-and-contract 等策略。

maxUnavailable 与 maxSurge 控制发布期间最少可用和额外副本。readiness 决定新 Pod 何时接收流量，terminationGracePeriodSeconds 和 preStop 帮助旧 Pod 优雅退出。

PodDisruptionBudget 限制自愿中断期间同时不可用的副本数，但不防止节点突然故障：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-api
  namespace: demo
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: demo-api

高可用还要求副本跨节点和可用区分布、入口和依赖冗余、容量余量以及真正可执行的故障恢复流程。

15. Namespace、RBAC 与运行时安全¶

Namespace 提供命名和策略边界，但不是强安全沙箱。不同团队或环境应结合 Namespace、RBAC、NetworkPolicy、ResourceQuota 和独立身份治理。

ServiceAccount 是 Pod 在 Kubernetes API 中的身份。默认不要自动挂载不需要的令牌：

spec:
  template:
    spec:
      serviceAccountName: demo-api
      automountServiceAccountToken: false

安全上下文示例：

spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: api
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

如果应用需要临时写入，单独挂载 emptyDir 到明确目录，不要因此把整个根文件系统改回可写。

NetworkPolicy 定义允许的 Pod 网络流量，但只有 CNI 插件支持策略时才生效。采用默认拒绝后按需开放，比假设集群内部天然可信更安全。

RBAC 遵循最小权限。先用 kubectl auth can-i 验证：

kubectl auth can-i get pods -n demo
kubectl auth can-i create secrets -n demo \
  --as system:serviceaccount:demo:demo-api

16. Helm、Kustomize 与 GitOps¶

原始 YAML 适合学习和少量资源；环境与应用增多后需要可维护的配置组织。

Kustomize 通过 base 和 overlay 对 YAML 做结构化差异，kubectl 原生支持：

kubectl kustomize overlays/staging
kubectl diff -k overlays/staging
kubectl apply -k overlays/staging

Helm 用 Chart 打包模板、默认值和依赖，适合分发可配置应用：

helm lint ./chart
helm template demo ./chart -f values-staging.yaml
helm upgrade --install demo ./chart \
  --namespace demo --create-namespace \
  -f values-staging.yaml --wait --timeout 5m
helm history demo -n demo
helm rollback demo 1 -n demo

模板渲染成功不表示资源语义正确，发布前仍需 schema、策略和 diff 检查。

GitOps 把 Git 中的声明状态作为来源，由集群内控制器持续同步。它能提高审计和恢复能力，但秘密管理、紧急变更、控制器权限和错误配置扩散仍需治理。无论使用何种工具，都应保留“谁批准、发布了什么、怎样回滚”的记录。

17. Kubernetes 分层排错¶

排错从资源状态开始，再看事件、日志、网络和节点，不要直接删除 Pod 期待问题消失。

kubectl get pods -n demo -o wide
kubectl describe pod POD -n demo
kubectl get events -n demo --sort-by=.lastTimestamp
kubectl logs POD -n demo --all-containers --tail=200
kubectl logs POD -n demo -c api --previous

常见状态：

状态	常见原因	第一检查点
Pending	资源不足、PVC、污点或调度约束	Pod events、scheduler 信息
ImagePullBackOff	镜像名、凭据、网络或限流	image、imagePullSecrets、events
CrashLoopBackOff	主进程重复退出	当前与 `--previous` 日志、退出码
Running 但 NotReady	readiness 失败	probe、端口、依赖和应用日志
OOMKilled	内存超过限制或泄漏	last state、limit、内存指标
Terminating 很久	finalizer、volume 或进程不退出	describe、finalizers、节点状态

Service 无法访问¶

kubectl get svc,endpoints,endpointslices -n demo
kubectl get pods -n demo -l app=demo-api --show-labels
kubectl run net-debug --rm -it --restart=Never \
  --image=curlimages/curl -n demo -- sh

在临时 Pod 中依次验证 DNS、Service 端口和目标 HTTP。没有 endpoint 通常是 selector 不匹配或 Pod 未 Ready；有 endpoint 仍失败则检查 targetPort、应用监听地址、NetworkPolicy 和 CNI。

临时调试¶

kubectl exec -it POD -n demo -- sh
kubectl port-forward service/demo-api 8080:80 -n demo
kubectl top pod -n demo
kubectl top node

精简镜像可能没有 shell 和诊断工具，可使用 kubectl debug 临时容器；生产环境应限制其权限并记录使用。修改线上 Pod 内文件不是持久修复，Pod 重建后会丢失，正确修复应进入镜像或声明配置。

18. Docker 与 Kubernetes 命令速查¶

Docker¶

目的	命令
查看容器	`docker ps -a`
启动容器	`docker run --name NAME -d IMAGE`
查看日志	`docker logs --tail 100 -f NAME`
进入容器	`docker exec -it NAME sh`
查看详情	`docker inspect NAME`
查看资源	`docker stats`
构建镜像	`docker build -t NAME:TAG .`
查看镜像	`docker image ls`
磁盘占用	`docker system df`
清理未用资源	`docker system prune`

清理命令执行前先查看对象和数据依赖；带 -a 或 --volumes 会扩大删除范围。

Compose¶

目的	命令
验证配置	`docker compose config`
启动并构建	`docker compose up -d --build`
查看状态	`docker compose ps`
聚合日志	`docker compose logs -f SERVICE`
容器内执行	`docker compose exec SERVICE COMMAND`
一次性任务	`docker compose run --rm SERVICE COMMAND`
停止并删除容器	`docker compose down`

kubectl¶

目的	命令
查看资源	`kubectl get TYPE -n NS -o wide`
查看细节和事件	`kubectl describe TYPE NAME -n NS`
声明式应用	`kubectl apply -f FILE`
预览差异	`kubectl diff -f FILE`
查看日志	`kubectl logs POD -n NS -c CONTAINER`
上一次容器日志	`kubectl logs POD -n NS --previous`
容器内执行	`kubectl exec -it POD -n NS -- sh`
端口转发	`kubectl port-forward svc/NAME LOCAL:REMOTE -n NS`
发布状态	`kubectl rollout status deploy/NAME -n NS`
回滚	`kubectl rollout undo deploy/NAME -n NS`
解释字段	`kubectl explain RESOURCE.FIELD`
权限确认	`kubectl auth can-i VERB RESOURCE -n NS`

19. 延伸阅读¶

Docker 官方文档：Engine、Dockerfile、Compose 和 Build
Compose Specification：Compose 文件规范
OCI Image Specification：容器镜像开放标准
Kubernetes 官方文档：概念、任务与 API
kubectl 速查表：常用集群命令
Kubernetes 工作负载：Pod 与各类控制器
Kubernetes 服务、负载均衡和网络：Service、Ingress 和网络模型
Kubernetes 安全：RBAC、Pod Security 与集群安全
Helm 文档：Chart、模板和发布管理
Kustomize 文档：基于 overlay 的配置管理