Amazon EKS에서 EBS CSI 드라이버를 사용하는 토폴로지 인식 볼륨 프로비저닝을 생성하고 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

Amazon EBS 구성 요소를 사용하는 Amazon EKS에서 클라우드 인프라 토폴로지를 구성하고 문제를 해결하려면 다음 단계를 완료합니다.

1. EBS CSI 애드온이 올바르게 구성되었는지 확인합니다.
2. 스토리지 클래스를 토폴로지 인식 구현으로 구성합니다.
3. 포드와 워크로드를 생성한 다음 토폴로지 인식 시나리오를 테스트합니다.
4. EBS CSI 컨트롤러 오류 문제를 해결합니다.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하는 경우 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

EBS CSI 애드온이 올바르게 구성되었는지 확인

참고: EBS 볼륨 프로비저닝에는 EBS CSI 프로비저너 ebs.csi.aws.com을 사용하는 것이 좋습니다. 또한, 토폴로지 인식 볼륨을 구현할 때는 인-트리 Kubernetes 프로비저너인 kubernetes.io/aws-ebs대신 EBS CSI 프로비저너를 사용합니다.

EBS CSI 애드온이 올바르게 구성되었는지 확인하려면 다음 단계를 완료합니다.

1.    CSI 드라이버가 설치되어 있는지 확인합니다. 설치되지 않은 경우 Amazon EBS CSI 드라이버를 참조하여 CSI 드라이버를 설치합니다.

2.    서비스 계정의 AWS Identity and Access Management(IAM) 역할에 최소 EBS 볼륨 작업 권한이 있는지 확인합니다.

참고: 서비스 계정에 IAM Roles for Service Account(IRSA)를 주석으로 추가해야 합니다. 서비스 계정에 IRSA를 주석으로 추가하지 않으면 기본적으로 Amazon EBS CSI 드라이버가 워커 노드에서 IAM 역할을 맡습니다. CSI 드라이버가 기본적으로 워커 노드에서 IAM 역할로 설정되어 있는 경우, AWS Management Console에서 필요한 IAM 역할 권한을 구성합니다.

스토리지 클래스를 토폴로지 인식 구현으로 구성

1.    다음 명령을 실행하여 스토리지 클래스를 배포합니다. 특정 배포 요구 사항에 맞게 필요에 따라 매니페스트를 편집합니다.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yaml

매니페스트 예시:

참고: 매니페스트의 특성을 사용 사례에 맞게 바꾸십시오.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

참고: 토폴로지 인식 구현을 위해서는 allowedTopologies 옵션을 구성해야 합니다. 이 옵션을 삭제하면 올바른 가용 영역이 유추되고 Amazon EBS CSI 컨트롤러가 포드가 예약된 볼륨을 생성합니다.

2.    다음 옵션 중 하나를 사용하여 pv-claim을 생성합니다.

(옵션 1) 배포된 스토리지 클래스 매니페스트에 지정된 프로파일 유형으로 볼륨을 요청하는 pv-claim을 생성합니다:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml

(옵션 2) 영구 볼륨 매니페스트에 지정된 사용 가능한 EBS 볼륨을 사용하는 pv-claim을 생성합니다. 옵션 **storageClassname:**을 빈 문자열 **, "",**로 변경하고 필요에 따라 nodeAffinity 블록을 수정해야 합니다.

kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifests

참고: 옵션 1 또는 옵션 2의 경우 볼륨의 가용 영역에서 노드를 사용할 수 없는 경우 배포가 실패합니다. 그 이유는 스케줄러가 토폴로지 제한에 맞게 동적으로 조정할 수 없기 때문입니다.

포드와 워크로드 생성 및 토폴로지 인식 시나리오 테스트

포드 생성

1.    이전 pv-claim을 사용하는 테스트 포드를 생성합니다.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yaml

참고: 스토리지 클래스 또는 영구 볼륨 내의 allowedTopologies에서 topology.ebs.csi.aws.com/zone을 사용하는 경우, 포드는 구성 매니페스트에 지정된 가용 영역에 배치됩니다. 해당 가용 영역에 사용 가능한 노드가 없는 경우 포드는 보류 중 상태가 됩니다.

2.    다음 get 및 describe pod 명령을 실행하여 배포 상태를 확인합니다.

kubectl get pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

참고: EXAMPLE_POD_NAME을 포트 이름으로 바꿉니다.

워크로드 생성

1.     다음 명령을 실행하여 이전 pv-claim을 사용하는 statefulSet 워크로드를 생성합니다.

kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml

2.    다음 get 및 describe 명령을 실행하여 statefulSet 워크로드의 상태를 확인합니다.

kubectl get statefulset,pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

참고: statefulSet 컨트롤러는 AWS 리전 us-east-2b 및 us-east-2c에서 볼륨에 대한 포드의 볼륨 요청을 처리하기 위해 여러 pv-claim을 생성합니다. 종료 시 statefulSet은 영구 볼륨을 정리한다는 보장이 없으며 이로 인해 다른 가용 영역으로 재예약된 statefulSet 포드에 대해 볼륨이 다시 프로비저닝되지 않을 수 있습니다.

토폴로지 인식 시나리오 테스트

(선택 사항) 다른 가용 영역에서 노드 교체가 어떻게 처리되는지 테스트하려면 지정된 AZ에서 노드를 스케일 다운하여 노드 재구성을 시뮬레이션합니다. 그런 다음 다른 AZ에서 새 노드를 스케일 업합니다. 완료되면 포드 생성 및 워크로드 생성 섹션을 참조하십시오.

시뮬레이션된 배포 문제에 대한 출력 예시:

from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.

멈춘 포드를 수정하려면 지정된 가용 영역의 노드를 다시 스케일업하여 볼륨 노드 선호도 충돌 오류를 해결합니다.

참고: 예상 가용 영역에서 새 노드를 확장할 때 조정기 실행 실패로 인해 배포가 실패할 수 있습니다. 문제 해결 단계는 다음 섹션 EBS CSI 컨트롤러 오류 문제 해결을 참조하십시오.

EBS CSI 컨트롤러 오류 문제 해결

포드 변동 및 노드 재활용을 시뮬레이션한 EBS CSI 오류 예시:

from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate

1.    포드를 설명하고 이벤트의 오류 로그 항목을 검토하여 문제를 격리합니다. 앞의 오류 예시에서 노드 오염 및 토폴로지 또는 선호도 구성으로 인해 5개 노드 중 4개를 예약할 수 없다는 메시지가 표시됩니다. 또한 올바른 가용 영역에서 실행 중인 마지막 노드가 바인드할 사용 가능한 영구 볼륨을 찾지 못했습니다.

2.    pv-claim 바인드의 상태를 확인하여 이 문제를 격리합니다.

kubectl describe persistentvolumeclaim <PVC_NAME>

참고: pv-claim 상태는 대기 중, 바인딩됨, 잘못됨 또는 찾을 수 없음입니다. 다음 예시에서 pv-claim은 드라이버가 볼륨을 생성하기를 대기하고 있습니다. 대기하는 동안 pv-claim은 타겟 노드에 바인드되지 않습니다.

`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  
`waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`

3.    ebs-csi-controller 포드의 csi-provisioner 컨테이너 로그를 확인합니다.

kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-system

다음 출력은 오류 이벤트 예시입니다.

Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not found

참고: 앞의 메시지와 비슷한 오류 이벤트가 발생하면 pv-claim 조정자가 선택된 타겟 노드 어노테이션을 찾지 못한 것입니다. pv-claim이 동기화할 수 있도록 이 어노테이션을 삭제합니다.

4.    선택된 타겟 노드 어노테이션을 제거하려면 다음 명령을 실행합니다. 선택된 노드 어노테이션을 제거하려면 출력을 복사하여 pv-claim 매니페스트에 저장해야 합니다.

kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"

진행 중인 문제 해결 단계로도 문제가 해결되지 않으면 격리된 컨테이너 워크로드에서 로그를 수집하고 AWS Support에 문의합니다. GitHub 리포지토리에서 관련 문제를 검색할 수도 있습니다.