서비스 네트워킹 개요

이 페이지에서는 Google Kubernetes Engine(GKE)에서 서비스를 배포하는 방법을 설명합니다. 이 페이지를 가이드로 사용하여 서비스 네트워킹의 패싯 및 GKE에 존재하는 서비스 네트워크 기능을 보다 정확히 파악할 수 있습니다.

서비스 네트워킹 개요

서비스 네트워킹은 클라이언트가 사용하는 애플리케이션의 기본 소유권, 구현 또는 환경을 추상화하는 방식으로 애플리케이션을 게시하는 것입니다. 가장 간단한 형태로 서비스는 애플리케이션이 액세스하는 안전하고 일관성 있고 사용 가능한 엔드포인트입니다.

클라이언트와 애플리케이션에는 통신 방식에 대한 다양한 요구사항이 있습니다. 포드에서 사용할 Kubernetes 클러스터에 애플리케이션을 노출하는 것만큼 간단할 수도 있고 전 세계 인터넷 클라이언트에서 애플리케이션으로 트래픽을 라우팅하는 것만큼 복잡할 수도 있습니다. GKE는 고유한 사용 사례에 적합한 애플리케이션을 서비스로 노출하는 다양한 방법을 제공합니다.

서비스의 요소

클라이언트에 애플리케이션을 노출하는 것과 관련이 있는 서비스의 주요 요소가 세 가지 있습니다.

  • 프런트엔드: 부하 분산기 프런트엔드는 클라이언트가 액세스하여 부하 분산기로 트래픽을 전송할 수 있는 범위를 정의합니다. 트래픽을 리슨하는 네트워크 위치로, 여기에는 네트워크, 특정 리전(또는 네트워크 내의 서브넷), 네트워크에 있는 하나 이상의 IP, 포트, 특정 프로토콜, 보안 연결을 설정하는 데 필요한 TLS 인증서가 포함됩니다.

  • 라우팅 및 부하 분산: 라우팅 및 부하 분산은 트래픽을 처리하고 라우팅하는 방법을 정의합니다. 프로토콜, HTTP 헤더, HTTP 경로와 같은 매개변수를 기반으로 서비스로 트래픽을 라우팅할 수 있습니다. 사용하는 부하 분산기에 따라 낮은 지연 시간 및 향상된 복원력을 고객에게 제공하기 위해 트래픽을 분산할 수 있습니다.

  • 백엔드: 부하 분산기 백엔드는 엔드포인트, 애플리케이션 플랫폼, 백엔드 서비스 검색 통합의 유형으로 정의됩니다. GKE는 GKE 엔드포인트가 확장 및 축소될 때 서비스 검색 통합을 사용하여 부하 분산기 백엔드를 동적으로 업데이트합니다.

다음 다이어그램은 내부 및 외부 트래픽에 대한 이러한 개념을 설명합니다.

이 다이어그램에서 외부 애플리케이션 부하 분산기는 전 세계 수백 개의 Google 접속 지점을 통해 공개 인터넷의 트래픽을 리슨합니다. 이 전역 프런트엔드는 트래픽을 Google 데이터 센터의 백엔드로 부하 분산하기 전에 클라이언트와 가까운 에지에서 트래픽을 종료할 수 있습니다.

내부 애플리케이션 부하 분산기는 VPC 네트워크 범위 내에서 리슨하여 비공개 통신을 내부적으로 수행할 수 있도록 합니다. 이러한 부하 분산기 속성은 여러 종류의 애플리케이션 사용 사례에 적합합니다.

GKE 부하 분산 이해하기

GKE 클러스터 외부에 애플리케이션을 노출하기 위해 GKE는 기본적으로 배포되는 GKE 인그레스 컨트롤러 및 GKE 서비스 컨트롤러를 제공하여 GKE 사용자 대신 부하 분산기를 배포합니다. 수명 주기가 GKE에 의해 완전히 자동화되고 제어된다는 점을 제외하면 VM 부하 분산 인프라와 동일합니다. GKE 네트워크 컨트롤러는 인그레스 및 서비스 API 표준을 준수하며 전문가의 의견이 담긴 상위 수준 인터페이스를 사용하여 컨테이너 기반 Pod IP 부하 분산을 제공합니다.

다음 다이어그램은 GKE 네트워크 컨트롤러가 부하 분산기 생성을 자동화하는 방법을 보여줍니다.

다이어그램에서 볼 수 있듯이 인프라 또는 앱 관리자는 GKE 클러스터에 대해 선언적 매니페스트를 배포합니다. 인그레스 및 서비스 컨트롤러는 GKE 네트워킹 리소스(예: 인그레스 객체)를 감시하고 매니페스트를 기반으로 부하 분산기(및 IP 주소, 방화벽 규칙 등)를 배포합니다.

컨트롤러는 환경 및 트래픽 변경사항을 기준으로 부하 분산기와 백엔드를 계속 관리합니다. 따라서 GKE 부하 분산은 개발자 중심의 인터페이스로 동적인 자체 부하 분산기 역할을 합니다.

애플리케이션을 노출할 메서드 선택

GKE에서 애플리케이션을 노출할 메서드를 선택할 때 클라이언트 네트워크, 프로토콜, 애플리케이션 리전성을 핵심적으로 고려해야 합니다. GKE의 인그레스 및 서비스 컨트롤러 제품군을 사용하면 이러한 각 요소를 염두에 두고 애플리케이션을 노출할 수 있습니다.

다음 섹션에서는 애플리케이션 네트워킹의 모든 측면을 다루지는 않지만, 다음 각 요소를 살펴보면 애플리케이션에 가장 적합한 솔루션을 결정하는 데 도움이 될 수 있습니다. GKE 환경은 대부분 각자 고유한 요구사항이 있는 여러 유형의 애플리케이션을 호스팅하므로 지정된 주어진 클러스터에서 두 개 이상을 사용하게 될 가능성이 높습니다.

인그레스 기능을 자세히 비교하려면 인그레스 구성을 참조하세요.

클라이언트 네트워크

클라이언트 네트워크는 애플리케이션 클라이언트가 애플리케이션에 액세스하는 위치의 네트워크를 의미합니다. 이는 부하 분산기의 프런트엔드가 리슨하는 위치에 영향을 줍니다. 예를 들어 클라이언트가 애플리케이션과 동일한 GKE 클러스터 내에 있을 수 있습니다. 이 경우 사용자는 클러스터 네트워크 내에서 애플리케이션에 액세스하여 Kubernetes 기반 ClusterIP 부하 분산을 사용할 수 있습니다.

또한 클라이언트는 Virtual Private Cloud(VPC) 내에서 또는 Cloud Interconnect 전체의 온프레미스 네트워크에서 애플리케이션에 액세스하는 내부 네트워크 클라이언트일 수 있습니다.

클라이언트는 공개 인터넷에서 애플리케이션에 액세스하는 외부 클라이언트일 수도 있습니다. 각 네트워크 유형마다 다른 부하 분산 토폴로지를 나타냅니다.

GKE에서는 내부 부하 분산기와 외부 부하 분산기 중에서 선택할 수 있습니다. 내부는 인터넷에서 직접 액세스할 수 없는 내부 비공개 네트워크인 VPC 네트워크를 나타냅니다. 외부는 공개 인터넷을 의미합니다. ClusterIP 서비스는 단일 GKE 클러스터 내부에 있으므로 VPC 네트워크보다도 작은 네트워크로 범위가 지정됩니다.

다음 표에서는 내부 및 외부 네트워크에서 사용할 수 있는 솔루션에 대한 개요를 제공합니다.

네트워크 유형 사용 가능한 솔루션
내부 ClusterIP 서비스
NodePort 서비스
내부 LoadBalancer 서비스
내부 인그레스
외부 NodePort 서비스1
외부 LoadBalancer 서비스
외부 인그레스
멀티 클러스터 인그레스

1 공개 GKE 클러스터는 각 GKE 노드에 공개 및 비공개 IP 주소를 제공하므로 NodePort 서비스에 내부 및 외부에서 액세스할 수 있습니다.

프로토콜

프로토콜은 클라이언트가 애플리케이션에 말하는 언어입니다. 음성, 게임, 지연 시간이 짧은 애플리케이션은 일반적으로 TCP 또는 UDP를 직접 사용하므로 레이어 4를 세밀하게 제어할 수 있는 부하 분산기를 요구합니다. 다른 애플리케이션은 HTTP, HTTPS, gRPC 또는 HTTP2를 사용하며 이러한 프로토콜을 명시적으로 지원하는 부하 분산기가 필요합니다. 프로토콜 요구사항은 어떤 유형의 애플리케이션 노출 메서드가 가장 적합한지 정의합니다.

GKE에서는 포트 및 프로토콜과 같은 네트워크 정보를 기반으로 트래픽을 라우팅하는 레이어 4 부하 분산기와 클라이언트 세션과 같은 애플리케이션 정보를 인식하는 레이어 7 부하 분산기를 구성할 수 있습니다. 다음 표와 같이 각 부하 분산기에는 특정 프로토콜 지원이 제공됩니다.

레이어 프로토콜 사용 가능한 솔루션
L4 TCP
UDP		 ClusterIP 서비스
NodePort 서비스
내부 LoadBalancer 서비스
외부 LoadBalancer 서비스
L7 HTTP
HTTPS
HTTP2 		내부 인그레스
외부 인그레스
멀티 클러스터 인그레스

애플리케이션 리전성

애플리케이션 리전성이란 애플리케이션이 둘 이상의 리전 또는 GKE 클러스터에 분산된 정도를 의미합니다. 애플리케이션의 단일 인스턴스를 호스팅할 때의 요구사항은 별도의 두 GKE 클러스터 간에 애플리케이션의 중복 인스턴스를 호스팅하는 경우와 다릅니다. 지연 시간을 단축하기 위해 GKE 클러스터 5개에 지리적으로 분산된 애플리케이션을 호스팅하여 최종 사용자에게 가까운 곳에 워크로드를 위치시키려면 부하 분산기에 대한 멀티 클러스터 및 멀티 리전을 더 잘 이해해야 합니다.

GKE 부하 분산 솔루션의 리전성을 다음과 같은 두 영역으로 나눌 수 있습니다.

  • 백엔드 범위(또는 클러스터 범위): 이 범위는 부하 분산기가 여러 GKE 클러스터에서 백엔드로 트래픽을 전송할 수 있는지 여부를 나타냅니다. 멀티 클러스터 인그레스는 서로 다른 클러스터와 서로 다른 리전의 포드로 트래픽을 전달하는 단일 가상 IP 주소를 노출할 수 있습니다.

  • 프런트엔드 범위: 이 범위는 부하 분산기 IP가 단일 리전 내에서 또는 여러 리전 간에 리슨하는지를 나타냅니다. 모든 외부 부하 분산기는 본질적으로 멀티 리전인 인터넷에서 리슨하지만 일부 내부 부하 분산기는 단일 리전 내에서만 리슨합니다.

다음 표에서는 이러한 두 측정기준에서 GKE 부하 분산 솔루션을 분석합니다.

백엔드 범위
(클러스터 범위)		 사용 가능한 솔루션
단일 클러스터 ClusterIP 서비스
NodePort 서비스
내부 LoadBalancer 서비스
외부 LoadBalancer 서비스
내부 인그레스
외부 인그레스
멀티 클러스터 멀티 클러스터 인그레스
프런트엔드 범위 사용 가능한 솔루션
리전 ClusterIP 서비스
내부 인그레스
전역 ClusterIP 서비스
NodePort 서비스
내부 LoadBalancer 서비스
외부 LoadBalancer 서비스
외부 인그레스
멀티 클러스터 인그레스

애플리케이션 노출을 위한 다른 솔루션

앞의 솔루션이 애플리케이션 노출에 사용할 수 있는 유일한 솔루션은 아닙니다. 다음 솔루션 또한 GKE 부하 분산기에 대해 실행 가능한 대안 또는 보완책이 될 수도 있습니다.

클러스터 내 인그레스

클러스터 내 인그레스는 Kubernetes 클러스터 자체 내에서 인그레스 프록시가 있는 소프트웨어 인그레스 컨트롤러를 의미합니다. 이는 Kubernetes 클러스터와 별도로 부하 분산 인프라를 호스팅하고 관리하는 GKE 인그레스 컨트롤러와는 다릅니다. 이러한 타사 솔루션은 일반적으로 클러스터 운영자에 의해 자체 배포 및 관리됩니다. istio-ingressgateway 및 nginx-ingress은 일반적으로 사용되는 오픈소스 클러스터 내 인그레스 컨트롤러의 두 가지 예시입니다.

클러스터 내 인그레스 컨트롤러는 일반적으로 Kubernetes 인그레스 사양을 준수하며 다양한 기능과 사용 편의성을 제공합니다. 오픈소스 솔루션에는 더 긴밀한 관리와 높은 수준의 기술 전문 지식이 필요한 경우가 많지만, 애플리케이션이 요구하는 기능을 제공하는 경우 니즈를 충족할 수 있습니다. 고급 기능 및 엔터프라이즈 지원을 제공하는 오픈소스 커뮤니티를 중심으로 구축된 기업용 인그레스 솔루션의 생태계 또한 방대합니다.

독립형 네트워크 엔드포인트 그룹(NEG)

GKE 인그레스 및 서비스 컨트롤러는 Cloud Load Balancing을 배포하는 선언적이고 자동화된 Kubernetes 기반 메서드를 제공합니다. GKE 백엔드에 부하 분산기를 수동으로 배포하는 유효한 사용 사례도 있습니다. 예를 들어 부하 분산기를 세밀하게 직접 제어하거나 컨테이너와 VM 백엔드 간 부하를 분산할 수 있습니다.

독립형 NEG는 NEG에 포드 백엔드 IP를 동적으로 업데이트하여 이 기능을 제공하지만, 부하 분산기의 프런트엔드를 수동으로 배포할 수 있습니다. 이를 통해 GKE 클러스터에서 제어하는 동적 백엔드를 유지하면서 부하 분산기를 최대로 직접 제어할 수 있습니다.

서비스 메시

서비스 메시는 중앙 집중식 제어 영역을 통해 클라이언트 측 부하 분산을 제공합니다. Traffic Director 및 Anthos Service Mesh는 GKE 클러스터 간, 리전 간, 컨테이너와 VM 간 내부 트래픽을 부하 분산하는 기능을 지원합니다. 이렇게 하면 내부 부하 분산(동-서 트래픽)과 애플리케이션 노출(북동쪽 트래픽) 사이의 경계가 흐려집니다. 최신 서비스 메시 컨트롤 영역의 유연성과 도달 범위로 인해 클라이언트와 서버가 모두동일한 서비스 메시 범위 내에 있을 가능성이 그 어느 때보다 높습니다. 앞의 GKE 인그레스 및 서비스 솔루션은 일반적으로 자체 사이드카 프록시가 없는 클라이언트를 위해 미들 프록시 부하 분산기를 배포합니다. 그러나 클라이언트와 서버가 동일한 메시에 있는 경우 미들 프록시 부하 분산이 아닌 메시를 통해 애플리케이션 노출을 처리할 수 있습니다.

다음 단계