咨询在Kubernetes集群部署Flask+Gunicorn+Nginx的标准方案

一、你当前Dockerfile的核心问题 #

• ENTRYPOINT与CMD搭配错误：Docker中同时指定ENTRYPOINT和CMD时，CMD的内容会作为ENTRYPOINT的参数传递。你的配置实际执行的是gunicorn --bind 0.0.0.0:8000 wsgi:app nginx -g daemon off;，导致Gunicorn把Nginx的启动命令当成自身参数，Nginx根本不会启动。
• 镜像过于臃肿：基于Nginx基础镜像安装Python环境，会引入大量不必要的系统依赖，镜像体积过大，不利于分发和快速部署。
• 多进程管理缺失：单容器内跑Gunicorn和Nginx两个进程，没有进程管理工具（如supervisord）的话，其中一个进程崩溃后容器可能不会自动重启，也无法监控每个进程的状态。

二、Kubernetes中的标准部署方案 #

方案1：同一个Pod部署双容器（Sidecar模式） #

这是中小型应用最常用的方案，优势很明显：

• 两个容器共享Pod的网络命名空间，Nginx可以直接通过localhost:8000访问Gunicorn，不用额外配置Service。
• 部署逻辑简单，不用拆分多个Deployment，一次就能部署完整的应用栈。
• Pod生命周期统一，重启时两个容器同步启停。

具体实现步骤：

1. 分别构建两个镜像：
   • Flask+Gunicorn镜像：基于Python镜像，安装依赖、复制代码，启动命令为gunicorn --bind 0.0.0.0:8000 wsgi:app。
   • Nginx镜像：可以用官方镜像，或者自定义镜像包含配置文件（更推荐用ConfigMap挂载配置）。
2. 编写Kubernetes部署YAML：

# Nginx配置的ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: flask-nginx-config
data:
  default.conf: |
    server {
        listen 80;
        server_name _;

        location / {
            proxy_pass http://localhost:8000;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
---
# 应用Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: flask-app
  template:
    metadata:
      labels:
        app: flask-app
    spec:
      containers:
      - name: flask-gunicorn
        image: your-flask-gunicorn-image:v1
        ports:
        - containerPort: 8000
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"
        # 可选：添加健康检查
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 10
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: default.conf
      volumes:
      - name: nginx-config
        configMap:
          name: flask-nginx-config
---
# 暴露应用的Service
apiVersion: v1
kind: Service
metadata:
  name: flask-app-service
spec:
  selector:
    app: flask-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer # 根据集群环境选择NodePort/ClusterIP

方案2：用Ingress Controller统一管理反向代理（生产环境推荐） #

如果你的集群有多个应用，或者需要更复杂的路由规则、SSL终止等功能，推荐用Kubernetes官方的NGINX Ingress Controller替代单独的Nginx容器：

1. 部署Flask+Gunicorn的Deployment和Service（只暴露8000端口的ClusterIP Service）。
2. 配置Ingress资源，将外部请求路由到Flask的Service。

示例Ingress配置：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: flask-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - your-app-domain.com
    secretName: app-tls-secret # 提前配置SSL证书的Secret
  rules:
  - host: your-app-domain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: flask-app-service
            port:
              number: 8000

三、要不要在同一个Pod里跑两个容器？ #

看你的实际场景：

• 建议同Pod部署的情况：
  • 这个Nginx只专门服务于当前Flask应用，没有共享需求。
  • 想简化部署流程，不想额外配置Ingress或多Service。
  • 追求本地通信的低延迟，避免跨Pod网络调用的开销。
• 不建议同Pod部署的情况：
  • 需要独立扩展Nginx和Flask（比如Nginx需要更多副本扛流量，而Flask不需要）。
  • 多个应用需要共享同一个反向代理层。
  • 需要更灵活的路由、SSL、限流等高级功能，适合用Ingress Controller。

四、额外优化建议 #

• 用多阶段构建Flask镜像：比如先在Python镜像中构建依赖，再把代码和依赖复制到轻量级的Python-alpine镜像，大幅减少镜像体积。
• 避免单容器多进程：如果一定要用单镜像，必须用supervisord这类进程管理器来监控两个进程的状态，但还是推荐多容器Pod的方式，更符合Kubernetes的设计理念。
• 用ConfigMap存储配置：Nginx配置、Flask的环境变量都放到ConfigMap里，不用硬编码在镜像中，修改配置无需重新构建镜像。
• 配置健康检查：给Gunicorn和Nginx都加上livenessProbe和readinessProbe，确保Kubernetes能及时发现并恢复异常容器。

内容的提问来源于stack exchange，提问作者yahiya ayoub