DevOps on Snow

K8s Container Cloud Deployment: From Dockerfile Image Build to Release

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

K8s Container Cloud Deployment: From Dockerfile Image Build to Release

When deploying services to an internal Kubernetes container cloud platform, the console form is only the final step. The real deployment path is: the code builds reliably, the Dockerfile produces a correct image, the image runs locally, the image is pushed to a registry, and Kubernetes can pull and run it with healthy probes.

This article follows the order of a real deployment and uses the China Telecom Cloud CeakE Container Service CKE console for the UI walkthrough. Other consoles may use different labels, but the underlying Kubernetes concepts—workloads, Services, Ingress, probes, and rolling updates—map closely.

flowchart LR A[Source code] --> B[Write Dockerfile] B --> C[Build image locally] C --> D[Run and verify locally] D --> E[Push to registry] E --> F[Create workload on platform] F --> G[Configure Service and Ingress] G --> H[Validate release and prepare rollback]

1. What to confirm before deployment

Write down the deployment inputs before touching the platform page.

Item	What to confirm	Example
Startup command	How the service starts and which port it listens on	`java -jar app.jar`, `./server`, `npm start`, port `8080`
Dockerfile	Whether the project has a repeatable image build	`Dockerfile`, `.dockerignore`
Registry	Registry address, project path, credentials	`registry.example.com/team/order-api`
Namespace	Target project or Kubernetes namespace	`team-dev`, `team-test`, `team-prod`
Configuration	Runtime config and secrets	`APP_ENV`, database URL, tokens
Network exposure	Internal-only or external access	`ClusterIP`, `Ingress`, `Route`, gateway
Resources	CPU, memory, storage, replicas	`requests: 200m/256Mi`, `limits: 1/1Gi`
Health checks	Endpoint used by the platform to judge health	`/healthz`, `/actuator/health`

Most platform UI fields are wrappers around Kubernetes objects:

Platform term	Kubernetes object	Purpose
Application / workload	`Deployment`	Manages replicas, rolling updates, and rollback
Instance / container group	`Pod`	Smallest unit that runs containers
Service	`Service`	Stable in-cluster endpoint for Pods
Route / domain / gateway	`Ingress` or platform entry object	External HTTP/HTTPS entry
Configuration	`ConfigMap`	Non-sensitive configuration
Secret	`Secret`	Passwords, tokens, certificates
Registry credential	`imagePullSecret`	Allows nodes to pull from private registries

The platform hides some YAML, but Kubernetes is still the execution layer underneath.

2. The key part: building an image from Dockerfile

Kubernetes does not run source code directly. A Deployment points to an image, the node pulls that image from a registry, and the container runtime starts it as a container.

Many deployment failures actually start at the image layer:

the build artifact was not copied into the final image;
the container startup command is wrong;
the service listens on 127.0.0.1 instead of 0.0.0.0;
required runtime config was neither baked into the image nor injected by the platform;
the image architecture does not match cluster nodes;
the private registry address, tag, or credential is wrong.

Dockerfile instructions you should recognize

Instruction	Purpose	Note
`FROM`	Selects the base image	Prefer explicit versions over `latest`
`WORKDIR`	Sets the working directory	Affects later `COPY`, `RUN`, and `CMD`
`COPY`	Copies files from build context	Prefer `COPY` unless `ADD` is truly needed
`RUN`	Runs commands during image build	Used for dependency install and compilation
`ARG`	Build-time variable	Not normally kept as runtime env
`ENV`	Runtime environment default	Do not store passwords here
`EXPOSE`	Documents the container port	It does not publish the port by itself
`USER`	Selects runtime user	Avoid running production containers as root
`ENTRYPOINT`	Fixed executable entry	Good for the main process
`CMD`	Default command or arguments	Can be overridden by `docker run`

The final . in this command is the build context:

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

Everything inside that context can be sent to the Docker builder, so add a .dockerignore:

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

This improves build speed, reduces image risk, and helps Docker layer caching behave predictably.

A practical image build flow

flowchart TD A[Verify native build] --> B[Write .dockerignore] B --> C[Write Dockerfile] C --> D[docker build] D --> E[docker run locally] E --> F[Tag image] F --> G[docker login] G --> H[docker push] H --> I[Deploy image on platform]

First confirm the project builds without Docker:

# Java example
./mvnw clean package -DskipTests

# Go example
go test ./...
go build -o server ./cmd/server

# Node.js example
npm ci
npm run build

Dockerfile should make a stable build repeatable. It should not hide a broken local build.

Go service example

# 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"]

Useful details:

Detail	Reason
Copy `go.mod` and `go.sum` before source files	Dependency download can use cache
Set `CGO_ENABLED=0 GOOS=linux GOARCH=amd64`	Produces a Linux amd64 binary for common cluster nodes
Use a separate runtime stage	Keeps source and build cache out of the final image
Run as `app` user	Avoids root runtime by default

Build and run locally:

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

If this local check fails, fix the image before touching Kubernetes. Check the actual port, bind address, startup command, health endpoint, and required environment variables.

Java Spring Boot example

# 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"]

If the service needs JVM options, keep them configurable:

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

Then inject runtime values from the platform:

1
2

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

Remember that JAVA_OPTS only works if the entrypoint actually reads it.

Node.js service example

# 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"]

For a static frontend, the runtime image can be Nginx instead of Node:

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

Image tag strategy

Avoid using only latest in production. It is hard to trace and hard to rollback.

Better options:

1
2
3

registry.example.com/<team>/<service>:<version>
registry.example.com/<team>/<service>:<git-short-sha>
registry.example.com/<team>/<service>:<environment>-<build-number>

Example:

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 .

At minimum, keep the Git SHA:

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

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

If the platform supports image digests, production can pin an immutable reference:

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

Tags are readable; digests are immutable.

Match image architecture with cluster nodes

If the image is built on ARM but the cluster runs amd64 nodes, the Pod may fail with exec format error.

Build amd64 explicitly:

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

Push to registry

Check the local image:

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

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

Retag if needed:

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

Push:

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

The cluster will not use images stored only in your local Docker daemon. A real platform pulls from the registry.

3. Create the workload on the platform

Once the image exists in the registry, create the workload. The screenshots below show the complete console flow.

Check the cluster and available capacity

Open Container → Cluster List, locate the target cluster, and confirm that it is running. Check the cluster type, version, node count, and tenant before entering the console so the service is not deployed to the wrong environment.

The cluster overview summarizes Deployment, StatefulSet, DaemonSet, Job, CronJob, and Pod counts together with node health and CPU, memory, and disk usage.

Do not rely on the green node status alone. Check resource headroom and recent warning events as well. If requests exceed the remaining allocatable resources, a new Pod can stay Pending even when every node is healthy.

Choose the correct workload type

The Workloads menu contains more than Deployment. Choose the controller based on how the process should run:

Console entry	Kubernetes object	Best fit
Stateless workload	`Deployment`	Replaceable and horizontally scalable web or API services
DaemonSet	`DaemonSet`	One instance per node, such as logging or monitoring agents
Stateful workload	`StatefulSet`	Stable identity, ordered rollout, or persistent storage
Job	`Job`	One-time work that exits after completion
CronJob	`CronJob`	Work executed periodically from a Cron schedule
Pod	`Pod`	Inspecting and troubleshooting runtime instances; rarely a direct long-lived deployment choice

The running/desired Pod count, replica count, and status provide a quick rollout check. A row showing 0/1 and Updating, for example, has not reached the desired state.

The Pod page is especially useful during incidents because it shows status, ready containers, restart count, Pod IP, and node. The CrashLoopBackOff row and very high restart count in the screenshot are direct failure signals; inspect container logs, previous logs, and Pod events before changing Service or Route settings.

Create a Deployment with the four-step wizard

From Stateless Workload, select Create Stateless Workload. The wizard is divided into Basic Information, Container Configuration, Service Configuration, and Advanced Configuration.

Step 1: basic information

Enter the name, project (the Kubernetes namespace), replica count, and description. One replica is enough for an initial test; production commonly starts with at least two replicas and a rolling strategy that preserves availability.

Step 2: container configuration

The image can be selected from the platform registry or entered as a full image reference. Verify the tag, pull policy, and vCPU/memory requests and limits:

IfNotPresent works well with immutable tags. The screenshot shows Always as the default; that is useful when tags can be overwritten, but production releases should still use unique tags.
Avoid leaving all CPU and memory controls unlimited. Set realistic requests, then define limits from load-test and monitoring data.
The container name identifies a container inside the Pod; it does not have to match the Deployment, and a Pod can contain multiple containers.

Further down, the form exposes environment variables, command and arguments, working directory, storage, and all three Kubernetes probes:

Readiness decides whether the Pod is included in Service endpoints and should normally be enabled for a network service.
Liveness decides whether Kubernetes should restart the container; avoid coupling it to unstable downstream dependencies.
Startup protects slow-starting applications from being restarted by liveness checks before initialization completes.

Step 3: service configuration

Bind an existing Service or create one directly from the wizard. This step can be skipped when the workload does not need an endpoint yet; a Service can be added later from the Network menu.

Select the access type, protocol, Service port, and container port. Prefer ClusterIP for ordinary internal services. NodePort opens a port on the nodes, while LoadBalancer depends on the cloud integration. Most importantly, the Service selector must match the workload labels or no endpoint will be created.

Step 4: advanced configuration

The first part contains DNS and additional host/network settings plus the rollout strategy. ClusterFirst is the usual DNS policy. With RollingUpdate, choose maxSurge and maxUnavailable together with the replica count; a single-replica service that allows one unavailable Pod will have downtime during a rollout.

The remaining controls cover node affinity, workload affinity/anti-affinity, tolerations, labels, annotations, monitoring, and private image credentials. Change scheduling rules only for a real placement requirement, and select an image secret when the cluster must authenticate to a private registry.

The four-step form ultimately produces a Kubernetes Deployment. Use the following table as a field checklist:

Field	Recommended value	Note
Application name	`order-api`	Keep it close to the service name
Namespace	`team-test` / `team-prod`	Separate environments and teams
Image	`registry.example.com/pay/order-api:git-a18c3f2`	Use the pushed image
Replicas	`1` for test, `2+` for production	Production needs multiple replicas for rolling updates
Container port	`8080`	Must match the real listening port
Environment variables	Platform form or ConfigMap	Do not bake environment differences into the image
Secrets	Secret	Do not put passwords in Dockerfile
CPU/memory	Start small, then tune	requests for scheduling, limits for upper bounds
Health check	`/healthz` or service health endpoint	Readiness controls traffic routing
Pull credential	Registry secret	Required for private registries

A typical 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

The three most important fields are image, containerPort, and readinessProbe. If readiness does not pass, the Pod can be running but still receive no traffic.

4. Configure service entry

Deployment makes Pods run. Service and Ingress make them reachable.

flowchart LR U[User or upstream service] --> I[Ingress or gateway] I --> S[Service] S --> P1[Pod 1] S --> P2[Pod 2] S --> P3[Pod 3]

Create a Service

The Network → Service page shows the access type, Cluster IP or external IP, and each Service-port-to-container-port mapping. ClusterIP, NodePort, and LoadBalancer expose the application at different scopes, so a port number alone does not tell you whether the service is publicly reachable.

Choose the project and name, then set the access type and ports:

Form field	Kubernetes field	Meaning
Service port	`spec.ports[].port`	Port used by clients of the Service
Container port	`spec.ports[].targetPort`	Port that receives the traffic in the Pod
Access type	`spec.type`	`ClusterIP`, `NodePort`, or `LoadBalancer`
Workload/label binding	`spec.selector`	Must match labels on the target Pods
Session Hold	`sessionAffinity`	Enable only when the application requires sticky sessions

Internal access usually uses a 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

Other in-cluster services can call:

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

External HTTP/HTTPS access usually uses Ingress, Route, or a company gateway:

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

Create a Route (Ingress)

This platform exposes Ingress under Network → Route. The list shows the route name, bound Services, project, and type; a single route can contain multiple backend rules.

Enter the route name, project, Ingress type, protocol, host, path matching mode, target Service, and target port. The screenshot uses type nginx and match mode Prefix, which correspond to the Ingress controller and pathType: Prefix. HTTPS additionally requires the TLS certificate or Secret expected by the platform.

A console may call this object Ingress, domain, route, layer-7 load balancer, or application entry. Whatever the label, troubleshoot the same chain: Route/Ingress → Service → Endpoint → Pod.

5. Validate release and prepare rollback

If YAML deployment is supported:

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

Useful checks:

kubectl get pods -n team-test -l app=order-api
kubectl describe deployment order-api -n team-test
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

Rollback:

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

Platform consoles usually expose the same behavior as version history, rollback, or redeploy actions.

6. Common troubleshooting table

Symptom	Likely cause	Where to look
`ImagePullBackOff`	Wrong image, missing tag, registry permission issue	Registry, `imagePullSecret`, Pod events
`ErrImagePull`	Node failed to pull image	`kubectl describe pod`
`CrashLoopBackOff`	Container starts and exits repeatedly	`kubectl logs --previous`, startup command, env vars
`Running` but `0/1 Ready`	Readiness probe fails	Health endpoint, port, timeout
External 404	Ingress host or path mismatch	Ingress and gateway rules
External 502/503	Service has no ready endpoint	Pod readiness, Service selector
Database connection failure	Secret, network policy, allowlist, DNS	Env vars, credentials, network
`OOMKilled`	Memory exceeded limit	Raise limit, inspect memory usage
`exec format error`	Image architecture mismatch	Rebuild with `buildx --platform linux/amd64`
New image not picked up	Same tag reused and pull policy did not force pull	Use a new tag or adjust `imagePullPolicy`

Recommended troubleshooting order:

flowchart TD A[Was Pod created] -->|No| B[Check Deployment events] A -->|Yes| C[Was image pulled] C -->|No| D[Check image address and registry credential] C -->|Yes| E[Did container start] E -->|No| F[Check startup command and logs] E -->|Yes| G[Is Pod Ready] G -->|No| H[Check readiness probe] G -->|Yes| I[Does Service have endpoints] I -->|No| J[Check selector and labels] I -->|Yes| K[Check Ingress or gateway]

7. Pre-release checklist

Check	Pass criteria
Dockerfile is repeatable	`docker build` works on another machine or CI
Image runs locally	`docker run` passes the health check
Tag is traceable	Tag includes version, build number, or Git SHA
Image is pushed	The platform can pull it from the registry
Config is not baked into image	Environment differences use ConfigMap / Secret
Secrets are not in Dockerfile	No password in `ENV`, source, or image layers
Resources are set	Reasonable requests and limits exist
Probes are set	Readiness and liveness endpoints work
Service selector is correct	Service has Pod endpoints
Entry route is verified	Domain, path, certificate, gateway are correct
Rollback is clear	Previous image tag or Deployment revision is known
Logs and metrics are available	Operators can inspect runtime behavior after release

Summary

The deployment path can be summarized as:

Use Dockerfile to turn the service into a runnable, traceable, pushable image; then let Kubernetes manage replicas with Deployment, provide stable access with Service, and route external traffic through Ingress or a platform gateway.

Four habits make this process much more reliable:

run the image locally before pushing it;
use a unique tag for every release instead of relying on latest;
inject configuration and secrets from the platform instead of baking them into the image;
prepare health checks, logs, and rollback before release.

Once this chain is stable, deploying through a container cloud platform becomes a standardized delivery workflow instead of trial and error in a web form.

从 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, and OpenShift: Relationship, Features, and Differences

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

Docker, Kubernetes, and OpenShift: Relationship, Features, and Differences

Docker, Kubernetes, and OpenShift are often mentioned together, but they do not solve the same problem. Docker focuses on packaging and running containers, Kubernetes focuses on orchestrating containers across a cluster, and OpenShift turns Kubernetes into a more opinionated enterprise platform.

The short version:

Tool	Positioning	Main problem it solves
Docker	Container toolchain	Package an application and its dependencies into an image, then run it as a container
Kubernetes / K8s	Container orchestration platform	Schedule, scale, expose, update, and self-heal containerized workloads across nodes
OpenShift	Enterprise Kubernetes platform	Provide Kubernetes with stronger defaults for teams, security, governance, delivery, and operations

1. Relationship: not a replacement chain, but layered responsibilities

The common statement “Kubernetes replaced Docker” is too vague.

A more accurate model is:

Docker helps developers build images, run containers, and manage local development environments.
Kubernetes does not require Docker as the image builder. It cares about desired state: which Pods should run, how many replicas exist, what configuration they use, and how services are exposed.
OpenShift is built on Kubernetes and adds enterprise platform capabilities such as a web console, project isolation, Routes, builds, Operators, identity integration, security constraints, and operational tooling.

Two details matter:

Kubernetes is not Docker: Kubernetes uses the Container Runtime Interface to talk to runtimes such as containerd and CRI-O. Older Kubernetes releases included a direct Docker Engine integration through dockershim, but dockershim was removed starting with Kubernetes v1.24.
OpenShift is not a separate replacement for Kubernetes: OpenShift remains Kubernetes. Core resources such as Pod, Deployment, Service, ConfigMap, Secret, and Namespace are still Kubernetes resources.

2. Docker: standardizing how applications run

Docker’s core value is standardizing the runtime environment of an application.

Without containers, deployment often depends on whether the target machine has the correct Java, Python, Node.js, shared libraries, configuration files, and environment variables. Docker packages the application, runtime, dependencies, and startup command into an image. That image can then be used to start containers consistently across environments.

Concept	Role	Mental model
Dockerfile	Describes how to build an image	Environment assembly instructions
Image	Read-only package containing files, dependencies, and configuration	Application artifact
Container	Running instance of an image	The actual isolated process environment
Registry	Stores and distributes images	Artifact repository for container images
Docker Compose	Defines multi-container local environments	Local development orchestration

Example:

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

Docker is especially strong at:

making environments reproducible;
standardizing application delivery through images;
starting containers quickly with low overhead;
improving local development with Docker Desktop, CLI, and Compose;
using a mature image ecosystem.

Its boundary is also clear: Docker is excellent for building and running containers, but it is not a full production cluster platform. Once you need multi-node scheduling, automatic recovery, rolling updates, service discovery, storage orchestration, and platform governance, you need something like Kubernetes.

3. Kubernetes: keeping containerized workloads in the desired state

Kubernetes is a container orchestration platform. Its core idea is declarative APIs plus control loops.

You describe the desired state: “run three replicas of this service using this image and expose this port.” Kubernetes continuously compares actual state with desired state. If one Pod disappears, it creates another. If a node fails, workloads can be rescheduled. If you update the image, Kubernetes can roll the change out gradually.

Key Kubernetes objects:

Object	Role
Cluster	A group of machines running Kubernetes
Node	Worker machine in the cluster
Pod	Smallest deployable unit in Kubernetes
Deployment	Declares replicas, image version, and update strategy for stateless workloads
Service	Provides stable access and service discovery for a set of Pods
Ingress	Manages HTTP/HTTPS entry traffic
ConfigMap	Stores non-sensitive configuration
Secret	Stores sensitive data such as tokens and certificates
Namespace	Provides naming and resource isolation

Minimal Deployment example:

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

Kubernetes provides scheduling, self-healing, horizontal scaling, rolling updates, service discovery, configuration management, and a very large open ecosystem.

Its boundary: Kubernetes is powerful, but a bare cluster is not automatically a complete enterprise platform. You usually still need to integrate a registry, CI/CD, GitOps, identity, monitoring, logging, ingress, certificates, backup, upgrade workflows, network policy, and security controls.

4. OpenShift: productizing Kubernetes for enterprises

OpenShift is Red Hat’s Kubernetes platform. It does not reinvent orchestration; it builds on Kubernetes and adds stronger defaults and platform capabilities.

If Kubernetes is the platform kernel, OpenShift packages that kernel with console, authentication, routing, project management, builds, pipelines, Operators, security constraints, lifecycle management, and operational experience.

Capability	In plain Kubernetes	In OpenShift
Web console	Optional and not the central default experience	Provides developer and administrator consoles
Project isolation	Namespace is the base primitive	Project wraps namespace usage for teams
Application entry	Ingress requires controller selection	Route is a common OpenShift entry model
Identity	Extensible, usually integrated separately	Commonly integrated with enterprise identity systems
Security	RBAC, admission, PSA, network policy, and more	Stronger default constraints and platform policies
Image build	Kubernetes itself does not build images	Often includes or integrates build workflows
Operators	Available in Kubernetes ecosystem	Deeply used to manage platform components
Lifecycle operations	Designed by the platform team	More productized install, upgrade, and day-2 operations

OpenShift is strong when an organization needs:

a more complete out-of-the-box platform;
stricter security defaults;
multi-team platform governance;
enterprise support and lifecycle management;
hybrid cloud and private deployment consistency.

The tradeoff is weight. OpenShift has a larger learning surface, more platform components, stricter defaults, and usually higher operational and subscription costs.

5. Key differences

Dimension	Docker	Kubernetes	OpenShift
Primary role	Container toolchain	Container orchestration	Enterprise Kubernetes platform
Scope	Single host, image build, local dev	Multi-node workload management	Kubernetes plus platform governance
Smallest unit	Container	Pod	Pod
Configuration	Dockerfile, Compose, CLI	YAML, kubectl, API	YAML, oc CLI, Console, Operators
Image build	Core capability	External concern	Often built in or integrated
Cluster scheduling	Not the main goal	Core capability	Based on Kubernetes
Local development	Excellent	Possible but heavier	Usually too heavy for basic local dev
Production cluster	Needs other systems	Strong fit	Strong enterprise fit
Security governance	Basic building blocks	Rich but requires design	Stronger opinionated defaults
Typical users	Developers, testers	Platform engineers, SREs	Enterprise platform teams

6. How they work together in a delivery flow

In real production systems, these tools are often combined rather than chosen as exclusive alternatives.

A typical flow:

Developers write code and a Dockerfile.
Local services are tested with Docker or Docker Compose.
CI builds an image with Docker, BuildKit, or an OpenShift build workflow.
The image is pushed to a registry such as Harbor, Quay, Docker Hub, or GitHub Container Registry.
Kubernetes deploys the image through Deployment, StatefulSet, Job, or similar resources.
Service, Ingress, or OpenShift Route exposes the application.
OpenShift adds console, identity, policy, monitoring, logging, GitOps, and operational governance.

1
2
3

Docker: turn the application into a standard image
Kubernetes: turn the image into a stable service in a cluster
OpenShift: turn Kubernetes into a governed enterprise platform

7. Common misconceptions

“Kubernetes no longer supports Docker, so Docker is useless?”

No. Kubernetes removed the special dockershim integration with Docker Engine. It did not reject Docker-built images. If an image follows the OCI / Docker image format, Kubernetes runtimes such as containerd and CRI-O can still pull and run it.

“Can Docker Compose replace Kubernetes?”

Only in small scenarios. Compose is excellent for local development, demos, and simple single-host deployments. It is not designed to be a full multi-node platform with scheduling, self-healing, rolling updates, service discovery, multi-tenancy, and cluster security.

“Is OpenShift just Kubernetes with a UI?”

No. The UI is only one part. OpenShift also adds platform lifecycle, authentication, authorization, routing, builds, image management, security constraints, Operators, and operations workflows.

“Do I need to master Docker and Kubernetes before learning OpenShift?”

You do not need to master everything first, but the learning path is clearer if you understand containers and images, then Pods and Deployments, and then OpenShift-specific concepts such as Project, Route, SCC, Build, Operator, and Console.

8. Choosing between them

Scenario	Recommended choice	Reason
Local development with databases and middleware	Docker / Docker Compose	Simple and fast
Small single-host deployment	Docker	Low operational cost
Multi-service, multi-replica production deployment	Kubernetes	Orchestration, self-healing, scaling, service discovery
Team already has strong K8s skills and wants openness	Kubernetes	Broad ecosystem and portability
Enterprise platform for many teams	OpenShift	Governance, security, console, operations, lifecycle
Regulated, private, hybrid-cloud deployment with vendor support	OpenShift	Stronger enterprise support and platform defaults
Learning container fundamentals	Docker	Build the mental model before moving to K8s

Final summary:

Docker is the container entry point: package and run applications consistently.
Kubernetes is the orchestration core: keep workloads running in the desired state across a cluster.
OpenShift is the enterprise platform layer: make Kubernetes more usable, governable, and operable for large organizations.

Remember this simple line: Docker manages containers, Kubernetes manages clusters, and OpenShift manages the platform experience around Kubernetes.

References

CI/CD Complete Guide:From Principles to Practice

Sat, 04 Jul 2026 10:36:23 +0800

CI/CD 完整指南：从原理到实战

一次搞懂持续集成、持续交付、持续部署到底是什么，再带你用 GitHub Actions 从 0 搭建一条真正能跑的自动化流水线。

一、先搞懂：为什么我们需要 CI/CD？

在聊概念之前，先还原一个真实的场景：

团队有 5 个开发者，每个人本地开发完功能后，各自打包、上传服务器、重启服务。某天上线后系统挂了，排查了 4 个小时才发现：小张覆盖了小李刚提交的配置，老王的代码依赖了一个只有他本机才装的库。

这种场景每天都在无数团队上演，核心痛点就三个：

集成地狱：代码合到一起就冲突，越拖越难合并
手动发布又慢又脆：一次上线要 2 小时，还经常回滚
环境不一致：“在我电脑上能跑啊” 成了最经典的借口

CI/CD 就是来解决这些问题的。它把 代码集成 → 测试 → 构建 → 部署 这一整套流程自动化，让机器替人完成重复、易错的工作。

如图所示，传统模式下团队把大量时间花在手动集成和发布上；而 CI/CD 模式下，开发者只需要 git push，剩下的交给流水线，几分钟就能拿到一个可部署的版本。

二、核心概念：CI、CD、CD 到底指什么？

这三个缩写经常被混在一起说，其实它们是流水线的三个阶段：

缩写	全称	中文	核心动作	触发时机
CI	Continuous Integration	持续集成	合并代码 + 自动构建 + 自动测试	每次 push / PR
CD	Continuous Delivery	持续交付	CI 通过后，自动打包成可发布产物	CI 成功后
CD	Continuous Deployment	持续部署	自动把产物部署到生产环境	交付产物就绪后

简单记忆：持续交付是"随时能发，但要不要发由人决定"；持续部署是"机器直接发，不需要人按按钮"。

一条完整的 CI/CD 流水线长什么样？

一条典型的流水线会经历这几个阶段：

Source（源码）：开发者 push 代码到仓库
Build（构建）：编译代码、安装依赖、生成可执行文件或镜像
Test（测试）：跑单元测试、集成测试、代码质量扫描
Package（打包）：把产物打成 Docker 镜像 / jar / 二进制
Deploy（部署）：推到测试环境 → 预发环境 → 生产环境
Monitor（监控）：上线后持续观察指标，异常自动回滚

每个阶段失败都会阻塞流水线，并通知开发者修复，确保 只有通过全部检查的代码才能进入下一阶段。

三、主流工具横向对比

市面上的 CI/CD 工具非常多，选型时主要看：托管方式、生态、集成成本。下面是最常用的几款：

工具	部署方式	配置语言	适合场景	是否免费
GitHub Actions	SaaS / 自托管	YAML	仓库在 GitHub 的项目	公开仓库免费
GitLab CI/CD	SaaS / 自托管	YAML	仓库在 GitLab 的项目	免费版功能齐全
Jenkins	自托管	Groovy	大型企业、复杂定制场景	开源免费
Drone	自托管	YAML	追求轻量、容器原生	开源免费
CircleCI	SaaS	YAML	云原生项目	有免费额度

新手怎么选？

个人项目 / 开源项目 → GitHub Actions，配置简单，和代码仓库零距离
公司用 GitLab → GitLab CI/CD，开箱即用
大型企业、需要深度定制 → Jenkins，插件生态最丰富，但维护成本高

本文后续实战用 GitHub Actions 演示，因为它最容易上手，而且本博客本身就是用 GitHub Actions 自动部署的。

四、GitHub Actions 核心概念

在写流水线之前，先理解 5 个核心术语：

概念	说明	类比
Workflow（工作流）	一个 YAML 文件，定义完整的自动化流程	一份"作业指导书"
Event（事件）	触发工作流的动作，如 push、PR、定时	“启动按钮”
Job（任务）	工作流里的一组步骤，默认多个 Job 并行执行	“一道工序”
Step（步骤）	Job 里的具体操作，可以是命令或 Action	“工序里的一步”
Action	可复用的步骤单元，类似函数	“一个工具函数”

一个 Workflow 可以包含多个 Job，每个 Job 跑在独立的虚拟机里，Job 之间可以通过 needs 定义依赖关系，形成串行或并行的执行图。

五、实战：用 GitHub Actions 自动部署 Hugo 博客

理论讲完，下面用一个真实案例演示。本博客就是用下面的流水线自动构建并部署到 GitHub Pages 的。

5.1 流水线全貌

name: deploy

# 代码提交到 main 分支时触发 GitHub Action
on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
        - name: Checkout
          uses: actions/checkout@v4
          with:
              fetch-depth: 0

        - name: Setup Hugo
          uses: peaceiris/actions-hugo@v3
          with:
              hugo-version: "0.123.0"
              extended: true

        - name: Build Web
          run: hugo -D

        - name: Deploy Web
          uses: peaceiris/actions-gh-pages@v4
          with:
              PERSONAL_TOKEN: ${{ secrets.TOKEN }}
              EXTERNAL_REPOSITORY: SymphonyW/SymphonyW.github.io
              PUBLISH_BRANCH: main
              PUBLISH_DIR: ./public
              commit_message: auto deploy

5.2 逐行解析

触发条件：

on:
  push:
    branches:
      - main

表示：只要有人把代码 push 到 main 分支，就触发这条流水线。也可以配置 pull_request、schedule（定时）、workflow_dispatch（手动触发）等。

运行环境：

1
2
3

jobs:
  deploy:
    runs-on: ubuntu-latest

runs-on 指定 Job 跑在哪台机器上，ubuntu-latest 是 GitHub 提供的免费 Linux 虚拟机，预装了常见工具。也可以选 windows-latest、macos-latest。

步骤一：拉取代码

- name: Checkout
  uses: actions/checkout@v4
  with:
      fetch-depth: 0

uses 表示引用一个现成的 Action，actions/checkout@v4 是官方提供的拉代码 Action。fetch-depth: 0 表示拉取完整 git 历史，Hugo 构建需要它来生成文章时间线。

步骤二：安装 Hugo

- name: Setup Hugo
  uses: peaceiris/actions-hugo@v3
  with:
      hugo-version: "0.123.0"
      extended: true

extended: true 安装的是 Hugo 扩展版，支持 SCSS 编译。版本号建议固定，避免上游升级导致构建失败。

步骤三：构建站点

1
2

- name: Build Web
  run: hugo -D

run 直接执行 shell 命令。-D 表示包含 draft 草稿文章（生产环境建议去掉）。

步骤四：部署到 GitHub Pages

- name: Deploy Web
  uses: peaceiris/actions-gh-pages@v4
  with:
      PERSONAL_TOKEN: ${{ secrets.TOKEN }}
      EXTERNAL_REPOSITORY: SymphonyW/SymphonyW.github.io
      PUBLISH_BRANCH: main
      PUBLISH_DIR: ./public
      commit_message: auto deploy

把 ./public 目录的构建产物推送到外部仓库 SymphonyW/SymphonyW.github.io 的 main 分支。PERSONAL_TOKEN 是从仓库 Secrets 里读取的，绝对不会出现在日志里，这是 CI/CD 管理密钥的标准做法。

整条流水线跑完大约 1 分钟，从你 git push 到博客上线，全程无人值守。

六、进阶：加上测试和质量检查

光构建不测试，CI 就名存实亡。下面是一个带测试的进阶示例：

name: ci

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        go-version: ['1.21', '1.22']
    steps:
      - uses: actions/checkout@v4

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: ${{ matrix.go-version }}

      - name: Run tests
        run: go test -race -coverprofile=coverage.out ./...

      - name: Upload coverage
        uses: codecov/codecov-action@v4
        if: success()

      - name: Lint
        uses: golangci/golangci-lint-action@v4
        with:
          version: latest

几个值得注意的点：

strategy.matrix：矩阵测试，一次性在 Go 1.21 和 1.22 两个版本上跑测试，确保兼容性
go test -race：开启竞态检测，能发现并发 bug
if: success()：只有前面步骤成功才上传覆盖率，避免上传垃圾数据
Lint 单独一步：代码风格检查和功能测试解耦，定位问题更快

七、CI/CD 落地最佳实践

理论 + 实战都讲完了，最后总结几条经过踩坑总结的最佳实践：

7.1 流水线设计原则

快速失败：把最快的检查（lint、单元测试）放前面，慢的（集成测试、E2E）放后面，让开发者尽早收到反馈
幂等性：同一次 push 触发多次流水线，结果必须一致，不能依赖外部可变状态
失败必须可复现：日志要清晰，错误信息要能直接定位到代码行
缓存依赖：actions/cache 缓存 node_modules、~/.m2 等，能把构建时间砍掉一半

7.2 安全要点

密钥只放 Secrets：PASSWORD、TOKEN 一律通过 ${{ secrets.XXX }} 注入，绝不能硬编码
最小权限原则：GITHUB_TOKEN 的权限按需授予，默认只读
第三方 Action 锁版本：用 @v4 而不是 @main，避免上游被篡改导致供应链攻击
敏感仓库用自托管 Runner：私有代码不要跑在公共 Runner 上

7.3 常见反模式

反模式	问题	正确做法
流水线里跑 30 分钟	开发者不愿意等，直接跳过	拆分并行 Job，加缓存
只有 main 分支跑 CI	feature 分支 bug 流到 main	所有 PR 都必须跑 CI
测试覆盖率 < 30% 还强跑	CI 形同虚设	先补关键路径测试，再逐步提高门槛
手动 ssh 部署	不可追溯、不可回滚	一切部署走流水线

八、CI/CD 的演进方向

CI/CD 不是终点，它还在持续演进，几个值得关注的趋势：

GitOps：以 Git 作为单一事实源，部署状态完全由 Git 仓库描述，ArgoCD、Flux 是代表工具
Progressive Delivery：渐进式发布，结合金丝雀发布、特性开关，把风险降到最低
AI 辅助 CI：用机器学习预测哪些测试可能失败、哪些代码改动有风险，跳过无关测试加速流水线
供应链安全：SLSA、Sigstore 等框架兴起，确保从源码到产物的每一步都可验证

总结

CI/CD 不是某个工具，而是一种 “让重复的事情自动化、让自动化的结果可信任” 的工程理念。它的价值不在于省了多少人力，而在于让每一次发布都变得 可预期、可追溯、可回滚。

回顾本文要点：

CI 解决集成问题，CD 解决交付和部署问题，三者是一条递进的流水线
选工具先看仓库托管在哪，GitHub 项目首选 GitHub Actions
流水线的核心是 触发 → 构建 → 测试 → 部署，每一步失败都要能阻塞下游
密钥走 Secrets、Action 锁版本、缓存依赖、快速失败，是落地的四条铁律

从今天开始，给你的项目加一条最简单的 CI 流水线吧 —— 哪怕只是 push 后自动跑一遍测试，也是迈向工程化的第一步。