Docker 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

Complete Docker Tutorial from Scratch with Go Language Examples

Sun, 29 Mar 2026 14:41:14 +0800

零基础Docker+Go完整教程

这是一份为纯新手准备的保姆级 Docker 教程，从 0 开始，带你彻底搞懂 Docker，并且全程使用 Go 语言作为实战演示，所有步骤都可以直接复制执行，看完就能上手。

一、为什么要学 Docker？你必须知道的痛点

你有没有遇到过这些问题？

在我电脑上明明能运行啊！：开发完的项目，自己电脑跑的好好的，部署到服务器就各种报错，缺依赖、版本不对、环境变量不一样…
环境配置地狱：想跑个 Redis、MySQL，要装半天，不同项目要不同版本的软件，电脑上装了好几个版本，乱成一团。
部署慢到崩溃：传统虚拟机，启动要几分钟，打包镜像几个 G，传半天才能传到服务器。

Docker 就是来解决这些问题的！

简单来说，Docker 就是把你的应用 + 所有依赖 + 运行环境 + 配置，全部打包成一个 集装箱。这个集装箱可以在任何装了 Docker 的机器上运行，完全不用管那台机器原来装了什么，真正做到 一次打包，到处运行。

而且 Docker 比虚拟机轻量太多了：

容器秒级启动，虚拟机要几分钟
镜像体积只有几十 MB，虚拟机几个 G
一台机器能跑成百上千个容器，虚拟机跑几个就卡了

二、Docker 核心概念：3 分钟搞懂

学 Docker，首先要搞懂这三个核心概念，记住这三个，你就懂了 80%：

概念	是什么？	类比理解
镜像 (Image)	一个只读的模板，包含了运行应用需要的所有东西：代码、运行时、库、环境变量、配置文件。	可以理解成面向对象里的类，是静态的，不变的。
容器 (Container)	镜像的运行实例，是真正跑起来的应用。你可以启动、停止、删除它。	可以理解成类的实例对象，是动态的，运行中的。同一个镜像可以启动 N 个容器，互相隔离。
仓库 (Repository)	存放镜像的地方，相当于镜像的应用商店。最有名的公共仓库是 Docker Hub，里面有几十万现成的镜像，比如 Nginx、MySQL、Redis，你直接拉下来就能用。	可以理解成GitHub，只不过存的是镜像，不是代码。

三者的关系：你从仓库pull（拉）镜像到本地，然后用这个镜像run（运行）出一个或多个容器。

三、Docker 安装：5 分钟搞定环境

Docker 支持 Windows、Mac、Linux 所有主流系统，新手推荐直接安装 Docker Desktop，它自带了 Docker 引擎、命令行工具、图形化界面，一键安装，非常方便。

3.1 Windows 系统安装

注意：Windows 10/11 家庭版需要开启 WSL2，专业 / 企业版也推荐用 WSL2，这是 Docker 官方推荐的模式。

下载 Docker Desktop 安装包：官网下载地址
双击安装包，一路下一步，安装的时候记得勾选 Use the WSL 2 based engine
安装完成后，启动 Docker Desktop，等待它启动完成（任务栏里的 Docker 图标不转了就好了）

3.2 Mac 系统安装

下载 Docker Desktop for Mac：官网下载地址
把下载的.dmg 文件打开，把 Docker 拖到 Applications 文件夹里
启动 Docker，等待它启动完成就行。

3.3 Linux 系统安装（以 Ubuntu/CentOS 为例）

Linux 用户可以用官方的一键安装脚本，非常简单：

# 1. 先安装curl（如果没装的话）
sudo apt update && sudo apt install -y curl  # Ubuntu/Debian
# 或者CentOS用：sudo yum install -y curl

# 2. 下载官方安装脚本
curl -fsSL https://get.docker.com -o install-docker.sh

# 3. 执行安装
sudo sh install-docker.sh

# 4. 启动Docker并设置开机自启
sudo systemctl start docker
sudo systemctl enable docker

3.4 验证安装是否成功

安装完成后，打开终端（Windows 用 PowerShell 或者 WSL 终端），执行：

`1`	`docker --version`

如果输出类似 Docker version 27.0.3, build 7d4bcd8，说明安装成功了！

然后我们跑一个测试镜像，验证 Docker 能不能正常工作：

`1`	`docker run hello-world`

如果看到下面这段文字，说明你的 Docker 已经完全正常了！

1
2
3

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

四、必做：配置镜像加速器（解决国内拉取慢的问题）

默认情况下，Docker 拉取镜像要从国外的 Docker Hub 拉，速度非常慢，甚至会失败。所以我们必须配置国内的镜像加速器，这一步一定要做！

4.1 配置方法

Windows/Mac 系统（Docker Desktop）

打开 Docker Desktop，点击任务栏 / 菜单栏的 Docker 图标，选择 Settings（设置）
找到 Docker Engine 选项
在右边的 JSON 配置里，添加registry-mirrors配置，把下面的内容复制进去：

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.m.daocloud.io",
    "https://docker.xuanyuan.me"
  ],
  "features": {
    "buildkit": true
  }
}

点击右下角的 Apply & Restart，等待 Docker 重启完成。

Linux 系统

Linux 用户需要修改 Docker 的配置文件：

# 1. 创建配置文件目录
sudo mkdir -p /etc/docker

# 2. 写入配置
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.m.daocloud.io",
    "https://docker.xuanyuan.me"
  ],
  "features": {
    "buildkit": true
  }
}
EOF

# 3. 重启Docker
sudo systemctl daemon-reload
sudo systemctl restart docker

4.2 验证加速器是否生效

重启完成后，执行：

`1`	`docker info`

在输出的内容里，找到Registry Mirrors，如果能看到你刚才配置的地址，说明生效了！现在拉镜像速度会快几十倍！

五、第一个 Docker 实战：5 分钟跑一个 Nginx 网站

光说不练假把式，我们先跑一个最简单的 Nginx 网站，体验一下 Docker 的魅力，顺便把基础命令都过一遍。

步骤 1：拉取 Nginx 镜像

首先，我们从仓库拉取 Nginx 的官方镜像：

`1`	`docker pull nginx`

如果你没配置加速器，这一步可能会很慢，配置了的话，几秒就下完了。这里如果不写版本，默认拉取latest最新版，你也可以指定版本，比如docker pull nginx:1.25

步骤 2：查看本地镜像

拉完之后，我们可以看看本地的镜像：

`1`	`docker images`

输出大概是这样：

你能看到刚才拉的 nginx 镜像。

步骤 3：运行 Nginx 容器

现在我们用这个镜像，启动一个容器：

`1`	`docker run --name my-nginx -p 8080:80 -d nginx`

这条命令是 Docker 的核心，我们来拆解一下每个参数，一定要记住：

docker run：创建并启动容器的核心命令

--name my-nginx：给这个容器起个名字，叫 my-nginx，不然 Docker 会给你随机起个奇怪的名字

-p 8080:80：端口映射！这是最常用的参数。格式是宿主机端口:容器内端口。 Nginx 默认在容器里监听 80 端口，我们把它映射到我们电脑的 8080 端口，这样我们就能通过电脑的 8080 端口访问到容器里的 Nginx 了。

-d：后台运行容器，不然你的终端会被容器占住，不能干别的了。

nginx：指定用哪个镜像来启动容器，就是我们刚才拉的 nginx 镜像。

步骤 4：验证容器是否运行

执行完之后，我们看看正在运行的容器：

`1`	`docker ps`

输出大概是这样：

你能看到 my-nginx 正在运行，端口映射8080->80也生效了。

现在，打开你的浏览器，访问 http://localhost:8080，如果看到 Nginx 的欢迎页面，恭喜你！你已经成功用 Docker 跑了第一个网站！

步骤 5：常用的容器操作

查看容器日志

如果容器出问题了，首先看日志：

# 查看日志
docker logs my-nginx

# 实时跟踪日志（类似tail -f）
docker logs -f my-nginx

进入容器内部

有时候我们需要进到容器里改配置、看文件：

`1`	`docker exec -it my-nginx /bin/bash`

这里的-it是交互式终端的意思，/bin/bash是进入后启动 bash 命令行。进去之后，你的命令行提示符会变，说明你已经在容器里了，你可以像正常 Linux 一样用 ls、cd 这些命令，输入exit就能退出容器。

停止 / 删除容器

不用的时候，我们可以停止容器：

`1`	`docker stop my-nginx`

停止之后，容器还在，只是不运行了，你可以用docker start my-nginx再启动它。如果彻底不要了，就删除：

1
2

# 删除前必须先停止容器
docker rm my-nginx

如果你想强制删除正在运行的容器，可以加-f：docker rm -f my-nginx

六、Docker 常用命令大全（收藏备用）

这里整理了所有日常会用到的 Docker 命令，做成表格，你可以收藏起来，用的时候直接查：

镜像相关命令

命令	说明	示例
`docker images`	列出本地所有镜像	`docker images`
`docker pull`	拉取远程镜像	`docker pull mysql:8.0`
`docker rmi`	删除本地镜像	`docker rmi nginx`
`docker build`	从 Dockerfile 构建镜像	`docker build -t my-app:1.0 .`
`docker search`	在 Docker Hub 搜索镜像	`docker search redis`
`docker tag`	给镜像打标签	`docker tag my-app:latest my-app:v1.0`
`docker push`	推送镜像到仓库	`docker push my-repo/my-app:v1.0`

容器相关命令

命令	说明	示例
`docker run`	创建并启动容器	`docker run -d -p 8080:80 --name my-nginx nginx`
`docker ps`	列出正在运行的容器	`docker ps`
`docker ps -a`	列出所有容器（包括停止的）	`docker ps -a`
`docker start`	启动已停止的容器	`docker start my-nginx`
`docker stop`	停止运行中的容器	`docker stop my-nginx`
`docker restart`	重启容器	`docker restart my-nginx`
`docker rm`	删除容器	`docker rm my-nginx`
`docker exec`	在运行的容器里执行命令	`docker exec -it my-nginx bash`
`docker logs`	查看容器日志	`docker logs -f my-nginx`
`docker cp`	宿主机和容器之间复制文件	`docker cp my-file.txt my-nginx:/app/`
`docker inspect`	查看容器 / 镜像的详细信息	`docker inspect my-nginx`

七、自定义镜像：用 Go 语言打包你的应用

看完了别人的镜像，现在我们来自己做一个镜像，把我们自己写的 Go 应用打包进去，这也是你日常开发最常用的场景。

7.1 先写一个简单的 Go 应用

我们先写一个最简单的 HTTP 服务，就几行代码，用来测试。

首先，创建一个项目文件夹，比如叫go-demo：

`1`	`mkdir go-demo && cd go-demo`

然后，在这个文件夹里，创建main.go文件，写入下面的代码：

package main

import (
	"fmt"
	"net/http"
	"os"
)

func main() {
	// 定义HTTP接口，访问根路径返回Hello
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		hostname, _ := os.Hostname()
		fmt.Fprintf(w, "Hello from Docker! 🐳\n")
		fmt.Fprintf(w, "容器主机名: %s\n", hostname)
		fmt.Fprintf(w, "你的IP: %s\n", r.RemoteAddr)
	})

	// 监听8081端口
	fmt.Println("服务启动在 :8081 端口...")
	http.ListenAndServe(":8081", nil)
}

这个代码很简单，就是启动一个 HTTP 服务，访问根路径的时候，返回欢迎信息，还有容器的主机名，这样我们能区分是不是在容器里运行。

然后，我们初始化 Go 模块，用来管理依赖：

`1`	`go mod init go-demo`

执行完之后，会生成一个go.mod文件，这是 Go 的依赖管理文件。

现在，我们可以先在本地跑一下，测试代码对不对：

`1`	`go run main.go`

然后访问http://localhost:8081，如果能看到 Hello 信息，说明代码没问题，按 Ctrl+C 停止。

7.2 什么是 Dockerfile？

要打包我们的应用，我们需要写一个Dockerfile，它是一个文本文件，里面写了构建镜像的所有步骤，Docker 会根据这个文件，一步步帮你构建出镜像。

我们先来看一下 Dockerfile 里最常用的指令，每个指令都很简单：

指令	作用
`FROM`	指定基础镜像，所有的镜像都是基于这个来构建的，这是 Dockerfile 的第一行
`WORKDIR`	指定工作目录，相当于`cd`到这个目录，后面的命令都是在这个目录下执行
`COPY`	把宿主机的文件复制到镜像里
`RUN`	执行命令，比如编译代码、安装依赖
`CMD`	容器启动的时候，默认执行的命令，也就是启动我们应用的命令
`EXPOSE`	声明容器要暴露的端口，只是声明，方便别人知道这个容器用了什么端口，不是实际的端口映射

7.3 单阶段构建：最基础的写法

我们先写一个最简单的单阶段 Dockerfile，就是所有的构建和运行都在一个镜像里。

在项目文件夹里，创建Dockerfile文件，写入下面的内容：

# 1. 基础镜像：用官方的Go镜像，里面已经装好了Go的编译环境
# **这里的版本号要和go.mod里的一致，不然可能会有兼容性问题**
FROM golang:1.21-alpine

# 2. 设置工作目录，后面的命令都在/app下执行
WORKDIR /app

# 3. 这里先复制go.mod，是为了利用Docker的缓存：只要依赖没变，就不用重新下载
COPY go.mod ./

# 4. 自动处理依赖，下载需要的包
RUN go mod tidy

# 5. 把所有代码复制过来
COPY . .

# 6. 编译Go代码，生成二进制文件
RUN go build -o main main.go

# 7. 暴露8081端口
EXPOSE 8081

# 8. 容器启动的时候，运行我们的程序
CMD ["./main"]

现在，我们来构建镜像：

`1`	`docker build -t go-demo:v1 .`

这里的-t go-demo:v1是给镜像起名字，叫 go-demo，版本 v1。最后的.是构建上下文，意思是把当前目录的文件作为构建的上下文，Docker 会把这些文件传给 Docker 引擎，所以这个点不能少！

构建完成之后，我们看看镜像大小：

`1`	`docker images`

你会发现，这个镜像有几百 MB！比如我这里是 431MB，这也太大了，一个几行的程序，镜像 400多MB？

这是因为，这个镜像里包含了整个 Go 的编译环境、所有的依赖源码、中间文件，这些东西在运行的时候根本不需要！我们运行的时候只需要那个编译好的二进制文件而已。

那怎么把镜像变小呢？这就要用到多阶段构建了！

7.4 多阶段构建

多阶段构建就是，我们把构建过程分成两个阶段：

构建阶段：用大的 Go 镜像，把代码编译成二进制文件
运行阶段：用一个超级小的基础镜像，只把编译好的二进制文件复制过来，其他的都不要！

这样，最终的镜像就只有运行需要的东西，体积会小 90% 以上！

我们来修改一下 Dockerfile，改成多阶段的：

# ======================================
# 第一阶段：构建阶段（Builder）
# 这个阶段用来编译代码，最后会被扔掉，只拿编译好的文件
# ======================================
FROM golang:1.21-alpine AS builder

# 设置工作目录
WORKDIR /app

# 复制依赖文件，下载依赖
COPY go.mod ./
RUN go mod tidy

# 复制代码
COPY . .

# 编译代码！这里要注意：
# CGO_ENABLED=0：关闭CGO，编译成纯静态的二进制文件，不需要任何动态链接库
# GOOS=linux：指定编译成Linux平台的，因为我们的容器是Linux的
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main main.go

# ======================================
# 第二阶段：运行阶段（Runtime）
# 这个阶段是最终的镜像，只有我们需要的东西
# ======================================
# 用超级小的Alpine镜像，只有5MB左右！
FROM alpine:latest

# 安装必要的依赖：ca-certificates是HTTPS需要的证书，tzdata是时区数据
RUN apk --no-cache add ca-certificates tzdata

# 设置时区为上海，不然容器里的时间是UTC的，差8小时
ENV TZ=Asia/Shanghai

# 设置工作目录
WORKDIR /root/

# 重点！从构建阶段，把编译好的main文件复制过来！
# 其他的编译环境、源码，都不要了！
COPY --from=builder /app/main .

# 暴露端口
EXPOSE 8081

# 启动程序
CMD ["./main"]

这里解释一下为什么要加CGO_ENABLED=0：默认情况下，Go 编译会用 CGO，生成动态链接的程序，在 Alpine 里会因为缺少 glibc 库而运行不了。关闭 CGO 之后，编译出来的是纯静态的二进制文件，不需要任何依赖，直接就能在 Alpine 里跑。

现在，我们重新构建镜像：

`1`	`docker build -t go-demo:v2 .`

构建完成之后，我们再看看镜像大小：

`1`	`docker images`

你看，原来的 v1 是 431MB，现在的 v2 只有27MB左右！直接缩小了95%左右！这就是多阶段构建的威力！

7.5 运行我们的 Go 应用镜像

现在，我们来运行这个新的镜像：

`1`	`docker run -d -p 8081:8081 --name go-demo go-demo:v2`

然后，打开浏览器，访问http://localhost:8081，你就能看到我们的 Go 应用返回的信息了！

完美！我们的 Go 应用已经成功打包成 Docker 镜像，并且跑起来了！

八、Docker Compose：一键启动多服务应用

平时我们开发的时候，很少只有一个服务，比如我们的 Go 应用，要连 MySQL、Redis，这时候如果一个个启动容器，要写好长的命令，太麻烦了。

这时候就轮到Docker Compose出场了！它可以把你的多个服务，写在一个配置文件里，然后一条命令，就能把所有服务都启动起来，一键搞定！

8.1 什么是 Docker Compose？

Docker Compose 是 Docker 官方的编排工具，用来定义和运行多个容器的应用。你只需要一个docker-compose.yml文件，就能定义你的所有服务，然后一条命令，就能把它们全部启动。

8.2 实战：Go+MySQL 多服务应用

我们来做一个实战，把我们的 Go 应用，加上 MySQL 数据库，用 Compose 一键启动。

首先，我们修改一下我们的 Go 应用，让它连接 MySQL，查询数据。

先修改main.go：

package main

import (
	"database/sql"
	"fmt"
	"net/http"
	"os"

	_ "github.com/go-sql-driver/mysql"
)

func main() {
	// 从环境变量获取MySQL的配置，这样不用写死在代码里
	dbUser := os.Getenv("DB_USER")
	dbPass := os.Getenv("DB_PASS")
	dbHost := os.Getenv("DB_HOST")
	dbName := os.Getenv("DB_NAME")

	// 连接MySQL
	dsn := fmt.Sprintf("%s:%s@tcp(%s:3306)/%s?parseTime=true", dbUser, dbPass, dbHost, dbName)
	db, err := sql.Open("mysql", dsn)
	if err != nil {
		panic(err)
	}
	defer db.Close()

	// 测试连接
	err = db.Ping()
	if err != nil {
		panic(err)
	}
	fmt.Println("成功连接MySQL!")

	// 定义接口
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		hostname, _ := os.Hostname()
		fmt.Fprintf(w, "Hello from Docker! 🐳\n")
		fmt.Fprintf(w, "容器主机名: %s\n", hostname)
		fmt.Fprintf(w, "MySQL连接成功！数据库名: %s\n", dbName)
	})

	// 启动服务
	fmt.Println("服务启动在 :8081 端口...")
	http.ListenAndServe(":8081", nil)
}

然后，我们更新一下依赖，把旧的go.mod删掉：

1
2
3

rm go.mod go.sum
go mod init go-demo
go mod tidy

现在，我们在项目根目录，创建docker-compose.yml文件，写入下面的内容：

# 定义服务，这里我们有两个服务：app和mysql
services:
  # 我们的Go应用服务
  app:
    # 从当前目录的Dockerfile构建镜像
    build: .
    # 容器名字
    container_name: go-app
    # 端口映射
    ports:
      - "8081:8081"
    # 环境变量，传给我们的Go应用，用来连接MySQL
    environment:
      DB_USER: root
      DB_PASS: 123456
      DB_HOST: mysql  # 这里注意！Compose里的服务名，就是互相访问的域名！所以我们直接用mysql作为主机名，就能访问到mysql容器了！
      DB_NAME: testdb
    # 依赖关系：先启动mysql，再启动app
    depends_on:
      mysql:
        condition: service_healthy


  # MySQL服务
  mysql:
    # 用MySQL 8.0的镜像
    image: mysql:8.0
    container_name: go-mysql
    # 端口映射
    ports:
      - "3307:3306"
    # 环境变量，MySQL的配置
    environment:
      MYSQL_ROOT_PASSWORD: 123456  # root密码
      MYSQL_DATABASE: testdb        # 自动创建的数据库名
    # 数据卷：把MySQL的数据持久化到本地，不然容器删了，数据就没了！
    volumes:
      - mysql-data:/var/lib/mysql
    # 给mysql加健康检查，检测mysql是否真的可以接受连接
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-p123456"]
      interval: 5s
      timeout: 5s
      retries: 10

# 定义数据卷
volumes:
  mysql-data:

这里有个重点：Compose 会自动给我们的服务创建一个网络，所以服务之间可以直接用服务名互相访问！比如我们的 app 服务，要连接 mysql，直接用mysql作为主机名就行，不用 IP，Compose 会自动解析，太方便了！

8.3 一键启动所有服务

现在，我们只需要执行一条命令，就能把 Go 应用和 MySQL 一起启动：

`1`	`docker-compose up -d`

-d是后台运行，和之前的一样。

执行完之后，Compose 会自动帮你：

构建 Go 应用的镜像
拉取 MySQL 的镜像
启动 MySQL 容器，自动创建数据库
启动 Go 应用容器，连接 MySQL

等个十几秒，启动完成之后，我们访问http://localhost:8081，就能看到：

完美！两个服务，一条命令就全部启动了！

如果你要停止所有服务，只需要执行：

`1`	`docker-compose down`

所有的容器就都停了，数据卷还在，下次启动数据还在。

九、常见问题与排错指南

新手用 Docker，经常会遇到这些问题，这里给你整理好了解决方案：

1. 端口占用，启动容器报错`port is already allocated`

这说明你电脑的那个端口已经被别的程序占用了，比如你已经有一个 Nginx 占用了 8080 端口。解决方法：换一个宿主机端口，比如把-p 8081:80，用 8081 端口就行。

2. 拉取镜像超时 / 失败

这是网络问题，首先检查你有没有配置镜像加速器，配置了的话，换一个加速器地址，或者多试几次。

3. Go 程序在 Alpine 容器里运行报错`no such file or directory`

这就是我们之前说的 CGO 的问题，你编译的时候没关 CGO，导致程序依赖动态链接库，Alpine 里没有。解决方法：编译的时候加上CGO_ENABLED=0 GOOS=linux，编译成静态二进制。

4. 容器里的时间不对，比北京时间差 8 小时

这是因为 Alpine 默认是 UTC 时区，解决方法：

安装 tzdata 包：RUN apk --no-cache add tzdata
设置时区环境变量：ENV TZ=Asia/Shanghai

5. 容器之间无法访问

如果是用 Compose 的话，检查你是不是用服务名作为主机名，不要用localhost，因为每个容器的localhost都是自己。如果是单独的容器，检查它们是不是在同一个网络里，或者把它们连到同一个网络。

十、总结

到这里，你已经掌握了 Docker 的核心技能了：

理解了 Docker 的核心概念，知道了镜像、容器、仓库是什么
学会了安装 Docker，配置镜像加速器，解决了国内的网络问题
掌握了 Docker 的常用命令，能熟练操作镜像和容器
学会了写 Dockerfile，用多阶段构建把 Go 应用打包成极小的镜像
学会了用 Docker Compose，一键启动多服务应用

Docker 是现代开发者的必备技能，学会了它，你再也不用为环境问题头疼，部署应用也变得无比简单。接下来，你可以把你自己的项目，用这个方法打包成 Docker 镜像，试试部署到服务器上，体验一下一键部署的快感！