NKS - 인그레스와 로드밸런서

NKS를 구성하기 위해서 이해없이 가이드만 보고 쭈욱쭈욱 설정을 진행했다. 

이해 없이 사용하기 위해서 매니지드 서비스가 존재한다고 생각한다. 하지만 운영을 하기 위해선 개념적 이해가 필요하다.

 

전체적으로 다시 한번 이해를 해보고자 한다. 특히 인그레스와 서비스(로드밸런서)의 개념을.

 

쿠버는 자신의 리소스를 관리하는 지휘자이다. 지휘자는 전체적인 리소스를 밸런싱을 해준다.

그 리소스 중 파드(POD)는 "일회성" 자원(리소스)이다. 이 말은 파드의 생명주기를 다하면 끝이라는 이야기다.

 

즉 파드는 재기동(리부팅)의 개념이 아니라 기존 파드는 사라지고 새로운 파드가 생성된다는 것이다.

 

new 생명이 올 때마다 ip도 new가 된다!!.. 띠용

이런 상황에서 파드 IP의 길잡이를 해주는 리소스가 "서비스(Service)"라고 보면 된다.

 

※ 모든 파드는 "서비스"를 통해서 데이터를 주고 받는다고 이해를 하면 된다.

 

서비스는 특정 노드에 종속되어서 생성되는 것이 아니라 k8s 내에 관리는 되는 가상 모듈(컴포넌트)이기 때문에

어떤 노드에 파드가 생기더라도 "서비스"가 파드의 새로운 주소를 알고 있기 때문에 라우팅에 문제가 없다.

(사실 서비스가 알고 있는것이 아니라 파드가 알려주는 것이라고 한다. 해서 파드를 먼저 생성하고 서비스를 나중에 생성하면 맵핑이 안된다 한다? 테스트는 안해봤다.)

 

서비스는 기본적으로 내부 IP를 가진 ClusterIP 모듈이다. 이것을 외부로 노출 시키려면 NodePort 얹으면 된다.

그리고 LoadBaiancer 모듈는 있는데  "로드 밸런서 프로비저닝"을 지원하지 않는 환경이라면 단순 NodePort 형태로 동작한다.

마지막으로 ExternalName 모듈이 있다. 다른 공간의 네이밍을 가진 파드에 연결하고자 할 때 사용한다.

 

로드 밸런서의 프로비저닝은 각 클라우드 벤더사마다 지원해 주는데 비용이 발생하는 녀석이다.

 

비용이 발생하는 부분으로 하나의 로드밸런서를 두고 하위에 라우터 역할하는 하는 "서버"를 만들면 된다.

근데 해당 기능이 이미 인그레스라는 타입으로 제공된다.

 

노드3개는 최소 사양으로 구성했다. ㅎ 소규모(하루 로그인 약 1000명)로 서비스하기에 충분하다. 스펙이 오히려 남는다!!!

 

로드 밸런서는 밸런싱을 할 타겟그룹을 정하고 로드에 연결하면 설정된 방식으로 밸런싱을 하게 된다.

 

근데 LB 뒤에 인그레스 콘트롤러를 두면....부하분산이 안된다 당연한 말이겠지....

 

결국 해당 lb는 외부 노출용인 것이다. 부하 분산이 안된다!.. 물론 인그레스 콘트롤러가 두개라면 늘리면...인그레스에대한 부하를 분산해주겠지...근데 의미가 있노??

뭐 어차피...쿠버네 서비스들이 밑단 서비스 분산을 해주는데..?

 

※ k8s에서 LB의 역할은 단순 외부 노출용도 그 이상 그 이하도 아닌듯하다.

 

k8s가 아닌 일반 아키텍쳐(3-tier)에서는 LB의 역할을 100%로 발휘 할 수 있다. 

 

괜히 쿠버쿠버하는것이 아닌듯요...

 

 

## 참고

[Kubernetes] # 쿠버네티스 네트워크 구성도

쿠버네티스에서 반드시 알아야 할 서비스(Service) 유형