ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 험난하고 험난한 Datahub - EKS Trouble shooting: prerequisites-cp-schema-registry pod CrashLoopBackOff 해결하기 (EBS CSI Controller 설치)
    Project/D.D.P (Datahub) 2023. 3. 27. 21:20
    728x90
    반응형

    EKS 구축하는 동안 제일 많이 한 말이 아늬...왜 안되냐고... 인 것 같다. 자꾸 파드가 죽고, 그러다 갑자기 지 혼자 살아나고, 그러다 다시 죽어있고..... 아니.. HA때문에 EKS 쓴다면서요.. 내 클러스터는 가용성 왜 이런데..

     

    문제 상황

    • prerequisites-cp-schema-registry-xxx 파드: CrashLoopBackOff
    • elasticsearch-master, prerequisites-kafka, prerequisites-mysql, prerequisites-zookeeper 파드: Pending

     

    문제 원인 파악

    0. 진정하기 (이제 crashloopbackoff만 봐도 화남)

     

    1. 파드에 문제가 생기면 일단 describe 확인 -> log 확인으로 문제 원인을 알 수 있다.

    kubectl describe pod prerequisites-cp-schema-registry-xxxx -n datahub

    describe의 맨 마지막 events 부분을 확인한다.

    보면 스케줄링 잘 됐고, 이미지 가져오는데도 문제가 없었다. 마지막에 warining이라고 되어있는데, 워닝은 가볍게 무시해주는게 국룰이지만 메세지가 back-off restarting failed container, 즉 failed container 재시작 지연 - failed container가 있다는 뜻이다.

    그렇다면 해당 컨테이너의 로그를 확인해본다.

     k9s로 해당 파드의 컨테이너 중 cp-schema-registry-server에 문제가 있는 걸 확인했다. kubectl로는 다음 명령어로 log를 확인할 수 있다.

    kubectl logs -c cp-schema-registry-server -f prerequisites-cp-schema-registry-xxxx -n datahub

    여러 줄이 자바 에러 메세지와 섞여서 나오지만 당황할 필요 없다. Error만 거슬러 올라가면 된다.

    가장 마지막 에러는

     

    [main] ERROR io.confluent.admin.utils.ClusterStatus - Expected 1 brokers but found only 0. Brokers found [].

     

    이다. 그럼 브로커를 못 찾았다는 뜻이니 왜 브로커를 못 찾았는지 거슬러 올라가면

     

    prerequisites-kafka/{서비스 ip주소}:9092 could not be established

     

    라는 메세지를 찾을 수 있다. 즉, prerequisites-kafka와 통신을 하지 못하기 때문이다.

    아까 보았듯, prerequisites-kafka는 pending상태이다. 해당 pod와 종속성이 있어 발생한 문제이므로 근본 원인은 해당 Pod의 pending 상태를 해결해야하고, 보아하니 나머지 pending상태인 친구들도 같은 이유일 것 같다.

     

     

    다음으로 prerequisites-kafka의 describe를 확인해본다.

    volume을 binding하다가 timeout error가 발생해서 스케줄러에 올라가지 못했다. 따라서 volume을 마운트하도록 해결해주면 된다.

     

    문제 해결

     "EKS binding volumes time out"으로 검색했을 때 가장 먼저 나온 stackoverflow 글을 통해 EBS CSI driver가 있어야 하고 이를 위해서 EBS CSI Controller와 관련 서비스 계정이 있어야한다는 것을 알았다. 설치하는 방법은 AWS 공식 문서를 참고했다.

     

    1. EBS CSI controller 파드를 위한 IAM policy 생성 - 클러스터 이름 부분에 클러스터 이름을 넣어주고, 혹시 aws config의 region과 다르다면 --region 옵션도 추가해준다.

    eksctl create iamserviceaccount \
      --name ebs-csi-controller-sa \
      --namespace kube-system \
      --cluster [클러스터이름] \
      --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
      --approve \
      --role-only \
      --role-name AmazonEKS_EBS_CSI_DriverRole

    2. 컨트롤러 설치를 위해 git repo를 clone한다

    git clone https://github.com/kubernetes-sigs/aws-ebs-csi-driver.git

    3. kustomization.yaml 파일에서 리전명을 클러스터가 있는 리전으로 변경해준다.

    cd aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/ecr && vi kustomization.yaml

    4. EBS CSL controller를 배포한다.

    kubectl apply -k ../ecr

    5. 아까 생성한 ebs-csi-controller-sa 서비스 어카운트에 주석을 지정한다.

    kubectl annotate serviceaccount ebs-csi-controller-sa \                                                                                                                                                                                                ✭
        -n kube-system \
        eks.amazonaws.com/role-arn=arn:aws:iam::[AWS 계정 번호]:role/AmazonEKS_EBS_CSI_DriverRole
    serviceaccount/ebs-csi-controller-sa annotated

    6. EBS CSI controller를 재배포한다.

    kubectl rollout restart deployment ebs-csi-controller -n kube-system

     

    해결

    kubectl get all -l app.kubernetes.io/name=aws-ebs-csi-driver -n kube-system

    위 명령어를 입력했을 때 다음과 같이 EBS CSI controller 리소스들이 출력되면 정상적으로 배포가 된 것이다. 이게 배포되고 얼마 있으니 자동으로 pending되었던 pod들이 배포되었고, prerequisites-cp-schema-registry 파드도 잘 배포되었다.

    728x90
    반응형

    댓글