클라우드 개발자 앙몬드

5년 넘게 했던 쿠버충 운영을 접은 뒤, 대략 4달정도는 애저 네이티브로 엔터프라이즈급 클라우드 죄다 올렸었댜. (뭐 운영환경 그래봤자 머신 수 15개 내외임 ㅋㅋ) 

뭐 더 파볼 것도 있긴 한데, 디테일한 것은 접은 뒤.. 향후 긴 기간 동안은 AI 쪽에 대해서 좀 알아볼 까 한댜.

아 그리고 애저 아키나 뭐 디테일한 옵션 등등에 대해서는 따로 글은 안팔거임.. 굳이 팔 이유는 없을 것 같댜.

AWS 정글만 7년 썼는데, 굳이 애저는 뭐가 어떻고 뭐가 다르다는 것으로 글 쓰는데에는 의미가 없는 것 같음.

그리고 쿠붕이 대다수가 아마 AWS로 시작해서 이미 장기간 사용해왔다면, 별도로 글 찾아볼 이유는 없을거임.

걍 니들 케이스 열어서 직접 하나씩 헤딩해가면서 해보셈 ㅇㅇ 

무튼.. 나도 이제 쿠버충 접고 AI로 입문합니댜

안녕

클라우드 개발자 앙몬드댜

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

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

(광고 수익아 올라가라)

오늘 얘기해볼건 하나의 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로 전환할거임 ㅇㅇ 

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

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

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

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

뭐지 하면서 고민해봤댜

제목을 보고, 내가 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 쓰면서 스파이크 트래픽 밸런싱 안되면 반드시 의심해봐라 ㅇㅇ 

너님들 아마 이거 글 찾아 들어왔으면,

우선 아르고CD를 이용해서 인클러스터 (니 아르고CD가 위치한 로컬 쿠버 클러스터) 외에,

타 어카운트 혹은 동일 어카운트 EKS 클러스터로, 앱 배포를 하려는 것일거임 ㅇㅇ 

그리고 니들 이 글 읽고 있으면, 아마 다른 페이지 아르고 멀티 싱크 참조글이 니들 환경에서 동작 안하거나 공식홈피 번역 힘들어서, 마지막으로 여기까지 들어왔을 가능성이 매우 농후함.

ㄱㅊ 그림으로 풀어서 설명해줄게. 우선 본론부터 들어가진 말자.

너님들도 이거 해보려고 여러 페이지 찾아보고, 오피셜도 분명 찾아봤을거임.

대충 우선 이 2개 오피셜은 기본적으로 찾아봤을 테고.

https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/declarative-setup.md#clusters

https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters

둘다 같은내용. 근데 글만 띠리릭 적혀있고 영어로 뭐시기 뭐시기.

근데 설명을 좀 난잡하게 해놨다. 친절하지 않게, 그냥 글만 주루룩 적어놓았다. 

영알못이면 ㄹㅇ 힘들 수 있음. (ㄱㅊ 나도 영어 거의 다 까먹음. 그래도 아직까지 나는 기계번역이 필요치는 않음 ㅅㄱ)

그래서 내가 번역을 해올까 하다가, 이거 찾으러 들어온 사람들 어차피 번역글엔 관심도 없어보일게 뻔하지 않겠냐?

"아 그냥 어떻게 하면 되는지 코드나 내놔" 

다들 이러겠지 ㅇㅇ; 

그래서 아예 그냥 구성요소랑 그림 한장으로 요약해주겠음.

이거 보고서 구현하셈. 쿠버 매니페스트나 IAM json 코드까지는 안내놓을거다. 그래도 설정코드까지는 직접 넣어봐야지 니들 내공에 좀 들어가지 않겠음?

아 나는 그래도 구현이 힘들다하면 비밀글 달아라. 코드 줄게 ㅇㅇ

아르고 문어대가리 멀티 싱크 설정하면서 느낀건데 웬만하면 출발지에서 쓰일 IAM이랑, 목적지 IAM 분리해라.

멀티어카운트로 가야 하는데, 니 만약에 IAM 하나만 쓰고서 서비스 런칭했다고 가정하면, 분리할 때 괜히 고생길 열릴 수 있음.

원래 잘 쓰고 있던 헬름차트 바이너리 (지금 3.12) 를, kube config 컨텍스트 좀 만지작 거리면서 놀다보니

다음과 같은 에러가 뜨기 시작함.

Error: Kubernetes cluster unreachable: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"

> 어제까지만 해도 잘 쓰던 헬름 애가 갑자기 찡찡댐

> 웃긴거는 그냥 kubectl 바이너리는 아무 문제 없음. 헬름 버그 스멜 의심됨.

대충 이슈 찾아보니 나만 겪은건 아닌거 같음.

github 에서 공식 레이즈되었던 이슈이기도 함.

https://github.com/helm/helm/issues/10975 

영어 울렁증 있으면 대충 아래 커맨드로 해서, 3.8 버전으로 다운그레이드 한 다음 헬름 업스톨 해보셈.

나는 풀렸음.

curl -L https://git.io/get_helm.sh | bash -s -- --version v3.8.2

아 참고로, 헬름 마이너 버전 차이에 따라서 헬름차트 value가 어떤건 박히고 어떤건 안박히는게 있음.

helm diff 플러그인 꽂아서 꼭 헬름 업스톨 전에 차이여부 확인해보셈.