Kubernetes: Up and Running, 제3판

8장. 인그레스를 통한 HTTP 부하 분산

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

모든 애플리케이션에서 중요한 부분은 해당 애플리케이션과 네트워크 트래픽을 주고받는 것입니다. 7장에서 설명한 것처럼, Kubernetes에는 서비스를 클러스터 외부로 노출할 수 있는 일련의 기능이 있다. 많은 사용자와 간단한 사용 사례의 경우 이러한 기능으로 충분합니다.

그러나 서비스 개체는 (OSI 모델에 따라) 레이어 4에서 작동합니다.¹ 즉, TCP 및 UDP 연결만 전달하고 해당 연결의 내부를 살펴보지 않습니다. 이 때문에 클러스터에서 많은 애플리케이션을 호스팅하는 경우 다양한 노출된 서비스를 사용합니다. 이러한 서비스가 type: NodePort 인 경우 클라이언트가 서비스별 고유 포트에 연결하도록 해야 합니다. 이러한 서비스가 type: LoadBalancer 인 경우 각 서비스에 대해 (종종 비싸거나 부족한) Cloud 리소스를 할당하게 됩니다. 하지만 HTTP(레이어 7) 기반 서비스의 경우 더 나은 방법을 사용할 수 있습니다.

Kubernetes가 아닌 상황에서 비슷한 문제를 해결할 때 사용자는 종종 "가상 호스팅"이라는 아이디어를 떠올립니다. 이는 단일 IP 주소에서 많은 HTTP 사이트를 호스팅하는 메커니즘입니다. 일반적으로 사용자는 로드 밸런서 또는 리버스 프록시를 사용하여 HTTP(80) 및 HTTPS(443) 포트에서 들어오는 연결을 수락합니다. 그러면 해당 프로그램은 HTTP 연결을 구문 분석하고 Host 헤더와 요청된 URL 경로를 기반으로 다른 프로그램으로 HTTP 호출을 프록시합니다. 이러한 방식으로 로드 밸런서 또는 역방향 프록시는 들어오는 연결을 디코딩하고 올바른 "업스트림" 서버로 트래픽을 전달합니다.

Kubernetes는 HTTP 기반 로드 밸런싱 시스템을 Ingress라고 부릅니다. 인그레스는 방금 설명한 "가상 호스팅" 패턴을 구현하는 Kubernetes 고유의 방식입니다. 이 패턴의 더 복잡한 측면 중 하나는 사용자가 로드 밸런서 구성 파일을 관리해야 한다는 것입니다. 동적 환경에서 가상 호스트 집합이 확장되면 이는 매우 복잡해질 수 있습니다. Kubernetes 인그레스 시스템은 이를 단순화하기 위해 (a) 해당 구성을 표준화하고, (b) 표준 Kubernetes 오브젝트로 이동하며, (c) 여러 인그레스 오브젝트를 로드 밸런서에 대한 단일 구성으로 병합합니다.

일반적인 소프트웨어 기반 구현은 그림 8-1에 표시된 것과 비슷합니다. 인그레스 컨트롤러는 두 부분으로 구성된 소프트웨어 시스템입니다. 첫 번째는 type: LoadBalancer 의 서비스를 사용하여 클러스터 외부에 노출되는 인그레스 프록시입니다. 이 프록시는 요청을 "업스트림" 서버로 보냅니다. 다른 구성 요소는 인그레스 재조정자 또는 운영자입니다. 인그레스 오퍼레이터는 인그레스 리소스에 지정된 대로 트래픽을 라우팅하도록 인그레스 프록시를 재구성하고 인그레스 ...