NGINX 로 온프레미스 Kubernetes 에 대한 TCP 로드 밸런싱 자동화
당신은 현대적인 앱 개발자입니다. 새로운 앱과 컨테이너를 작성, 테스트, 배포 및 관리하기 위해 오픈 소스 및 일부 상용 도구를 사용합니다. 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 pods를 실행하기 위해 Kubernetes 를 선택했습니다. 마이크로서비스, Cloud Native Computing Foundation 및 기타 현대적인 산업 표준의 아키텍처와 개념에 동의했습니다.
이 여정에서 Kubernetes가 실제로 강력하다는 것을 발견했습니다. 그러나 얼마나 어렵고, 융통성이 없고, 실망스러울 수 있는지에 대해서도 놀랐을 것입니다. 라우터, 방화벽, 로드 밸런서 및 기타 네트워크 디바이스에 대한 변경 및 업데이트를 구현하고 조정하는 것은 특히 자체 데이터 센터에서 압도적인 작업이 될 수 있습니다! 개발자가 눈물을 흘리기에 충분합니다.
이러한 문제를 어떻게 처리하는지는 관리형 서비스 또는 온프레미스 중 어느 곳에서 어떻게 Kubernetes를 실행하느냐와 관련이 있습니다. 이 문서에서는 deployment 선택이 사용 편의성에 영향을 미치는 핵심 영역인 TCP 로드 밸런싱에 대해 설명합니다.
목차
1. 관리형 Kubernetes 를 사용한 TCP 로드 밸런싱(일명 Easy 옵션)
2. 온프레미스 Kubernetes 를 사용한 TCP 로드 밸런싱(일명 Hard 옵션)
3. 온프레미스 TCP 로드 밸런싱을 위한 더 나은 솔루션: NGINX
3-1. 아키텍처와 흐름
3-2. Kubernetes 용 NGINX 로드 밸런서의 스냅샷
4. 지금 시작하세요.
1. 관리형 Kubernetes 를 사용한 TCP 로드 밸런싱(일명 Easy 옵션)
Kubernetes 용 퍼블릭 클라우드 제공자와 같은 관리형 서비스를 사용하는 경우, 지루한 네트워킹 작업의 대부분이 자동으로 처리됩니다. 단 한 번의 명령 (kubectl apply -f loadbalancer.yaml)으로 서비스 유형 LoadBalancer가 Public IP, DNS 레코드 및 TCP 로드 밸런서를 제공합니다. 예를 들어, 이 명령을 사용하여 트래픽을 NGINX Ingress Controller가 포함된 pod로 분산하도록 Amazon Elastic Load Balancer를 구성할 수 있으며, 백엔드가 변경되더라도 걱정할 필요가 없습니다. 너무 쉽기 때문에 당연하게 생각하실 수도 있습니다.
2. 온프레미스 Kubernetes 를 사용한 TCP 로드 밸런싱(일명 Hard 옵션)
온프레미스 클러스터에서는 완전히 다른 시나리오입니다. 여러분 또는 여러분의 네트워킹 동료가 네트워킹을 제공해야 합니다. “사용자를 내 Kubernetes 앱으로 이동시키는 것이 왜 그렇게 어려운가?” 라고 궁금해하실 수도 있습니다. 대답은 간단하지만 약간 충격적입니다: 클러스터의 정문인 서비스 유형 LoadBalancer가 실제로 존재하지 않기 때문입니다.
앱과 서비스를 클러스터 외부에 노출하려면 네트워크 팀이 장비를 재구성하기 전에 티켓, 승인, 절차, 심지어 보안 검토까지 해야 할 수도 있습니다. 또는 모든 작업을 직접 수행해야 하므로 애플리케이션 배포 속도가 느려질 수도 있습니다. 더 나쁜 것은, NodePort가 변경되면 트래픽이 차단될 수 있기 때문입니다! 그리고 우리 모두는 사용자가 500개의 오류를 얼마나 좋아하는지 알고 있습니다. 여러분의 상사는 아마 그보다 더 싫어할 것입니다.
3. 온프레미스 TCP 로드 밸런싱을 위한 더 나은 솔루션: NGINX
새로운 프로젝트를 통해 “hard 옵션”을 “easy 옵션”으로 바꿀 수 있습니다: Kubernetes 용 NGINX Load Balancer입니다. 이 무료 프로젝트는 NGINX Ingress Controller를 감시하고 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes Controller입니다. 설계가 매우 간단하기 때문에 설치와 운영이 간단합니다. 이 솔루션을 사용하면 온프레미스 환경에서 TCP 로드 밸런싱을 구현하여 새로운 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있도록 보장할 수 있으며, 손을 쓸 필요가 없습니다.
3-1. 아키텍처와 흐름
Kubernetes용 NGINX Load Balancer는 Kubernetes 클러스터 내부에 위치합니다. Kubernetes에 등록되어 nginx-ingress service(NGINX Ingress Controller)를 감시합니다. 백엔드에 변경 사항이 있을 때, Kubernetes 용 NGINX Load Balancer는 Worker IP와 NodePort TCP 포트 번호를 수집한 다음, NGINX Plus API를 통해 IP: 포트를 NGINX Plus로 보냅니다. reload할 필요 없이 NGINX 업스트림 서버가 업데이트되고, NGINX Plus는 올바른 업스트림 서버와 Kubernetes NodePort로 트래픽을 로드 밸런싱합니다. 고가용성을 달성하기 위해 NGINX Plus 인스턴스를 추가할 수 있습니다.
3-2. Kubernetes 용 NGINX 로드 밸런서의 스냅샷
아래 스크린샷에는 배포된 Kubernetes용 NGINX Load Balancer와 해당 작업을 수행하는 두 개의 창이 있습니다.
- Service Type – Load Balancer(nginx-ingress 용)
- External IP – NGINX Plus 서버에 연결
- Ports – NodePort는 일치하는 NGINX 업스트림 서버를 사용하여 443:30158에 매핑됩니다(NGINX Plus 실시간 대시보드에 표시됨).
- Logs – Kubernetes 용 NGINX Load Balancer가 NGINX Plus에 데이터를 성공적으로 보내고 있음을 나타냅니다.
참고: 이 예에서 Kubernetes worker node는 10.1.1.8 및 10.1.1.10 입니다.

4. 지금 시작하세요.
Kubernetes 클러스터 엣지에서의 네트워킹 문제로 불편을 겪고 계신다면, 프로젝트를 사용해 보시고 의견을 알려주세요. Kubernetes 용 NGINX Load Balancer의 소스 코드는 오픈 소스(Apache 2.0 라이선스)로 제공되며 모든 설치 지침은 GitHub에서 확인할 수 있습니다.
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.
NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.