문제 발생
alb ingress controller를 사용하는 ingress 사용할때 발생할 수 있을 문제이다.
기존에 잘 운영하고 있던 ingress에서 보안을 좀더 강화해보고자 별도의 security group을 annotation에 추가한 후 갑자기 서버에 접근이 되지 않고 504 Gateway time-out이 나타났다 😈
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: "internalIngress"
namespace: "default"
annotations:
alb.ingress.kubernetes.io/security-groups: sg-0000xxxx
...
물론 위의 예시와 같이 미리 만들어 둔 security group을 참조하도록 하는것이 아니라 아래처럼 security group의 inbound 를 모두 정의할 수도 있다.
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}, {"HTTP": 8080}, {"HTTPS": 8443}]'
원인 파악
로드밸런서에서 security group을 추가하면서 apiVersion도 변경하고 private에서 public으로 변경하는 등 변경점이 꽤 있었기 때문에 어느 부분때문에 문제가 생기는지 파악하기가 어려웠다.
일단 로드밸런서에서 파드로 트래픽을 보내주지 못하고 있는건지 파드에서 정상값을 리턴해주고 있지 못한건지 확인을 하기 위해
먼저 svc에서 생성된 endpoint ip가 pod의 ip를 정상적으로 가지고 있는지 확인을 했다. (svc -> pod 체크)
또 pod에 설치되어 있는 nginx의 access log를 살펴봄으로써 pod로 트래픽이 잘들어오는 지를 확인했다. 그런데 아무런 로그가 찍히고 있지 않는 것으로 보아 로드밸런서에서 통과하고 있지 못하고 있다고 생각했다.
그리하여 로드밸런서쪽 메트릭을 보니 위의 화면 처럼 5XX 응답값이 높다고 나왔다.
그럼 로드밸런서는 파드쪽으로 헬스체크는 가능한지 확인해보고자 타겟그룹의 상태들을 확인하였는데 여기서 모두 unhealthy 상태인 것을 확인했다.
문제 해결
원인을 파악했으니 문제를 해결해야겠는데, 여기서 또 오랜 시간동안 삽질한 끝에 수동으로 추가한 security group은 alb controller가 관리해주지 않는 다는 것을 알았다.
즉, security group을 지정해주지 않으면 alb-controller가 cluster security group의 inbound에 해당 로드밸런서로부터 통신이 가능하도록 로드밸런서의 security group을 자동으로 추가해준다. 하지만 security group을 수동으로 지정해 주었기 때문에 cluster security group쪽에서 로드밸런서 sg가 추가되지 않았고, 로드밸런서가 노드로 헬스체크하는데 실패하여 unhealthy상태로 빠져 504 gateway가 떴던 것이었다.
EKS > cluster 선택 > Networking > Cluster security group 에 있는 security group의 inbound로 로드밸런서의 security group을 inbound로 추가해주면 된다.
여기서 포트를 추가할 때 ingress가 instance type 인지 ip type 인지에 따라 달라지는데, instance type인 경우 EC2의 노드 포트를 이용하기 때문에 노드 포트 범위인 30002~32704로, ip인 경우 Health check Protocol에 따라 (보통 80또는 443) 설정해 주면 된다.
ingress annotation에서 다음 부분 확인
alb.ingress.kubernetes.io/target-type: ip
# 별도로 지정하지 않으면 default가 instance 이다.
alb.ingress.kubernetes.io/target-type: instance1) alb target type이 Instance 일때
1) alb target type이 IP일때
