클라우드 개발자 앙몬드

안녕

클라우드 개발자 앙몬드댜

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

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

(광고 수익아 올라가라)

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

오랜만에 글좀 정리하러 왔음

쿠버네티스에 스파이크 트래픽이 들어오면, 이상하게 한쪽 파드로만 쏠리는 증상이 있댜

뭐지 하면서 고민해봤댜

제목을 보고, 내가 nginx ingress 글 자주 올리는거보면 대충 구조 어떤지 글 쓰는 사람들은 알거임.

LB (L4) > Nginx_POD > EN_service > POD

왜 이딴 구조로 했냐면, LB가 반드시 1개의 L4 이면서 네임스페이스가 다른 각기 파드로 트래픽을 전달하기 위한 구조로는, 지금 이 방법밖에 내가 못찾았었음.

L7 LB로 크로스네임스페이스 기법 있긴 한데, 나는 지금 환경에서 반드시 L4를 썼어야함.

그래서 Nginx Ingress로 확장시켜온거임.

근데 EN_Service 를 보면 알겠지만, 이거 결국 내부적으로는 kube dns 쿼리하는데 있어서 coredns가 반드시 동반됨.

이 때 위 구조에서 간혹 문제가 발생함.

일상적이고 점진적인 트래픽인 로드밸런싱이 문제 없는데, 꼭 스파이크성 트래픽에서는 로드밸런싱 못하더라.

의심해볼게 딱 두개다.

- 캐시?

- TTL?

사실 2개 모두 큰 축에선 같은 범주긴 함. 

coredns도 결국 DNS인지라 캐시와 쿼리 설정이 들어감.

너님들도 아마 coredns 글 파봤으면 이거 봤을거임.

https://kubernetes.io/ko/docs/tasks/administer-cluster/dns-custom-nameservers/

그리고 이 부분.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

각 단어의 자세한 의미는 공홈 들어가서 보셈.

여기서 ttl 30초인데, 이거를 그냥 지워버리면? 그냥 ttl 30초로 디폴트임.

이거 비활성화 하려면 반드시 ttl 0으로 지정해줘야함.

ExternalName 쓰면서 스파이크 트래픽 밸런싱 안되면 반드시 의심해봐라 ㅇㅇ