여러분은 현대적인 애플리케이션 개발자입니다. 오픈 소스 도구와 일부 상용 도구를 활용해 새로운 애플리케이션과 컨테이너를 작성, 테스트, 배포 및 관리합니다. 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 파드를 실행하기 위해 Kubernetes를 선택했습니다. 또한 마이크로서비스 아키텍처와 개념, Cloud Native Computing Foundation, 그리고 그 밖의 현대적인 업계 표준을 채택했습니다.
이 여정을 거치면서 Kubernetes가 실제로 강력하다는 사실을 알게 되었을 것입니다. 하지만 Kubernetes가 얼마나 어렵고 유연성이 떨어지며 답답할 수 있는지에 놀랐을 수도 있습니다. 라우터, 방화벽, 로드 밸런서 및 기타 네트워크 장치의 변경과 업데이트를 구현하고 조율하는 일은 감당하기 어려울 정도로 복잡해질 수 있습니다. 특히 자체 데이터 센터에서는 더욱 그렇습니다! 개발자가 눈물을 흘릴 만도 합니다.
이러한 과제를 어떻게 해결할지는 Kubernetes를 어디에서 어떤 방식으로 운영하는지(관리형 서비스 또는 온프레미스)에 따라 크게 달라집니다. 이 글에서는 배포 방식에 따라 사용 편의성이 크게 달라지는 핵심 영역인 TCP 부하 분산을 다룹니다.
관리형 Kubernetes를 사용한 TCP 부하 분산(일명 쉬운 옵션)
Kubernetes용 퍼블릭 클라우드 공급자와 같은 관리형 서비스를 사용하면 번거로운 네트워킹 작업의 상당 부분이 자동으로 처리됩니다. 단 하나의 명령어(kubectl apply -f loadbalancer.yaml)만 실행하면 Service 유형인 LoadBalancer가 퍼블릭 IP, DNS 레코드 및 TCP 로드 밸런서를 제공합니다. 예를 들어 Amazon Elastic Load Balancer가 NGINX Ingress Controller를 포함하는 Pod로 트래픽을 분산하도록 구성할 수 있으며, 이 명령어를 사용하면 백엔드가 변경되어도 걱정할 필요가 없습니다. 너무 간편해서 당연하게 여기고 계실지도 모릅니다!
온프레미스 Kubernetes를 사용한 TCP 부하 분산(일명 어려운 방법)
온프레미스 클러스터의 경우에는 상황이 완전히 다릅니다. 사용자 또는 네트워크 담당자가 네트워킹 구성 요소를 직접 마련해야 합니다. “사용자가 내 Kubernetes 앱에 접속하도록 하는 일이 왜 이렇게 어려울까?”라는 의문이 들 수 있습니다. 답은 간단하지만 다소 충격적입니다. 클러스터의 관문 역할을 하는 LoadBalancer 유형의 Service는 실제로 존재하지 않습니다.
클러스터 외부에 앱과 서비스를 노출하려면 네트워크 팀에서 장비를 재구성하기 전에 티켓, 승인, 절차는 물론 보안 검토까지 요구할 수 있습니다. 아니면 모든 작업을 직접 처리해야 해서 애플리케이션 제공 속도가 현저히 느려질 수도 있습니다. 더 심각한 문제는 NodePort가 변경되면 트래픽이 차단될 수 있기 때문에 Kubernetes 서비스를 함부로 변경할 수도 없다는 것입니다! 사용자가 500 오류를 얼마나 싫어하는지는 모두 잘 알고 있습니다. 아마 상사는 더 싫어할 것입니다.
온프레미스 TCP 부하 분산을 위한 더 나은 솔루션: Kubernetes용 NGINX Loadbalancer
새 프로젝트를 사용하면 “어려운 옵션”을 “쉬운 옵션”으로 바꿀 수 있습니다. 바로 Kubernetes용 NGINX Loadbalancer입니다. 이 무료 프로젝트는 Kubernetes 컨트롤러로, NGINX Ingress Controller를 모니터링하고 부하 분산용으로 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트합니다. 설계가 매우 직관적이어서 설치와 운영이 간편합니다. 이 솔루션을 사용하면 온프레미스 환경에서 TCP 부하 분산을 구현할 수 있으며, 별도의 수동 작업 없이도 새로운 앱과 서비스가 즉시 감지되어 트래픽을 처리할 수 있습니다.
아키텍처 및 흐름
NGINX Loadbalancer for Kubernetes는 Kubernetes 클러스터 내부에 위치합니다. Kubernetes에 등록되어 nginx-ingress 서비스(NGINX Ingress Controller)를 모니터링합니다. 백엔드가 변경되면 NGINX Loadbalancer for Kubernetes는 워커 IP와 NodePort TCP 포트 번호를 수집한 다음, NGINX Plus API를 통해 IP:포트를 NGINX Plus로 전송합니다. NGINX 업스트림 서버는 재로드 없이 업데이트되며, NGINX Plus는 올바른 업스트림 서버와 Kubernetes NodePort로 트래픽을 부하 분산합니다. NGINX Plus 인스턴스를 추가하여 고가용성을 구현할 수 있습니다.
실제 작동 중인 Kubernetes용 NGINX 로드 밸런서 살펴보기
아래 스크린샷에는 NGINX Loadbalancer for Kubernetes가 배포되어 제 역할을 수행하는 모습을 보여 주는 두 개의 창이 있습니다:
- 서비스 유형 – LoadBalancer(
nginx-ingress용) - 외부 IP – NGINX Plus 서버에 연결
- 포트 – NodePort는 443:30158에 매핑되며, 이에 대응하는 NGINX 업스트림 서버가 있습니다(NGINX Plus 실시간 대시보드에 표시된 것과 같음)
- 로그 – Kubernetes용 NGINX 로드 밸런서가 NGINX Plus로 데이터를 성공적으로 전송하고 있음을 나타냅니다
참고: 이 예시에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
지금 시작하세요
Kubernetes 클러스터의 엣지에서 발생하는 네트워킹 문제로 어려움을 겪고 있다면 이 프로젝트를 직접 사용해 보고 의견을 들려주세요. NGINX Loadbalancer for Kubernetes의 소스 코드는 오픈 소스(Apache 2.0 라이선스)이며, 모든 설치 지침은 GitHub에서 확인할 수 있습니다.
피드백을 보내려면 리포지토리에 댓글을 남기거나 NGINX 커뮤니티 Slack에서 메시지를 보내주세요.
관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.