1. 实验背景与整体思路拆解1.1 为什么配置管理和镜像构建是K8s绕不开的两座山先说个我自己带新手时经常遇到的问题很多人学Kubernetes一开始就把精力全扑在Pod、Deployment、Service这些大件上觉得会写个YAML把应用跑起来就算入门了。结果一碰到稍微复杂点的场景就卡壳——比如你要把同一个镜像跑在不同环境里数据库地址、缓存地址、日志级别全不一样怎么办比如你改了配置难道要把镜像重新build一遍再比如你从Docker Hub拉一个镜像改了两行配置就得重新打包这镜像越攒越多磁盘直接报警。这就是为什么在K8s的学习路径里配置管理和镜像构建必须放在靠前的位置。配置管理解决的是应用和环境解耦的问题镜像构建解决的是应用如何打包分发的问题。这两个问题不搞清楚后面做多环境部署、做CI/CD流水线、做微服务拆分全都会踩坑。这次实验手册对应的是两个实验实验5是镜像构建实验6是K8s配置管理。从标题顺序上看先构建镜像再管理配置这个安排其实很有讲究——你得先有一个能跑的镜像才谈得上给这个镜像里的应用注入配置。但实际做下来你会发现这两块内容的知识点高度交织ConfigMap里挂载的配置文件最终要能被镜像里的应用正确读取而镜像构建时写的Dockerfile又决定了应用在容器里怎么找配置。所以我把这两部分放在一起讲思路会更连贯。1.2 D3作业的定位从能跑到会配D3这个阶段的学习目标我理解下来就一句话让一个容器化应用不仅在本地能跑在K8s集群里也能稳定跑、灵活配。前两个实验大概率是搭集群、部署应用属于能跑的层面。到了实验5和实验6就进入会配的层面了。这里要特别强调一点很多人会混淆K8s和Docker的职责边界。简单说Docker负责打包K8s负责编排。镜像构建是Docker的核心能力配置管理则是K8s的编排能力之一。但两者不是割裂的——你构建镜像时选的base镜像、写的环境变量、暴露的端口都直接决定了后续在K8s里怎么做配置注入。所以这组实验本质上是打通构建-分发-运行-配置这条完整链路。另外现在K8s的安装方式也很多二进制搭建、kubeadm、minikube、还有基于Rocky Linux这类系统的脚本化安装。我见过不少人在Rocky 10.2上折腾集群搭建环境版本不一样配置管理的行为细节也会有差异。这次实验手册我在写的时候尽量让步骤对发行版不那么敏感但你在实操时如果遇到行为不一致优先检查Kubernetes版本和容器运行时containerd还是docker的差异。2. 镜像构建实验关键细节与实操要点2.1 Dockerfile的核心语法从零开始写一个可用的镜像实验5的第一步通常是编写Dockerfile。很多人上来就拷贝网上的模板这是大忌。Dockerfile虽然看起来就是几行指令但每一条指令的语义、执行时机、对镜像体积的影响都是需要理解的。最基本的Dockerfile包含这么几个核心指令FROM指定基础镜像。这是整个镜像的地基原则是能用官方镜像就别用第三方精简版能指定版本就别用latest。比如FROM nginx:1.25-alpine就比FROM nginx:latest可靠得多。WORKDIR设置工作目录。这不仅是规范更重要的是避免后续指令里的路径混乱。我见过太多人把文件拷到容器里的根目录然后CMD里写相对路径找半天找不到文件。COPY或ADD把本地文件拷贝进镜像。能用COPY就别用ADDADD虽然支持自动解压和远程URL但这两点恰恰是构建时容易出幺蛾子的地方——解压行为不符合预期、远程拉取失败导致构建中断。RUN在构建阶段执行命令。每一条RUN都会产生一个新的镜像层所以能用把多条命令串在一起执行就尽量不要写多条RUN这样可以显著减少层级和体积。ENV设置环境变量。这个对后续配置管理非常关键因为很多应用会读取环境变量来覆盖配置文件里的默认值。EXPOSE声明容器监听端口。注意它只是声明不真正发布端口。真正让端口对外可访问还得靠-p参数或者在K8s的Service里指定。CMD或ENTRYPOINT指定容器启动时执行的命令。两者区别要搞清楚CMD可以被子命令覆盖ENTRYPOINT是主入口。最佳实践是ENTRYPOINT固定启动脚本CMD提供默认参数。举个例子一个简单的Nginx静态站点镜像可以这么写FROM nginx:1.25-alpine LABEL maintaineryournameexample.com WORKDIR /usr/share/nginx/html COPY ./dist/ . EXPOSE 80 CMD [nginx, -g, daemon off;]这个例子我在教学里反复用因为每一行都有明确的学习目标镜像选型、标签规范、工作目录、内容拷贝、端口声明、启动方式。每一步都值得展开讲清楚为什么这样做。2.2 构建镜像的实操过程与参数选择Dockerfile写好了接下来就是执行构建命令。基础命令是docker build -t myapp:v1.0 .这里有几个参数我要单独拎出来讲因为它们在真实项目中影响巨大。-t是打标签格式是仓库名:标签。标签规划是个容易忽略的细节我建议从一开始就养成习惯——不要用latest打生产镜像而是用语义化版本号或者时间戳。latest只适合本地开发调试一旦推到私有仓库后面根本分不清哪个镜像对应哪个代码版本。-f参数指定Dockerfile的路径和文件名。默认情况下docker会在构建上下文中找名为Dockerfile的文件但如果你的项目里有开发版、生产版多个Dockerfile就要用-f显式指定。.是构建上下文。这里有个高频坑点构建上下文是整个目录会被打包发送给Docker守护进程如果你在目录里放了乱七八糟的大文件、node_modules、构建产物这步会奇慢无比。正确做法是配合.dockerignore文件把不需要的文件排除掉。我见过一个真实案例同事把好几个GB的数据文件放在项目目录里每次构建都要等十分钟加了.dockerignore之后直接变成二十秒。还有一个比较进阶的参数是--build-arg它允许你在构建时动态传入参数。比如你有一个多环境的镜像可以通过这个参数传入不同的配置文件路径或者版本号。但要注意ARG和ENV是有区别的——ARG只在构建阶段有效ENV会留存到容器运行时。如果你要在容器里读到这个值必须写ENV或者在启动命令里明确传递。构建完成后用docker images查看本地镜像列表再用docker run做一次本地验证。这一步很多人跳过了直接推到K8s里跑结果镜像起不来才回头查问题浪费大量时间。本地验证的姿势是docker run -d -p 8080:80 --name test-app myapp:v1.0 curl localhost:8080-d是后台运行-p是把容器端口映射到宿主机--name起个便于识别的名字。curl通了你再去推镜像几乎不会有大问题。2.3 推送镜像到私有仓库的账号配置细节本地验证没问题下一步就是把镜像推到仓库里。这里有两种路径一种是推到公共的Docker Hub另一种是推到私有仓库比如Harbor、Nexus或者云厂商的镜像仓库服务。推送到Docker Hub的命令是docker login docker tag myapp:v1.0 yourusername/myapp:v1.0 docker push yourusername/myapp:v1.0推送到私有仓库稍复杂一点核心问题是HTTPS证书和信任配置。如果你是自建的Harbor用的还是自签证书那么K8s节点上的容器运行时尤其是containerd在拉取镜像时可能会报证书错误。解决办法是把CA证书拷贝到每个节点的指定目录然后重启containerd具体路径随系统版本不同而异。还有一个很多初学者完全没概念的点K8s集群里的节点跟你在本地执行docker push的机器是两回事。你在本地能拉私有仓库镜像不代表K8s节点也能拉。K8s拉取私有仓库镜像需要先创建Secretkubectl create secret docker-registry regcred \ --docker-serveryour-registry.example.com \ --docker-usernameyourname \ --docker-passwordyourpassword \ --docker-emailyouremailexample.com然后在Deployment的YAML里通过imagePullSecrets字段引用这个Secret。这个知识点在实验5里不一定是必须的但等到实验6你在集群里创建Pod时大概率会碰到因为你要验证的镜像很可能就在私有仓库里。提前准备好后面少走弯路。3. K8s配置管理核心机制解析3.1 ConfigMap把配置从应用里剥离出来实验6的重头戏是配置管理。K8s里有两种原生的配置资源ConfigMap和Secret。两者的底层机制非常相似区别只在数据是否敏感——ConfigMap存明文配置Secret存敏感数据。但就是这个相似让很多人学完后面就忘前面所以我打算把它们合在一起讲透。ConfigMap的核心思想是把配置和数据从应用镜像中剥离出来在应用运行时再注入进去。这意味着你可以用同一个镜像通过不同的ConfigMap在开发、测试、生产环境里跑出完全不同的行为。这正是十二要素应用里配置与代码分离这一条在K8s里的落地方式。创建ConfigMap有几种方式我推荐从小例子入手kubectl create configmap app-config \ --from-literalAPP_ENVproduction \ --from-literalLOG_LEVELinfo--from-literal适合创建简单的键值对。如果你有一整个配置文件可以用--from-file直接把文件内容放进去kubectl create configmap nginx-config \ --from-filenginx.conf./nginx.conf这里有个细节--from-file后面如果只写文件名那么ConfigMap里的键就是文件名本身如果你写成文件名路径的格式就可以自定义键名。这个在挂载到容器里时会影响路径结构务必要想清楚。还有一个容易被忽略的方式是--from-env-file它可以把一个环境变量文件格式类似.env批量导入ConfigMap。在自动化脚本里这个方式特别高效。3.2 Secret敏感数据怎么存才安全Secret的创建方式跟ConfigMap几乎一样只是命令名换了kubectl create secret generic db-secret \ --from-literalDB_PASSWORDS3curePss创建完成后你可以用kubectl get secret db-secret -o yaml查看它的定义。这里要注意Secret的值在K8s API里是Base64编码存储的不是明文。但Base64只是编码不是加密任何人只要有权限查看Secret的定义随手就能解码出来。这是一个非常重要的认知K8s自带的能力只能做到模糊化真正的加密需要依赖外部方案比如对接KMS服务或者使用 sealed-secrets 这类工具。在实际项目中Secret的管理建议遵循这么几条原则不要把Secret的定义文件提交到Git仓库里除非你用了SOPS或者类似工具做加密。用单独的命名空间隔离敏感配置配合RBAC控制访问权限。定期轮换Secret的值轮换后需要滚动重启相关的Pod才会生效。优先使用stringData字段来声明字符串值它比data字段更人性化不需要你手动做Base64编码。3.3 配置注入的两种核心方式与选择依据ConfigMap和Secret创建好了怎么让Pod用上它们这又是一个高频考点。K8s里提供了两种注入方式环境变量注入和Volume挂载。环境变量注入一般用于传递简单的键值对尤其是应用原生支持读取环境变量的场景。在Pod定义里通过env字段配合configMapKeyRef或secretKeyRef来引用apiVersion: v1 kind: Pod metadata: name: web-pod spec: containers: - name: web image: myapp:v1.0 env: - name: APP_ENV valueFrom: configMapKeyRef: name: app-config key: APP_ENV - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: DB_PASSWORDVolume挂载适合注入完整配置文件或者配置内容较多、格式复杂的场景。你可以把ConfigMap整体挂载为容器里的一个目录或文件spec: containers: - name: web image: myapp:v1.0 volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: app-config这两种方式的选择逻辑我总结成一句话能用环境变量就用环境变量配置文件复杂才用挂载。原因有三点第一环境变量对应用代码侵入最小很多框架原生支持第二环境变量的更新可以通过Deployment滚动重启快速生效第三Volume挂载虽然支持热更新但应用不一定会监听配置文件变化反而可能造成配置不一致的幻觉。3.4 挂载细节中的坑子路径、只读和热更新Volume挂载看起来简单实际用起来全是细节。我先后踩过这么几个坑写出来帮大家避雷。第一个坑挂载会覆盖目录下的原有文件。这是新手最容易懵的地方。比如你把ConfigMap挂载到/etc/nginx/conf.d结果发现目录下原有的default.conf不见了。这是因为K8s的configMap卷默认会把这个挂载点变成ConfigMap内容的专属目录覆盖掉镜像里原有的文件。解决办法是使用subPath来指定挂载ConfigMap里的某一个键为单个文件或者把配置文件的路径设计得更干净一些。第二个坑subPath方式不支持热更新。如果你用了subPath来挂载单个文件那么ConfigMap的内容更新后容器里的文件不会自动更新。这在开发调试时特别容易让人困惑明明改完ConfigMap了Pod里读到的还是旧内容。如果你需要热更新就要放弃subPath用整个卷挂载的方式。第三个坑挂载目录权限问题。某些镜像里运行应用的用户不是root而是特定用户比如nginx用户、www-data用户ConfigMap卷默认的权限是0444所有人可读这在大多数情况下够用。但如果你的应用需要在运行期间修改配置文件就会因为没有写权限而出错。这时候需要设置defaultMode字段来调整文件权限比如defaultMode: 0666。K8s里这个字段是用八进制表示的写YAML时容易忽略前导零要格外注意。第四个坑更新ConfigMap不会自动重启Pod。这是K8s设计上最需要理解的点。ConfigMap更新了已经运行的Pod不会自动感知更不会自动重启。只有通过Deployment管理的Pod在配置变更后触发一次滚动重启新Pod才会拿到新配置。最常见的运维技巧是执行kubectl rollout restart deployment/xxx让它重新拉取配置。4. 镜像构建与配置管理的联调实验4.1 一次完整的端到端实验流程设计实验5和实验6虽然是两个独立实验但在真实项目中它们是联合使用的。一个完整的端到端流程应该是先构建一个读配置的自定义镜像再创建ConfigMap注入配置最后通过Deployment部署这个镜像并验证配置是否生效。我这里给出一套可以直接照做的完整实验流程你跟着走一遍比单独做实验5和实验6理解要深刻得多。第一步准备一个会读配置的小应用镜像。为了让实验效果直观我建议用Nginx加一个自定义的首页来演示。先创建一个简单的index.html!DOCTYPE html html headtitleConfig Demo/title/head body h1Environment: PLACEHOLDER/h1 pThis page is served from a container with injected config./p /body /html注意这里的PLACEHOLDER我们后续会用它来验证配置注入是否生效。其实更优雅的做法是用环境变量配合启动脚本动态生成首页这里先以最直观的方式来演示。第二步写Dockerfile构建并推送镜像。FROM nginx:1.25-alpine WORKDIR /usr/share/nginx/html COPY index.html . EXPOSE 80 CMD [nginx, -g, daemon off;]执行构建命令然后推送镜像docker build -t your-registry.example.com/demo-web:v1.0 . docker push your-registry.example.com/demo-web:v1.0第三步创建ConfigMap来存放环境标识。kubectl create configmap web-config \ --from-literalENV_NAMESTAGING第四步创建Deployment把ConfigMap的环境变量注入容器并用启动命令动态替换首页占位符。apiVersion: apps/v1 kind: Deployment metadata: name: demo-web spec: replicas: 1 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: demo-web image: your-registry.example.com/demo-web:v1.0 ports: - containerPort: 80 env: - name: ENV_NAME valueFrom: configMapKeyRef: name: web-config key: ENV_NAME command: [/bin/sh, -c] args: - | sed -i s/PLACEHOLDER/$$ENV_NAME/g /usr/share/nginx/html/index.html exec nginx -g daemon off;这里的关键点在于启动命令里用sed替换占位符然后再启动Nginx。通过这种方式配置的价值就体现出来了——镜像本身是完全通用的环境信息完全由ConfigMap决定。注意在K8s的command/args里环境变量的引用要写$$ENV_NAME而不是$ENV_NAME因为K8s在解析时会先处理一层$符号双美元符号才能正确传给容器内的shell。第五步创建Service暴露服务然后验证。kubectl expose deployment demo-web --typeNodePort --port80 --target-port80 kubectl get svc demo-web拿到端口后在浏览器里访问http://任意节点IP:端口如果页面显示的是STAGING说明镜像构建、配置创建、注入和启动这一整条链路全部打通了。4.2 命令行三板斧查询、验证、排错整个联调过程中你会反复用到同一组命令我习惯叫它们K8s命令行三板斧kubectl get pods kubectl describe pod pod名 kubectl logs -f pod名get pods用来快速查看Pod状态重点看STATUS列是不是Running。如果状态是CrashLoopBackOff、ImagePullBackOff、Pending别慌按顺序查。describe pod是排错最强大的命令没有之一。它会把Pod整个生命周期的关键事件全部列出来包括镜像拉取状态、容器创建状态、健康检查结果、挂在节点上的资源开销等。排错时优先看底部的Events区域那里通常直接告诉你失败原因。logs用来查看应用日志。注意容器启动到一半就崩掉的场景可以用kubectl logs pod名 --previous看上一次退出容器的日志这个参数在CrashLoopBackOff调错时极其好用。还有一类场景需要进入容器内部验证比如检查挂载的配置文件是否正确kubectl exec -it pod名 -- /bin/sh cat /etc/config/nginx.conf注意镜像里可能没有bash所以用sh更稳妥。4.3 多环境配置的扩展思路实验6的标准流程跑通后我强烈建议你做一步扩展练习模拟多环境配置切换。这是配置管理最典型的工程应用场景。你可以创建三个ConfigMap分别对应dev、staging、productionkubectl create configmap web-config-dev --from-literalENV_NAMEDEV kubectl create configmap web-config-staging --from-literalENV_NAMESTAGING kubectl create configmap web-config-prod --from-literalENV_NAMEPROD然后通过修改Deployment里ConfigMap的名字比如从web-config-staging改成web-config-prod再执行滚动重启观察应用的环境标识是否变化。这个练习做下来你会真正理解同一个镜像多环境复用这个核心价值。以后再遇到环境问题就不需要重新build镜像只需要在集群里调整配置和运维动作效率完全不是一个量级。5. 镜像构建与配置管理高频问题排查实录5.1 镜像构建阶段的典型故障与解决办法镜像构建这个阶段我见过的报错至少有两类高频问题我先把排查思路理清楚。第一类构建上下文太大构建速度慢。这种情况基本是.dockerignore缺失或者不完整。排查方法是先看项目目录有多大用du -sh确认再看Docker build时从发送构建上下文到第一条指令执行之间的耗时。如果这个时间异常长优先补全.dockerignore文件把.git、node_modules、target、dist、日志目录、临时文件都排除掉。第二类基础镜像拉取失败或超时。这个问题的根因往往是网络。你从Docker Hub拉镜像不稳定或者企业内网对公网拉取有限制。解决办法是配置镜像加速器或者把基础镜像预先拉到本地。在企业环境里更稳妥的做法是搭一个镜像仓库作为代理缓存把外部镜像同步到内网构建时统一走内网地址。这个方案虽然前期配置成本高但一旦跑通构建速度和稳定性都会有质的提升。第三类RUN命令执行失败。很多Dockerfile在RUN apt-get install这种环节失败多半是包管理器的源问题。Ubuntu的sources.list里如果写的是官方源在某些网络环境下就会慢或者超时。处理办法一招就能解决问题在RUN之前先用sed替换成可用的镜像源然后再安装依赖包。这里还要注意构建缓存的坑——如果前面的指令没变但你的系统源变了要加上--no-cache参数强制重新构建。5.2 配置不生效的排查路线配置注入不生效是实验6里碰到最多的问题。这里的排查思路我建议按以下顺序逐层定位效率最高。第一步确认ConfigMap/Secret本身内容是否正确。kubectl get configmap web-config -o yaml重点检查data字段下的键值对是否跟预期一致。很多时候是创建时拼写错误或者--from-file读取了错误路径的文件。第二步确认Pod定义里的引用是否正确。检查env里的configMapKeyRef的name和key以及volumeMounts里的mountPath和subPath。这里最容易出错的是name写错或者key的大小写对不上K8s对键名是大小写敏感的。第三步进入容器内部验证实际生效状态。kubectl exec -it pod名 -- /bin/sh env | grep ENV_NAME cat /etc/config/nginx.conf这一步能直接看到容器里的环境变量和配置文件内容。如果容器里能看到值但应用读不到那问题就在应用本身对配置文件的读取逻辑上比如路径写错、文件名不对、进程没有重启。第四步检查是否有中间层覆盖了配置。如果应用还支持从命令行参数或者远端配置中心读取配置优先级比环境变量和本地文件更高那么即使K8s里的注入没问题应用也可能被另一层配置覆盖。这种问题在加了Java的Spring Cloud、Go的Viper这类配置框架后会特别隐蔽排查时要有这个意识。5.3 镜像拉取与认证类问题排查跟镜像拉取相关的报错我列几个高频场景供你对照。场景一ImagePullBackOff错误提示pull access denied。这基本可以判断为仓库认证失败。要么是imagePullSecrets没有配置要么是Secret里的凭证过期或者权限不足。先用kubectl get secrets确认Secret存在再用kubectl describe pod确认Pod正确引用了这个Secret最后在节点上手动docker login验证凭证是否有效。场景二私有仓库HTTPS证书问题提示x509: certificate signed by unknown authority。说明K8s节点不信任你自建仓库的CA证书。解决办法是把CA证书放到节点上的/etc/docker/certs.d/仓库地址/目录下docker运行时或者配置/etc/containerd/certs.d/containerd运行时然后重启容器运行时。有些精简系统里还需要额外配置信任锚点细节查官方文档。场景三镜像标签过期。有些团队习惯用latest标签覆盖推送结果K8s节点因为缓存了旧的latest不会重新拉取。碰到这种情况最直接的解决办法是把镜像标签改成唯一的版本号比如v1.0.3并在Deployment里更新镜像地址后重启Pod。你还会遇到K8s默认的imagePullPolicy问题如果镜像标签是latest或者未指定策略默认是Always这反而会经常触发不必要的拉取指定了具体版本时策略默认变成IfNotPresent可以避免频繁请求仓库。5.4 常见问题速查表为了方便你后面快速查找我把这次实验里出现频率最高的问题整理成一张表问题现象可能原因排查命令/操作解决方法构建很慢构建上下文太大du -sh .观察构建日志耗时完善.dockerignoreRUN指令安装失败包源不可达查看RUN报错日志替换源增加--no-cache重试Pod状态ImagePullBackOff仓库认证失败或镜像不存在kubectl describe pod看Events创建/更新Secret确认镜像路径Pod状态CrashLoopBackOff应用启动即退出kubectl logs --previous看退出日志修复应用启动命令或配置环境变量不生效configMapKeyRef引用错误kubectl exec进容器跑env核对name/key拼写配置文件找不到mountPath或文件名不正确kubectl exec进容器看挂载目录检查volumeMounts和volumes定义ConfigMap更新后Pod没反应Pod不会自动重启kubectl get pod看启动时间kubectl rollout restart deployment/xxx挂载目录原有文件消失卷挂载覆盖了目录ls查看挂载点改用subPath挂载单个文件Secret更新不生效Secret被挂载为subPath查看mounts声明改用卷挂载或重启Pod这张表建议你保存到自己的实验笔记里实战中碰到问题先对着表排查一轮能省掉大量盲目试错的时间。6. 实验总结与进阶练习建议6.1 两个实验的核心收获做完整组实验你应该明确拿到这么几个核心收获。第一Dockerfile的核心指令含义和择优使用原则能够根据应用类型独立写出可用的Dockerfile第二掌握镜像构建、打标签、推送、本地验证的完整闭环第三理解ConfigMap和Secret的创建方式、底层存储差异、以及各自的适用场景第四熟练使用环境变量注入和Volume挂载这两种配置注入手段并能说清两者的取舍第五具备从镜像构建到配置注入再到应用验证的端到端排错能力。这五条如果都能做到说明你在容器化这条路上已经跨越了会跑和会配的分水岭。接下来挑战更复杂的存储、网络、权限控制就有了扎实的地基。6.2 进阶方向滚动更新、Helm与持久化实验结束不等于学习结束。我建议你趁热打铁把以下三个方向作为进阶目标。第一个方向是滚动更新与回滚。你现在已经能在Deployment里改配置了下一步要思考改了镜像版本后怎样让Pod逐个替换而不是同时重启所有实例更新后发现配置有问题怎么用一条命令回滚到上一个版本这背后的机制是ReplicaSet的伸缩协调理解了它你对K8s的期望状态模型会有更深的体会。第二个方向是Helm。手动写YAML部署一个应用勉强能应付但一个应用如果有十几个YAML文件要区分dev/prod环境手动管理就会失控。Helm把相关Kubernetes资源打包成一个chart用模板变量渲染出不同环境的配置本质上是对YAML的编程化管理。我见过很多团队从复制YAML改IP切换到Helm之后部署效率提升是肉眼可见的。第三个方向是持久化存储。配置管理解决的是动态注入持久化解决的是数据不丢。容器本身是无状态的Pod重建后数据就会消失。你后面如果部署数据库、消息队列这类有状态应用就需要引入PersistentVolume和PersistentVolumeClaim这个知识体系和配置管理同样重要而且两者经常会组合使用——比如给数据库挂载初始化配置同时挂载数据卷。6.3 最后再分享一个小技巧实际做实验时我发现很多同学卡在配置文件内容对不对这个问题上反复折腾。这里有一个我常用的技巧在创建ConfigMap时先用--dry-runclient -o yaml把生成的YAML输出到本地检查一遍再真正创建到集群里。kubectl create configmap web-config \ --from-literalENV_NAMESTAGING \ --dry-runclient -o yaml这个命令不会真的创建资源只会把YAML内容打印到终端。你可以在创建之前就检查ConfigMap的键名对不对、格式对不对避免创建完发现拼写错误再删了重建。这个习惯也适用于Deployment、Service、Secret这些所有Kubernetes资源——凡是涉及YAML编写先用--dry-run检查一遍再apply能省掉大量低级错误带来的时间浪费。我做这组实验的体会是容器化技术的知识点其实并不难难的是把它们串成一条完整的链路去理解。镜像构建、仓库推送、配置注入、Pod编排这四步看似独立实际上环环相扣。你只有亲手把这条链路完整跑通一遍遇到问题亲自排查一遍才能真正建立起对K8s运行机制的直觉。希望这份实验手册能帮你少走一些弯路剩下的就是打开终端开始动手。