[Azure / AKS] AGIC vs Application Gateway for Containers

Gateway API 기반 Gateway/Route 분리 전략

AKS에서 L7 Ingress를 구성할 때 예전에는 Ingress-NGINX + AGIC(Application Gateway Ingress Controller) 조합이 사실상 정석에 가까웠다.

하지만 Kubernetes 커뮤니티가 Gateway API를 차세대 표준으로 밀기 시작했고, Azure도 이에 맞춰 Application Gateway for Containers(AGfC) 를 내놓으면서 흐름이 크게 바뀌고 있다.Microsoft Tech Community+1

이 글에서는,

AGIC와 AGfC의 차이
Kubernetes Gateway API에서 Gateway / HTTPRoute 역할 분리
AGfC에서 Gateway/Route 기반으로 멀티 서비스·멀티 팀·멀티 테넌시를 어떻게 설계할 수 있는지
실제 YAML 예시 (멀티 사이트 호스팅, 트래픽 분할, Path/Header 기반 라우팅)

까지 한 번에 정리해 본다.

대상 독자

AKS를 이미 운영 중이고 Ingress를 AGfC로 옮기려는 사람

Gateway API 기반으로 Gateway/Route 분리 전략을 설계하고 싶은 DevOps / SRE / 아키텍트

AGIC → AGfC 마이그레이션과 운영 모델을 고민 중인 팀

1. AGIC vs Application Gateway for Containers 한눈에 비교

1-1. AGIC(Application Gateway Ingress Controller) 개요

AGIC는 AKS 내부에서 돌면서 Kubernetes Ingress 리소스를 감시하고, 이를 기존 Application Gateway(클래식 L7 LB) 설정으로 변환해주는 컨트롤러다.Azure 문서+1

데이터 플레인: 기존 Application Gateway
컨트롤 플레인: AKS 안에서 띄운 ingress-controller Pod
구성 인터페이스:
- Kubernetes Ingress + Annotation
- 일부 기능은 Annotation에 의존 (예: WAF, 리디렉션, 멀티 사이트 등)azure.github.io

1-2. Application Gateway for Containers(AGfC) 개요

AGfC는 AGIC의 “진화 버전”으로, Kubernetes Gateway API를 네이티브로 지원하는 L7 LB + 동적 트래픽 관리 제품이다.Microsoft Learn+2GitHub+2

AKS용 애플리케이션 계층 부하 분산 + 동적 라우팅 전용 제품
Gateway API + Ingress API 둘 다 지원, 단 Gateway API 사용 권장Microsoft Learn+2Microsoft Learn+2
거의 실시간에 가까운 라우팅 업데이트, 트래픽 분할, WAF, 멀티 사이트 호스팅 등 지원Microsoft Learn+3Microsoft Learn+3Microsoft Learn+3

공식 문서에서도 AGIC 대비 장점으로 성능, 트래픽 분할, Gateway API 지원, Kubernetes/ARM 양쪽에서 구성 가능 등을 언급하며, AGIC → AGfC 마이그레이션을 권고하고 있다.Microsoft Learn+1

2. Kubernetes Gateway API 핵심 개념 정리

(Gateway / HTTPRoute 역할 분리가 왜 중요한지)

Gateway API는 Kubernetes의 다음 세대 L4/L7 라우팅 표준이다. 기존 Ingress의 한계를 보완하기 위해 설계되었고, Ingress + LoadBalancer + Service Mesh까지 포괄하는 범용 모델을 목표로 한다.Kubernetes+2gateway-api.sigs.k8s.io+2

가장 중요한 포인트는 역할(퍼소나) 기반 리소스 분리다.

GatewayClass
- 인프라 제공자(Cloud / 플랫폼 팀) 관점
- 어떤 종류의 LB를 쓸지, 어떤 구현체를 사용할지 정의
Gateway
- 클러스터/플랫폼 운영자 관점
- “어떤 IP/포트/도메인으로 들어온 트래픽을 받을 것인가”
- Listener, TLS, 기본 정책 등 Layer 7 수신부 정의
HTTPRoute (또는 GRPCRoute, TCPRoute 등)
- 앱 개발자/서비스 팀 관점
- “어떤 Path/Host/Header/Query에 따라 어떤 Service로 라우팅할 것인지” 정의gateway-api.sigs.k8s.io+2Kgateway+2

즉,

Gateway = 수신점 / 인프라 레벨

HTTPRoute = 라우팅 룰 / 애플리케이션 레벨

로 나눠서 관리할 수 있다는 게 핵심이다.

이 구조 덕분에,

인프라 팀은 IP, DNS, 인증서, WAF, 공용 Listener, 보안 정책에 집중하고
서비스 팀은 Path/Host/버전별 라우팅, Canary/Blue-Green에 집중하는
분업이 가능해진다.

3. AGfC 아키텍처와 컴포넌트 이해하기

공식 문서를 기준으로 AGfC는 다음과 같이 구성된다.Microsoft Learn+2Microsoft Learn+2

데이터 플레인:
- Azure 리소스로 배포된 Application Gateway for Containers(ALB)
- AKS 외부에 존재하며, Frontend IP/Port를 가진 L7 LB
컨트롤 플레인:
- AKS에 배포되는 Application Load Balancer(ALB) Controller
- Gateway / HTTPRoute 등 Gateway API 리소스를 감시하고
- → AGfC 리소스를 프로비저닝/업데이트

요청 흐름은 대략 다음과 같다.Microsoft Learn+1

클라이언트 → AGfC Frontend(IP/도메인)로 HTTP(S) 요청
AGfC는 Listener → Gateway → HTTPRoute 구성을 기반으로 라우팅 결정
선택된 백엔드(Target Group, Pod, Service)로 요청 전달
x-forwarded-for, x-request-id 등을 헤더에 추가해 애플리케이션까지 전달

여기까지가 큰 그림이고, 이제 Gateway/Route 기반 분리 전략을 실제로 어떻게 가져갈 수 있는지 살펴보자.

4. Gateway / HTTPRoute 기반 분리 전략 패턴

Gateway API의 장점은 **“Gateway는 공유, Route는 분리”**라는 모델을 자연스럽게 가져갈 수 있다는 점이다.

여기서는 AKS + AGfC 환경을 기준으로 자주 쓰이는 3가지 패턴을 정리해 본다.

4-1. 인프라 팀이 Gateway, 서비스 팀이 Route 관리

시나리오

인프라/플랫폼 팀:
- 공용 도메인, 인증서, IP, WAF, Frontend Listener 관리
서비스 팀:
- api.service.com, admin.service.com 같은 호스트/Path 라우팅
- 신규 서비스, 버전별 Canary, Blue-Green 등

구성 아이디어

infra 네임스페이스에 Gateway 리소스를 생성
각 앱 팀 네임스페이스에 HTTPRoute를 생성
HTTPRoute에서 parentRefs로 infra 네임스페이스의 Gateway를 참조

# infra-namespace 에서 관리하는 Gateway 예시
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra
spec:
  gatewayClassName: azure-alb
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.cloudnote.dev"
      tls:
        mode: Terminate
        certificateRefs:
          - name: cloudnote-cert

# app1 네임스페이스에서 관리하는 HTTPRoute 예시
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app1-route
  namespace: app1
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
      sectionName: https
  hostnames:
    - "api.cloudnote.dev"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: app1-svc
          port: 80

이렇게 구성하면,

인프라 팀은 Gateway(Listener/TLS/WAF) 만 관리
각 팀은 자기 네임스페이스 내 Route와 Service만 손대면 됨
RBAC으로 네임스페이스별 HTTPRoute 권한만 주면,
공용 Gateway는 건드리지 못하게 막을 수 있다.Mischa van den Burg+1

4-2. 도메인/서비스 별 Route 분리 (멀티 사이트 호스팅)

AGfC는 하나의 Gateway 리소스(= AGfC Frontend)에서 여러 사이트/도메인을 동시에 호스팅하는 시나리오를 공식 문서에서 예시로 제공한다.Microsoft Learn+2Microsoft Learn+2

대표적인 패턴:

www.cloudnote.dev → 프론트엔드 SPA
api.cloudnote.dev → 백엔드 API
admin.cloudnote.dev → 관리 콘솔

Gateway는 하나, HTTPRoute는 여러 개로 분리한다.

# 하나의 Gateway에 여러 Host를 허용
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra
spec:
  gatewayClassName: azure-alb
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.cloudnote.dev"
      tls:
        mode: Terminate
        certificateRefs:
          - name: cloudnote-cert

# www Route
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: web
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
      sectionName: https
  hostnames:
    - "www.cloudnote.dev"
  rules:
    - backendRefs:
        - name: web-frontend-svc
          port: 80

# API Route
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: api
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
      sectionName: https
  hostnames:
    - "api.cloudnote.dev"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: / # 전체
      backendRefs:
        - name: api-backend-svc
          port: 8080

이 패턴을 쓰면,

도메인 별로 Route를 분리하면서도
실제 Application Gateway for Containers는 하나만 운영할 수 있어 비용/운영 측면에서 효율적이다.Microsoft Learn+2GitHub+2

4-3. 팀/조직 별 Route 분리 + Cross-namespace 라우팅

Gateway API는 Cross-namespace 라우팅도 지원한다.Tigera - Creator of Calico+2Mischa van den Burg+2

즉,

Gateway는 infra 네임스페이스
HTTPRoute는 team-a, team-b, team-c 네임스페이스
Backend Service는 또 다른 네임스페이스에 있어도 된다

예시: Route는 team-a, 백엔드는 shared namespace

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: team-a-api
  namespace: team-a
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
      sectionName: https
  hostnames:
    - "team-a-api.cloudnote.dev"
  rules:
    - backendRefs:
        - name: team-a-api-svc
          namespace: shared-backend
          port: 8080

이렇게 가져가면,

앱 팀은 자기 Route만 관리
백엔드/코어 서비스는 별도 네임스페이스로 격리
RBAC·NetworkPolicy·네임스페이스 전략과 결합해서
팀/조직 구조를 그대로 라우팅 계층에 투영할 수 있다.

5. Gateway API로 가능한 고급 라우팅 패턴 (AGfC 연동)

AGfC는 Gateway API의 다양한 기능을 그대로 활용한다. 공식 문서 기준으로 Path / Header / QueryString 기반 라우팅, 트래픽 분할(Weighted routing) 등을 지원한다.Microsoft Learn+2Microsoft Learn+2

5-1. Path / Header / Query 기반 라우팅

예시:

/api는 백엔드 API
/admin은 관리자 콘솔
특정 Header(X-Canary: true)가 있는 트래픽만 Canary 버전으로 보내기

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: advanced-route
  namespace: api
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
      sectionName: https
  hostnames:
    - "api.cloudnote.dev"
  rules:
    # /api/* → main API
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-v1-svc
          port: 8080

    # /admin/* → admin 콘솔
    - matches:
        - path:
            type: PathPrefix
            value: /admin
      backendRefs:
        - name: admin-svc
          port: 80

    # 특정 헤더가 있는 요청만 canary 로 보내기
    - matches:
        - headers:
            - type: Exact
              name: X-Canary
              value: "true"
      backendRefs:
        - name: api-v2-canary-svc
          port: 8080

공식 예제에서도 URL 경로, 쿼리 문자열, 헤더에 따라 다른 백엔드로 보내는 패턴을 보여준다.Microsoft Learn+2gateway-api.sigs.k8s.io+2

5-2. 트래픽 분할(Weighted Routing)로 Canary / Blue-Green

AGfC + Gateway API 조합은 가중치 기반 트래픽 분할을 지원한다.Tigera - Creator of Calico+3Microsoft Learn+3Microsoft Learn+3

예시:

api-v1 80%, api-v2 20% 비율로 트래픽 분배

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-canary
  namespace: api
spec:
  parentRefs:
    - name: shared-gateway
      namespace: infra
      sectionName: https
  hostnames:
    - "api.cloudnote.dev"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-v1-svc
          port: 8080
          weight: 80
        - name: api-v2-svc
          port: 8080
          weight: 20

이 구조를 활용하면,

처음엔 v2에 5~10%만 보내서 Canary 테스트
에러 없으면 30% → 50% → 100%로 점진 롤아웃
문제가 생기면 weight 값을 조정해 즉시 롤백

같은 Blue-Green/Canary 전략을 아주 자연스럽게 구현할 수 있다.

6. 보안 & 운영: AGfC + Azure WAF, TLS, 로그

AGfC는 Azure Web Application Firewall와 통합할 수 있고, Gateway 레벨에서 TLS 및 보안 정책을 통일 관리할 수 있다.Microsoft Learn+2Microsoft Learn+2

6-1. TLS 종료 & 인증서 관리

TLS 인증서는 Gateway 리스너에서 Terminate
HTTPRoute에서는 일반 HTTP 라우팅만 신경 쓰면 됨
인증서 로테이션, 도메인 추가는 인프라(Gateway) 레벨에서만 처리

6-2. WAF 정책

AGfC Frontend에 Azure WAF 정책을 붙여서
- OWASP 룰셋, Rate Limit, 특정 패턴 차단을 Gateway 레벨에서 적용
HTTPRoute는 비즈니스/애플리케이션 로직 라우팅만 담당

6-3. 로깅 & 모니터링

AGfC는 요청에 x-request-id 헤더를 추가해 주기 때문에,

애플리케이션 로그 + AGfC 로그를 이 ID로 묶어서 추적할 수 있다.Microsoft Learn+1

Azure Monitor / Log Analytics / APM(예: Datadog)와 연동해
- 라우트별, 서비스별, 버전별 트래픽/에러율 모니터링
Canary/Blue-Green 시나리오에서도 Route + 로그만으로도 충분한 가시성을 확보

7. AGIC → AGfC 마이그레이션 시 Gateway/Route 전략 팁

Microsoft는 AGIC에서 AGfC로의 마이그레이션에 대해 점진·무중단 전환을 권고한다.Microsoft Learn+1

핵심 아이디어:

기존 AGIC + Application Gateway는 그대로 둔다
AGfC + Gateway API 기반 구성을 병렬로 추가
DNS, Path, Host 단위로 트래픽을 점진적으로 AGfC로 이동
충분히 검증되면 AGIC 관련 리소스를 정리

이를 Gateway/Route 관점에서 보면,

1단계 – 동일 도메인에 별도 Path 붙이기
- /api는 기존 AGIC, /api-v2는 AGfC로 라우팅
2단계 – Host 분리 후 전환
- api-v2.cloudnote.dev를 AGfC에 먼저 붙이고
- 모든 검증이 끝나면 api.cloudnote.dev의 DNS를 AGfC로 변경
3단계 – Same Host + Weighted Routing
- AGfC 도입 후에는 HTTPRoute의 weight 기능으로
- 점진 트래픽 전환/롤백 자동화 가능

8. 정리 – AKS에서 Gateway/Route 분리를 어떻게 가져갈 것인가

정리하면,

AGIC
- Ingress + Annotation 기반
- Application Gateway(클래식) 구성에 최적화
AGfC + Gateway API
- Gateway / HTTPRoute로 역할 분리
- 멀티 사이트 호스팅, 트래픽 분할, Cross-namespace 라우팅
- 인프라와 애플리케이션의 책임 분리가 명확해짐Mischa van den Burg+3Microsoft Tech Community+3Microsoft Learn+3

Gateway/Route 기반 분리 전략의 핵심은 세 가지다.

Gateway는 인프라 팀, Route는 서비스 팀
- Listener, 도메인, 인증서, WAF, 공통 정책은 Gateway
- 각 서비스의 Path/Host/버전 라우팅은 HTTPRoute
하나의 Gateway로 여러 서비스/도메인/팀을 통합
- 멀티 사이트 호스팅, 멀티 테넌시, Cross-namespace 라우팅
- 비용 효율 + 운영 단순화
Canary/Blue-Green, Path/Header/Query 기반 라우팅까지 코드로 관리
- HTTPRoute 하나로 트래픽 전략을 모두 정의
- GitOps와 결합하면 라우팅 변경도 Git PR로 관리 가능

AKS를 이미 운영 중이라면,

새로운 서비스부터라도 AGfC + Gateway API + Gateway/Route 분리 패턴으로 설계해 두면,

장기적으로 마이그레이션과 운영이 훨씬 수월해진다.

'DevOps > Cloud' 카테고리의 다른 글

[Azure] Azure Front Door 보안 강화 (Service Tag + AFID 기반 백엔드 보호 전략) (0)	2025.12.11
[Azure] Azure Bastion + Key Vault Secret 기반 SSH 접속 (0)	2025.12.02
[Azure] Azure Virtual Desktop(AVD) 가이드 (0)	2025.12.02
[Cloud] AWS vs Azure 비교 완벽 가이드 (0)	2025.11.28
[Azure] AKS(Azure Kubernetes Service) 살펴보기 (0)	2025.11.28

Gateway API 기반 Gateway/Route 분리 전략

1. AGIC vs Application Gateway for Containers 한눈에 비교

1-1. AGIC(Application Gateway Ingress Controller) 개요

1-2. Application Gateway for Containers(AGfC) 개요

2. Kubernetes Gateway API 핵심 개념 정리

(Gateway / HTTPRoute 역할 분리가 왜 중요한지)

3. AGfC 아키텍처와 컴포넌트 이해하기

4. Gateway / HTTPRoute 기반 분리 전략 패턴

4-1. 인프라 팀이 Gateway, 서비스 팀이 Route 관리

4-2. 도메인/서비스 별 Route 분리 (멀티 사이트 호스팅)

4-3. 팀/조직 별 Route 분리 + Cross-namespace 라우팅

5. Gateway API로 가능한 고급 라우팅 패턴 (AGfC 연동)

5-1. Path / Header / Query 기반 라우팅

5-2. 트래픽 분할(Weighted Routing)로 Canary / Blue-Green

6. 보안 & 운영: AGfC + Azure WAF, TLS, 로그

6-1. TLS 종료 & 인증서 관리

6-2. WAF 정책

6-3. 로깅 & 모니터링

7. AGIC → AGfC 마이그레이션 시 Gateway/Route 전략 팁

8. 정리 – AKS에서 Gateway/Route 분리를 어떻게 가져갈 것인가

'DevOps > Cloud' 카테고리의 다른 글

티스토리툴바