Python应用容器化实战：从Docker到Kubernetes的部署指南

写Python写了好几年，最让我头疼的从来不是语言本身，而是"在我电脑上能跑"这句话。本地开发环境好不容易跑起来的服务，交给别人一部署就崩，要么Python版本对不上，要么系统库缺失，要么MySQL连不上，每次都要把环境问题重新踩一遍。后来我把Python应用容器化，用Docker打包成镜像、用Docker Compose编排本地依赖服务、再放到Kubernetes集群里统一调度，才发现这套组合拳真正解决了Python项目从开发到上线的"最后一公里"。

这篇文章不打算讲太多虚的，就从Python开发者的实际痛点出发，把Docker和Kubernetes这条链路拆开揉碎，讲清楚每一步为什么这么做、实际操作会遇到哪些坑、怎么排查。无论你是刚入门Python、还在折腾Python安装环境的初学者，还是已经能用Flask/FastAPI写接口、想把服务正经部署上线的开发者，这篇都会有你能直接拿去用的东西。

1. 先把Python应用装进容器：Dockerfile的正确打开方式

容器化的第一步不是去学Kubernetes，而是把Python应用先装进一个标准化的容器里。一个能跑起来的镜像，干净的依赖环境加上可复现的启动命令，后面所有编排和调度都建立在这块地基上。这里最常见的三个坑，我至少帮人排查过几十回：基础镜像选错、依赖反复安装、容器里用root乱跑。

1.1 基础镜像选型：全量、slim还是alpine

很多Python开发者的第一个Dockerfile，上来就是FROM python:3.12，这是最省事但也是最糙的选择。python官方镜像分好几个变体，选型差别直接决定镜像体积和编译各种Python包时的体验，选错了一个pandas或psycopg2能把你编译到怀疑人生。

我自己的选择标准很简单：默认用slim，碰都不碰alpine；除非这个服务就是一个纯标准库脚本、一个第三方依赖都没有，才考虑alpine。

原因在于Python生态里有大量带C扩展的包，像numpy、pandas、psycopg2、lxml、bcrypt这类。它们大多数是编译好的wheel包，而wheel是区分平台和libc的。Alpine用的是musl libc，很多wheel包没有musl版本，pip会当场给你编译，慢不说，还经常缺编译工具链。glibc系的slim镜像里，几乎常见的包都有预编译wheel，pip install就是解压复制，秒装完。

用一句话给新手解释：全量镜像像精装修房子，啥都有但搬起来费劲；slim像简装房，基础功能齐全又不浪费空间；alpine像毛坯房，看着小，装修（编译依赖）全靠你自己。日常基于slim去加你需要的东西，是最平衡的做法。

1.2 依赖层的缓存顺序：一行代码引发的"重装地狱"

刚开始写Dockerfile，很多人喜欢图省事，把依赖安装和代码复制写在一起：

FROM python:3.12-slim WORKDIR /app COPY . . RUN pip install -r requirements.txt CMD ["python", "main.py"]

这个写法在功能上没问题，但会让每次构建都遭受"重装地狱"——因为Docker的镜像是一层一层叠加的，COPY的改动会使得该层以及之后的所有缓存层全部失效。这段代码里COPY把所有代码都放进了一层，然后RUN pip install相当于在代码层之上。于是只要你的Python代码改了一个字符，整个层缓存失效，Docker就要重新执行pip install把依赖全部装一遍。

正确的姿势是充分利用层缓存，把不常变动的依赖和经常变动的代码分开：

FROM python:3.12-slim ENV PIP_NO_CACHE_DIR=1 \ PIP_DISABLE_PIP_VERSION_CHECK=1 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["python", "main.py"]

这样拆分之后，只要requirements.txt没变，pip install这层缓存就一直有效，构建一次之后，后续改代码再构建只需要重新COPY代码那一层，构建时间从几分钟直接降到十几秒。

想再进一步提速的话，Docker BuildKit还支持为pip的下载缓存单独开一个持久化的cache挂载点，加上这个参数之后，即使requirements.txt变动了，之前下过的wheel包也还在：

# syntax=docker/dockerfile:1 RUN --mount=type=cache,target=/root/.cache/pip \ pip install -r requirements.txt

我个人在实际项目里的体会是，先COPY依赖文件再安装、后COPY源代码，这个顺序对开发体验的提升非常明显。团队里每次改完接口都要重新构建镜像，快慢直接影响大家的效率和心情。

1.3 镜像里别用root跑：非root用户和PID 1问题

镜像能跑起来和"应该这样跑"是两回事。默认情况下容器内就是root用户，这就带来一个实际风险：如果应用被攻破，攻击者拿到的就是容器内的最高权限，配合不恰当的挂载卷（比如把宿主机目录挂进去了），容器逃逸的风险会成倍上升。

安全加固的常规做法是在Dockerfile里创建专用用户，再用USER切换，让Python进程以非root身份运行：

FROM python:3.12-slim RUN groupadd -r appuser && useradd -r -g appuser -u 1000 appuser WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . USER appuser EXPOSE 8000 CMD ["python", "main.py"]

这里有个新手容易踩的坑：切换成非root用户之后，如果代码里有依赖运行期写文件的逻辑（比如写日志、生成缓存），而工作目录的所有者不是这个用户，就会报PermissionError。我一般会在Dockerfile里先建好目录并归属给appuser：

RUN mkdir -p /app/logs && chown -R appuser:appuser /app

还有一个特别容易被忽略的细节：CMD的写法。Dockerfile里的CMD有两种形式——exec形式和shell形式。exec形式是CMD ["python", "main.py"]，shell形式是CMD python main.py。exec形式会直接让python进程成为容器内的1号进程（PID 1），这样才能正确接收来自Docker和Kubernetes的SIGTERM信号，实现优雅退出。shell形式则会在中间多夹一层shell，信号传递会被干扰，前面提到的"容器和本地行为不一致"往往就是这么来的。

2. 本地开发绕不开的组合拳：Docker Desktop与Compose实战

镜像写好了，接下来就要在本地把应用跑起来。作为Python开发者，你的服务大概率不是孤零零的——要连MySQL，要接Redis。如果MySQL和Redis也直接装在本地电脑上，团队里每个人环境都不一样，典型的"在我电脑上能跑"就又回来了。用Docker Compose把这些依赖服务和应用一起编排起来，是本地开发最顺手的方案。

2.1 Docker Desktop启动失败的常见原因与排查思路

Windows上装Docker Desktop，我遇到最多的问题就是启动时报错Docker Desktop failed to start because virtualisation support wasn't detected。很多人看到这个报错就慌了，其实排查起来按顺序来就行：

1. 进任务管理器，切换到"性能"标签，看CPU一栏右下角"虚拟化"是否显示"已启用"。如果显示"已禁用"，去BIOS里把Intel VT-x或AMD-V打开。有些品牌的机器BIOS里虚拟化选项藏得比较深，搜索"虚拟化"或"Virtualization"关键词慢慢找。
2. 如果虚拟化已经启用还报错，多半是WSL2的问题。在PowerShell里跑wsl --status看看状态，如果是WSL1，执行wsl --update升级到WSL2。
3. Docker Desktop的Settings里，把"Use the WSL 2 based engine"勾选上，而不是用旧的Hyper-V后端。新版Docker Desktop默认就是WSL2后端，但如果你从旧版本升级上来，这个设置可能会被保留成Hyper-V。

这个报错里还有一个很隐蔽的坑：Windows的"内核隔离"功能（基于虚拟化的安全，VBS）会和Docker Desktop产生冲突。如果你按前面步骤排查完还是启动失败，去"Windows安全中心"-"设备安全性"-"内核隔离"，把内存完整性关掉再试试。关掉VBS之后Docker Desktop大概率就能正常启动了。

Docker Desktop好不容易装好，我建议顺手在设置里把资源上限调整一下。不少PC默认给WSL2的内存上限只有2GB，如果你本地要同时跑Python服务、MySQL、Redis，内存很容易不够。一般给WSL2分4GB~6GB比较舒服，在Settings的Resources里调整。

2.2 Compose编排：Python应用、MySQL、Redis一次拉起

本地开发玩Docker Desktop，最常用的其实不是docker run，而是docker compose。写一个docker-compose.yml，把应用、MySQL、Redis全部编排起来，一条命令全部启动。

services: app: build: . ports: - "8000:8000" environment: MYSQL_HOST: mysql MYSQL_PORT: 3306 REDIS_HOST: redis REDIS_PORT: 6379 depends_on: mysql: condition: service_healthy redis: condition: service_healthy volumes: - .:/app mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: example MYSQL_DATABASE: appdb ports: - "3306:3306" volumes: - mysql_data:/var/lib/mysql healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 5s timeout: 3s retries: 10 redis: image: redis:7-alpine ports: - "6379:6379" healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s timeout: 3s retries: 10 volumes: mysql_data:

这里有一个值得认真理解的地方：为什么Python代码里连接MySQL和Redis时，host要写mysql和redis？因为在同一个Compose网络里，服务名就是其他服务访问你的域名，Docker内置DNS会自动做解析。你在代码里配MYSQL_HOST=mysql就行，不同机器上这个配置完全通用，不用关心MySQL跑在哪台机器上。

depends_on加上condition: service_healthy的写法也很关键。如果只写depends_on: [mysql, redis]，Compose只保证MySQL容器启动了，不保证MySQL已经准备好接受连接。Python应用启动早于MySQL就绪时，连库直接报错。加了healthcheck之后，Compose会等MySQL的mysqladmin ping检查通过，再启动你的应用。

数据库容器要不要把端口映射到宿主机？我的建议是：本地开发为了方便调试，映射一下可以接受；但如果是生产环境接的数据库，不通过Compose管理，那就算了。此外数据库数据一定要用命名卷挂载，否则容器删除之后数据全丢，这是本地开发最容易出的"惨案"。

2.3 容器里跑Python和本地的几个差异点

哪怕你的Dockerfile和Compose没任何问题，容器里跑Python应用和本地直跑，依然会有若干让你困惑的行为差异：

• 时区差异：基础镜像默认是UTC，Python的datetime.now()拿到的和本地差8个小时，查日志时对不上时间。在Dockerfile里加一句ENV TZ=Asia/Shanghai，或者在Compose里的environment里设置TZ。
• 代码挂载与权限：Compose里通过volumes把当前目录挂到容器/app，宿主机上文件属主不是容器里那个appuser的话，Python进程可能会写不了文件。如果只是本地开发不想纠结权限，可以暂时不用USER指令；生产镜像则必然用非root用户，配合宿主机目录权限单独处理。
• pycache权限问题：挂载代码进容器后，Python运行时会在目录里生成__pycache__，而容器内appuser对宿主机目录没有写权限时，Python就会悄悄把字节码缓存写到其他位置或者提示缓存错误。这也是"本地能跑、容器里报错"的经典来源之一。开发阶段我在Compose里用root跑，不纠结这个；生产环境则把缓存开关关掉，或确保目录权限正确。

遇到"容器里行为和本地不一致"的问题，第一反应不是瞎改代码，而是进入容器内部去看：

docker exec -it <container_name> bash

进去之后挨个看工作目录、用户身份、环境变量、Python版本、pip list，差异通常一眼就能看出来。查完再退出，去改配置和Dockerfile。

3. 从Docker到Kubernetes：先换掉这套心智模型

Docker和Compose用顺手之后，你会遇到下一个问题：这些容器是在单台机器上跑的。假如宿主机挂了、内存不够了、需要在几台机器上同时部署同一套服务，Compose就完全不够用了。Kubernetes解决的是集群层面的容器编排问题，但它不是Docker的上级，也不是"多机版Compose"，它引入了全新的抽象模型，需要你把思维切过来。

3.1 为什么我们需要Kubernetes，它和Docker的边界在哪

在单机场景下，Docker像一家只经营一家门店的公司：所有店员（容器）都在这一家店里工作，店门关了（宿主机宕机），所有店员都没法营业。数据要扩容，就只能给这家门店拼命加货架（加大机器配置），这就是所谓的垂直扩容，有上限，钱花了也不一定扛得住。

Kubernetes则是一个总部，它能同时管理几十上百家门店（节点），哪家门店倒了，总部把店员（Pod）调度到还在营业的门店里去；顾客突然增多，总部自动多派店员过去（水平扩容）；店员挂了，总部自动补一个一模一样的店员进去。

所以Docker和Kubernetes不是替代关系。Docker负责构建镜像、本地运行容器；Kubernetes负责的是"把这些容器放到一个资源池里，自动调度、自动恢复、自动伸缩"。可以理解为：Docker解决了"怎么打包和运行"，Kubernetes解决了"怎么管理和保证运行时的稳定性"。

3.2 从Compose的思维切换：Pod、Deployment、Service、Ingress

刚开始学Kubernetes，很多人用Compose的概念去套，结果一头雾水。这里有一组最基础的概念对应关系，可以帮助快速建立框架：

这里最重要的一个思维切换是：Pod才是Kubernetes里的最小调度单元，而不是容器。一个Pod里面可以放一个容器，也可以放多个容器。为什么要搞出Pod这么一层？因为有些场景下，我们需要把两个容器绑在同一个"宿主机"上运行，共享网络、共享存储，比如只有一个sidecar负责收集日志、导流，或者一个容器起代理服务、一个容器跑业务进程。Pod把它们作为一个整体调度，要么一起被调度到某个节点，要么一起被销毁。

理解了Pod之后，另一个容易糊涂的地方是Deployment和Service的分工。Deployment管的是Pod的"生死"——期望几个副本、怎么滚动更新、节点挂了怎么办。而Service管的则是一组Pod的"入口"——Pod经常被销毁重建，IP是飘忽不定的，Service给这一组Pod分配一个稳定的虚拟IP和DNS名字，外部请求先到Service，再由它转发到后端的Pod上。Service相当于店铺门口的总服务台，顾客不用管店员是谁，找服务台就行。

至于Ingress，你把它想象成是商场总入口处的门卫：根据访问的域名和URL路径，把不同的顾客引导到不同的楼层和柜台。比如api.example.com/api转到A服务的Service，api.example.com/admin转到B服务的Service。

3.3 本地搭一个最小的Kubernetes环境：minikube、kind还是k3s

学习Kubernetes，除非你有现成的托管集群可用，否则第一步是本地搞一个轻量环境。常见的三个选择：minikube、kind、k3s。

如果说你已经装了Docker Desktop，那么新版的Docker Desktop本来就可以一键开启Kubernetes，在Settings的Kubernetes页勾选Enable Kubernetes就能得到一个单节点集群。这种方式最省事，对新手足够友好。唯一的问题是它出来得比minikube早，集群版本升级跟着Docker Desktop走，自己没法灵活选版本。

如果你不想让Docker Desktop这个"全家桶"承载太多功能，用kind是最快的方案——因为它本质上是"在Docker容器里再跑一套K8s节点"，不依赖虚拟化技术，几个命令行就能起一个集群：

kind create cluster --name dev

跑完用kubectl get nodes就能看到节点状态。我个人用kind比较多，因为它在CI里也能很稳定地跑，适合做本地验证。如果想要更接近生产环境的体验，用minikube，它能模拟出存储、负载均衡器等更多组件。

4. 把FastAPI服务部署到Kubernetes：一份能直接抄的清单

概念过一遍之后，最重要的还是把服务真正部署到集群里看它跑起来。下面我用一个FastAPI服务为例，把整个部署清单逐行拆给你看。这个服务不需要多复杂，就是能响应/healthz健康检查、能连上MySQL和Redis就行。需要说明的是，以下镜像地址和配置都是示例，实际操作时替换成你自己的镜像仓库和配置即可。

4.1 镜像前置工作：打包、打标签、推送到镜像仓库

Kubernetes节点从镜像仓库拉镜像，默认是去Docker Hub或你指定的私有镜像仓库。本地构建好的镜像，要打上仓库地址的标签再推送：

docker build -t registry.example.com/fastapi-demo:1.0.0 . docker push registry.example.com/fastapi-demo:1.0.0

这里有个容易忽视的细节：Kubernetes的镜像名需要是全限定名，就是必须包含仓库地址。如果你只写fastapi-demo:1.0.0，kubelet默认会去Docker Hub找这个镜像，因为Docker Hub上没有，肯定拉不到。这和本地Docker跑镜像的规则有点差异，本地你用短名字跑得欢，一到K8s就拉取失败（ImagePullBackOff），多半就是这个原因。

4.2 Deployment清单逐行拆解

Deployment是Kubernetes里管无状态应用副本的核心资源。把下面这个YAML保存为deployment.yaml，这就是一个相对完整的FastAPI服务部署配置：

apiVersion: apps/v1 kind: Deployment metadata: name: fastapi-app namespace: default spec: replicas: 3 selector: matchLabels: app: fastapi-app template: metadata: labels: app: fastapi-app spec: containers: - name: app image: registry.example.com/fastapi-demo:1.0.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8000 protocol: TCP env: - name: MYSQL_HOST value: mysql-service - name: MYSQL_PORT value: "3306" - name: REDIS_HOST value: redis-service resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi readinessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 15 periodSeconds: 20 failureThreshold: 3

一行一行拆开看：

• replicas: 3：期望保持3个Pod副本。Kubernetes里有个控制器（Deployment controller）会一直盯着，一旦某个Pod挂了就立刻重新调度一个新Pod出来。
• selector.matchLabels：Deployment通过这个label匹配自己管辖的Pod。注意这个selector一旦创建就不能改，因为控制器靠它来识别归属。
• imagePullPolicy: IfNotPresent：如果节点上还没有这个镜像就去拉取。镜像tag是latest时，Kubernetes会强制每次都拉取，所以生产环境应该尽量避免使用latest标签，而是用带版本号的tag，方便回滚。
• env：环境变量的注入方式。这里用value直接写，更规范的应该用ConfigMap和Secret来管理，下一章详细说。
• resources.requests和limits：requests是调度器为Pod预留的最小资源，limits是运行时允许占据的上限。对Python服务来说，一开始requests设100m CPU和128Mi内存是比较保守的起步值，生产环境要根据压测结果调整。如果只设limits不设requests，调度器不知道你实际需要多少资源，部署时容易把Pod堆积到同一台机器，而某台机器资源还很闲。
• readinessProbe和livenessProbe：两类探针。readiness决定Pod能不能接收流量，fail的话就从Service的endpoints里摘除，但容器不会重启；liveness决定容器是否还"活着"，连续失败会重启容器。FastAPI里对应的/healthz路由需要尽快加上，它是Kubernetes判断你服务状态的唯一依据。

4.3 Service与Ingress：让外部流量找到你的服务

Deployment创建好之后，Pod是有IP的，但Pod会漂移，你不能把Pod IP直接给用户用。所以需要一个Service给这一组Pod提供一个稳定的访问入口：

apiVersion: v1 kind: Service metadata: name: fastapi-app spec: selector: app: fastapi-app ports: - port: 80 targetPort: 8000 type: ClusterIP

Service的类型主要有三种，适用场景完全不同：

ClusterIP类型的Service在集群内部访问没问题，但集群外的浏览器访问不到它。如果你的应用要对外提供API，生产上一般用LoadBalancer或Ingress。Ingress的好处是能把多个服务按域名/路径统一成单一入口：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: rules: - host: api.example.com http: paths: - path: / pathType: Prefix backend: service: name: fastapi-app port: number: 80

Ingress本身不管流量转发，它只是一个规则声明，真正干活的是Ingress Controller（比如nginx-ingress）。你创建了Ingress资源但集群里没有Ingress Controller，这个规则不会生效。很多新手在minikube里配好Ingress之后访问不了，就是因为在装minikube时没有同时启用ingress组件。要检查本地集群有没有Ingress Controller，可以看kubectl get pods -n kube-system，或者直接minikube addons enable ingress启用它。

5. 生产环境最关键的细节：探针、滚动更新与优雅退出

部署上去能跑只是开始，真正考验的是版本更新时服务不中断、某个Pod出错时自动恢复、整个发布过程对用户无感知。这三个问题对应Kubernetes里三个最实用的机制：探针、滚动更新、优雅退出。

5.1 三种探针，配错了比不配更麻烦

前面提到readiness和liveness，其实Kubernetes还有第三种探针：startupProbe。三种探针分工明确：

• startupProbe：针对启动特别慢的应用。比如FastAPI服务启动时要加载大型机器学习模型，可能要花30秒到1分钟，默认的探针周期根本等不到它起来。给一个足够长的startupProbe窗口，Kubernetes就会耐心等，而不会因为liveness检测太早失败就把容器反复杀掉。
• livenessProbe：探活，判断容器是不是卡死了。连续失败就重启容器。适合检测死循环、死锁这类导致进程活着但无法正常工作的情况。
• readinessProbe：判断是否就绪，是否要把流量打给它。连续失败就把它从Service里摘除，但不重启容器。

这里容易踩的坑是：有人图省事，把三个探针配成同一个检查路径同一个参数。假如你的应用因为某种原因进入了"能响应healthz但业务数据链路已断"的状态，比如能起HTTP服务但连不上MySQL了。如果healthz里没检查数据库连接，readiness仍然返回200，Service就继续把流量打给这个状态异常的Pod，用户在接口层看到的就是"服务器开了但报错"。

所以生产环境的healthz端点，我一般会让它同时做依赖检查：查MySQL连接、查Redis连接，依赖挂了就返回500。这样readiness才能真实反映服务的可用状态。

5.2 滚动更新：maxSurge和maxUnavailable怎么配

Deployment更新镜像版本时，默认采用滚动更新策略，分批创建新Pod、销毁旧Pod，保证整个过程服务在线。控制这个节奏的是strategy.rollingUpdate下的两个参数：

spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0

• maxUnavailable：更新过程中允许有多少个旧Pod不可用。设成0意味着无论如何都保证有足够的Pod在线，适合用户流量不能断的严肃场景。
• maxSurge：允许超出期望副本数多少个Pod。设成1意味着可以多启动1个新Pod，等新Pod就绪后再杀掉旧Pod，实现"先起新的、再下旧的"。

对Python服务这种启动速度不算快的进程，这两个值按1/0来配，会是比较稳妥的做法，更新过程中Pod总数会短暂超过期望值，但不会有服务空的瞬间。如果实例数很少（比如就2个副本），保守一点可以把maxUnavailable设成0，maxSurge设成1，空间换时间。

还有一个和滚动更新强相关的点是优雅退出。Kubernetes在缩容或滚动更新时，会给Pod发送SIGTERM信号，然后在默认的30秒terminationGracePeriodSeconds宽限期之后，发SIGKILL强杀进程。如果你的Python应用启动慢、当前还有正在处理的请求，SIGTERM之后要是没在30秒内退出，旧的Pod会被直接杀掉，正在处理中的请求就会中断。

Python服务里最容易遇到这种情况的是异步任务或者长耗时请求。假如K8s一滚动更新，线上就报"连接被重置"，大概率就是优雅退出没做好。要让FastAPI服务优雅退出，最简单的方案是使用Gunicorn作为进程管理器，而不是直接用uvicorn裸跑。Gunicorn作为容器主进程时会收到SIGTERM，它会停止接收新连接，并给正在处理的worker一段时间完成当前请求，再优雅退出。在Dockerfile里我通常这样写：

CMD ["gunicorn", "app.main:app", "-w", "4", "-b", "0.0.0.0:8000", "--timeout", "60"]

如果业务代码里需要更精细的控制，可以在FastAPI的lifespan事件里处理，或者注册signal handler。其实我的经验是：容器里Python应用尽量别自己做信号处理，把进程管理交给Gunicorn这种成熟的进程管理器，省心很多。

滚动更新还有一个反直觉的细节：更新完成后，旧Pod的Terminating状态和Pod的终止前钩子（preStop hook）有关。如果代码里没有特殊的收尾逻辑（比如通知注册中心下线、等待几秒再退出），很多问题都是可以靠加一个preStop sleep来缓解的，给流量从Service里摘除留出时间：

lifecycle: preStop: exec: command: ["sh", "-c", "sleep 5"]

5.3 配置管理：ConfigMap和Secret，别把配置写死在镜像里

最后一个是很多Python项目从单机搬到K8s后会踩的坑：配置散落在环境变量和代码文件里。在镜像里写死配置，意味着每次改配置都得重新构建镜像，太痛苦。正确的做法是把配置从镜像中剥离，用Kubernetes的ConfigMap和Secret来管理。

ConfigMap用于非敏感配置，比如URL、端口、日志级别、功能开关。Secret用于敏感信息，比如数据库密码、API密钥、Redis密码。

apiVersion: v1 kind: ConfigMap metadata: name: app-config data: MYSQL_HOST: mysql-service MYSQL_PORT: "3306" LOG_LEVEL: info --- apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque stringData: MYSQL_PASSWORD: SuperSecretPassword

然后在Deployment里通过envFrom一次性注入：

spec: containers: - name: app envFrom: - configMapRef: name: app-config - secretRef: name: app-secret

有两个点必须提醒。第一，Secret并不是加密的，它只是base64编码，任何一个能在集群里看Secret的人，都能轻松解码看到明文。真正的"机密"场景需要配合外部密钥管理系统来用，而不是指望Secret本身保密。第二，修改ConfigMap之后，已经运行中的Pod并不会自动拿到新配置，需要重启Pod或触发一次滚动更新。有些团队会用第三方工具（比如Reloader）监听ConfigMap变化自动触发滚动更新，也可以靠自己手动kubectl rollout restart deployment/fastapi-app。

写到最后再分享一个我自己练手时的习惯。每次我想验证一套K8s配置是否正确，都会先在本地用kind起一个临时集群，把Deployment、Service、ConfigMap全部apply进去，再kubectl port-forward svc/fastapi-app 8000:80把服务映射到本地直接访问。这套流程既不污染开发环境，又能快速复现问题。容器化这条路，刚开始看着工具链很长，但等你把Python应用、Docker和Kubernetes三者真正串起来之后，部署这件事就会变得异常清晰和平稳。