经常有刚接触云原生的同学问我是不是学会了 Docker 就相当于会了容器化是不是能在服务器上跑几个容器就算掌握 Linux 运维的核心了我的判断很明确Docker 只是容器化这条路上的第一步。它解决的是“单机环境一致性”和“应用打包分发”的问题而 Kubernetes简称 K8S解决的是“多机、多服务、大规模编排调度”的问题。两者不是二选一而是层层递进。如果你只停留在docker run的层面遇到服务挂了没人拉起、流量突增无法自动扩容、多台机器难以统一管理时就会明显感受到瓶颈。这篇文章面向的是零基础或刚入门的读者。我会先帮你把 Docker 和 K8S 的关系、核心概念梳理清楚然后从 Linux 环境安装 Docker 开始一步步带你完成镜像加速、MySQL 8.0 容器化部署、K8S 最小集群搭建、Pod 与 Service 实践、常见故障排查以及监控告警配置。读完这篇文章你至少能独立跑通一条“容器化部署 集群管理 故障排查”的完整链路后续再深入源码或原理时会轻松很多。1. 这篇文章真正要解决的问题很多运维教程容易犯一个毛病把 Docker 讲成一套独立的命令手册把 K8S 讲成一套独立的概念字典。结果读者学完命令会敲了概念也能背了但一回到真实工作场景仍然不知道从哪里下手。真正的问题在于你没有一个完整的容器化认知框架。你不知道一个应用从开发到上线的链路里Docker 负责哪一环K8S 负责哪一环Linux 运维又是在哪个层面兜底。这篇文章会用“一条链路”的方式把这些点串起来在单机环境用 Docker 把 MySQL 8.0 跑起来并处理好数据持久化、端口映射、容器日志这些日常操作。在多机环境用 K8S 把服务调度到集群里管理副本数、故障恢复和外部访问。在运行阶段遇到 Pod 异常、CPU Throttling、磁盘告警等问题时知道该从哪个命令开始排查。在工程层面知道权限如何收敛、资源如何限制、监控如何接入。什么样的读者最应该读一是刚转行做 Linux 运维的初级工程师二是后端开发想补容器化知识三是正在准备 K8S 面试但缺少实操支撑的人。如果你已经是能够独立维护生产级 K8S 集群的资深工程师这篇文章的深度可能不够但用来给团队成员做入门培训倒是很合适。2. Docker 与 K8S先分清两个层级的工具先打一个比方。Docker 像是集装箱。它把应用、依赖、配置、运行环境全部打包成一个标准化的“箱子”也就是镜像。无论这个箱子在开发者的笔记本上、测试服务器上还是生产环境里都能以几乎一致的方式运行。这解决了传统部署里最让人头疼的问题环境不一致。K8S 像是港口调度系统。单个集装箱再标准如果没有吊车、堆场、船舶计划统一调度一百个、一万个箱子就会乱成一团。K8S 就是管理容器集群的“调度中枢”它负责决定容器调度到哪台机器、需要维持多少个副本、某个副本挂了怎么拉起、外部流量怎么分发到容器。所以两者根本不是竞争关系。你完全可以用 Docker 跑几个小项目不需要 K8S但如果你需要在多台服务器上部署几十个服务并且要求高可用、自动扩缩容只用 Docker 手工管理会迅速失控。对比维度DockerKubernetes定位容器引擎负责镜像打包与单机容器运行容器编排平台负责多机集群调度与管理核心组件Dockerd、Containerd、Docker CLIkube-apiserver、kubelet、kube-proxy、etcd管理对象镜像、容器、网络、数据卷Pod、Deployment、Service、Node适合规模单机或少量容器大规模多机容器集群故障恢复容器本身不具备自动拉起能力ReplicaSet 会自动维持副本数服务发现需要手工处理端口映射Service 提供稳定的访问入口和负载均衡另一个常见误区是有人以为“学完 Docker 就等于会 K8S”。实际上K8S 的最小调度单元是 Pod而不是容器。Pod 里面可以有一个或多个容器这些容器共享网络命名空间和存储卷。这意味着你在 Docker 里面对的是一个个独立的容器在 K8S 里至少要多理解一层封装关系。从运维视角看Docker 阶段你要关注的是镜像体积、容器日志、数据卷、端口冲突切换到 K8S 阶段你的关注点变成了 Pod 调度、资源请求与限制、滚动更新、RBAC 权限、网络策略和监控告警。思维模式从“管理一台机器上的进程”升级为“声明式地描述整个集群的期望状态”。这一章的核心结论是Docker 是基础K8S 是进阶。基础不牢进阶无从谈起但如果只满足于 Docker职业生涯的天花板会很快到来。3. 环境准备安装 Docker 并解决镜像下载慢实操之前先明确一个建议入门阶段尽量使用 Linux 环境。无论是 CentOS、Ubuntu 还是 DebianDocker 在 Linux 上的行为最直接也最接近生产环境。如果你只有 Windows 电脑优先安装 WSL2 或准备一台虚拟机而不是一开始就依赖 Docker Desktop。3.1 在 Linux 上安装 Docker以 CentOS 7 系列为例安装 Docker 的标准路径是配置 Docker 官方仓库然后安装 docker-ce 相关组件# 安装基础工具 sudo yum install -y yum-utils # 添加 Docker 仓库 sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo # 安装 Docker 引擎 sudo yum install -y docker-ce docker-ce-cli containerd.io # 启动并设置开机自启 sudo systemctl start docker sudo systemctl enable docker # 验证安装 sudo docker versionUbuntu 的安装路径略有不同核心是先把 Docker 的 GPG key 和 apt 源配置好sudo apt-get update sudo apt-get install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \ -o /etc/apt/keyrings/docker.asc sudo chmod ar /etc/apt/keyrings/docker.asc echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.asc] \ https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable \ | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io sudo systemctl start docker sudo systemctl enable docker安装完成后用docker run hello-world验证是否正常。如果镜像拉取缓慢或失败问题大概率出在镜像源上。3.2 配置镜像加速国内拉取 Docker Hub 镜像经常遇到超时或速度极慢的问题。此时需要修改 Docker 的守护进程配置添加可靠的镜像加速地址。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json EOF { registry-mirrors: [ https://docker.m.daocloud.io ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker镜像加速地址在不同网络环境下可用性差异较大如果某个地址失效可以搜索当前可用的公共加速器替换。配置完成后再执行docker info在输出中检查Registry Mirrors字段是否已经生效。这一步看似简单却是很多新手卡住的第一道坎。3.3 关于 Docker Desktop 的虚拟化报错很多 Windows 用户安装 Docker Desktop 后启动时弹出类似virtualization support wasnt detected的报错。这通常意味着 Windows 的虚拟化能力没有被正确开启。排查顺序如下进入 BIOS/UEFI确认 Intel VT-x 或 AMD-V 已开启。在 Windows 功能中启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”。如果仍然失败尝试卸载 Docker Desktop改在 WSL2 内安装 Docker Engine。从入门效率来看我仍然建议优先把精力放在 Linux 环境上因为 Docker Desktop 的很多配置与生产环境并不一致容易让初学者产生误解。4. Linux 运维中最常用的 Docker 核心操作环境准备就绪后你会频繁使用一组 Docker 命令。把这些命令刻进肌肉记忆比死记概念更有价值。4.1 镜像与容器的基本命令# 拉取镜像 docker pull nginx:1.25 # 查看本地镜像 docker images # 运行一个后台容器宿主机 8080 端口映射到容器 80 端口 docker run -d --name my-nginx -p 8080:80 nginx:1.25 # 查看运行中的容器 docker ps # 查看所有容器包括已停止 docker ps -a # 进入容器内部执行交互式命令 docker exec -it my-nginx bash # 查看容器日志 docker logs -f my-nginx # 停止、启动、删除容器 docker stop my-nginx docker start my-nginx docker rm my-nginx这些命令之间的逻辑关系是镜像image是静态模板容器container是模板运行时的实例。docker pull把模板下载到本地docker run基于模板创建一个可运行的实例docker exec进入实例内部查看状态或调试。很多新手容易混淆docker exec和docker attach。简单来说docker exec是在运行中的容器里启动一个“新的进程”比如打开一个 shelldocker attach是附加到容器的主进程上。日常调试更推荐docker exec -it因为它不会干扰容器主进程的运行。4.2 CMD 与 ENTRYPOINT 的差异在 Dockerfile 中CMD和ENTRYPOINT是两个容易混淆的指令但它们在 K8S 的 Pod 配置中也会反复出现。核心区别是ENTRYPOINT定义容器启动时执行的“入口程序”。CMD定义默认参数如果docker run时带上了参数会覆盖CMD。当两者同时存在时CMD的内容会作为参数传给ENTRYPOINT。看一个最小示例# 文件路径Dockerfile FROM ubuntu:22.04 ENTRYPOINT [echo] CMD [hello]构建并运行docker build -t demo-entry . # 不传参数输出 hello docker run demo-entry # 传入 world输出 world注意此时 CMD 被覆盖 docker run demo-entry world理解了这一点你在 K8S 中配置 Pod 的command和args时就会清晰很多。容器的启动行为不是随便写的而是由镜像的入口配置和启动参数共同决定的。4.3 数据卷与端口映射容器是无状态的。当容器被删除容器内创建的数据也会消失。因此在部署 MySQL、Redis 这类需要持久化数据的应用时必须使用数据卷。# 创建命名数据卷 docker volume create mysql-data # 启动 MySQL 时挂载数据卷并映射端口 docker run -d \ --name mysql8 \ -e MYSQL_ROOT_PASSWORDRoot123456 \ -p 3306:3306 \ -v mysql-data:/var/lib/mysql \ mysql:8.0这里-v mysql-data:/var/lib/mysql表示把宿主机上名为mysql-data的卷挂载到容器内的数据目录。容器删除后数据仍然保留在数据卷中重新创建容器时再次挂载同一个卷即可恢复数据。端口映射方面-p 3306:3306的含义是把宿主机 3306 端口流量转发到容器内 3306 端口。如果你部署多个 MySQL 实例就需要映射不同宿主机端口例如-p 3307:3306。5. 实战Docker 安装 MySQL 8.0 并使用接下来用一个完整示例把镜像拉取、容器运行、数据持久化、客户端连接串起来。这是运维工作中最常见的任务之一。第一步拉取 MySQL 8.0 镜像docker pull mysql:8.0第二步准备本地目录并启动容器。这里建议直接用目录挂载而不是命名卷因为目录更容易备份和管理mkdir -p /data/mysql8/conf mkdir -p /data/mysql8/data docker run -d \ --name mysql8 \ --restartalways \ -e MYSQL_ROOT_PASSWORDRoot123456 \ -e TZAsia/Shanghai \ -p 3306:3306 \ -v /data/mysql8/data:/var/lib/mysql \ mysql:8.0解释一下关键参数--restartalways容器异常退出后自动重启适合生产环境的基础组件。MYSQL_ROOT_PASSWORD初始化 root 用户的密码。TZAsia/Shanghai设置容器时区避免数据库时间与业务服务器不一致。-v /data/mysql8/data:/var/lib/mysql把 MySQL 数据文件持久化到宿主机目录。第三步验证容器状态和连接# 查看容器状态 docker ps | grep mysql8 # 查看容器日志 docker logs -f mysql8日志中出现ready for connections表示初始化完成。接下来可以在宿主机上通过 mysql 客户端或任意数据库工具连接测试mysql -h 127.0.0.1 -P 3306 -uroot -p输入密码后如果进入 MySQL 交互界面说明部署成功。第四步验证数据持久化。可以创建一个测试库然后删除容器再重新创建确认数据没有丢失CREATE DATABASE test_db;然后执行docker rm -f mysql8 docker run -d \ --name mysql8 \ --restartalways \ -e MYSQL_ROOT_PASSWORDRoot123456 \ -e TZAsia/Shanghai \ -p 3306:3306 \ -v /data/mysql8/data:/var/lib/mysql \ mysql:8.0重新连接后test_db仍然存在说明持久化配置生效。这里有一个生产环境容易踩的坑如果使用-v /data/mysql8/data:/var/lib/mysql挂载目录而该目录曾经被其他初始化过程写入过不完整的文件MySQL 可能拒绝启动。遇到这种情况先看docker logs再检查数据目录的属主和权限必要时用干净的目录重新初始化。6. K8S 安装部署搭建一个最小集群K8S 的安装是初学者绕不过去的一道坎。这里给出一个最小化集群的搭建思路重点不是追求生产级高可用而是让你理解控制面节点与工作节点的职责划分。生产级 K8S 通常至少需要三台机器一台 master 节点、两台 worker 节点。入门阶段可以先用一台机器模拟单节点集群这也足够演示核心概念。以 CentOS 为例所有节点都需要执行以下基础准备工作# 关闭 swapK8S 1.8 之后要求必须关闭 swapoff -a # 注释 /etc/fstab 中的 swap 行防止重启后失效 # 加载内核模块 modprobe br_netfilter # 配置内核参数 cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system然后安装 kubelet、kubeadm、kubectlcat EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] nameKubernetes baseurlhttps://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled1 gpgcheck0 EOF sudo yum install -y kubelet kubeadm kubectl sudo systemctl enable --now kubelet在控制面节点执行初始化命令sudo kubeadm init \ --apiserver-advertise-address$(hostname -I | awk {print $1}) \ --pod-network-cidr10.244.0.0/16初始化成功后按提示执行kubectl配置mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config单节点集群还需要去掉 master 节点的污点否则 Pod 无法调度上来kubectl taint nodes --all node-role.kubernetes.io/control-plane-最后安装一个网络插件这里以 Flannel 为例kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml等待片刻后执行kubectl get nodes如果看到节点状态为Ready说明最小集群搭建成功。kubectl get nodes需要说明的是具体版本号会随官方发布而变化安装时以 kubeadm 输出的版本为准。K8S 的安装过程比较考验网络环境镜像拉取失败时优先检查源地址是否可用以及容器运行时是否配置正确。7. 理解 K8S 核心对象Pod、Deployment、Service集群搭建完成后你会开始和 K8S 的一系列对象打交道。最重要的三个概念是 Pod、Deployment 和 Service。7.1 用 YAML 部署一个 Nginx 副本组先看一个最常用的 YAML 文件# 文件路径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:1.25 ports: - containerPort: 80Deployment 的作用是声明“我希望集群里始终有 3 个 Nginx Pod”。如果某个 Pod 挂了Deployment 会通过 ReplicaSet 自动创建一个新 Pod保证副本数不减少。这种声明式管理方式是 K8S 与传统运维的核心差异之一。执行部署kubectl apply -f nginx-deployment.yaml # 查看 Pod 状态 kubectl get pods -o wide如果 Pod 一直处于Pending或ContainerCreating状态通常需要检查资源是否充足、镜像是否能拉取、网络插件是否正常。7.2 用 Service 暴露访问入口Pod 的 IP 会随着重建而变化所以不能直接让客户端访问某个 Pod 的 IP。Service 提供了一个稳定的虚拟 IP 和访问入口可以把流量负载均衡到一组 Pod 上。# 文件路径nginx-service.yaml apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - port: 80 targetPort: 80 type: NodePort执行kubectl apply -f nginx-service.yaml kubectl get svc如果看到nginx-service的PORT(S)显示为80:30080/TCP说明可以通过任意节点的30080端口访问到 Nginx。访问http://节点IP:30080验证。这里的关键点是Service 通过selector选择带有app: nginx标签的 Pod然后自动维护 Endpoints。即使 Pod 被删除重建Service 的访问入口不会变化。7.3 只读权限用户如何配置在团队协作中不可能给每个人都发放管理员的 kubeconfig。更合理的做法是创建只读用户只允许查看资源不能修改或删除。下面是一个最小 RBAC 配置# 文件路径readonly-rbac.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: readonly-clusterrole rules: - apiGroups: [] resources: [pods, services, nodes, namespaces, events] verbs: [get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: readonly-binding subjects: - kind: User name: readonly-user apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: readonly-clusterrole apiGroup: rbac.authorization.k8s.io配置用户凭证时建议使用临时证书或独立的 kubeconfig 文件避免把管理员证书直接分发出去。生产环境中权限收敛的原则是“最小权限、按需申请”这一点在 K8S 里比传统 Linux 服务器上的账号权限管理更值得重视。8. K8S 故障排查CPU Throttling、Pod 异常与日志分析K8S 的故障排查是运维工程师的核心能力。这里不展开所有场景只挑两类最常见、也最容易让新手慌张的问题。8.1 CPU Throttling 到底是怎么回事先明确一个概念K8S 中的 CPU 请求request用于调度CPU 限制limit用于运行时限制。当你给容器设置了 CPU limit 后内核会通过 CFS 配额机制限制容器最多能使用多少 CPU 时间。当容器持续高负载运行超过 CFS 配额时内核会强制限流表现为容器内进程大量陷入throttled状态。最典型的现象是应用业务指标显示负载很高但 CPU 使用率看起来又不算特别高或者响应延迟明显上升。排查方式如下# 进入容器查看 cgroup 的 CPU 统计 docker exec -it container-id cat /sys/fs/cgroup/cpu/cpu.stat输出中的nr_throttled表示被限流的次数。如果这个数字持续增长说明容器确实被限流了。对应的解决思路是增加 Deployment 中的 CPU limit给容器留出更多余量。如果业务本身有突发流量可以适当提高 request 值保证调度时预留足够的物理资源。如果整个节点 CPU 资源紧张需要考虑扩容节点或优化应用性能。K8S 本身推荐的是给 Pod 设置合理的 request 和 limit而不是把 limit 设置得无限大。限流本身是保护机制问题往往出在“限额配置与实际负载不匹配”上。8.2 Pod 异常的常见排查路径Pod 状态异常时不要盲目删除重建而是按顺序排查# 查看 Pod 总体状态 kubectl get pods # 查看事件定位调度失败原因 kubectl describe pod pod-name # 查看容器日志 kubectl logs pod-name # 如果容器里有多个容器指定容器名 kubectl logs pod-name -c container-name # 进入容器排查内部环境 kubectl exec -it pod-name -- bash常见的几种状态和原因状态可能原因排查方向Pending资源不足、节点亲和性、污点限制kubectl describe pod查看调度事件ContainerCreating镜像拉取失败、卷挂载失败查看节点kubelet日志、检查镜像源CrashLoopBackOff应用启动失败、配置错误kubectl logs查看应用日志ImagePullBackOff镜像不存在或无法拉取检查镜像名称、仓库权限、网络遇到 Pod 问题第一反应应该是看事件和日志而不是直接kubectl delete pod。因为删除 Pod 之后事件可能就看不到了排错成本反而更高。9. 监控告警Node Exporter Prometheus Grafana 与磁盘告警规则集群跑起来之后下一步就是监控。传统的 Linux 运维习惯是看top、df、free但在 K8S 场景下单台机器的视角不够需要一套能覆盖集群所有节点的监控体系。目前最经典的组合是Node Exporter 采集节点指标Prometheus 存储指标并计算告警规则Grafana 负责可视化展示。Node Exporter 可以用 DaemonSet 方式部署确保每个节点都运行一个监控采集 Pod。Prometheus 通过服务发现自动获取各节点的监控端点这里不展开完整部署重点看磁盘告警规则如何配置。# 文件路径disk-alert-rule.yaml groups: - name: disk-alerts rules: - alert: DiskUsageHigh expr: | (1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100 85 for: 5m labels: severity: warning annotations: summary: 节点 {{ $labels.instance }} 磁盘使用率超过 85% description: 当前使用率已达到 {{ $value | humanizePercentage }}说明一下这个告警规则的逻辑node_filesystem_avail_bytes是可用字节数node_filesystem_size_bytes是总字节数两者相减再取百分比就得到磁盘使用率。for: 5m表示持续 5 分钟才触发告警避免短时波动造成误报。在 Prometheus 中加载规则后可以在 Prometheus 的 Alerts 页面看到告警状态。接入 Alertmanager 后还可以把告警推送到企业微信、钉钉、邮件等渠道。监控体系搭建的收益是长远的当集群规模变大后人工巡检不再可行指标告警才是保障服务稳定性的第一步。10. 最佳实践与工程建议把容器化和集群管理落地到真实项目时有几个工程经验值得提前掌握。第一镜像命名和标签管理要规范。镜像不能只打latest生产环境应该使用带版本号的标签比如myapp:1.4.2。这样可以精确定位每个部署版本回滚时也有明确目标。第二数据持久化要提前设计。MySQL、Redis 这类应用必须使用 PersistentVolume 和 PersistentVolumeClaim而不是把数据放在容器层。容器重建是常态数据丢失是不可接受的。第三资源请求与限制要给每个容器都配置。没有 request 会导致调度器无法准确评估节点资源没有 limit 会导致单个容器把节点资源耗尽。配置时可以参考历史监控数据给 request 留出 20% 左右的余量limit 设为峰值的 1.2 到 1.5 倍。第四权限遵循最小化原则。能只读就不给写权限能使用命名空间就不给集群级权限。生产集群的 kubeconfig 要定期轮换不要长期使用永久证书。第五变更之前先备份变更之后先看日志。无论是修改 Deployment 镜像版本还是调整 K8S 集群配置第一步都应该是备份当前对象定义kubectl get deployment xxx -o yaml backup.yaml。出问题的时候这条备份能救命。第六熟练使用kubectl describe和kubectl logs。如果只能记住两条排查命令就是这两条。它们能覆盖大多数日常故障场景。11. 总结与后续学习方向现在回头看一下你已经跑通了整条链路从安装 Docker、配置镜像加速到用容器部署 MySQL 8.0从搭建 K8S 最小集群到理解 Pod、Deployment、Service 的关系从处理 CPU Throttling 和 Pod 异常到配置 Prometheus 磁盘告警。这条链路覆盖了 Linux 运维在容器化时代最核心的工作场景。下一步的实践建议是先不要急着搭建复杂集群而是用自己的电脑准备一台 Linux 虚拟机把 Docker 常用命令练熟用 Docker Compose 部署一套包含 MySQL、Redis、Nginx 的小型应用。然后再把 K8S 的最小集群重新搭一遍尝试把已有多容器应用迁移到 Deployment 和 Service 管理。这个过程跑通之后再去研究 K8S 的调度原理、网络模型、存储机制理解起来会快很多。如果你正在准备运维相关岗位面试建议重点准备这几个方向Docker 镜像分层原理、容器与虚拟机区别、Pod 的生命周期、Deployment 滚动更新策略、Service 的负载均衡方式、RBAC 权限模型、资源请求与限制对调度的影响。这些内容都能在实操中找到对应场景而不是死记硬背。容器化技术迭代很快但核心思路一直没有变让应用的交付和运行更加标准化、自动化。把 Docker 和 K8S 的基本功打牢你会发现后续学习云原生、Serverless、服务网格都有迹可循。建议先把这篇文章保存起来跟着章节逐步操作一遍再回到你自己负责的业务环境里寻找可以容器化的场景。