EKS 503 탈출기

EKS를 처음 구축하고 나를 반겨준 화면은 단연 503 Service Unavailable 이었다. ㅠㅠ 문제의 원인은 Pod, Service, Ingress 혹은 이미지 자체에 있을 수 있다.

문제점을 찾기 위해서 아래와 같은 순서대로 확인했다.

Pod가 정상 동작 중인지 확인

먼저 pod가 동작 중인지 확인한다.

1
2
3
4
5
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
shipda-api-v2-7b45cdf6df-7hfsk 1/1 Running 0 2d12h
shipda-api-v2-7b45cdf6df-b8hzq 1/1 Running 0 2d12h
shipda-api-v2-7b45cdf6df-v24vh 1/1 Running 0 2d12h

뭐 다들 정상 동작중이니 이미지를 확인해본다.

이미지 검사

Pod에 올라간 도커 이미지가 진짜로 제대로 도는지 확인해본다. 다만 이는 Health Check를 잘 만들어놨다면 좀 쉽게 체크할 수 있다.

1
kubectl port-forward pod/shipda-api-v2-7b45cdf6df-7hfsk 8080:8080

해당 Pod의 8080포트를 localhost 8080 포트에 바인딩시킨다. 그 후 로컬호스트의 8080포트에 대고 API를 테스트해본다.

여기까지 문제가 없으면 Service 혹은 Ingress가 문제다.

서비스

원인은

  1. 인그레스가 서비스를 못찾거나
  2. 서비스가 Deployment 를 못찾거나

이 둘 중 하나로 좁혀졌다. 하지만 어디서 문제인지 도통 알 수가 없었다. 그래서 옆에 곰돌이를 앉혀놓고 다시 한 번 서비스를 확인해본다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ kubectl describe service -n shipda
Name: shipda-api-v2
Namespace: shipda
Labels: <none>
Annotations: kubectl.kubernetes.io/
Selector: run=shipda-api-v2
Type: NodePort
IP: 10.100.75.73
Port: <unset> 80/TCP
TargetPort: 8080/TCP
NodePort: <unset> 30888/TCP
Endpoints: 172.31.1.205:8080,172.31.21.125:8080,172.31.39.55:8080
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>

deployment는

1
2
3
4
5
6
7
8
9
apiVersion: apps/v1
kind: Deployment
metadata:
name: shipda-api-v2
labels:
app: shipda-api-v2
namespace: shipda
spec:
...

곰돌이에게 deployment의 metadata를 설명하다가 갑자기 뜨얽!
Deployment에서는 label을 app: shipda-api-v2 로 해놨는데 Service Selector는 run: shipda-api-v2 로 해놓았던 것이었다!

따라서

잉그레스 -> 서비스 -> 디플로이먼트

이렇게 흘러가야할 트래픽이 서비스에서 디플로이먼트로 흘러가지 못해서 503에러가 발생했다. 왜 selector를 run으로 한지 이유는 모르겠지만…

같은 VPC인데도 EKS에서 RDS 연결 안될 경우

AWS의 Kubernetes 서비스인 EKS를 구성할때 겪었던 일이다.
EKS와 RDS를 같은 VPC 안에 두었음에도 불구하고 EKS에서 RDS로 연결이 되지 않고 계속해서 타임아웃에러만 발생했다.

이 경우 먼저 Pod에서 RDS 주소를 인지하는지 먼저 확인했다.
먼저 Pod 이름 먼저 확인

1
$ kubectl get all -n shipda

파드 이름이 pod/shipda-api-v2-79d868d65-2kh4t 이라 한다면 pod에다 nslookup 명령어를 실행시킨다.

1
2
3
4
5
6
7
8
9
10
11
$ kubectl exec -it pod/shipda-api-v2-79d868d65-2kh4t -n shipda nslookup <blahblah>.rds.amazonaws.com
Server: 10.100.0.10
Address: 10.100.0.10:53

Non-authoritative answer:
<blahblah>.rds.amazonaws.com canonical name = <blahblah>.ap-northeast-2.compute.amazonaws.com
Name: <blahblah>.ap-northeast-2.compute.amazonaws.com
Address: 111.111.111.111

Non-authoritative answer:
<blahblah>.rds.amazonaws.com canonical name = <blahblah>.ap-northeast-2.compute.amazonaws.com

DNS 를 리졸빙 하는걸로 봐서는 DNS는 문제 없는것 같다. 그러면 실제로 접속이 되는지 핑을 날려본다.

1
$ kubectl exec -it pod/shipda-api-v2-79d868d65-2kh4t -n shipda ping <blahblah>.rds.amazonaws.com

핑이 가지 않았다. 해결 방법을 한참 찾았다. 같은 VPC라서 문제 없을 줄 알았는데 뒤통수 맞은 기분이었다. 사실 프로덕션으로 GCP와 Azure는 썼었는데 AWS는 처음이라 좀 더 헤맸을수도 있다. 사실 요즘 클라우드가 다들 엇비슷해서 있을거 (거의) 있어서 적응에는 큰 문제는 없지만 아마존 같은 경우엔 VPC, Security Group, Subnet, RoutingTable 등을 좀 더 세밀하게 지정해야 하기 때문에 헤맸을 수도 있다.

결국 해결책은 -

RDS의 시큐리티 그룹에 EKS의 시큐리티 그룹을 넣어주면 해결되는 일이었다.

뭔가 굉장히 허탈하다. 참고로 다른 VPC라면 VPC 피어링을 사용하면 된다.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×