Kubernetes：如何按内存限制或定时自动重启Pod？

当然可以！在Kubernetes里完全能实现你想要的这两种重启逻辑，刚好对应gunicorn这类主流进程管理器的常见需求，下面分场景给你拆解具体实现方法：

Kubernetes本身就有一套原生机制来处理这种情况，核心是**OOM Killer（内存不足杀手）**和Pod的restartPolicy配置：

• 首先你需要给Pod的容器设置内存限制（resources.limits.memory），当容器使用的内存超过这个值时，kubelet会触发OOM Killer杀死该容器。
• 然后通过Pod的restartPolicy来控制容器被杀死后的重启行为：
  • Always：不管容器是正常退出还是异常终止，都会自动重启（最常用的选项，适合大多数服务场景）
  • OnFailure：只有容器异常退出（退出码非0）时才重启
  • Never：从不重启容器

举个Deployment配置的例子，给容器设置1Gi内存限制，并配置Always重启策略：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      restartPolicy: Always  # 关键配置
      containers:
      - name: my-app-container
        image: your-app-image:latest
        resources:
          limits:
            memory: "1Gi"  # 内存限制，超过后会触发OOM
          requests:
            memory: "512Mi"

当容器内存触达1Gi限制时，OOM Killer会干掉容器，紧接着kubelet就会按照Always策略重启它，和gunicorn遇到内存泄漏时重启进程的逻辑类似。

Kubernetes没有原生的“定时重启Pod”功能，但有几种非常实用的实现方式，能满足类似进程管理器的定时重启需求：

方法1：用CronJob定期触发Deployment/StatefulSet滚动重启 #

这是最推荐的集群级方案，优雅且不侵入容器内部。思路是用CronJob定时执行kubectl rollout restart命令，让Deployment/StatefulSet滚动重启所有Pod，避免服务中断。

比如创建一个每天凌晨2点重启名为my-app的Deployment的CronJob：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: restart-my-app
spec:
  schedule: "0 2 * * *"  # 每天凌晨2点执行（Cron表达式）
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: restart-sa  # 需要有操作Deployment的权限
          containers:
          - name: kubectl
            image: bitnami/kubectl:latest
            command: ["kubectl", "rollout", "restart", "deployment/my-app"]
          restartPolicy: OnFailure

注意：你需要提前创建一个拥有Deployment编辑权限的ServiceAccount（restart-sa），避免权限不足的问题。

方法2：在容器内部实现进程级定时重启 #

如果你的服务是用gunicorn跑的，直接用gunicorn本身的参数就能实现定时/定量重启，比如：

• --max-requests N：处理N个请求后自动重启worker进程
• --max-requests-jitter M：在max-requests基础上增加随机抖动（避免所有worker同时重启）
• 要是想按时间重启，可以在容器里加个cron任务，定时执行kill -HUP <gunicorn-master-pid>来平滑重启worker

这种方法是进程级的重启，不会重启整个Pod，适合不想中断Pod网络的场景。

方法3：用Liveness Probe触发定时Pod重启 #

你可以在容器里写一个简单的脚本，记录Pod启动时间，当运行时间超过指定阈值时，让Liveness Probe检测失败，kubelet就会自动重启Pod。

比如，先在容器里放一个检查脚本check_restart.sh：

#!/bin/bash
START_TIME=$(cat /var/run/pod_start_time)
CURRENT_TIME=$(date +%s)
MAX_RUN_TIME=86400  # 24小时，单位秒

if [ $((CURRENT_TIME - START_TIME)) -gt $MAX_RUN_TIME ]; then
  exit 1  # 返回非0，让Liveness Probe失败
else
  exit 0
fi

然后在Pod配置里加上Liveness Probe，并在容器启动时记录启动时间：

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: your-app-image:latest
    command: ["sh", "-c", "date +%s > /var/run/pod_start_time && /path/to/your/app"]
    livenessProbe:
      exec:
        command: ["sh", "/path/to/check_restart.sh"]
      initialDelaySeconds: 30
      periodSeconds: 60  # 每分钟检查一次

当Pod运行超过24小时后，Liveness Probe会检测失败，kubelet就会重启这个Pod。

• 内存触发重启的场景，建议配合监控工具跟踪内存使用情况，避免频繁OOM重启影响业务稳定性。
• 定时重启时，优先用CronJob滚动重启Deployment，这种方式能保证服务的可用性（滚动更新，不会一次性杀掉所有Pod）。
• 如果是有状态服务（StatefulSet），定时重启也要注意数据持久化的问题，避免数据丢失。

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