EKS ALB ingress 로 크로스네임스페이스를 구현해보쟈

안녕

클라우드 개발자 앙몬드댜

뭐 동시에 데브옵스 엔지니어가 주력이긴 하댜 ㅇㅇ 

 

잡설 치우고 오랜만에 글좀 싸러 왔댜

(광고 수익아 올라가라)

 

오늘 얘기해볼건 하나의 alb ingress 를 이용하여, 각기 다른 네임스페이스에 위치한 어플리케이션 deployment로 트래픽을 전달하는 것이댜.

 

일반적으로, ALB 인그레스 인스턴스가 생성되면 (니 실제 AWS ALB임) 특정 네임스페이스에 종속되면서, 해당 네임스페이스에 위치한 파드로만 트래픽을 전달할 수 있댜. 

다시 말하면, 니 ALB 인그레스가 X 네임스페이스에 위치한다면, X 네임스페이스에 위치한 파드로만 전달할 수 있다는 얘기임. Y 네임스페이스에 위치한 파드로는 전달 못함.

그래서 일반적으로는, X 네임스페이스에 위치한 인그레스 1개. 그리고 Y 네임스페이스에 위치한 ALB 1개. 이렇게 따로따로 선언한댜.

근데 문제가 당연히 있지?

>>> 동일한 도메인명을 가지면서, path별로 분리할 경우 어떻게 할 것인지?

 

뭐 정답은 뻔하다.

1. 그냥 네임스페이스 분리 포기하던가.

2. 니 클라이언트랑 쇼부봐서 호출 도메인 전부 다르게 가져가면서 ALB 분리시키던가.

 

하지만, 이 2개를 한번에 해결할 수 있는 ALB 옵션이 있댜.

metadata:
  annotation:
    alb.ingress.kubernetes.io/group.name: "쿠붕이들이_원하는_이름으로_픽스"
  name: "x인그레스"
  namespace: "x"
  
  
......

metadata:
  annotation:
    alb.ingress.kubernetes.io/group.name: "쿠붕이들이_원하는_이름으로_픽스"
  name: "y인그레스"
  namespace: "y"

당연히 kind니 apiVersion은 다 고정인거 알제? 

spec에 정의되는 path는 알아서 분리시켜라.

 

이렇게 하면, ALB가 1개로만 선언되면서, spec에 동일 도메인 호스트 집어넣은 뒤 크로스 네임스페이스가 가능해진댜.

 

그러면 여기서 하나 의문점이 또 생기지.

>>> 굳이 왜 네임스페이스 나눔? 그냥 다 통일하면 안됨? ㅇㅇ

 

쿠버네티스에서 네임스페이스 분리는 생각보다 중요한 의미를 가짐.

우선 리소스들 다 배포된 상태에서, 네임스페이스 지우면 그 위에 위치한 모든 오브젝트 다 날아가는거 알제? 

(모르면 한번 지워봐. kubectl delete namespace ㅋㅋ)

 

그리고 일반적으로 메트릭 수집할 때, 프로메테우스 기준으로 네임스페이스 분할하여 해당 메트릭을 쉽게 조회할 수 있댜.

대충 뭐 스테이트풀셋 STS는 고정적인 이름에 인덱스만 붙지만, 일반적으로 deployment를 쓰잖아 앱들은?

그거 워크로드명 해쉬값으로 선언되기에 메트릭 패널 가져다 붙이는게 ㄹㅇ 귀찮음.

 

또 메트릭 외에, 로그 조회할 때도, 아마 니 사이트들의 쿠버충 데브옵스충들이 네임스페이스로 로그조합해서 ES에 쑤셔넣을텐데, 그 로그 조회할 때도 네임스페이스 필터만 주어도 니들 앱 로그 쉽게 조회 가능함.

 

다시 말하면, 네임스페이스를 분리할 때 니들 서비스 운영 안정성과 유틸리티 사용 편의성이 훨씬 쉬워진다는거임.

난 그래서 지금까지 앱들 죄다 네임스페이스 분리시켜둠 ㅇㅇ 

다시 말하지만, 난 극단적으로 뺀질거리는 닝겐인지라 ㅇㅇ 

 

상세 아키텍처는 아래 아마존 정글러 페이지를 보셈 (우리 정글 뭐함?)

https://aws.amazon.com/ko/blogs/tech/a-deeper-look-at-ingress-sharing-and-target-group-binding-in-aws-load-balancer-controller/

AWS 로드 밸런스 컨트롤러의 Ingress 공유 및 대상 그룹 바인딩 자세히 살펴보기 | Amazon Web Services