개요
GKE 서비스 조정을 사용하여 GKE 클러스터 내에서 네트워크 트래픽이 전달되는 방식을 제어할 수 있습니다. 클러스터에 배포한 네트워크 함수로 특정 유형의 트래픽을 전달하는 규칙을 정의할 수 있습니다. GKE 서비스 조정은 네트워크 트래픽의 일반 경로를 재정의하는 정책 기반 라우팅과 유사합니다.
용어 및 개념
이 페이지에서는 다음 개념을 사용합니다.
서비스 함수(SF)
서비스 함수는 수신된 데이터 패킷에서 작동하는 소프트웨어 구성요소입니다. 서비스 레이어는 레이어 2(데이터 링크 계층)부터 시작하여 OSI 모델의 모든 레이어에서 작동할 수 있습니다.
서비스 함수는 크게 다음과 같이 분류할 수 있습니다.
- 보안용 방화벽
- 액세스 제어를 위한 프록시
- 속도 향상을 위한 WAN 가속화
- 콘텐츠 분석을 위한 딥 패킷 검사(DPI)
- 감시 및 조사를 위한 합법적 가로채기(LI)
- 비공개 및 공개 IP 주소용 네트워크 주소 변환기(NAT)
- 헤더 보강용 HTTP
- 트래픽을 효율적으로 분산하기 위한 부하 분산기
서비스 함수의 대체 용어는 다음과 같습니다.
- 컨테이너 어플라이언스
- 가상 어플라이언스
- 가상화된 네트워크 기능(NFV)
- 컨테이너화된 네트워크 기능(CNF)
- 클라우드 네이티브 네트워크 기능(CNF)
서비스 조정에서 서비스 객체는 서비스 함수(SF)를 나타냅니다.
서비스 함수 체인(SFC)
서비스 함수 체인(SFC)은 네트워크 트래픽을 특정 순서로 처리하기 위해 서로 연결된 방화벽, 프록시, 부하 분산기와 같은 일련의 서비스 함수를 말합니다. 이 체인은 파이프라인처럼 작동하는데, 여기서 각 서비스 함수는 트래픽에서 특정 태스크를 수행한 후 다음 함수로 태스크를 전달합니다.
서비스 함수 체인(SFC)을 서비스 체인(SC)이라고도 합니다.
서비스 조정에서 ServiceFunctionChain 객체는 서비스 함수 체인(SFC)을 나타냅니다.
서비스 함수는 모든 서비스 함수 체인과 독립적으로 작동합니다. 일반적으로 서비스 함수는 자신이 속한 서비스 함수 체인을 알지 못합니다.
서비스 조정
서비스 조정은 소스와 목적지에 완전히 투명한 방식으로 선택된 서비스 함수로 패킷을 라우팅합니다. 이 개념을 '정책 기반 라우팅', '트래픽 리디렉션' 또는 '서비스 함수 전달'이라고도 합니다. 서비스 조정은 Geneve + NSH 캡슐화를 사용하여 투명한 라우팅을 달성합니다(RFC 8926, RFC 8300, Geneve + NSH IETF Draft 참조).
서비스 조정의 중요한 특성은 다음과 같습니다.
- 서비스 함수의 백엔드 포드 간 부하 분산: 서비스 함수는 확장성과 안정성을 위해 여러 포드에서 실행되는 경우가 많습니다. 서비스 조정은 단일 포드가 과부하되지 않도록 수신 네트워크 트래픽을 이러한 포드 간에 균일하게 분산합니다.
- 5-튜플 흐름 어피니티 지원(특정 흐름에서 모든 중간 홉이 안정적이어야 함): 5-튜플 흐름은 소스 IP 주소, 소스 포트, 목적지 IP 주소, 목적지 포트, 프로토콜을 기반으로 하여 네트워크 트래픽의 특정 스트림을 식별하는 방법입니다. 서비스 조정은 동일한 흐름 내의 모든 패킷이 동일한 서비스 함수(홉) 집합으로 일관되게 전달되도록 합니다.
- 대칭 반환 데이터 경로 사용 설정: 대칭 반환 데이터 경로는 응답 트래픽이 원래 요청 트래픽과 동일한 경로를 따라 소스로 돌아옵니다. 서비스 조정은 이러한 대칭성을 보장하며, 이는 일부 네트워크 프로토콜 및 애플리케이션에 중요합니다.
서비스 조정되는 특정 네트워크 트래픽에 대해 중간 서비스 함수 포드는 일관된 중간 홉 및 예측 가능한 경로를 보장하기 위해 특정 네트워크 트래픽의 모든 패킷을 처리합니다. 동일한 서비스 함수 포드는 반환 트래픽을 수신하여 대칭 트래픽 흐름을 보장합니다. 원래 트래픽이 동일한 클러스터 내 목적지로 전송되는 경우 반환 트래픽은 동일한 서비스 체인을 통해 자동으로 되돌아가는 방법을 찾습니다. 원래 트래픽이 클러스터 외부에 있으면 체인의 최종 서비스 함수가 소스 네트워크 주소 변환 (SNAT) 또는 중개자 역할을 하는 프록시를 사용하여 트래픽을 다시 유도합니다.
사용 사례
GKE 서비스 조정은 정책 기반 라우팅을 클러스터에 통합합니다. 이렇게 하면 다음과 같은 기본 사용 사례를 사용할 수 있습니다.
자체 관리형 보안 서비스:
조직은 가상 방화벽(vFW), 가상 차세대 방화벽(vNG-FW), 가상 침입 감지 시스템(vIDS)과 같은 컨테이너화된 네트워크 기능(CNF)을 사용하여 자체 보안 인프라를 구성할 수 있습니다. 서비스 조정은 의도한 목적지에 도달하기 전 이러한 CNF를 통해 트래픽이 라우팅되도록 보장하여 보호 및 제어 레이어를 제공합니다.
관리형 보안 제공업체(MSP):
MSP는 GKE 서비스 조정을 활용하여 클라우드 기반 보안 서비스 체인을 통해 트래픽을 라우팅할 수 있습니다. 따라서 Secure Web Gateways(SWG), SASE(Secure Access Service Edge), SD-WAN(Software-Defined Wide Zone Network) 기능을 비롯한 포괄적인 보안 솔루션을 제공할 수 있습니다.
전자통신 및 5G 네트워크:
서비스 조정은 전자통신 및 5G 인프라 내에서 다양한 네트워크 기능의 트래픽 흐름을 관리합니다. 가상 라우터(vRouter), 가상 세션 경계 컨트롤러(vSBC), 5G 핵심 네트워크 기능을 조정하여 효율적인 트래픽 관리, 부하 분산, 특정 보안 또는 서비스 품질 정책을 보장할 수 있습니다.
서비스 조정 작동 방식
이 섹션에서는 서비스 조정의 다양한 구성요소가 작동하는 방식을 설명합니다.
서비스 함수
네트워크 트래픽 흐름 식별: GKE 서비스 조정은 고유한 흐름 ID, 패킷의 소스 IP 주소, 소스 포트, 목적지 IP 주소, 목적지 포트, 프로토콜의 5-튜플 해시를 사용하여 각 네트워크 연결을 식별합니다.
흐름 어피니티 보장: 서비스 조정은 동일한 흐름 ID의 모든 패킷을 서비스 함수(SF)의 동일한 경로를 통해 전달하여 흐름 어피니티를 보장합니다.
패킷을 수정하여 새 흐름을 만드는 경우: 서비스 함수가 패킷의 5-튜플 필드를 수정하는 경우입니다. 예를 들어 NAT가 소스 IP 주소를 변경하면 새 흐름이 생성됩니다.
새 흐름의 트래픽 선택: 트래픽 선택 프로세스는 새 흐름을 평가하여 원래 흐름과 다른 경로를 사용할 수 있는 남은
Service Functions을 통한 경로를 결정합니다.프록시와 NAT를 두 흐름으로 처리: 프록시 또는 NAT를 통한 트래픽은 소스에서 프록시/NAT로, 프록시/NAT에서 목적지로의 두 가지 개별 흐름으로 간주됩니다. 서비스 조정은 이 두 흐름에 대해 동일한 경로를 보장하지 않습니다.
소스 주소 검증: 서비스 조정으로 조정되지 않는 트래픽에도 SF는 항상 소스 주소 검증이 적용됩니다. 서비스 함수가 소스 IP 주소가 일치하지 않는 새 흐름을 시작하면 명시적으로 허용되지 않는 한 해당 패킷이 삭제됩니다.
캡슐화 투명성 유지: 서비스 조정은 SF 간 트래픽에 Geneve 캡슐화를 사용하지만 서비스 함수 포드 자체는 이를 인식하지 못합니다. 포드에 들어가기 전에 패킷이 캡슐화 해제되어 서비스 함수 개발을 간소화합니다.
기존 연결
TrafficSelector를 만들면 서비스 조정이 선택기의 기준과 일치하는 모든 기존 연결에 이를 자동으로 적용합니다. 이러한 연결에서 적절한 서비스 함수로 패킷을 리디렉션합니다. 서비스 함수 자체가 이러한 진행 중인 연결을 관리합니다. 일반적인 방법은 패킷을 삭제하고 클라이언트에 의존하여 새 연결을 시작한 후 처음부터 서비스 체인에 원활하게 통합하는 것입니다.
리소스 수명 주기
TrafficSelector 및 ServiceFunctionChain 리소스는 모두 삭제 대상으로 표시된 직후 삭제됩니다. 리소스 삭제를 방지하거나 지연하는 웹훅 또는 완료자는 없습니다.
포드 간 트래픽
서비스 조정은 서비스 가상 IP 주소를 확인한 후 트래픽 선택을 수행합니다. 목적지 포드의 IP 주소가 가상 IP 주소가 확인된 후 .egress.to.ipBlock 필드에 지정된 CIDR 내에 있는 경우 ClusterIP를 사용하여 서비스로 전달되는 트래픽을 서비스 조정으로 선택할 수 있습니다.
NetworkPolicy 적용
서비스 조정은 NetworkPolicy를 우회하지 않습니다. 소스 포드의 이그레스 정책과 목적지 포드의 인그레스 정책은 서비스 조정을 위해 선택된 트래픽에 계속 적용됩니다. 그러나 서비스 함수의 인그레스 또는 이그레스 시 NetworkPolicy 시행은 적용되지 않습니다. NetworkPolicy의 인그레스 또는 이그레스 규칙은 소스 및 목적지 포드에 잘 정의되지만 패킷 전달자에는 정의되지 않기 때문입니다.
이점
GKE 서비스 조정을 채택하고 클라우드 네이티브 기술로 전환하면 다음과 같은 이점이 있습니다.
- Marketplace 서비스: 제3자는 Google Cloud Marketplace에서 컨테이너화된 제품을 제공하고 서비스 조정 API를 사용할 수 있습니다. GKE에서 제공하고 관리하는 Kubernetes 내장 API를 기반으로 배포 가이드를 제공할 수 있습니다.
- Kubernetes 세분성: Kubernetes 클러스터 내에서 트래픽을 제어할 수 있습니다. 조정하려는 트래픽을 분류할 수 있습니다. 서비스 조정을 선택적으로 적용할 워크로드를 선택할 수 있습니다.
- 양방향성: GKE의 서비스 조정은 기본적으로 양방향입니다. 즉, 특정 흐름에서 반환 경로는 전달 경로에 대칭적입니다. 이는 서비스 함수(SF)가 복제본 그룹으로 배포될 때 중요합니다. 스테이트풀(Stateful)을 유지하기 위해 동일한 흐름이 동일한 설정된 복제본을 통과해야 합니다.
- 다중 네트워크 지원: 대부분의 서비스 함수에는 컨트롤 플레인 및 관리 영역으로부터 데이터 영역을 분리하기 위한 여러 포드 인터페이스가 필요합니다. 일부 서비스 함수에는 아키텍처의 일부로 여러 인터페이스가 있습니다. GKE의 서비스 조정에는 포드의 멀티 네트워크와의 통합이 포함됩니다. 이를 통해 사용자는 특정 포드 네트워크에 서비스 조정을 만들 수 있습니다.
- 애플리케이션에 원시 패킷 전송: GKE의 서비스 조정은 원래 패킷을 캡슐화하여 포드로 직접 전달합니다. 이렇게 하면 캡슐화를 해제할 필요가 없으며 애플리케이션이 원래 패킷에서 직접 작동할 수 있습니다.