先确认基础配置

在将Django应用部署到Kubernetes之前，我会先确认应用本身已配置为生产环境。检查settings.py中DEBUG是否设为False，并配置ALLOWED_HOSTS为实际域名或通配符。数据库应使用PostgreSQL或MySQL等生产级数据库，并将连接参数通过环境变量注入。建议将SECRET_KEY、数据库密码等敏感信息存储在Kubernetes的Secret对象中，而非硬编码在代码或Dockerfile里。这一步如果跳过，后续Pod启动后可能因调试模式暴露错误信息，或因为ALLOWED_HOSTS不匹配导致请求被拒。通常我在本地先启动一个生产模式容器测试，确认环境变量注入正常，再继续下一步。

镜像构建要点

使用多阶段构建Docker镜像以减小体积。第一阶段基于Python官方镜像安装依赖并编译静态文件；第二阶段使用轻量级基础镜像如python:3.11-slim，仅复制必要文件。注意在Dockerfile中设置WORKDIR为/app，并确保collectstatic命令在构建时执行，将静态文件收集到STATIC_ROOT目录。验证镜像时需本地启动容器并测试应用是否能正常响应，避免因缺少系统库而导致启动失败。镜像体积如果太大，Kubernetes拉取会慢，且如果使用NodePort或LoadBalancer暴露服务，频繁更新镜像可能影响可用性。建议在构建后通过docker run -p 8000:8000测试，确认静态文件能正常加载。

编写Kubernetes清单

编写Kubernetes资源清单文件时，应定义Deployment、Service和Ingress三个核心资源。Deployment中需明确指定副本数（如2-3个用于生产环境），并添加livenessProbe与readinessProbe，探针路径设为Django的健康检查接口（例如/health/）。Service类型建议先使用ClusterIP进行内部通信，待调试通过后再切换为NodePort或LoadBalancer。Ingress需配置域名与TLS证书，注意Ingress Controller需提前部署（如Nginx Ingress）。容易误判的是探针的初始延迟：如果应用启动慢，initialDelaySeconds设置太短会导致Pod反复重启。建议用kubectl logs观察启动时间后调整。

部署顺序与验证

使用kubectl apply -f命令逐步创建资源，顺序为：先创建ConfigMap和Secret，再创建Deployment，最后创建Service和Ingress。观察Pod状态，通过kubectl get pods -w确认所有Pod进入Running且Ready列显示为1/1。若Pod处于CrashLoopBackOff，执行kubectl logs 查看错误日志，常见原因包括环境变量缺失、数据库连接失败或静态文件路径错误。我会先检查Secret和ConfigMap是否已正确挂载，再确认数据库服务是否从集群内可达。注意Ingress创建后可能需等待DNS解析生效，可以用curl -H "Host: yourdomain.com" http:// 测试。

数据库迁移处理

数据库迁移不应在应用启动时自动执行，而应通过单独的Job运行。创建一个Kubernetes Job，使用与Deployment相同的镜像，执行python manage.py migrate命令。Job需在首次部署前以及每次数据库模型变更后手动触发。注意迁移Job需具有与Deployment相同的数据库访问权限，并确保迁移运行完毕后再更新Deployment副本，否则可能导致新旧代码同时操作数据库引发冲突。我在生产环境常遇到的是迁移Job因超时失败，通常给Job添加activeDeadlineSeconds限制，并设置重试次数。迁移完成后需及时清理Job历史，避免过多残留对象。

风险与后续维护

部署时需留意Django的SECRET_KEY若变更会导致会话失效和密码重置令牌无效，因此务必通过Secret持久化。此外，静态文件需通过Nginx或对象存储提供服务，而非Django本身，否则在高并发下会阻塞worker进程。如果使用持久卷存储媒体文件，需确认PVC的访问模式为ReadWriteMany，否则多副本Pod无法同时写入。务必在部署前设置资源请求与限制，防止Pod因内存超限被OOMKill。后续维护中，更新镜像时建议使用滚动更新策略，并设置maxSurge和maxUnavailable参数控制滚动节奏。每次更新后观察Pod状态和日志，必要时回滚到上一个版本：kubectl rollout undo deployment/。