EKS Fargate上Airflow Pod持续重启（错误码143）求助

1. 资源不足（最可能触发CrashLoopBackOff的原因） #

Fargate为Pod分配的资源是0.25vCPU 0.5GB，而Airflow 2.4.1的Webserver组件启动需要更高的资源配额，尤其是内存。资源不足会导致进程无法正常初始化8080端口，或者直接被OOM Kill，进而引发存活/就绪探针失败，最终进入循环重启状态。

解决方式：
在values.yaml中调整Webserver、Scheduler、Worker的资源请求与限制：

webserver:
  resources:
    requests:
      cpu: "0.5"
      memory: "1Gi"
    limits:
      cpu: "1"
      memory: "2Gi"
scheduler:
  resources:
    requests:
      cpu: "0.5"
      memory: "1Gi"
    limits:
      cpu: "1"
      memory: "2Gi"
worker:
  resources:
    requests:
      cpu: "0.5"
      memory: "1Gi"
    limits:
      cpu: "1"
      memory: "2Gi"

重新执行部署命令：

helm upgrade --install airflow apache-airflow/airflow -n dev --values values.yaml --set volumePermissions.enabled=true

2. VolumePermissions参数拼写错误 #

部署命令中volumePermissions.enbled=true存在拼写错误，正确参数应为volumePermissions.enabled=true。该参数控制初始化容器为日志目录设置权限，若未正确开启，Airflow进程可能没有权限写入EFS挂载的/opt/airflow/logs目录，导致启动失败。

解决方式：修正参数后重新部署，确保初始化容器能完成目录权限配置。

3. EFS挂载权限与状态异常 #

即使开启了volumePermissions，EFS的配置也可能存在问题：

• 检查EFS安全组是否允许Fargate Pod所在子网的流量访问
• 确认EFS挂载目标部署在Pod所在的VPC子网中
• 验证PVC状态是否为Bound，PV的访问模式是否为ReadWriteMany（Airflow多Pod需要共享日志存储）

验证命令：

kubectl get pvc -n dev af-efs-fargate-1
kubectl describe pv <对应PV名称>

4. 探针初始化延迟过短 #

当前探针配置的initialDelaySeconds=15s太短，Airflow Webserver启动需要一定时间，尤其是资源紧张时，进程还未就绪就会触发探针失败。

解决方式：在values.yaml中延长探针初始延迟：

webserver:
  livenessProbe:
    initialDelaySeconds: 60
  readinessProbe:
    initialDelaySeconds: 60

5. 查看容器日志定位具体错误 #

探针失败只是表象，直接查看Webserver容器的日志能获取最直接的错误信息：

kubectl logs -n dev airflow-webserver-775d548b98-wd5x8 -c webserver
kubectl logs -n dev airflow-webserver-775d548b98-wd5x8 -c webserver --previous

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