AWS EKS에서 EBS CSI를 사용할 때 발생된 문제에 대한 해결 사례 #241121

- 히스토리

https://story-sh.tistory.com/entry/EKS%EC%97%90-EBS-CSI-%EC%98%AC%EB%A0%A4%EC%84%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EC%9E%90-241023

EKS에 EBS CSI 올려서 사용하자-241023

위의 글을 보았듯이 해당 속도에 대한 이슈를 해결한 뒤에 이어지는 이야기......

 

그 이후 잘 사용하다가 EKS 의 k8s 버전업데이트 이후 갑자기 아래와 같은 증상으로 

EBS csi의 볼륨이 정상적으로 동작하지 않았습니다....

추가로 말하자면 현재환경은 AWS SSO를 사용하는 환경~

 

- 로그 및 원인

이게 로그를 못찍어놨는데... 마운트가 되지않는다는 멘트였습니다.

현재 생성할때와 같은 권한 문제로 나왔습니다.

• PVC 생성 단계에서 해당 에러 발생

Warning ProvisioningFailed 11s ebs.csi.aws.com_ebs-csi-controller-c45779884-mtfw7_1c5bf2bd-af5f-40e3-a7da-100501981141 failed to provision volume with StorageClass "ebs-dev-sc": rpc error: code = Internal desc = Could not create volume "pvc-a030ad78-9443-4cdf-b45b-bbd8218208c5": could not create volume in EC2: operation error EC2: CreateVolume, get identity: get credentials: failed to refresh cached credentials, failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: 3d81d39c-6fd4-4844-8381-acc7ff860182, api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity

 

실제로 기존 동적이었던 pvc를 백업하고 나서 삭제하고 실제 EBS볼륨도 삭제하여 생성 테스트했는데도 비슷한 권한에 대한 증상이었습니다.

 

음 이게 기존 잘쓰다가 k8s업데이트과정 이후에 발현되서.... 그 과정에 ebs csi의 업데이트가 있던건데...  결론적으로는 기존 잘되던 부분에서 권한(IRSA)에 추가로 더 넣어야 했던 부분이 생긴걸로 생각합니다. 업데이트이후에 대한 권한이...더 필요했던거같네요..

 

- 해결 방법

[현재환경은 AWS SSO를 사용하는 환경 참고]

1. 권한 체크 및 추가(sts:AssumeRoleWithWebIdentity 부분)

EKS->클러스터->추가기능

해당 IAM체킹

신뢰관계추가

- 추가 

EBS는 노드 EC2의 zone이 같아야 한다. (EC2 a-z <=>EBS a-z, EC2 a-z <X>EBS c-z)

EBS 특성에 따른 zone을 지정할때 참고

1. sc로 zone 지정하여 관리

해당 노드그룹의 노드는 a zone임으로 태킹 작업

해당 노드그룹의 노드는 c zone임으로 태킹 작업

 

- 테스트

yaml 준비~

1. ebssc-a.yaml (스토리지클래스생성-zone a)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-dev-sc-a
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - ap-northeast-2a

2. ebssc-c.yaml (스토리지클래스생성-zone c)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-dev-sc-c
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - ap-northeast-2c

3. ebs-pvc-a.yaml (PVC 생성a)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-test-pvc-a
spec:
  storageClassName: 'ebs-dev-sc-a'
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

4. ebs-pvc-c.yaml (PVC 생성c)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-test-pvc-c
spec:
  storageClassName: 'ebs-dev-sc-c'
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

5. test-pod-ebs-a.yaml (기존에 만든 pvc에 연결하는 파드 생성 및 마운트된 경로에 test.txt체크)a

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs-app
spec:
  containers:
  - name: test-app111a
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /test/test.txt; sleep 10; done"]
    volumeMounts:
    - name: test-ebs-mount
      mountPath: /test
  volumes:
  - name: test-ebs-mount
    persistentVolumeClaim:
      claimName: ebs-test-pvc-a

6. test-pod-ebs-c.yaml (기존에 만든 pvc에 연결하는 파드 생성 및 마운트된 경로에 test.txt체크)c

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs-app
spec:
  containers:
  - name: test-app111c
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /test/test.txt; sleep 10; done"]
    volumeMounts:
    - name: test-ebs-mount
      mountPath: /test
  volumes:
  - name: test-ebs-mount
    persistentVolumeClaim:
      claimName: ebs-test-pvc-c

 

 

음 별도의 EC2에 NFS서버를 활용해서 NFS CSI를 쓰는 방법도 좋아보입니다. 왜냐면 EBS csi 는 파드와 N:1 이 안되니...위의 사례는 파이프라인과 1:1 이라 가능한거니 머...

저는 개인적으로 너무 EKS향보다는 K8s향이 좋습니다.

 

무엇이든 기본에 충실 최근 AWS가 빠른업데이트여서 좋기는 합니다만 항상 출구가 있어야 하니 모두 파이팅!~