로드밸런싱 관련 질문드립니다

대세는 쿠버네티스 [초급~중급]

Ingress - Nginx

작성

296

Service로 로드밸런싱을 해도 되고 Ingress로 로드밸런싱을 해도 될 것으로 생각되는데 각각 어떤 장단점을 가질까요?

무엇보다, Service가 이미 로드밸런싱 가능한 오브젝트인데 Ingress라는 걸 앞에 한단계 더 붙여야 할 필요성이 아직 와닿지 않아서 질문 드려봅니다!

답변 2

질문자

우선, 제가 이해한 내용은 이렇습니다!

(예시를 기준으로)

각 Pod 앞에 붙인 Service는 로드밸런싱 용도가 아니고 그저 Pod으로 가는 길목에 불과하므로 여긴 로드밸런싱을 따질 필요가 없는 부분이고
Ingress Controller 앞에 붙는 Service가 로드밸런서 역할임. 물론 이는 로드밸런싱이 가능하겠지만 로드밸런싱을 하더라도 Ingress Controller Pod에 대한 로드밸런싱이지 실제 서비스에 대한 로드밸런싱이 아님
결국, 이런 구조에서 Service(Ingress Controller을 위한 Service든, 실제 페이지를 위한 Service든)가 실제 페이지를 위한 로드밸런싱을 해줄 수는 없고 Ingress가 로드밸런서가 되게 됨

지식공유자

Hyunsang Han님께서 잘 답변해 주셨고요. 감사합니다.

추가로 내용을 덧붙이자면,

로드밸런싱이라는 기능에 단순이 분배의 역할만 있지는 않습니다.

분배를 할때도, 랜덤분산, 부하가중치분산, 응답속도분산 등 여러 방식이 필요하고

트래픽 제어나 관리 등 많은 기능을 사용합니다.

이런 모든 기능들을 제공해주는게 Ingress단에 Nginx와 같은 로드밸런서 구현체입니다.

Service 오브젝트에도 약간의 로드밸런서 기능들은 있지만, 목적 자체가 Kubernets 상에 Pod라는 오브젝트와 연결고리를 만들어 주기위한 역할입니다.

전체적인 시스템, 여러 App들간의 트래픽 관리, 통제, 이런 큰 틀에서 봤을때 Ingress의 역할은 별도로 필요한 부분입니다.

각각의 기능들만 봤을때는 굳이 많은 기능 필요없고, 비슷해보이는데 안써도 되지 않을까 생각이 들지만,

실무 프로젝트에 들어가면, Ingress를 안쓴다는거 자체가 말이 안되는 상황이 됩니다^^

인프런 커뮤니티 질문&답변