Featured image of post [Kubernetes] Gateway API로 멀티클러스터 게이트웨이 설정하기
Kubernetes

[Kubernetes] Gateway API로 멀티클러스터 게이트웨이 설정하기

Kubernetes Gateway API로 멀티클러스터·멀티클라우드 트래픽을 표준화하는 방법을 다룹니다. EKS·GKE·Istio 기반 데모, Gateway·HTTPRoute 배포와 통신 검증, TLS·트래픽 분할·블루그린·카나리, GKE Gateway Controller 요약, FAQ 및 공식·GKE·DZone·Medium 참고 자료를 포함합니다.

Kubernetes Gateway API는 Kubernetes Network SIG에서 제안한 Ingress의 진화형으로, 클러스터 외부 트래픽을 표준화하고 멀티클러스터·멀티클라우드 환경에서의 라우팅을 단일 API로 다룰 수 있게 한다. 이 글에서는 Gateway API 사양을 활용해 EKS(주 클러스터)와 GKE(원격 클러스터)에서 Istio를 사용한 멀티클러스터 게이트웨이 구성을 단계별로 소개하고, 보안·트래픽 관리·실무 예제까지 다룬다.

개요

Kubernetes Gateway API란

Kubernetes Gateway API는 클라우드 네이티브 애플리케이션의 트래픽 관리를 위한 표준 API로, 기존 Ingress보다 유연한 라우팅·역할 분리·다중 프로토콜 지원을 제공한다. HTTPRoute, TCPRoute, TLSRoute 등을 통해 세밀한 트래픽 제어가 가능하며, 여러 클러스터와 클라우드에 걸친 서비스 통합을 단순화한다.

멀티클러스터·멀티클라우드가 필요한 이유

  • 고가용성(HA): 한 리전·클라우드 장애 시 다른 클러스터로 트래픽 전환
  • 지연 최소화: 사용자와 가까운 리전으로 라우팅
  • 비용·정책: 벤더별 장점 활용, 규정 준수·데이터 거주지 요구 반영

이 글의 목적과 구성

  • 목적: Gateway API로 멀티클러스터 게이트웨이를 구성하고 검증하는 방법을 실습 수준에서 소개
  • 구성: 데모 환경 소개 → 애플리케이션·서비스 배포 → Gateway·HTTPRoute 배포 및 통신 검증 → 멀티클러스터 게이트웨이 설정 → 보안·트래픽 관리 → 예제·FAQ·참고 자료
graph TD
  App["애플리케이션"] -->|"배포"| ClusterA["클러스터 A"]
  App -->|"배포"| ClusterB["클러스터 B"]
  ClusterA -->|"통신"| SvcA["서비스 A"]
  ClusterB -->|"통신"| SvcB["서비스 B"]
  SvcA -->|"트래픽 관리"| GatewayApi["Gateway API"]
  SvcB -->|"트래픽 관리"| GatewayApi

멀티클러스터 Kubernetes Gateway 데모 개요

데모 환경

  • 주 클러스터: Amazon EKS (Elastic Kubernetes Service)
  • 원격 클러스터: Google GKE (Google Kubernetes Engine)
  • 서비스 메쉬: Istio (primary-remote 구성), Gateway API 컨트롤러로 사용

EKS와 GKE 간 통신을 Istio로 묶고, Gateway API 리소스로 진입점과 라우팅을 정의한다.

graph LR
  EksCluster["EKS 클러스터"] -->|"HTTP 요청"| GatewayApi["Gateway API"]
  GatewayApi -->|"서비스 호출"| GkeCluster["GKE 클러스터"]
  GkeCluster -->|"응답"| GatewayApi
  GatewayApi -->|"응답"| EksCluster

데모 진행 순서

  1. 서비스·배포 구성: 양쪽 클러스터에 helloworld·echoserver용 Service·Deployment 배포
  2. Gateway API 리소스 배포: 주 클러스터(EKS)에 Gateway·HTTPRoute 적용 후, 원격 클러스터(GKE) 서비스까지 도달하는지 검증

클러스터에서 애플리케이션 및 서비스 배포

사용하는 리소스 요약

리소스주 클러스터 EKS원격 클러스터 GKE
helloworld Service✓✓
helloworld Deployment v1✓—
helloworld Deployment v2—✓
echoserver Service✓✓
echoserver Deployment—✓

원격에만 배포가 있어도, 서비스 리소스는 양쪽에 두어 Gateway가 백엔드를 찾을 수 있게 한다.

helloworld-service.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: v1
kind: Service
metadata:
  name: helloworld
spec:
  selector:
    app: helloworld
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

helloworld-deployment v1 / v2

v1은 EKS, v2는 GKE에 배포한다. version: v1 / version: v2 라벨과 이미지만 다르게 두면 된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# helloworld-deployment-v1 (EKS)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: helloworld
      version: v1
  template:
    metadata:
      labels:
        app: helloworld
        version: v1
    spec:
      containers:
        - name: helloworld
          image: myrepo/helloworld:v1
          ports:
            - containerPort: 8080

echoserver Service·Deployment

echoserver는 원격 클러스터에만 Deployment를 두고, Service는 두 클러스터 모두에 만든다.

1
2
3
4
5
6
7

kubectl apply -f helloworld-service.yaml --context=eks-cluster
kubectl apply -f helloworld-service.yaml --context=gke-cluster
kubectl apply -f helloworld-deployment-v1.yaml --context=eks-cluster
kubectl apply -f helloworld-deployment-v2.yaml --context=gke-cluster
kubectl apply -f echoserver-service.yaml --context=eks-cluster
kubectl apply -f echoserver-service.yaml --context=gke-cluster
kubectl apply -f echoserver-deployment.yaml --context=gke-cluster

배포 확인

1
2
3
4

kubectl get svc -n demo --context=eks-cluster
kubectl get pods -n demo --context=eks-cluster
kubectl get svc -n demo --context=gke-cluster
kubectl get pods -n demo --context=gke-cluster

graph TD
  Cluster["클러스터"] -->|"배포"| HwSvc["helloworld 서비스"]
  Cluster -->|"배포"| HwV1["helloworld v1 배포"]
  Cluster -->|"배포"| HwV2["helloworld v2 배포"]
  Cluster -->|"배포"| EchoSvc["echoserver 서비스"]
  Cluster -->|"배포"| EchoDep["echoserver 배포"]

K8s Gateway API 리소스 배포 및 멀티클러스터 통신 검증

Gateway 리소스 (Istio 컨트롤러)

Gateway는 클러스터 진입점을 정의한다. gatewayClassName: istio로 Istio가 이 Gateway를 구현하게 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-ingress
spec:
  gatewayClassName: istio
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All

HTTPRoute 리소스

HTTPRoute는 Gateway에 붙어 경로별 백엔드와 가중치를 지정한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-http-route
spec:
  parentRefs:
    - name: my-gateway
      namespace: istio-ingress
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: my-service
          port: 80

통신 검증

Gateway에 할당된 주소로 요청을 보내 멀티클러스터 동작을 확인한다.

1
2
3

kubectl get gateway my-gateway -n istio-ingress -o jsonpath='{.status.addresses[0].value}'
curl http://<Gateway_IP>/hello
curl http://<Gateway_IP>/

graph LR
  Client["Client"] -->|"HTTP Request"| Gateway["Gateway"]
  Gateway -->|"Route to Service"| Service["Service"]
  Service -->|"Response"| Gateway
  Gateway -->|"Response"| Client

멀티클러스터 게이트웨이 설정

개념

멀티클러스터 게이트웨이는 여러 클러스터를 하나의 논리적 진입점으로 노출한다. 트래픽은 경로·호스트·가중치에 따라 서로 다른 클러스터의 백엔드로 전달된다.

GKE Gateway Controller

GKE는 Gateway API를 구현하는 GKE Gateway Controller를 제공한다. Fleet에 등록된 클러스터 간 ServiceExport/ServiceImport와 조합해 멀티클러스터 게이트웨이를 구성할 수 있다. 자세한 절차는 GKE 멀티클러스터 게이트웨이 문서를 참고한다.

설정 요약

  • 구성 클러스터: Gateway·HTTPRoute가 배포되는 클러스터
  • 대상 클러스터: ServiceExport로 서비스를 내보내는 클러스터
  • HTTPRoute의 backendRefs에서 ServiceImport를 참조하면 여러 클러스터의 백엔드로 라우팅된다.
graph TD
  ExtTraffic["External Traffic"] -->|"Routes to"| Gateway["Gateway"]
  Gateway -->|"Forwards to"| ClusterA["Cluster A"]
  Gateway -->|"Forwards to"| ClusterB["Cluster B"]
  ClusterA -->|"Service A"| AppA["App A"]
  ClusterB -->|"Service B"| AppB["App B"]

보안 및 트래픽 관리

TLS 설정

  1. TLS Secret 생성 후 Gateway 리스너에 참조한다.
1

kubectl create secret tls my-tls-secret --cert=path/to/tls.crt --key=path/to/tls.key -n my-namespace
  1. Gateway에서 HTTPS 리스너와 certificateRefs 지정:
1
2
3
4
5
6
7
8
9

listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
        - kind: Secret
          name: my-tls-secret

트래픽 분할 (가중치)

HTTPRoute의 backendRefs에 weight를 주면 비율대로 트래픽이 나뉜다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

rules:
  - matches:
      - path:
          type: PathPrefix
          value: /
    backendRefs:
      - name: service-v1
        port: 80
        weight: 80
      - name: service-v2
        port: 80
        weight: 20

블루-그린·트래픽 미러링

  • 블루-그린: 동일 경로에 대해 weight 100으로 한 백엔드만 사용하다가, 배포 후 라우트만 전환
  • 미러링: 일부 구현체는 미러 백엔드로 트래픽 복제를 지원하며, HTTPRoute 확장 또는 구현체별 어노테이션으로 설정한다.

예제

HTTPRoute로 경로·버전별 라우팅

/v1은 v1 80%·v2 20%, /v2는 전부 v2로 보내는 예시다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: v1-service
          port: 80
          weight: 80
        - name: v2-service
          port: 80
          weight: 20
    - matches:
        - path:
            type: PathPrefix
            value: /v2
      backendRefs:
        - name: v2-service
          port: 80

카나리 배포 (개발·테스트)

안정 버전 90%, 카나리 10%로 나누는 예:

1
2
3
4
5
6
7

backendRefs:
  - name: stable-service
    port: 80
    weight: 90
  - name: canary-service
    port: 80
    weight: 10

graph TD
  Client["Client"] -->|"Request /v1"| V1Svc["v1-service"]
  Client -->|"Request /v2"| V2Svc["v2-service"]
  Client -->|"Request /app"| StableSvc["stable-service"]
  Client -->|"Request /app"| CanarySvc["canary-service"]

FAQ

Q. Gateway API와 기존 Ingress의 차이는?

  • Ingress는 주로 HTTP(S) 단일 리소스에 제한적이다. Gateway API는 Gateway·Route·역할(클래스·게이트웨이·라우트 소유자) 분리, TCP/UDP/TLS 등 다중 프로토콜, 크로스 네임스페이스 바인딩을 지원해 확장성과 정책 적용이 쉽다.

Q. 멀티클러스터 장애 조치는?

  • 구현체에 따라 다르다. GKE의 경우 글로벌 부하 분산과 상태 점검으로 비정상 백엔드를 제외하고, 정상 클러스터로만 트래픽을 보낸다. Istio 기반이면 서비스 메쉬 수준의 헬스 체크·폴아웃과 조합할 수 있다.

Q. Istio와 Gateway API를 같이 쓰는 이점은?

  • Gateway API가 표준 라우팅·게이트웨이 모델을 제공하고, Istio가 mTLS·재시도·타임아웃·메트릭 등 고급 기능을 담당한다. 한 번 Gateway API로 정의해 두면 다른 구현체로 바꾸기 쉬워진다.
graph TD
  ClusterA["클러스터 A"] -->|"트래픽"| ClusterB["클러스터 B"]
  ClusterA -->|"모니터링"| FailDetect["장애 감지"]
  FailDetect -->|"트래픽 전환"| ClusterB
  FailDetect -->|"알림"| OpsTeam["운영팀"]

관련 기술

  • Kubernetes: 컨테이너 오케스트레이션, Service·Deployment·Gateway API 리소스의 기반
  • Istio: 서비스 메쉬, 트래픽 제어·보안·관찰성, Gateway API 구현체 중 하나
  • 서비스 메쉬: 마이크로서비스 간 통신·정책·모니터링을 인프라 계층에서 처리
  • 클라우드 네이티브: 컨테이너·오케스트레이션·선언적 API를 전제로 한 설계
graph TD
  K8s["Kubernetes"] --> ServiceMesh["서비스 메쉬"]
  K8s --> CloudNative["클라우드 네이티브 아키텍처"]
  ServiceMesh --> Istio["Istio"]
  ServiceMesh --> TrafficMgmt["트래픽 관리"]
  CloudNative --> MicroSvc["마이크로서비스"]
  CloudNative --> Container["컨테이너"]

결론

  • 멀티클러스터·멀티클라우드 환경에서 Gateway API는 진입점과 라우팅을 표준 리소스로 통일해, 벤더·구현체에 덜 종속된 구성이 가능하게 한다.
  • 역할 분리(GatewayClass·Gateway·HTTPRoute 소유자)로 인프라팀과 앱팀이 협업하기 좋고, TLS·트래픽 분할·블루그린·카나리를 같은 API 패턴으로 다룰 수 있다.
  • 커뮤니티와 구현체(Istio, GKE, Envoy Gateway 등)가 계속 확장 중이므로, 공식 사양과 사용 사례 문서를 함께 참고하는 것을 권한다.
graph LR
  Client["클라이언트"] -->|"HTTP 요청"| GatewayApi["Gateway API"]
  GatewayApi -->|"라우팅"| Eks["EKS 클러스터"]
  GatewayApi -->|"라우팅"| Gke["GKE 클러스터"]
  Eks -->|"서비스 호출"| SvcA["서비스 A"]
  Gke -->|"서비스 호출"| SvcB["서비스 B"]

참고 자료

Related Content

[Data Engineering] 윈도잉 기법: 스트림 처리와 데이터 분석 가이드

윈도잉(Windowing)은 스트림 데이터 처리에서 시간·개수·세션 기준으로 데이터를 그룹화해 실시간 분석과 집계를 가능하게 하는 핵심 기술이다. Apache Kafka·Flink 등에서 활용되며, 메모리 효율성과 패턴 인식, 시스템 부하 최적화에 중요하다. 타임·슬라이딩·세션 윈도우 유형과 적용 사례, 성능 최적화 전략을 체계적으로 설명한다.
[Data Engineering] 윈도잉 기법: 스트림 처리와 데이터 분석 가이드