![[CI/CD] AWS EKS 설정 Troubleshooting](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FA83Ar%2FbtsH4GZx27I%2FkLEZrATv6ylr7nzHJ4gXj0%2Fimg.png)
개요
AWS EKS를 사용해서 k8s 환경을 설정하여 CI/CD를 편하게 하고자 하는 과정에서 만난 에러들을 해결할 때 도움되었던 부분들을 기록하고자 한다.
Errors & Troubleshooting
1. 노드에서 생성 가능한 Pod의 한도 초과
상황
Warning FailedScheduling 101s default-scheduler 0/1 nodes are available: 1 too many pods. preemption: 0/1 nodes are available: 1 no preemption victims found for incoming pod.
젠킨스 파드 생성 시 위와 같은 에러를 만나고 나서 여러 방면으로 검색해 본 결과, 이용 가능한 노드에서 생성 가능한 최대 파드의 개수가 초과하여 발생하는 에러라는 것을 알았다.
https://velog.io/@brillog/트러블슈팅-Pod의-volume-node-affinity-conflict-에러-해결
[트러블슈팅] Pod의 "volume node affinity conflict" 에러 해결
에러 메시지 Pod의 status가 'Pending' 상태로 지속되며 정상적으로 뜨지 않아 kubectl describe로 확인해 봤더니 아래와 같이 "volume node affinity conflict" 에러가 발생하였습니다. Pod 상태 확인 에러 메시지
velog.io
위의 링크에서 진행한 프로세스를 통해 필자의 환경에서 확인해 보았다. 젠킨스가 kustomization.yaml에 가장 마지막에 정의되어 있었는데 데몬으로 돌아가는 셋들을 포함하면 앞에서 딱 11개가 끊겼었다. 노드 1개(t3.small) max-pods가 11개여서 pending 상태에서 멈춘 것이었다.
해결
cluster 내 정의한 Node Group 정책에서 기본 인스턴스 생성 개수를 1개에서 2개로 늘려주고 최소 개수를 1개로, 최대 개수를 4로 늘려주는 방향으로 업데이트하였다.
위의 사진과 같이 다른 존(A, B)에 하나씩 생성된 것을 확인할 수 있다. 이후엔 정상적으로 위의 node가 부족하다는 에러는 발생하지 않는다.
2. Volume node affinity conflict
2 node(s) had volume node affinity conflict.클러스터 내 생성된 인스턴스에 매핑된 볼륨, 즉 저장소가 없다는 뜻이다. 그런 일이 발생할만한 경우의 수는 여러 가지가 존재하는데, 필자의 경우 jenkins에서 발생한 에러 기준으로 설명한다.
kubectl get pv
위 명령어로 확인해 보니 PV는 jenkins-pv에 적은 대로 잘 생성된 것을 확인할 수 있었다. 해당 PV는 ebs csi를 통해 스토리지를 할당하도록 되어 있는데 잘 생성되었음에도 불구하고 에러가 생겼다는 것은 액세스에 문제가 있다는 것을 예상해 볼 수 있다.
해결
결론부터 말하자면 Topology Aware Hint를 사용한다.
- Topology Aware Hint란?
https://aws.amazon.com/ko/blogs/tech/amazon-eks-reduce-cross-az-traffic-costs-with-topology-aware-hints/
Amazon EKS에서 Topology Aware Hint 기능을 활용하여 Cross-AZ 통신 비용 절감하기 | Amazon Web Services
Amazon EKS로 클러스터 구성 시 일반적으로 고가용성을 위해서 모든 가용 영역(Availability Zone, AZ)에 워커 노드들을 배치합니다. 클러스터에서 실행되는 Pod들 또한 모든 AZ 에 배포되도록 설정하면 높
aws.amazon.com
🔎 eks topology.kubernetes.io/zone: Google 검색
www.google.co.kr
3. backend service does not exist
kubectl get ingress 명령어를 실행했을 때 나오는 alb DNS 주소로 접속했지만 위의 텍스트가 뜨는 경우가 있다. 필자의 경우 ingress.yaml에 연관된 deployment, service 등에 포함되는 namespace를 설정해주지 않아 service를 인식하지 못한 것이었다.
해결
따라서 ingress의 namespace를 다른 구성요소와 같은 것으로 맞춰주었다.
4. 503 Service Temporarily Unavailable
사실 해당 에러는 굉장히 다양한 이유에서 발생된다. 말 그대로 서버 쪽에 장애가 생겨 제대로 동작하지 않은 것이기 때문이다. 따라서 필자의 해결책과는 다른 상황일 수 있으니 그대로 적용하지 말고 적절히 판단하여 적용하길 바란다. 하지만 결국 네트워크 설정에 문제가 있어 발생하는 것이므로 네트워크 설정이나 k8s 스크립트 구성이 제대로 되어 있는지 한 번 더 확인해 보는 것을 추천한다.
검색 시 나오는 여러 이유들 ex) 네트워크 보안 그룹의 인바운드/아웃바운드 규칙 미설정, 서버 리소스 부족으로 인해 자체적으로 다운된 상태, k8s 스크립트 내 label selector 매칭 안됨(필자의 경우)
해결
jenkins 공식 문서에 있는 k8s 예제를 그대로 긁어오느라 이전에 작성해 뒀던 스크립트와 맞지 않는 부분이 있었다.
service.yaml에서는 spec.selector가 이전에 쓰던 label이었고, deployment.yaml에서는 긁어온 label이 자리 잡고 있어서 서로 인식하지 못하고 있던 것이었다. 그래서 둘 중 하나로 맞춰서 실행시켜 주면 해결된다. 아래 링크를 통해 점검해 보다가 알게 된 사실이었다.
https://repost.aws/knowledge-center/eks-resolve-http-503-errors-kubernetes
Resolve 503 errors when I access Kubernetes in EKS cluster
I get HTTP 503 (Service unavailable) errors when I connect to a Kubernetes Service that runs in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
repost.aws
다시 한번 강조하지만, 필자의 상황과 다른 경우일 수 있으니 kubectl logs와 같은 명령어들을 잘 사용해서 에러 모니터링을 잘 수행하는 것을 추천한다.