Cloud Native on Snow

K8s 容器云平台服务部署流程：从 Dockerfile 打包镜像到上线

Thu, 03 Sep 2026 22:11:19 +0800

K8s 容器云平台服务部署流程：从 Dockerfile 打包镜像到上线

最近在公司内部 K8s 容器云平台上部署服务，最大的感受是：平台页面上的“创建应用”只是最后一步，真正决定部署是否顺利的，是前面这条链路：代码能稳定构建 → Dockerfile 写得正确 → 镜像能在本地跑起来 → 镜像能推到仓库 → K8s 能拉取镜像并通过探针验证服务健康。

这篇文章按一次真实上线的顺序来讲，并以中国电信云 CeakE 容器服务 CKE 的控制台为例展示具体操作。不同平台的页面名称可能不同，但只要底层是 Kubernetes，工作负载、Service、Ingress、探针和滚动更新等概念都能一一对应。

flowchart LR A[代码仓库] --> B[编写 Dockerfile] B --> C[本地构建镜像] C --> D[本地运行验证] D --> E[推送镜像仓库] E --> F[容器云平台创建工作负载] F --> G[配置 Service 和 Ingress] G --> H[发布验证和回滚预案]

一、部署前先确认什么

先把需要的信息列清楚，后面就不会在平台页面里边填边猜。

准备项	需要确认什么	常见示例
服务启动方式	本地如何启动，监听哪个端口	`java -jar app.jar`、`./server`、`npm start`，端口 `8080`
Dockerfile	是否在项目根目录，是否能完整构建运行环境	`Dockerfile`、`.dockerignore`
镜像仓库	仓库地址、项目名、账号权限	`registry.example.com/team/order-api`
平台命名空间	服务要部署到哪个项目 / Namespace	`team-dev`、`team-test`、`team-prod`
配置来源	哪些是环境变量，哪些是密钥	`APP_ENV`、数据库地址、Token
网络入口	只集群内访问，还是需要外部域名	`ClusterIP`、`Ingress`、`Route`、网关
资源规格	CPU、内存、磁盘、实例数	`requests: 200m/256Mi`，`limits: 1/1Gi`
健康检查	平台用哪个接口判断服务可用	`/healthz`、`/actuator/health`

容器云平台通常会把 Kubernetes 的对象包装成更好填的表单。它们之间大概是这个关系：

平台页面里的名字	Kubernetes 对象	主要作用
应用 / 工作负载	`Deployment`	管理 Pod 副本、滚动更新和回滚
实例 / 容器组	`Pod`	真正运行容器的最小单元
服务	`Service`	给一组 Pod 提供稳定的集群内访问地址
路由 / 域名 / 网关	`Ingress` 或平台自定义入口	把外部 HTTP/HTTPS 流量转进集群
配置	`ConfigMap`	注入非敏感配置
密钥	`Secret`	注入密码、Token、证书等敏感信息
镜像拉取凭据	`imagePullSecret`	让节点有权限从私有镜像仓库拉镜像

一句话：平台最终还是把你填的内容转成 Kubernetes 资源，只是帮你隐藏了一部分 YAML。

二、重点：根据 Dockerfile 打包镜像

Dockerfile 是镜像的构建说明书。K8s 不会拿你的源代码直接运行，它只会根据 Deployment 里的 image 字段去镜像仓库拉一个镜像，然后把这个镜像启动成容器。

所以不要把“部署失败”一上来就归因于平台。很多问题其实发生在镜像阶段：

镜像里没有复制到正确的产物；
容器启动命令写错；
服务监听了 127.0.0.1，导致 Pod 外部访问不到；
本地能访问的配置文件没有放进镜像，也没有通过环境变量注入；
镜像架构不对，比如在 ARM 机器上构建了 linux/arm64，但集群节点是 linux/amd64；
私有仓库权限或 Tag 写错，导致 ImagePullBackOff。

1. 先理解 Dockerfile 常用指令

指令	作用	注意点
`FROM`	指定基础镜像	尽量使用明确版本，不要只写 `latest`
`WORKDIR`	设置容器内工作目录	后续 `COPY`、`RUN`、`CMD` 都会基于它执行
`COPY`	把构建上下文里的文件复制进镜像	优先用 `COPY`，除非确实需要 `ADD` 的额外能力
`RUN`	构建镜像时执行命令	常用于安装依赖、编译代码、清理缓存
`ARG`	构建期变量	构建完成后默认不会保留为运行时环境变量
`ENV`	运行期环境变量默认值	不要把密码写进 `ENV`
`EXPOSE`	声明容器监听端口	只是元数据，不等于真正开放端口
`USER`	指定运行用户	生产环境建议不要用 `root` 跑应用
`ENTRYPOINT`	固定启动入口	适合固定主进程
`CMD`	默认启动参数或命令	可以被 `docker run` 后面的参数覆盖

镜像构建还有一个容易被忽略的概念：构建上下文。下面命令最后的 . 不是装饰，它表示把当前目录作为构建上下文发给 Docker：

`1`	`docker build -t registry.example.com/team/order-api:1.0.0 .`

如果项目目录里有 .git、node_modules、target、日志、临时文件，都会影响构建速度，甚至把不该进入镜像的文件带进去。因此项目根目录建议放一个 .dockerignore：

.git
.github
.idea
.vscode
node_modules
target
dist
build
*.log
.env
.env.*
README.md

.dockerignore 的目标不是“少传几个文件”这么简单，它直接影响三件事：构建速度、镜像安全、缓存命中率。

2. 一个通用的镜像构建流程

无论是 Go、Java、Node.js 还是 Python 服务，打包镜像都可以按这条路径走：

flowchart TD A[确认本地构建命令] --> B[编写 .dockerignore] B --> C[编写 Dockerfile] C --> D[docker build 构建镜像] D --> E[docker run 本地验证] E --> F[打 Tag] F --> G[docker login] G --> H[docker push 推送仓库] H --> I[平台使用该镜像部署]

先确认项目不用 Docker 也能构建成功：

# Java 示例
./mvnw clean package -DskipTests

# Go 示例
go test ./...
go build -o server ./cmd/server

# Node.js 示例
npm ci
npm run build

这一步很重要。Dockerfile 不是用来掩盖项目本身构建问题的。项目在本地基础构建都不稳定，放进 Docker 后只会更难排查。

3. Go 服务 Dockerfile 示例

Go 服务适合用多阶段构建：第一阶段负责编译，第二阶段只保留运行需要的二进制文件。

# syntax=docker/dockerfile:1

FROM golang:1.23-alpine AS builder
WORKDIR /src

RUN apk add --no-cache git ca-certificates

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o /out/server ./cmd/server

FROM alpine:3.20
WORKDIR /app

RUN addgroup -S app && adduser -S app -G app
COPY --from=builder /out/server /app/server
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

USER app
EXPOSE 8080
ENTRYPOINT ["/app/server"]

这个 Dockerfile 里有几个关键点：

写法	为什么这样做
`COPY go.mod go.sum ./` 后先 `go mod download`	依赖文件不变时可以复用缓存，加快后续构建
`CGO_ENABLED=0 GOOS=linux GOARCH=amd64`	构建适合 Linux x86 节点运行的静态二进制
第二阶段使用 `alpine`	镜像体积更小，运行层更干净
创建 `app` 用户并 `USER app`	避免容器内进程以 root 身份运行
只复制 `/out/server`	不把源码、编译缓存、测试文件带到最终镜像

构建命令：

`1`	`docker build -t registry.example.com/team/order-api:1.0.0 .`

本地运行验证：

docker run --rm --name order-api \
  -p 8080:8080 \
  -e APP_ENV=local \
  registry.example.com/team/order-api:1.0.0

curl http://localhost:8080/healthz

如果本地 curl 都不通，先不要推仓库，也不要上平台。优先检查：

应用实际监听端口是不是 8080；
应用是否监听 0.0.0.0，而不是只监听 127.0.0.1；
启动命令是否正确；
健康检查路径是否真实存在；
必需环境变量是否已经传入。

4. Java Spring Boot 服务 Dockerfile 示例

Spring Boot 服务也建议多阶段构建。构建阶段使用 JDK，运行阶段只使用 JRE。

# syntax=docker/dockerfile:1

FROM eclipse-temurin:21-jdk AS builder
WORKDIR /src

COPY mvnw pom.xml ./
COPY .mvn .mvn
RUN ./mvnw -q -DskipTests dependency:go-offline

COPY src src
RUN ./mvnw -q -DskipTests package

FROM eclipse-temurin:21-jre
WORKDIR /app

RUN useradd -r -u 10001 appuser
COPY --from=builder /src/target/*.jar /app/app.jar

USER appuser
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

如果服务需要 JVM 参数，不建议把所有参数写死在 Dockerfile 里。可以留给平台环境变量控制：

`1`	`ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]`

平台里再配置：

1
2

JAVA_OPTS=-Xms512m -Xmx512m -XX:+UseG1GC
SPRING_PROFILES_ACTIVE=prod

这里要注意：JAVA_OPTS 本身不是 Kubernetes 标准字段，它只是你的启动脚本或 ENTRYPOINT 读取的环境变量。写了环境变量但启动命令没使用，它就不会生效。

5. Node.js 服务 Dockerfile 示例

Node.js 服务重点是依赖缓存和不要把开发依赖带进运行镜像。

# syntax=docker/dockerfile:1

FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:22-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
RUN npm prune --omit=dev

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production

RUN addgroup -S app && adduser -S app -G app
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist

USER app
EXPOSE 3000
CMD ["node", "dist/server.js"]

如果你用的是前端静态站点，最终镜像可以不是 Node，而是 Nginx：

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

FROM nginx:1.27-alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80

6. 镜像 Tag 怎么命名

生产环境不建议只用 latest。latest 看起来方便，但它不可追踪：今天的 latest 和昨天的 latest 可能不是同一个镜像。

更实用的 Tag 规则：

1
2
3

registry.example.com/<团队>/<服务名>:<版本号>
registry.example.com/<团队>/<服务名>:<Git提交短SHA>
registry.example.com/<团队>/<服务名>:<环境>-<构建号>

示例：

1
2
3

docker build -t registry.example.com/pay/order-api:1.4.2 .
docker build -t registry.example.com/pay/order-api:git-a18c3f2 .
docker build -t registry.example.com/pay/order-api:test-20260903-001 .

我更推荐至少保留 Git 提交信息：

GIT_SHA=$(git rev-parse --short HEAD)
IMAGE=registry.example.com/pay/order-api:${GIT_SHA}

docker build -t ${IMAGE} .
docker push ${IMAGE}

这样平台回滚时，你能明确知道回到哪一次提交，而不是猜某个 Tag 当时指向什么。

如果公司平台支持使用镜像 Digest，生产环境还可以把 image 写成不可变形式：

`1`	`registry.example.com/pay/order-api@sha256:xxxxxxxxxxxxxxxx`

Tag 适合人看，Digest 更适合机器保证不可变。

7. 构建架构要和集群节点一致

如果你在 Mac M 系列、ARM 开发机或某些 CI Runner 上构建镜像，而公司 K8s 节点是 x86，那么需要特别关注镜像架构。

查看本地机器架构：

1
2

docker version
docker info

明确构建 linux/amd64 镜像：

docker buildx build \
  --platform linux/amd64 \
  -t registry.example.com/team/order-api:git-a18c3f2 \
  --push .

如果平台 Pod 报错类似 exec format error，优先怀疑镜像架构和节点架构不匹配。

8. 登录并推送镜像仓库

构建完成后，先确认本地有镜像：

`1`	`docker images \| grep order-api`

登录公司镜像仓库：

`1`	`docker login registry.example.com`

如果镜像 Tag 还不是仓库地址，需要重新打 Tag：

`1`	`docker tag order-api:local registry.example.com/pay/order-api:git-a18c3f2`

推送：

`1`	`docker push registry.example.com/pay/order-api:git-a18c3f2`

推送成功后，容器云平台才能从仓库拉到这个镜像。注意：K8s 集群不会使用你本机 Docker 里的镜像。除非是特殊的本地集群，生产平台只会从镜像仓库拉取。

三、在容器云平台创建工作负载

镜像准备好后，才进入平台部署阶段。下面结合控制台截图走一遍完整流程。

1. 进入集群并检查资源状态

在“容器 → 集群列表”中找到目标集群。进入控制台前先确认集群状态为“运行中”，并核对集群类型、版本、节点数和所属租户，避免把服务发布到错误的环境。

进入集群后的“概览”页会集中展示 Deployment、StatefulSet、DaemonSet、Job、CronJob 和 Pod 数量，以及节点健康状态、CPU、内存和磁盘使用情况。

发布前不要只看“节点健康”，还要同时检查资源水位和事件列表。截图里 CPU、内存都已经有一定占用；如果 requests 配得过大，Pod 可能因为剩余可分配资源不足而一直处于 Pending。事件列表中的 Warning 也应在发布前确认是否与目标项目或网络入口有关。

2. 先选对工作负载类型

左侧“工作负载”菜单并不只有 Deployment。平台把常见控制器和 Pod 分开列出，选择时可以按运行模式判断：

控制台入口	Kubernetes 对象	适用场景
无状态负载	`Deployment`	Web、API 等可横向扩容、实例可替换的服务
守护进程集	`DaemonSet`	每个节点运行一个实例，如日志采集、监控 Agent
有状态负载	`StatefulSet`	需要稳定网络标识、顺序发布或持久存储的服务
普通任务	`Job`	数据迁移、一次性计算等执行完成即退出的任务
定时任务	`CronJob`	按 Cron 表达式周期执行的任务
容器组	`Pod`	查看实际运行实例和排错，一般不直接创建长期业务 Pod

Deployment 列表中的“容器组（运行/期望）”、副本数和状态可以快速判断发布是否完成。比如 0/1 且状态为 Updating，说明新 Pod 还没有达到期望状态。

Pod 页面尤其适合排错：它同时展示状态、就绪容器数、重启次数、Pod IP 和所在节点。截图中的 CrashLoopBackOff 和异常高的重启次数就是明确的故障信号，此时应优先查看容器日志、上一轮日志和 Pod 事件，而不是先改 Service 或 Route。

3. 按四步向导创建 Deployment

在“无状态负载”页面点击“新建无状态工作负载”，控制台会依次进入基本信息、容器配置、服务配置和高级配置四个步骤。

第一步：基本信息

填写名称、项目（对应 Namespace）、实例数量和描述。测试环境可以先用 1 个实例验证；生产环境通常至少 2 个实例，并结合滚动更新策略保证发布期间仍有可用 Pod。

第二步：容器配置

容器镜像既可以从平台镜像仓库选择，也可以直接输入完整镜像地址。需要重点核对镜像 Tag、拉取策略以及 vCPU/内存的请求和限制：

使用不可变 Tag 时可以选 IfNotPresent；截图中的默认值是 Always，它适合同一 Tag 可能被覆盖的场景，但生产发布仍建议使用唯一 Tag；
不建议把 CPU、内存请求与限制都保持为“无限制”，至少要设置合理的 requests，生产环境再根据压测和监控设置 limits；
容器名称是 Pod 内的标识，不等于 Deployment 名称；一个 Pod 也可以配置多个容器。

向下滚动可以配置环境变量、启动命令、运行参数、工作目录、健康检查和存储卷。平台把 Kubernetes 的三类探针分别显示为存活检查（Liveness）、就绪检查（Readiness）和启动检查（Startup）：

Readiness 决定 Pod 是否加入 Service Endpoint，业务服务通常应该配置；
Liveness 用于判断是否需要重启容器，不要把偶发抖动的外部依赖放进检查逻辑；
启动慢的应用可使用 Startup Probe，避免还在启动时就被 Liveness 反复重启。

第三步：服务配置

这里可以绑定已有 Service，也可以直接新建。若当前工作负载暂时不需要被访问，可以先跳过，后续再从“网络 → 服务”中单独创建。

新建 Service 时要填写访问类型、服务端口、容器端口和协议。对普通内部服务优先使用 ClusterIP；NodePort 会在节点上开放端口；LoadBalancer 是否可用取决于云平台和负载均衡配置。最关键的是把 Service 正确绑定到工作负载标签，否则 Service 不会产生 Endpoint。

第四步：高级配置

高级配置上半部分包括 DNS 策略、额外 Hosts/网络，以及升级策略。常规场景保持 ClusterFirst；升级方式使用 RollingUpdate 时，需要结合副本数设置最大扩容 Pod 数（maxSurge）和最大不可用 Pod 数（maxUnavailable）。单副本服务若允许 maxUnavailable: 1，发布过程中会短暂不可用。

高级配置下半部分可以设置节点亲和性、工作负载亲和/反亲和、污点容忍、标签、注解、应用监控和私有镜像密钥。只有在确实需要指定节点、跨节点分散副本或访问私有仓库时再修改；不清楚含义时，先保留平台默认的调度配置。

四步表单最终仍会生成 Kubernetes Deployment。填写时可以用下面这张表快速对照：

配置项	推荐填法	说明
应用名称	`order-api`	尽量和服务名一致
命名空间	`team-test` / `team-prod`	区分环境和团队
镜像地址	`registry.example.com/pay/order-api:git-a18c3f2`	使用刚推送的镜像
副本数	测试 `1`，生产 `2+`	生产至少两个副本才有滚动更新意义
容器端口	`8080`	必须和应用实际监听端口一致
环境变量	平台表单或 ConfigMap	普通配置不要写死进镜像
密钥	Secret	密码、Token、证书不要写入 Dockerfile
CPU/内存	先小后调	requests 保证调度，limits 控制上限
健康检查	`/healthz` 或业务健康接口	Readiness 决定是否接流量
镜像拉取凭据	平台仓库凭据	私有仓库必填

如果用 YAML 表达，一个典型 Deployment 长这样：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  namespace: team-test
  labels:
    app: order-api
spec:
  replicas: 2
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      imagePullSecrets:
        - name: registry-secret
      containers:
        - name: order-api
          image: registry.example.com/pay/order-api:git-a18c3f2
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
          env:
            - name: APP_ENV
              value: "test"
          envFrom:
            - configMapRef:
                name: order-api-config
            - secretRef:
                name: order-api-secret
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: http
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /healthz
              port: http
            initialDelaySeconds: 30
            periodSeconds: 20
            timeoutSeconds: 2
            failureThreshold: 3

这里最值得关注的是三件事：

image 必须是平台节点能访问的完整镜像地址；
containerPort 必须和应用真实监听端口一致；
readinessProbe 不通过时，Pod 即使启动了也不会接收流量。

健康检查接口要轻量、稳定，最好只检查进程是否能处理请求，以及必要的本地依赖是否正常。不要把一堆下游系统都强绑定进去，否则某个非核心依赖抖动，会导致自己的 Pod 被平台摘流量甚至重启。

四、配置服务入口

Deployment 只负责让 Pod 跑起来。要让其他服务或用户访问它，还需要 Service 和 Ingress。

flowchart LR U[用户或上游服务] --> I[Ingress 或网关] I --> S[Service] S --> P1[Pod 1] S --> P2[Pod 2] S --> P3[Pod 3]

1. 创建 Service

“网络 → 服务”页面会显示访问方式、Cluster IP 或外部 IP，以及“服务端口 → 容器端口/协议”的映射关系。列表中的 ClusterIP、NodePort 和 LoadBalancer 对应三种不同暴露范围，不能只根据端口号判断服务是否能从公网访问。

新建 Service 时先选择项目和名称，再选择访问类型并配置端口：

表单字段	Kubernetes 字段	说明
服务端口	`spec.ports[].port`	客户端访问 Service 使用的端口
容器端口	`spec.ports[].targetPort`	流量最终转发到 Pod 的端口
访问类型	`spec.type`	`ClusterIP`、`NodePort` 或 `LoadBalancer`
绑定工作负载/标签	`spec.selector`	必须能匹配目标 Pod 的 labels
Session Hold	`sessionAffinity`	只有业务确实需要会话粘性时才开启

集群内访问一般用 Service：

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

这表示集群内其他服务可以通过类似下面的地址访问：

`1`	`http://order-api.team-test.svc.cluster.local`

如果需要外部 HTTP/HTTPS 访问，通常配置 Ingress、Route 或公司网关规则：

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

2. 创建 Route（Ingress）

该平台把 Ingress 放在“网络 → 路由”中。路由列表展示名称、绑定的 Service、项目和类型；一个路由可以包含多条后端规则。

新建路由时依次填写路由名称、项目、Ingress 类型、协议、域名、路径匹配方式、目标 Service 和目标端口。截图中的类型为 nginx、匹配方式为 Prefix，它们分别对应 Ingress Controller 和 pathType: Prefix。如果选择 HTTPS，还需要按平台要求配置 TLS 证书或 Secret。

平台页面里可能不会叫 Ingress，而是叫“域名”“路由”“七层负载均衡”或“应用入口”。无论名称如何，排错时都沿着 Route/Ingress → Service → Endpoint → Pod 这条链路逐层检查。

五、发布、验证和回滚

如果平台支持直接应用 YAML，可以这样发布：

1
2
3

kubectl apply -f k8s/
kubectl rollout status deployment/order-api -n team-test
kubectl get pods -n team-test -l app=order-api -o wide

常用验证命令：

# 看 Pod 是否 Ready
kubectl get pods -n team-test -l app=order-api

# 看 Deployment 发布状态
kubectl describe deployment order-api -n team-test

# 看某个 Pod 事件
kubectl describe pod <pod-name> -n team-test

# 看日志
kubectl logs -f deployment/order-api -n team-test

# 临时端口转发验证服务
kubectl port-forward svc/order-api 8080:80 -n team-test
curl http://localhost:8080/healthz

如果新版本有问题，先暂停扩散，再回滚：

1
2
3

kubectl rollout history deployment/order-api -n team-test
kubectl rollout undo deployment/order-api -n team-test
kubectl rollout status deployment/order-api -n team-test

平台控制台一般也会提供“版本历史”“回滚”“重新部署”按钮。无论用页面还是命令，本质都是修改 Deployment 的 Pod Template，让控制器重新创建一批 Pod。

六、常见问题速查

现象	可能原因	排查方向
`ImagePullBackOff`	镜像地址错、Tag 不存在、仓库无权限	查镜像仓库、`imagePullSecret`、Pod 事件
`ErrImagePull`	节点拉镜像失败	`kubectl describe pod` 看具体错误
`CrashLoopBackOff`	容器启动后反复退出	看 `kubectl logs --previous`，检查启动命令和环境变量
`Running` 但 `0/1 Ready`	Readiness Probe 不通过	检查健康检查路径、端口、超时设置
外部访问 404	Ingress 路径或域名规则不匹配	查 Ingress 规则、网关转发路径
外部访问 502/503	Service 没有可用 Endpoint	查 Pod Ready 状态、Service selector
连接数据库失败	Secret、网络策略、白名单、DNS 配置问题	查环境变量、凭据、网络连通性
`OOMKilled`	内存超过 limit	提高 limit，分析内存峰值，调整 JVM/运行时参数
`exec format error`	镜像架构和节点架构不一致	用 `docker buildx --platform linux/amd64` 重构建
修改镜像后平台没更新	Tag 没变且拉取策略未强制拉取	使用新 Tag，或调整 `imagePullPolicy`

排错时建议按这个顺序看：

flowchart TD A[Pod 是否创建] -->|没有| B[看 Deployment 事件] A -->|已创建| C[镜像是否拉取成功] C -->|失败| D[查镜像地址和仓库权限] C -->|成功| E[容器是否启动] E -->|失败| F[查启动命令和日志] E -->|成功| G[Pod 是否 Ready] G -->|失败| H[查 Readiness Probe] G -->|成功| I[Service 是否有 Endpoint] I -->|没有| J[查 selector 和 label] I -->|有| K[查 Ingress 或网关规则]

七、上线前检查清单

检查项	通过标准
Dockerfile 可重复构建	换一台机器或 CI 也能 `docker build` 成功
镜像本地可运行	`docker run` 后健康检查通过
镜像 Tag 可追踪	Tag 包含版本号、构建号或 Git SHA
镜像已推送仓库	平台能看到或拉取该镜像
配置未写死进镜像	环境差异通过 ConfigMap / Secret 注入
密码未进入 Dockerfile	不在 `ENV`、源码、镜像层里保存敏感信息
资源限制已配置	设置合理的 requests 和 limits
探针已配置	Readiness 和 Liveness 路径真实可用
Service selector 正确	Service 能找到 Pod Endpoint
入口规则已验证	域名、路径、证书、网关转发正常
回滚方式明确	知道上一版镜像 Tag 或 Deployment revision
日志和监控可用	上线后能看日志、指标和告警

总结

在公司 K8s 容器云平台部署服务，可以把流程压缩成一句话：

先用 Dockerfile 把服务变成可运行、可追踪、可推送的镜像，再让 K8s 用 Deployment 管理副本，用 Service 稳定访问，用 Ingress 或网关承接外部流量。

真正建议养成的习惯有四个：

镜像先本地跑通，再推仓库；
每次发布使用唯一 Tag，不依赖 latest；
配置和密钥交给平台注入，不写死进镜像；
上线前准备好健康检查、日志查看和回滚路径。

只要这条链路稳定，平台部署就会从“填表碰运气”变成“标准化交付流程”。

从 Docker 到 Kubernetes：面向 Docker 用户的 K8s 从 0 到 1 教程

Sat, 08 Aug 2026 18:32:47 +0800

从 Docker 到 Kubernetes：面向 Docker 用户的 K8s 从 0 到 1 教程

你已经学过 Docker，说明你已经知道镜像、容器、端口映射、环境变量和日志这些东西。Kubernetes 的入门难点不在于“又多了几个命令”，而在于它把单机容器运行，升级成了面向集群的声明式应用管理。

本文会从 Docker 用户最熟悉的视角切入，带你完成一条完整路径：

学完后你应该能做到	对应能力
看懂 Pod、Deployment、Service、ConfigMap、Secret、Ingress	理解 K8s 核心资源
在本地启动一个 K8s 集群	用 Docker Desktop、kind 或 minikube 做实验
把一个 Nginx 应用部署到集群	编写并应用 YAML
暴露服务并在浏览器访问	使用 Service、port-forward、Ingress
扩缩容、滚动更新、回滚	掌握发布运维基本动作
排查常见错误	用 `kubectl describe`、`logs`、`exec`、`events` 定位问题

本文不追求把 Kubernetes 的所有概念一次塞完。先把主干跑通，再回头补网络、存储、权限、调度和生产治理，学习效率会高很多。

一、先换脑：Docker 管一台机器，K8s 管一组机器

用 Docker 时，你常常是在一台机器上执行：

`1`	`docker run -d --name web -p 8080:80 -e APP_ENV=prod nginx:alpine`

这条命令已经包含了很多信息：用什么镜像、叫什么容器、暴露什么端口、传什么环境变量、后台运行。

到了 Kubernetes，思路会变成：

我不直接告诉某台机器“启动这个容器”，我向集群提交一份 YAML，声明“我希望有 3 个副本一直运行，并通过一个稳定服务入口访问”。至于 Pod 放在哪个节点、挂了以后谁重建、更新时怎么替换，交给 Kubernetes 的控制器处理。

可以先用这张表记住最常用的映射：

Docker 里你熟悉的东西	Kubernetes 里的对应概念	变化点
Container	Pod	Pod 是调度最小单位，里面通常放一个主容器
`docker run`	Deployment	不只启动一次，而是持续维护期望副本数
`-p 8080:80`	Service / Ingress	容器 IP 会变，访问入口需要抽象出来
`-e` / `.env`	ConfigMap / Secret	配置从镜像里拆出来，由集群注入
`docker logs`	`kubectl logs`	查看 Pod 或 Deployment 的日志
`docker exec`	`kubectl exec`	进入某个 Pod 内部排查
Docker Compose	多个 K8s YAML 或 Helm Chart	从本地多容器编排变成集群资源编排

一句话总结：Docker 解决“容器怎么打包和运行”，Kubernetes 解决“很多容器如何在集群里持续稳定运行”。

二、K8s 集群到底长什么样

Kubernetes 集群通常由两类角色组成：

角色	负责什么	可以怎么理解
Control Plane 控制面	接收 API 请求、保存状态、调度 Pod、运行控制器	集群的大脑
Worker Node 工作节点	真正运行 Pod，维护容器网络和节点状态	集群的工人

你平时敲的 kubectl 并不是直接控制容器，而是向 API Server 发请求。API Server 把你提交的资源写进集群状态，控制器再不断把“实际状态”调整成“期望状态”。

这就是 Kubernetes 最核心的机制：声明式 + 控制循环。

举个例子：

你声明 replicas: 3。
控制器发现当前只有 2 个 Pod。
控制器创建第 3 个 Pod。
某个 Pod 挂了，实际状态又变成 2 个。
控制器继续补回 3 个。

所以 K8s 不是一个“执行脚本工具”，而是一个持续工作的状态管理系统。

三、准备本地实验环境

如果你已经学过 Docker，大概率已经安装了 Docker Desktop。入门阶段有三条常见路线：

方案	适合谁	特点
Docker Desktop 内置 Kubernetes	Windows / macOS 新手	图形界面开启，最省事
kind	已经熟悉 Docker CLI 的人	用 Docker 容器模拟 K8s 节点，创建和删除很快
minikube	想体验更完整本地集群的人	插件丰富，文档多，适合学习

无论选择哪种方式，最终目标都一样：让 kubectl 能连上一个可用集群。

1
2
3

kubectl version --client
kubectl get nodes
kubectl get namespaces

如果能看到节点，说明本地集群已经可用：

1
2

NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   10m   v1.xx.x

如果你还没有安装工具，建议优先看官方入口：

kubectl 安装入口：Install and Set Up kubectl
kind 快速开始：kind Quick Start
minikube 快速开始：minikube start

本教程后面的命令只依赖通用的 kubectl，不强绑定某个本地集群方案。

四、先用命令跑一个应用

先不用急着写 YAML，先用命令感受一下 Kubernetes 如何运行容器。

1
2
3

kubectl create deployment web --image=nginx:1.27-alpine --port=80
kubectl get deployments
kubectl get pods -o wide

你会看到 Kubernetes 创建了一个 Deployment，并由它管理一个 Pod。

1
2

kubectl expose deployment web --type=ClusterIP --port=80
kubectl get services

ClusterIP 只能在集群内部访问。为了在本机浏览器打开它，可以临时做端口转发：

`1`	`kubectl port-forward service/web 8080:80`

然后打开：

`1`	`http://localhost:8080`

你应该能看到 Nginx 欢迎页。

这个过程和 Docker 很像：

Docker	Kubernetes
`docker run nginx`	`kubectl create deployment web --image=nginx`
`docker ps`	`kubectl get pods`
`docker logs <container>`	`kubectl logs <pod>`
`docker stop <container>`	`kubectl delete pod <pod>`，但 Deployment 会自动拉起新 Pod

注意最后一点：如果你直接删除 Pod，它会被自动重建。

1
2

kubectl delete pod <你的 Pod 名字>
kubectl get pods

这就是 Deployment 的价值：它关心的是“应该有几个 Pod 活着”，而不是“某个具体 Pod 必须永远活着”。

五、真正入门：用 YAML 声明应用

命令适合体验，真正的 Kubernetes 项目会把资源写成 YAML，和代码一起进 Git。这样才方便审查、回滚、复用和自动化部署。

新建一个 app.yaml：

apiVersion: v1
kind: Namespace
metadata:
  name: k8s-lab
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: k8s-lab
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "50m"
              memory: "64Mi"
            limits:
              cpu: "200m"
              memory: "128Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: k8s-lab
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

应用它：

1
2

kubectl apply -f app.yaml
kubectl -n k8s-lab get deployments,replicasets,pods,services -o wide

再访问：

`1`	`kubectl -n k8s-lab port-forward service/web 8080:80`

这里有几个字段必须理解：

字段	作用
`apiVersion`	资源使用哪个 API 版本
`kind`	资源类型，比如 Deployment、Service
`metadata.name`	资源名字
`metadata.namespace`	资源所在命名空间
`spec`	你期望资源长什么样
`selector.matchLabels`	Deployment 如何找到自己管理的 Pod
`template.metadata.labels`	Pod 身上的标签
`replicas`	期望副本数
`resources.requests`	调度时预留的资源
`resources.limits`	容器最多能用多少资源
`readinessProbe`	Pod 是否准备好接流量
`livenessProbe`	Pod 是否还活着，失败后可重启

最容易写错的是 selector 和 labels。Deployment 的 selector.matchLabels 必须匹配 Pod 模板里的 template.metadata.labels，否则 Deployment 找不到自己要管理的 Pod。

日常开发里，你可以先记住这条链：

1
2

Deployment -> ReplicaSet -> Pod
Service -> 根据 label 找到一组 Pod -> 提供稳定访问入口

六、发布、扩缩容和回滚

Kubernetes 的发布能力主要围绕 Deployment 展开。

查看当前发布状态：

1
2

kubectl -n k8s-lab rollout status deployment/web
kubectl -n k8s-lab rollout history deployment/web

扩容到 5 个副本：

1
2

kubectl -n k8s-lab scale deployment/web --replicas=5
kubectl -n k8s-lab get pods

缩回 3 个副本：

`1`	`kubectl -n k8s-lab scale deployment/web --replicas=3`

更新镜像：

1
2

kubectl -n k8s-lab set image deployment/web nginx=nginx:stable-alpine
kubectl -n k8s-lab rollout status deployment/web

如果更新后发现有问题，回滚：

1
2

kubectl -n k8s-lab rollout undo deployment/web
kubectl -n k8s-lab rollout status deployment/web

这里的关键点是：Kubernetes 默认会滚动更新。它不会一次性杀掉所有旧 Pod，而是逐步创建新 Pod、等待新 Pod 就绪，再替换旧 Pod。

生产环境里不要随便用 latest 镜像标签。更推荐使用不可变版本号，例如：

`1`	`registry.example.com/team/web:2026-08-08-1730-a1b2c3d`

这样你才能知道线上到底跑的是哪一次构建，也方便回滚和审计。

七、配置和密钥：不要把所有东西塞进镜像

在 Docker 里你可能会这样传环境变量：

`1`	`docker run -e APP_MODE=prod -e API_TOKEN=xxx my-app:1.0`

在 Kubernetes 里，普通配置通常放 ConfigMap，敏感信息通常放 Secret。

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-config
  namespace: k8s-lab
data:
  APP_MODE: "demo"
  WELCOME_TEXT: "Hello Kubernetes"
---
apiVersion: v1
kind: Secret
metadata:
  name: web-secret
  namespace: k8s-lab
type: Opaque
stringData:
  API_TOKEN: "replace-me"

在 Deployment 里注入：

envFrom:
  - configMapRef:
      name: web-config
  - secretRef:
      name: web-secret

完整位置是在容器配置下：

containers:
  - name: nginx
    image: nginx:1.27-alpine
    envFrom:
      - configMapRef:
          name: web-config
      - secretRef:
          name: web-secret

需要注意：Kubernetes 的 Secret 默认只是做了编码和访问控制，不等于天然加密保险箱。生产环境要结合 RBAC、etcd 加密、外部密钥系统和最小权限一起设计。

八、Service 和 Ingress：应用怎么被访问

Pod 的 IP 会变，不能把 Pod IP 当成长期入口。Service 的作用就是给一组 Pod 一个稳定入口。

常见入口方式：

方式	解决什么问题	适合场景
`ClusterIP`	集群内部访问	默认方式，服务之间互调
`NodePort`	从节点端口访问服务	本地实验、临时调试
`LoadBalancer`	云厂商创建外部负载均衡	云上生产入口
`Ingress`	基于域名和路径转发 HTTP/HTTPS	Web 服务生产入口
`port-forward`	本机临时转发到 Pod 或 Service	开发调试

本地学习最稳的是 port-forward：

`1`	`kubectl -n k8s-lab port-forward service/web 8080:80`

Ingress 需要先安装或启用 Ingress Controller。启用后，一个典型 Ingress 资源长这样：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: k8s-lab
spec:
  rules:
    - host: web.localtest.me
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

可以把 Ingress 理解成集群入口处的 HTTP 路由器。它不是直接替代 Service，而是把外部 HTTP 流量转发到 Service，再由 Service 转到后面的 Pod。

九、排错：先看状态，再看事件和日志

初学 K8s 最常见的挫败感是：YAML 已经 apply 了，但服务就是访问不了。不要靠猜，按固定路线排。

先看资源是否存在：

`1`	`kubectl -n k8s-lab get deployments,pods,services -o wide`

看 Pod 详情和事件：

`1`	`kubectl -n k8s-lab describe pod <pod-name>`

看日志：

1
2

kubectl -n k8s-lab logs <pod-name>
kubectl -n k8s-lab logs deployment/web

进入容器：

`1`	`kubectl -n k8s-lab exec -it <pod-name> -- sh`

按时间查看事件：

`1`	`kubectl -n k8s-lab get events --sort-by=.metadata.creationTimestamp`

常见状态可以这样判断：

状态	常见原因	优先看什么
`ImagePullBackOff`	镜像名、tag、仓库权限错误	`describe pod` 的 Events
`CrashLoopBackOff`	应用启动后反复退出	`logs`
`Pending`	没有合适节点、资源不足、PVC 未绑定	`describe pod`
`Running` 但访问不了	Service selector 错、端口错、readiness 未通过	`get svc`、`describe endpoints`
`OOMKilled`	内存超过 limit	`describe pod`、资源配置

一个非常实用的检查顺序：

kubectl get pods
-> kubectl describe pod
-> kubectl logs
-> kubectl get svc/endpoints
-> kubectl exec
-> kubectl get events

如果你在 Docker 里已经习惯了 logs 和 exec，K8s 排错并不陌生，只是目标对象从“容器”变成了“Pod 和资源清单”。

十、从能跑到能用：下一步学什么

学完本文，你已经有了 Kubernetes 的主干认知。后面建议按这个顺序补：

阶段	重点	为什么先学它
基础资源	Pod、Deployment、Service、ConfigMap、Secret、Namespace	每天都会用
发布能力	RollingUpdate、Rollback、健康检查、资源限制	直接影响稳定性
网络入口	Service、Ingress、DNS、NetworkPolicy	解决服务访问和隔离
存储	Volume、PVC、StorageClass	有状态应用必需
权限	ServiceAccount、Role、RoleBinding、RBAC	多人和生产集群必需
包管理	Kustomize、Helm	管理复杂 YAML
运维观测	Metrics、日志、Tracing、告警	线上排障必需

最后清理实验环境：

`1`	`kubectl delete namespace k8s-lab`

如果你用 kind 或 minikube 创建了专门的本地集群，可以继续删除集群：

1
2

kind delete cluster --name k8s-lab
minikube delete

Kubernetes 入门时不要急着背所有资源。先记住这条线：

1
2
3

镜像 -> Deployment -> Pod -> Service -> Ingress
配置 -> ConfigMap / Secret
运维 -> rollout / scale / logs / describe / exec

这条线跑通了，你就已经从“会用 Docker 跑容器”，走到了“会用 Kubernetes 管应用”的门口。

参考资料

Docker、Kubernetes、OpenShift 的关系、特点与区别

Sat, 08 Aug 2026 18:03:11 +0800

Docker、Kubernetes、OpenShift 的关系、特点与区别

很多人学习云原生时会先听到 Docker，然后听到 Kubernetes，最后又遇到 OpenShift。三者经常被放在一起讨论，但它们不是同一层面的工具：Docker 偏应用打包与容器运行，Kubernetes 偏集群编排，OpenShift 则是在 Kubernetes 之上做企业级平台化。

先给出一句话版本：

工具	一句话定位	主要解决的问题
Docker	容器工具链	如何把应用和依赖打成镜像，并在单机上稳定运行
Kubernetes / K8s	容器编排平台	如何在多台机器上调度、发布、扩缩容和自愈容器化应用
OpenShift	企业级 Kubernetes 平台	如何把 Kubernetes 变成适合多团队、合规、安全、运维和交付的平台

一、三者关系：不是替代链，而是职责分层

很多误解来自一句话：“Kubernetes 替代了 Docker。”这句话不严谨。

更准确的说法是：

Docker 让开发者更容易构建镜像、运行容器、管理本地开发环境。
Kubernetes 不关心你必须用 Docker 来构建镜像，它关心的是：集群里应该跑哪些 Pod、跑几个副本、挂什么配置、暴露什么服务、怎么滚动升级。
OpenShift 基于 Kubernetes，并额外提供企业常用的平台能力，比如 Web 控制台、项目隔离、Route、构建流水线、Operator、安全策略、身份认证和平台运维工具。

这里有两个关键点：

Kubernetes 不等于 Docker：Kubernetes 通过 CRI（Container Runtime Interface）对接容器运行时，常见运行时包括 containerd、CRI-O 等。早期 Kubernetes 曾通过 dockershim 直接集成 Docker Engine，但 dockershim 已从 Kubernetes v1.24 起移除。
OpenShift 不等于另一个 Kubernetes 替代品：OpenShift 仍然是 Kubernetes，底层 API、Pod、Deployment、Service、ConfigMap、Secret 等核心资源都来自 Kubernetes。它的价值在于把 Kubernetes 产品化、平台化、企业化。

如果用一个分层视角来看：

二、Docker：把应用装进标准化容器

Docker 最核心的价值是把“应用如何运行”标准化。

传统部署里，一个应用能否跑起来，取决于目标机器是否安装了正确版本的 JDK、Python、Node.js、系统库、配置文件和环境变量。Docker 的思路是：把应用代码、运行时、系统依赖和启动命令一起打包成镜像，然后用这个镜像启动容器。

1. Docker 的核心概念

概念	作用	你可以怎么理解
Dockerfile	描述镜像如何构建	一份“环境装配说明书”
Image 镜像	只读模板，包含运行应用所需文件、依赖和配置	应用交付包
Container 容器	镜像的运行实例	真正在跑的进程环境
Registry 镜像仓库	存储和分发镜像	容器镜像的制品仓库
Docker Compose	用一个 YAML 文件定义多容器本地环境	本地开发环境编排工具

一个非常典型的 Dockerfile 可能长这样：

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

这个文件表达的是：

基于 node:22-alpine 做基础环境；
把项目文件复制进去；
安装依赖；
声明端口；
指定容器启动命令。

开发机、测试环境、生产环境只要运行同一个镜像，运行方式就能大幅一致。

2. Docker 的特点

Docker 的优势很明显：

环境一致：镜像包含运行所需依赖，减少“我电脑上可以跑”的问题。
交付标准化：镜像可以用 Tag、Digest、签名、扫描等方式纳入制品管理。
启动快、资源轻：容器共享宿主机内核，通常比虚拟机更轻量。
本地开发体验好：Docker Desktop、Docker CLI、Docker Compose 让本地起 MySQL、Redis、Nginx 等依赖非常方便。
生态成熟：Docker Hub 和各类镜像仓库提供大量现成基础镜像。

3. Docker 的边界

Docker 很适合解决“一个容器怎么构建、怎么运行”的问题，但它不是完整的生产集群平台。

当应用变成几十个服务、几百个容器、横跨多台服务器时，你还需要回答：

容器应该调度到哪台机器？
某台机器挂了，服务如何自动恢复？
如何让多个副本滚动升级？
如何做服务发现和负载均衡？
如何控制配置、密钥、存储、网络策略？
如何让平台维持“期望状态”？

这些就是 Kubernetes 的主场。

三、Kubernetes：让一群容器按期望状态运行

Kubernetes，常简称 K8s，是容器编排平台。它的核心不是“启动一个容器”，而是“让一组容器化应用在集群中长期稳定运行”。

Kubernetes 的关键思想是 声明式 API + 控制循环。

你告诉 Kubernetes：“我希望这个服务永远有 3 个副本，使用这个镜像，对外暴露 80 端口。”Kubernetes 会不断观察真实状态，如果发现只剩 2 个副本，就再拉起 1 个；如果某个节点不可用，就把工作负载调度到其他节点。

1. K8s 的核心对象

对象	作用
Cluster	一组运行 Kubernetes 的机器
Node	集群中的工作节点，可以是虚拟机或物理机
Pod	Kubernetes 最小调度单元，内部可以包含一个或多个容器
Deployment	声明无状态应用的副本数、镜像版本和滚动更新策略
Service	为一组 Pod 提供稳定访问入口和服务发现
Ingress	管理 HTTP/HTTPS 入口流量
ConfigMap	管理非敏感配置
Secret	管理密码、Token、证书等敏感信息
Namespace	做资源隔离和命名空间划分

下面是一个最简 Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/team/web:1.0.0
          ports:
            - containerPort: 3000

这段 YAML 的意思是：运行 3 个 web Pod，每个 Pod 里有一个容器，容器镜像是 registry.example.com/team/web:1.0.0。

2. K8s 的特点

Kubernetes 的核心能力包括：

调度：根据资源、亲和性、污点、拓扑等条件，把 Pod 放到合适节点。
自愈：容器退出、Pod 异常、节点不可用时，控制器会尝试恢复到期望状态。
水平扩缩容：通过 HPA 等机制按 CPU、内存或自定义指标扩缩副本。
滚动更新和回滚：逐批替换旧版本 Pod，降低发布风险。
服务发现：Service 为动态变化的 Pod 提供稳定访问入口。
配置和密钥管理：ConfigMap 和 Secret 让配置与镜像解耦。
生态开放：CNI、CSI、CRI、Ingress Controller、Service Mesh、Operator 等生态组件非常丰富。

3. K8s 的边界

Kubernetes 强大，但它不是“开箱即用的完整企业平台”。裸 Kubernetes 往往还需要你自己选型和集成：

镜像仓库和镜像扫描；
CI/CD 或 GitOps；
统一登录和权限模型；
多租户项目管理；
监控、日志、告警；
应用入口网关和证书；
集群安装、升级、备份和运维；
安全基线、准入控制、网络策略。

这也是为什么很多企业会选择托管 Kubernetes 服务，或者选择 OpenShift 这类更完整的平台。

四、OpenShift：把 Kubernetes 做成企业级平台

OpenShift 是 Red Hat 的 Kubernetes 平台。它不是重新发明一套编排系统，而是在 Kubernetes 之上加入一组更“有默认答案”的企业级能力。

如果说 Kubernetes 是一套强大的“平台内核”，OpenShift 更像是把内核、控制台、权限、网络入口、构建、流水线、安全策略、Operator 和运维能力组合起来，交付给企业内部团队使用。

1. OpenShift 常见能力

能力	Kubernetes 原生情况	OpenShift 的平台化增强
Web 控制台	Kubernetes Dashboard 不是核心默认体验	提供面向开发者和管理员的 Console
项目隔离	Namespace 是基础对象	Project 在 Namespace 基础上封装更贴近团队使用
应用入口	Ingress 需要选择控制器	Route 是 OpenShift 常用入口模型
身份认证	可扩展，但需要集成	通常集成 OAuth、LDAP、OIDC 等企业身份系统
安全约束	PSA、RBAC、Admission 等能力分散	SCC、安全默认值和平台策略更强
构建镜像	K8s 本身不负责构建镜像	常见提供 Build、Source-to-Image、镜像流等能力
Operator	Kubernetes 可使用 Operator	OpenShift 深度使用 Operator 管理平台组件
运维升级	需要自己设计流程	更强调安装、升级、生命周期和 Day-2 运维

说明：不同 OpenShift 版本、安装方式和启用组件会有差异，具体能力以实际发行版和官方文档为准。

2. OpenShift 的特点

OpenShift 的典型优势是：

更完整的开箱体验：控制台、登录、项目、路由、构建、平台组件管理更统一。
默认安全更严格：对容器权限、用户、镜像运行方式通常更保守，更适合企业治理。
面向多团队协作：Project、RBAC、配额、模板、Operator 等能力更适合平台团队给业务团队供给环境。
企业支持和生命周期管理：Red Hat 生态、支持服务、升级路径和认证矩阵对企业很重要。
混合云与私有化场景友好：很多企业需要在本地数据中心、私有云、公有云之间保持一致的平台能力。

3. OpenShift 的代价

OpenShift 的代价也要说清楚：

学习曲线更高：除了 Kubernetes 概念，还要理解 Route、Project、SCC、BuildConfig、ImageStream 等 OpenShift 组件。
平台更重：安装、资源占用、升级流程和权限模型都比本地 Docker 或裸 K8s 复杂。
默认约束更多：一些在普通 K8s 或 Docker 中能跑的镜像，可能因为 root 用户、特权容器、文件权限等问题在 OpenShift 中被拦下。
成本更高：企业订阅、平台运维、人力投入都需要纳入预算。

所以 OpenShift 不是“永远比 K8s 更好”，而是更适合有企业级平台需求的团队。

五、核心区别对比

更细一点可以这样对比：

维度	Docker	Kubernetes	OpenShift
主要定位	容器工具链	容器编排平台	企业级 Kubernetes 平台
管理范围	单机容器、本地开发、镜像构建	多节点集群、工作负载、服务发现	K8s 集群 + 企业平台能力
最小运行单元	Container	Pod	Pod（基于 K8s）
配置方式	Dockerfile、Compose YAML、CLI	YAML、kubectl、API	YAML、oc CLI、Console、Operator
是否负责镜像构建	是，核心能力之一	不负责，通常外接 CI/CD	常见内置或集成构建能力
是否负责集群调度	不擅长	是，核心能力	是，基于 K8s
是否适合本地开发	很适合	可用但偏重	通常偏重
是否适合生产多节点	需要配合其他系统	适合	很适合企业生产
默认安全治理	基础能力	能力丰富但需要设计	默认更强、更有约束
典型用户	开发者、测试、单机部署	平台工程师、SRE、云原生团队	企业平台团队、运维、安全、业务团队
生态开放性	容器生态成熟	CNCF 生态核心	K8s 生态 + Red Hat 生态

六、一条完整链路里它们怎么配合

实际生产环境里，三者不是非此即彼，常常会同时出现。

一个典型流程是：

开发者写代码和 Dockerfile。
本地用 Docker 或 Docker Compose 调试服务。
CI 系统执行 docker build、buildx、BuildKit，或者 OpenShift 的 Source-to-Image 构建镜像。
镜像推送到 Harbor、Quay、Docker Hub、GitHub Container Registry 等仓库。
Kubernetes 使用 Deployment、StatefulSet、Job 等资源部署镜像。
Service、Ingress 或 OpenShift Route 提供访问入口。
OpenShift Console、Operator、监控、日志、GitOps、权限和安全策略负责平台化治理。

所以你可以这样记：

1
2
3

Docker：把应用变成标准镜像
Kubernetes：把镜像变成集群中的稳定服务
OpenShift：把 Kubernetes 变成企业内部可治理、可交付、可运维的平台

七、常见误区

1. “Kubernetes 不支持 Docker 了，所以 Docker 没用了？”

不是。

Kubernetes 移除的是对 Docker Engine 的特殊直接集成 dockershim，不是拒绝 Docker 构建出来的镜像。只要镜像符合 OCI / Docker 镜像格式，Kubernetes 仍然可以通过 containerd、CRI-O 等运行时拉取并运行。

换句话说：你仍然可以用 Docker 构建镜像，只是 Kubernetes 节点不一定用 Docker Engine 来运行容器。

2. “Docker Compose 可以替代 Kubernetes 吗？”

看场景。

Docker Compose 很适合本地开发、Demo、小型单机部署。它能把多个容器、网络、卷统一写进一个 compose.yaml。

但 Compose 不擅长处理多节点调度、故障自愈、滚动升级、服务发现、集群权限、多租户和复杂网络策略。如果你需要生产级多节点平台，Kubernetes 更合适。

3. “OpenShift 就是 Kubernetes 换皮吗？”

也不是。

OpenShift 基于 Kubernetes，但它不是只加了一个 UI。它还提供安装、升级、身份、权限、项目、路由、构建、镜像流、安全约束、Operator 管理和平台运维等大量工程能力。对企业来说，这些“周边工程”往往比 Kubernetes 内核本身更耗时。

4. “学 OpenShift 前必须精通 Docker 和 K8s 吗？”

不必等到“精通”，但建议按这个顺序建立心智模型：

先理解容器、镜像、Dockerfile；
再理解 Pod、Deployment、Service、Ingress、ConfigMap、Secret；
最后理解 OpenShift 的 Project、Route、SCC、Build、Operator、Console。

这样学 OpenShift 时就不会把平台增强能力和 Kubernetes 原生能力混在一起。

八、怎么选型

可以用这张表做初步判断：

场景	推荐选择	原因
本地开发需要快速启动数据库、缓存、中间件	Docker / Docker Compose	轻量、简单、开发体验好
单机部署一个小服务	Docker	成本低，维护简单
多服务、多副本、多节点生产部署	Kubernetes	编排、自愈、服务发现、扩缩容能力完整
团队已有 K8s 能力，希望保持最大开放性	Kubernetes	生态通用，云厂商和社区支持广
企业内部要给多个团队提供统一应用平台	OpenShift	权限、租户、安全、控制台、运维能力更完整
强合规、私有化、混合云、需要厂商支持	OpenShift	更强调企业支持、生命周期和安全治理
只是学习容器基础	Docker	先掌握镜像和容器，再上 K8s 更顺

如果你是个人开发者或小团队，通常从 Docker 开始，再学习 Kubernetes。等到团队规模、生产复杂度、安全合规和平台治理需求上来，再评估 OpenShift。

如果你是企业平台团队，问题可能不是“要不要 Kubernetes”，而是“我们是自己拼一套 Kubernetes 平台，还是采用 OpenShift 这类更完整的企业发行版”。这时要重点比较：

平台团队人数和能力；
安全合规要求；
集群规模和升级频率；
业务团队自助使用诉求；
预算和厂商支持需求；
对开源灵活性和产品约束的接受程度。

九、总结

把三者放在一张图里：

应用源码
  ↓
Dockerfile / docker build
  ↓
容器镜像
  ↓
Kubernetes Pod / Deployment / Service
  ↓
OpenShift Project / Route / Console / Operator / 安全治理

最终结论：

Docker 是容器入口：让应用可打包、可复制、可运行。
Kubernetes 是编排核心：让容器化应用在集群中按期望状态运行。
OpenShift 是企业平台：让 Kubernetes 更适合大规模、多团队、强治理的生产环境。

学云原生时，最重要的不是背工具名，而是看清每一层解决的问题。只要记住“Docker 管容器，K8s 管集群，OpenShift 管平台”，三者的关系就很清楚了。