클라우드 개발자 앙몬드

안녕

클라우드 개발자 앙몬드댜

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

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

(광고 수익아 올라가라)

오늘 얘기해볼건 하나의 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/

드디어 스태틱 IAC 떼어버리고, 다이나믹 IAC로 전환할거임 ㅇㅇ 

테라폼보다는 확실히 코드 런타임으로 인프라 구성시키는게 개발자들 입장에서도 러닝커브가 덜할 것이 분명하기 때문 ㅇㅇ 

원래부터 테라폼 문법을 싫어하기도 했고, 이상하게 다들 이겁니드아! 하면 꼭 반례자료 찾아서 드라이브 잘만하는거를 보여주고 싶거든 ㅇㅇㅇ