질문드립니다,

뒤에 설명 해주실수도 있지만 컨테이너 오케스트레이션 강의를 듣고 궁금한것 질문드립니다.

예를 들어서 k8s로 노드를 3개띄우고 컨테이너를 8개를 띄운다고 하면 8개를 적절히 노드 3개에서 나누나요? 물론 말씀하신 replicas 설정등등는 뒤로 미루고 개념적으로 궁금합니다.

인글레스를 대표적으로 엔진엑스를 사용하는데 그 spring cloud apigateway를 앞단에 둘것 같습니다만

인클레스 -> spring cloud apigateway -> 컴포넌트

아마 이런식으로 해야되는게 여러가지 있지만 대표적으로

jwt 토근 값을 apigateway에서 검증하는 과정이 있을듯한데

결론적으론 인글래스랑 apigateway 중복으로 인해 네트워크 레이턴시가 있을듯하여 질문드립니다.

스케일 아웃 하려면 클러스터 물리 서버 노드를 최대한 많이 붙여두면 쿠버네티스가 알아서 죽이고 살리고 하니 극단적으로 좋을까요? 물론 클라우드 비용 제외하고 말씀드립니다.

폐쇄망에서도 사용 하나요?

구성 할때 그럼 싱글 클러스터도 구축 하겠지만, 마스터 노드 1개 워커 1개 물리적 서버가 최소 필요하다고 생각되는데 그럼 최소 2대 있어야되나요?

강의자 한정헌입니다. 답변 드리면 다음과 같습니다.

먼저 개념 정의부터 명확히 하면,

노드 및 컨테이너: 노드는 컨테이너가 실행되는 물리적 또는 가상 머신입니다. Kubernetes 클러스터의 각 노드는 여러 컨테이너를 호스팅할 수 있습니다. 따라서 3개의 노드와 8개의 컨테이너가 있는 경우 해당 컨테이너는 Kubernetes 스케줄러의 결정에 따라 3개 노드에 걸쳐 예약됩니다.

스케줄링: Kubernetes 스케줄러는 노드에 컨테이너(Pod로 패키징됨)를 배치하는 일을 담당합니다. 이는 taints , tolerations, affinity 규칙과 같은 다양한 요소를 기반으로 수행됩니다. 목표는 로드 균형을 맞추고 사용 가능한 리소스를 효율적으로 사용하는 것입니다.

따라서 특정 제약 조건이나 선호도 규칙이 없다고 가정하면 8개의 컨테이너(각 컨테이너가 자체 포드에서 실행된다고 가정)가 3개 노드에 배포됩니다. 그렇지만 분포가 고르지 않을 수도 있습니다.

예를 들어
노드 1에는 포드가 3개 ,노드 2에는 포드가 3개 , 노드 3에는 포드가 2개 있을 수 있습니다.

요
약하면 Kubernetes는 기본적으로 컨테이너를 노드 전체에 균등하게 나누지 않습니다. 대신 리소스 가용성 및 기타 요소를 기반으로 컨테이너를 예약합니다. 배포는 사용자가 설정한 다양한 구성 및 제약 조건의 영향을 받을 수 있습니다.
Spring Cloud API Gateway 앞에서 NGINX를 Ingress 컨트롤러로 사용하는 경우 말씀하신 바대로
네트워크 지연 가능성이 있을 수 있으나 매우 경미할 것 같네요. 이를 이중 프록시 레이어로 구성한다고 하는데요. 이런 경우에는 다음과 같이 역할을 줄 수 있겠죠.

NGINX 수신 컨트롤러: Kubernetes 클러스터로 들어오는 외부 트래픽을 처리합니다. SSL 종료, 호스트 이름 또는 경로 기반 라우팅과 같은 작업을 수행하고 로드 밸런싱도 처리할 수 있습니다.
Spring Cloud API 게이트웨이: 클러스터 내에서 작동하며 라우팅, 로드 밸런싱은 물론 인증, 속도 제한 등과 같은 추가 기능을 제공합니다.

이런 경우 각 계층은 추가 처리 및 네트워크 홉으로 인해 약간의 오버헤드 및 잠재적으로 대기 시간이 증가할 수 있습니다.

그렇지만 이런 아키텍처 결정 전에 우선
NGINX와 Spring Cloud API 게이트웨이가 모두 필요한지 고민할 필요가 있을 것 같네요. 또 이런 결정시에는 각 요소의 아래와 같은 장단점을 고려해야 할 것 같네요.

NGINX: 클러스터 가장자리에서 트래픽 라우팅 및 로드 밸런싱을 처리하는 데 매우 효과적

Spring Cloud API Gateway: 동적 라우팅, 속도 제한, 서비스 간 통신과 같은 고급 기능을 제공.
네 더 많은 물리적 서버 노드를 추가하여 Kubernetes 클러스터를 확장하는 것은 용량과 복원력을 높이는 강력한 방법이 될 수 있습니다 , 그렇지만 k8s 와 같은 경우 수평형 Pod Autoscaling 를 우선 고려하고 이것이 한계에 도달할 경우 Cluster Autoscaler를 구현하여 단계적으로 Pod 및 노드 수를 동적으로 조정하는 것이 일반적인 방법입니다. 또 Pod Autoscaling 를 고려하여 더 크거나 더 강력한 노드를 추가하는 것이 작은 노드를 많이 추가하는 것보다 더 효과적일 수 있습니다.
당연히 private 망에서도 k8s를 구성할 수 있습니다.
예 로컬에 k8s 구성하는 경우 다음과 같이 구성 가능합니다.
개발/테스트: 노드 1개(마스터 및 작업자 역할이 모두 포함된 단일 노드 설정) ex) Minikube
기본 프로덕션: 마스터 노드 1개 + 작업자 노드 1개(고가용성 부족으로 인해 프로덕션에는 적합하지 않음)
권장 프로덕션: 마스터 노드 3개 + 작업자 노드 2개(고가용성 및 내결함성을 위해)

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