如何在Amazon EKS的Airflow部署中添加EFS且不破坏原有部署？

你的核心问题是安装EFS CSI驱动后，Airflow依赖的原有EBS存储（gp2存储类）的PVC无法正常绑定，导致Scheduler、PostgreSQL、Redis等组件启动失败。原因包括：

• Airflow的PostgreSQL、Redis等核心组件需要RWO（单节点读写）类型存储（EBS符合该要求），而EFS是RWX（多节点读写），无法满足这类组件的存储需求
• 事件日志显示storageclass.storage.k8s.io "ebs-sc" not found，说明Airflow配置中指定了不存在的存储类；同时原有gp2存储类的PV可能被清理或无法被调度

1. 确认并恢复gp2存储类 #

先检查集群中是否存在默认的gp2存储类：

kubectl get storageclass

如果gp2不存在，执行以下yaml重新创建（EKS默认自带该存储类，若被误删则需手动恢复）：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  name: gp2
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

创建命令：

kubectl apply -f gp2-sc.yaml

2. 修正Airflow Helm配置 #

修改Airflow的values.yaml文件，确保核心组件使用gp2存储类，同时单独配置EFS挂载给需要的组件（比如Worker）：

核心组件存储配置（恢复原有EBS存储）

# PostgreSQL 存储配置
postgresql:
  persistence:
    enabled: true
    storageClass: "gp2"
    size: 8Gi

# Redis 存储配置
redis:
  persistence:
    enabled: true
    storageClass: "gp2"
    size: 1Gi

# Airflow 日志存储配置
logs:
  persistence:
    enabled: true
    storageClass: "gp2"
    size: 100Gi

添加EFS挂载配置（给Worker挂载EFS用于DAG数据存储）

假设你已创建efs-sc存储类和efs-storage-claim PVC，在values.yaml中添加：

workers:
  extraVolumes:
    - name: efs-volume
      persistentVolumeClaim:
        claimName: efs-storage-claim
  extraVolumeMounts:
    - name: efs-volume
      mountPath: /opt/airflow/efs-data  # DAG可在此路径写入数据

3. 升级Airflow Helm部署 #

执行Helm升级命令，应用修改后的配置：

helm upgrade airflow apache-airflow/airflow -n airflow -f your-values.yaml

4. 验证部署状态 #

• 检查PVC绑定状态：

kubectl get pvc -n airflow

确保data-airflow-postgresql-0、redis-db-airflow-redis-0、logs-airflow-worker-0都处于Bound状态

• 检查Pod启动状态：

kubectl get pods -n airflow

等待所有Pod进入Running状态，测试DAG能否正常写入/opt/airflow/efs-data路径

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