roki_1213

안녕하세요!

특정 서비스에서 NLB + ALB를 사용하여 고정 IP 및 타켓 라우팅 규칙을 사용하는 예시를 공유 드립니다. 

(구조에 리스닝, 타켓을 개념을 잘 분리해서 작업하면됩니다)

저는 처음에 아래 구조를 보면서 고정IP는 사용이 가능하지만 라우팅 규칙을 사용이 불가능 할 것이라고 생각했습니다..

이유는 NLB L4 에서는 도메인 호스트 (test80.test.com, test81.test.com)을 인식할 수 없다고 생각하여 루프가 발생하는게 아닌가 했습니다.....

하지만 공식 문서에서 지원을 하다고 되어 있습니다! (추정하는것 보다는 테스트 정답 같습니다 ㅠㅠ)

구조

  Router 53 대상(NLB)→ NLB → ALB → 서버 (Nginx 2개 81, 80)

NLB 구조

   리스닝 : 80, 443

   타켓그룹: ALB 80, 443

ALB 구조

   리스닝 :

      80 규칙:

        모든 요청 https 라우팅

      443 규칙:

        test80.test.com → 서버 80 포트

        test81.test.com → 서버 81 포트

개인적으로 테스트한 내용으로 틀린 정보가 있을 확률이 매우 높습니다. 

운영에 적용 전 따로 테스트가 필요합니다.

배포로인한 서비스 연속성(인바운드 트래픽 유실, 아웃바운드 트래픽 유실, 어플리케이션 안정성)에 이슈가 발생하지 않게 하는 것이 중요합니다.

하기 내용은 AWS 환경에서 동작한다는 기준으로 작성했습니다.

배포 진행 시 이슈 (502, 504 발생)

1. 신규 파드에 느린 어플리케이션 시작 (트래픽을 받을 상태가 아닌 상황)

2. 기존 파드에 종료 ( 타켓그룹에서 계속 트래픽을 전달함, 기존 어플리케이션에 정상적인 종료가 안된 상태)

위에 이슈를 조치하기위해 ReadinessGates 를 사용해야됩니다. (aws alb controller사용한다는 기준)

자세한 가이드 (https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/deploy/pod_readiness_gate/)
 

ReadinessGates를 사용할 경우 (트래픽을 받을 상태가 아닌 상황, 타켓그룹에서 계속 트래픽을 전달함)을 조치할 수 있습니다. 

하지만 "기존 어플리케이션에 정상적인 종료가 안된 상태"는 조치가 되지 않습니다.

위에 이슈를 조치하는 방법은 preStop, terminationGracePeriodSeconds, alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds= 30 예시

참고 블로그 

https://waspro.tistory.com/682

https://pmh.codes/kube/

Cloudfront 멀티 index.html 설정 방법을 기록해보겠습니다.

cloudfront 함수를 사용하고 구현합니다.

함수

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html

구성 방법

Cloudfront 함수 생성 -> JavaScript runtime 2.0 으로 구성 -> 배포(Cloudfront 선택) -> 뷰어 요청에 생성한 함수 연결 -> 끝