企业官网建设流程全解析

很多刚接触云原生和容器技术的同学，第一反应往往是：Docker 还没弄明白，K8S 又是什么？两个东西到底什么关系？为什么招聘 JD 里 Linux 运维岗几乎都要求掌握这两项？本文就围绕 Docker 与 K8S 这条主线，从零开始梳理容器化与集群编排的核心知识，并结合 Linux 运维日常工作场景，带你走一遍从环境安装、镜像管理、容器运行，到 Kubernetes 集群部署、Pod 调度、权限控制与故障排查的完整链路。内容尽量做到新手能看懂，有基础的同学也能直接照着敲命令、查报错。

1. 为什么要学 Docker 和 K8S

先看一个最简单的问题：为什么 Docker 和 K8S 能成为 Linux 运维技能栈中的高频词汇？

过去我们在服务器上部署应用，流程通常是：安装依赖、配置环境变量、放置代码压缩包、启动进程。这套流程在单机环境还能接受，一旦涉及多台服务器、多种运行环境、不同版本依赖，问题就来了：

• 开发环境跑得好好的，测试环境启动失败；
• 换一台服务器部署，缺了这个库少了那个依赖；
• 多个应用共享一台机器，版本互相冲突；
• 线上扩容要把整套部署流程重新走一遍。

Docker 解决的是“环境一致性和应用打包”问题。它把应用连同它依赖的运行环境一起打包成镜像，镜像在任意安装了 Docker 的 Linux 主机上都能以容器方式运行。简单理解：镜像就是模板，容器就是模板创建的运行实例。

K8S（Kubernetes）解决的是“大规模容器调度和管理”问题。当容器数量从几个增长到几十个、几百个，单靠 Docker 命令去手动启停、扩容、故障恢复已经不现实。K8S 提供了自动部署、自动伸缩、服务发现、负载均衡、故障自愈等能力，成为容器编排领域事实上的标准。

对 Linux 运维来说，这两者的价值很直接：Docker 让你把应用“标准化交付”，K8S 让你把容器“规模化运维”。需要特别注意的是，Docker 和 K8S 不是同一个层次的东西，Docker 是容器运行时的一种实现，K8S 是容器编排平台。K8S 默认使用的是 containerd 作为容器运行时，也支持其他符合 CRI 标准的运行时，Docker 只是其中一种。

2. 环境准备：先把 Docker 安装好

学习 Docker 和 K8S 的第一步，是准备一套可用的实验环境。下面以 Linux 环境为主来演示安装过程，操作系统版本比较常见的是 Ubuntu 20.04/22.04、CentOS 7.9/8 或 Rocky Linux。不同系统下软件源不同，安装命令略有差异，本文重点演示思路，具体版本请根据你的实际环境调整。

2.1 Linux 下安装 Docker

先更新系统软件包索引，然后安装依赖工具，再添加 Docker 官方软件源。

以 Ubuntu 系统为例：

sudo apt update sudo apt install -y apt-transport-https ca-certificates curl software-properties-common # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加 Docker 软件源 echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

CentOS 7 系统下的安装方式稍有不同：

sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin sudo systemctl start docker sudo systemctl enable docker

安装完成后启动 Docker 服务，并设置开机自启：

sudo systemctl start docker sudo systemctl enable docker sudo systemctl status docker

2.2 配置镜像加速源

由于网络环境的原因，直接从 Docker Hub 拉取镜像速度可能很慢，甚至超时。国内使用 Docker 时通常需要配置镜像加速源。常见的加速源有阿里云容器镜像服务、腾讯云、中科大等，由于可用性经常变动，这里不写死具体地址，只说明配置方式。

编辑/etc/docker/daemon.json文件，如果文件不存在则新建：

{ "registry-mirrors": ["https://your-mirror-address"] }

修改完成后重启 Docker 使配置生效：

sudo systemctl daemon-reload sudo systemctl restart docker

配置完成后，可以用docker info查看 Registry Mirrors 是否生效。

2.3 验证安装

docker version docker info

再运行一个测试容器：

docker run hello-world

如果能看到类似 “Hello from Docker!” 的输出，说明 Docker 安装成功，整个镜像拉取和容器运行链路是通的。

2.4 Windows 和 macOS 环境说明

Windows 上安装 Docker 通常使用 Docker Desktop，它依赖 Windows 的虚拟化功能。安装启动时如果遇到 “Docker Desktop failed to start because virtualization support was not detected” 这类报错，一般要从下面几个方向排查：

如果你只是为了学习 Linux 运维和 K8S，还是建议直接在 Linux 虚拟机或云服务器上操作，这样更贴近生产环境，也能避免桌面虚拟化带来的各种兼容问题。

3. Docker 核心概念与常用命令

3.1 镜像、容器、仓库

Docker 有三个最基础的概念：

• 镜像（Image）：只读模板，包含应用代码、运行时、系统库、配置等所有内容。
• 容器（Container）：镜像运行的实例，可以被启动、停止、删除。
• 仓库（Repository）：集中存放镜像的地方，最常用的是 Docker Hub。

它们的关系可以类比为：镜像好比是操作系统的 ISO 安装盘，容器则是安装并运行起来的系统实例。每次基于同一个镜像可以创建多个互不影响的容器实例。

3.2 镜像常用命令

# 搜索镜像 docker search nginx # 拉取镜像 docker pull nginx:latest # 查看本地镜像列表 docker images # 删除镜像 docker rmi nginx:latest # 查看镜像详细信息 docker inspect nginx:latest

在搜索热词中经常能看到“docker 镜像下载慢”这个话题，这通常对应两个原因：一是没有配置镜像加速源，需要按上文方式配置；二是拉取的镜像体积本身很大，比如包含完整操作系统的镜像，可以考虑改用更精简的 Alpine 版本。

3.3 容器生命周期命令

容器生命周期管理是日常运维最常用的部分：

# 创建并启动容器 docker run -d --name nginx-demo -p 8080:80 nginx # 查看运行中的容器 docker ps # 查看所有容器（包含已退出） docker ps -a # 停止容器 docker stop nginx-demo # 启动已停止的容器 docker start nginx-demo # 重启容器 docker restart nginx-demo # 删除容器 docker rm nginx-demo

这里重点解释一下docker run中的参数：

• -d表示后台运行；
• --name指定容器名称；
• -p 8080:80表示把本机 8080 端口映射到容器的 80 端口；
• -v用于挂载数据卷，实现数据持久化，后面实战部分会用到。

3.4 进入容器执行命令

热词中的docker exec -it是非常高频的运维命令。它表示在运行中的容器内执行命令：

docker exec -it nginx-demo bash

-i表示保持标准输入打开，-t表示分配一个终端，这样就能得到一个交互式 shell。如果容器内没有 bash，可以尝试 sh：

docker exec -it nginx-demo sh

除了交互式进入容器，还可以直接执行单条命令，比如查看容器内进程：

docker exec nginx-demo ps aux

3.5 日志与资源查看

# 查看容器日志 docker logs nginx-demo # 实时跟踪日志输出 docker logs -f nginx-demo # 查看容器资源占用 docker stats

docker logs是排错时第一个要用的命令。应用启动报错、连接数据库失败、端口被占用等问题，大多能从日志里找到线索。

4. Docker 实战：安装 MySQL 8.0 和 Redis 主从

学习 Docker 不能停留在命令层面，最好把它放进真实应用场景里。下面以开发环境中最常见的 MySQL 8.0 和 Redis 主从搭建为例，演示 Docker 在实际部署中的应用。

4.1 使用 Docker 安装 MySQL 8.0 并连接

拉取 MySQL 8.0 镜像：

docker pull mysql:8.0

启动 MySQL 容器，并设置 root 用户密码：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=your_password \ -e MYSQL_DATABASE=testdb \ mysql:8.0

参数说明：

• -e MYSQL_ROOT_PASSWORD设置 root 密码；
• -e MYSQL_DATABASE创建一个默认数据库；
• -p 3306:3306映射宿主机 3306 端口。

容器启动后，使用本机客户端连接验证：

mysql -h 127.0.0.1 -P 3306 -u root -p

如果宿主机没有安装 mysql 客户端，也可以通过容器内的客户端连接：

docker exec -it mysql8 mysql -u root -p

4.2 数据持久化：挂载数据卷

MySQL 容器如果被删除，容器内数据会一起消失。生产环境绝对不能这样干，必须把数据文件挂载到宿主机磁盘上：

mkdir -p /data/mysql8/conf mkdir -p /data/mysql8/data docker run -d \ --name mysql8 \ -p 3306:3306 \ -v /data/mysql8/conf:/etc/mysql/conf.d \ -v /data/mysql8/data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=your_password \ mysql:8.0

这里的-v /data/mysql8/data:/var/lib/mysql是关键：宿主机目录/data/mysql8/data与容器内 MySQL 数据目录/var/lib/mysql建立了绑定关系。即使容器被删除，只要宿主机目录还在，数据就不会丢。重新创建容器时，只要挂载同一个目录，数据会自动恢复。

4.3 使用 Docker 搭建 Redis 主从

Redis 主从复制是常见的数据冗余方案。用 Docker 在一台机器上模拟主从结构非常简单。先创建三个容器，分别是主节点和两个从节点：

# 主节点 docker run -d --name redis-master -p 6379:6379 redis:7 redis-server --appendonly yes # 从节点1 docker run -d --name redis-slave1 -p 6380:6379 redis:7 redis-server --appendonly yes --slaveof 172.17.0.2 6379 # 从节点2 docker run -d --name redis-slave2 -p 6381:6379 redis:7 redis-server --appendonly yes --slaveof 172.17.0.2 6379

这里有一个容易踩坑的地方：从节点配置的--slaveof参数，IP 地址不能写127.0.0.1，需要写主容器的实际 IP。可以通过docker inspect redis-master查看容器的 IP 地址，或者使用docker network自定义网络让容器之间通过容器名通信。

更推荐的做法是创建一个自定义 Docker 网络：

docker network create redis-net docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7 redis-server --appendonly yes docker run -d --name redis-slave1 --network redis-net -p 6380:6379 redis:7 redis-server --appendonly yes --slaveof redis-master 6379 docker run -d --name redis-slave2 --network redis-net -p 6381:6379 redis:7 redis-server --appendonly yes --slaveof redis-master 6379

在同一个自定义网络中，容器之间可以直接通过容器名解析 IP，这样就避免了手动查 IP 的麻烦。

4.4 验证主从状态

进入从节点容器，执行info replication：

docker exec -it redis-slave1 redis-cli info replication

输出中如果出现master_link_status:up，说明主从同步正常。

5. Docker Compose：多容器编排入门

通过上面的例子可以看到，用docker run一条条命令启动多个容器，容器一多就非常零散，而且配置无法复用。Docker Compose 的价值就是把多个容器的启动参数写在一个 YAML 配置文件中，一条命令启动整个应用栈。

5.1 编写 docker-compose.yml

以 MySQL 和 Redis 组合为例，创建docker-compose.yml：

version: '3.8' services: mysql: image: mysql:8.0 container_name: mysql8-compose ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: your_password MYSQL_DATABASE: testdb volumes: - mysql_data:/var/lib/mysql restart: always redis: image: redis:7 container_name: redis-compose ports: - "6379:6379" command: redis-server --appendonly yes volumes: - redis_data:/data restart: always volumes: mysql_data: redis_data:

这个文件中定义了两个服务：MySQL 和 Redis。volumes部分声明了命名卷，Docker Compose 会自动管理卷的创建和挂载。

5.2 Compose 常用命令

# 启动所有服务 docker compose up -d # 查看服务状态 docker compose ps # 查看日志 docker compose logs -f mysql # 停止服务 docker compose stop # 停止并删除容器和网络 docker compose down # 停止并删除容器、网络、数据卷 docker compose down -v

docker compose down -v会连同数据卷一起删除，操作前必须确认是否要保留数据，否则数据会全部丢失。

5.3 适合使用 Compose 的场景

Docker Compose 适合单机多容器的应用编排，比如开发环境、测试环境、小型生产项目。但是当应用规模变大，需要多台机器组成集群时，就需要升级到 Kubernetes 这类容器编排平台。

6. Kubernetes 核心概念与架构

Kubernetes 简称 K8S，为什么叫 K8S？因为 K 和 S 之间正好有 8 个字母。它是一个开源的容器编排平台，由 Google 发起，目前由云原生计算基金会（CNCF）维护。

6.1 Pod：K8S 最小调度单位

Pod 是 K8S 中最小、最基本的部署单元。一个 Pod 可以包含一个或多个容器，这些容器共享网络命名空间和存储卷。最常见的用法是一个 Pod 只跑一个主容器，日志采集等辅助容器也可以作为 Sidecar 和主容器共存于同一个 Pod 中。

在网络热词中经常看到“k8s pod”，说明很多初学者对 Job、Deployment、DaemonSet 这些概念还不够熟悉时，Pod 是最先遇到的对象。理解 Pod 的关键在于：Pod 是“一组容器的集合”，K8S 不直接调度容器，而是调度 Pod。

6.2 Deployment：管理无状态应用

Deployment 负责管理无状态应用的部署和更新。它描述了一个 Pod 模板，以及期望的副本数。Deployment 会自动创建 ReplicaSet，由 ReplicaSet 负责维持指定数量的 Pod 副本。

举个例子，如果你希望 nginx 应用始终有 3 个副本在运行，只需要声明一个 Deployment，K8S 会确保任何时刻都有 3 个 Pod 存在。某个 Pod 崩溃了，Deployment 会自动创建新的 Pod 替换。

6.3 Service：服务发现与负载均衡

Pod 的 IP 是动态变化的，Pod 重建后 IP 就会变。Service 就是为解决这个问题而生的：它为一组 Pod 提供稳定的访问入口，并负责负载均衡。Service 通过 Selector 选择匹配的 Pod，外部请求访问 Service 的 IP 和端口，再由 Service 转发到后端 Pod。

6.4 控制平面与工作节点

一个 K8S 集群通常包含两类节点：

• 控制平面（Control Plane）：运行 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 等组件，负责集群的管理和控制。
• 工作节点（Worker Node）：运行 kubelet、kube-proxy，以及容器运行时（如 containerd），负责实际运行 Pod。

kube-apiserver 是所有组件交互的入口，etcd 用于保存集群的持久化状态。这些组件各司其职，组成了一个完整的管理闭环。

7. K8S 安装部署与常用命令

7.1 安装部署方式

K8S 的安装部署方式非常多，新手很容易迷茫。这里把常见方式分成几类来理解：

• 单机学习最推荐：使用 minikube，一条命令启动单节点集群，适合本地开发和学习。
• 生产环境多节点：使用 kubeadm 初始化集群，这是目前社区使用最广泛的部署方式。
• 二进制方式：手动部署每个组件，过程繁琐，但能帮助深入理解组件协作关系。
• 云平台托管：使用云厂商的托管 K8S 服务，不用管理控制平面，只需要关注工作节点。

本文以 kubeadm 方式为主来理解集群搭建思路，但具体版本和命令需要根据目标环境调整。一个比较常见的搭建流程是：

1. 所有节点安装容器运行时（如 containerd）；
2. 所有节点安装 kubelet、kubeadm、kubectl；
3. 控制平面节点执行kubeadm init初始化集群；
4. 工作节点执行kubeadm join加入集群；
5. 配置 kubectl 访问集群。

7.2 kubectl 常用命令

kubectl是操作 K8S 集群的命令行工具，日常使用频率非常高：

# 查看节点状态 kubectl get nodes # 查看所有命名空间下的 Pod kubectl get pods -A # 查看某个命名空间下的 Pod kubectl get pods -n default # 查看 Pod 详细信息，排错最常用 kubectl describe pod <pod-name> # 查看 Pod 日志 kubectl logs <pod-name> # 进入 Pod 容器 kubectl exec -it <pod-name> -- bash # 查看 Service kubectl get svc # 查看 Deployment kubectl get deployment

7.3 部署第一个应用到 K8S

利用 YAML 文件声明式地创建资源，是 K8S 的标准使用方式。创建一个nginx-deployment.yaml：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80

应用这个配置：

kubectl apply -f nginx-deployment.yaml

查看 Pod 状态：

kubectl get pods

等所有 Pod 处于 Running 状态后，创建一个 Service 暴露服务：

kubectl expose deployment nginx-deployment --type=NodePort --port=80

查看 Service 分配的端口：

kubectl get svc

然后通过任意节点的节点IP:NodePort端口访问 nginx 服务。

7.4 K8S 只读权限用户配置

网络热词中有一个很有代表性的运维场景：“k8s 只开只读权限的用户”。在生产环境中，给不同团队成员分配不同权限是安全底线。通过 K8S RBAC（Role-Based Access Control）可以实现一个只能查看资源、不能修改资源的只读用户。

下面是创建只读角色的思路。先创建 Role，限制只能执行 get、list、watch 操作：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: read-only-role rules: - apiGroups: [""] resources: ["pods", "pods/log", "services", "configmaps", "secrets"] verbs: ["get", "list", "watch"]

再创建 RoleBinding，把角色绑定到指定用户：

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: default name: read-only-binding subjects: - kind: User name: readonly-user apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: read-only-role apiGroup: rbac.authorization.k8s.io

配置完成后，该用户在 default 命名空间下，对声明过的资源只有读取权限。如果尝试执行kubectl delete pod，会返回 Forbidden 错误。

这个配置片段重点演示的是 RBAC 权限控制思路。生产环境还需要联调证书或者 ServiceAccount，按实际需求调整。

8. 常见问题与故障排查

Docker 和 K8S 日常使用中遇到的问题非常多样，这里整理几个高频情况，方便大家按图索骥。

8.1 常见问题速查表

8.2 K8S CPU Throttling 问题

热词中的 “k8s cpu throttling” 是性能排查中经常遇到的一个问题。当 Pod 设置了 CPU 的 limit，比如cpu: "1"，表示该 Pod 最多使用 1 个 CPU 核心。K8S 底层的 CPU 配额机制会对 CPU 使用进行周期限制，如果应用短期内超过配额，就会出现 CPU Throttling，表现为应用响应变慢、延迟升高，但kubectl top pod看到 CPU 使用率并不高。

排查思路：

• 首先使用kubectl top pod <pod-name>查看实际 CPU 使用量；
• 如果 CPU 使用长期接近 limit，说明 limit 配置偏低，需要适当地调大；
• 如果 CPU 使用率不高却仍然出现 throttling，可以检查应用是否有突刺型负载，考虑设置合理的requests和limits；
• 对于 CPU 敏感型应用，建议结合 HPA（HorizontalPodAutoscaler）自动扩容，避免单个 Pod 长时间被 CPU 限制。

8.3 快速排查方法

做容器和集群排错，建议养成一个固定的排查顺序：

1. 先看状态：kubectl get pods，确认 Pod 处于 Running、Pending 还是 CrashLoopBackOff。
2. 再看详情：kubectl describe pod <pod-name>，最关键的 Events 部分会给出调度失败、镜像拉取失败等明确原因。
3. 再看日志：kubectl logs <pod-name>，应用本身的报错是定位问题的第一手资料。
4. 最后看资源：kubectl top pod、docker stats，确认是否资源不足。
5. 看网络和存储：确认 Service 和 Pod 的标签是否匹配，PVC 是否绑定成功。

这套流程覆盖了大部分常见问题，配合 8.1 的表格能解决绝大多数日常故障。

9. 最佳实践与工程建议

9.1 镜像管理规范

• 不使用latest标签发布生产环境。latest指向的镜像会变化，无法追溯，强烈建议使用明确版本号，例如nginx:1.27.3。
• 镜像尽可能精简，使用 Alpine 等小型基础镜像能显著减少拉取时间和存储占用。
• 私有化镜像仓库建议加镜像签名或扫描，避免引入漏洞镜像。
• 定期清理不用的镜像和容器，避免磁盘空间被占满。

# 清理停止的容器 docker container prune # 清理悬空镜像 docker image prune # 清理所有未使用资源 docker system prune -a --volumes

docker system prune -a --volumes属于高危操作，会删除所有未被使用的容器、网络、镜像以及数据卷。执行前必须确认这些资源确实不需要，否则数据无法找回。

9.2 容器与集群安全

• Docker 容器默认以 root 用户运行，风险和宿主机 root 等同。生产环境尽量指定非 root 用户，或在镜像中创建专用用户。
• 容器权限遵循最小化原则，不使用的 Linux capabilities 不要开放。
• K8S 集群控制平面组件不要直接暴露到公网。
• 权限管理使用 RBAC，给不同角色分配最小权限。只读用户、开发用户、管理员用户的权限必须区分开。
• 涉及生产环境的任何变更，先备份，再小范围验证，最后全量执行。

9.3 持久化与备份

• 所有有状态应用必须挂载数据卷，不能依赖容器内部存储。
• 数据库等有状态服务，建议使用 StatefulSet 来管理，Pod 有稳定的网络标识和存储标识。
• 定期备份 MySQL、Redis 数据，备份文件存储到独立存储系统。
• K8S 集群本身的 etcd 也要纳入备份计划，etcd 损坏会导致集群状态全部丢失。

9.4 资源限制配置

在 K8S 中，每个容器都应该设置resources.requests和resources.limits：

resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "256Mi"

requests是调度依据，表示该容器至少需要这么多资源；limits是运行时上限，防止容器无限占用节点资源。完全不设置资源限制的容器，一旦出现内存泄漏，可能拖垮整个节点。

9.5 监控与告警

生产级 K8S 集群离不开监控体系。比较常见的组合是 Prometheus + Grafana + node-exporter：

• node-exporter 采集节点层面的 CPU、内存、磁盘、网络指标；
• Prometheus 负责收集和存储指标数据；
• Grafana 提供可视化面板和告警规则配置。

磁盘告警规则的通用配置思路是：在 Prometheus 中定义规则，当节点磁盘使用率超过阈值（比如 85%）时触发告警，再通过 Alertmanager 发送通知。具体的规则语法和启动参数版本关联较大，学习时建议结合官方文档按实际版本配置。

9.6 命名与标签规范

K8S 资源数量一旦增多，命名和标签就非常重要。给所有资源打上统一的标签，比如app、env、version，后续做选择、排查、扩缩容都会方便很多。Service 的 Selector 必须和 Pod 的 labels 保持一致，这一个细节能避免大量网络不通问题。

10. 总结与学习路线

到这里，Docker 和 K8S 的主线知识已经梳理了一遍。我们分别覆盖了 Docker 的镜像、容器、数据卷、Compose 等核心能力，又讲解了 K8S 的 Pod、Deployment、Service、RBAC 等核心概念，并通过 MySQL、Redis、nginx 等实际案例熟悉了部署流程。

接下来的学习路线，给大家一个参考顺序：

1. 扎实掌握 Linux 基础命令，特别是文件管理、进程管理、网络排查、systemd 服务管理，这是运维的地基。
2. 熟练使用 Docker 常用命令，理解镜像和容器的关系，掌握数据卷和端口映射。
3. 用 Docker Compose 搭建一个完整应用栈，比如 MySQL + Redis + 后端应用。
4. 学习 K8S 核心对象，从 Pod、Deployment、Service 开始，逐步扩展到 ConfigMap、Secret、StatefulSet、Ingress。
5. 动手搭建一个多节点 K8S 集群，哪怕是用虚拟机模拟多节点，也能帮助你理解集群组件协作。
6. 研究监控告警、日志收集、权限控制、故障排查，这些是生产环境真正考验能力的地方。

最后给出两点实际建议。测试和预发环境是练手的好地方，不要一上来就在生产环境操作，尤其是删除、清空、卸载这类高危动作，先在小范围验证，确认无风险后再执行。运维是一份长期积累的工作，把命令、报错和排查过程沉淀成自己的笔记，效率会提升很多。希望这份 Docker 与 K8S 入门实战教程能帮你省去一些摸索的时间，少踩几个坑。