K8s 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 管应用”的门口。

K8s on Snow

K8s Container Cloud Deployment: From Dockerfile Image Build to Release

K8s Container Cloud Deployment: From Dockerfile Image Build to Release

1. What to confirm before deployment

2. The key part: building an image from Dockerfile

Dockerfile instructions you should recognize

A practical image build flow

Go service example

Java Spring Boot example

Node.js service example

Image tag strategy

Match image architecture with cluster nodes

Push to registry

3. Create the workload on the platform

Check the cluster and available capacity

Choose the correct workload type

Create a Deployment with the four-step wizard

Step 1: basic information

Step 2: container configuration

Step 3: service configuration

Step 4: advanced configuration

4. Configure service entry

Create a Service

Create a Route (Ingress)

5. Validate release and prepare rollback

6. Common troubleshooting table

7. Pre-release checklist

Summary

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

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

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

二、K8s 集群到底长什么样

三、准备本地实验环境

四、先用命令跑一个应用

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

六、发布、扩缩容和回滚

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

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

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

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

参考资料