문이 둘이면 경비도 둘이어야 한다

한 줄 요약

메시로 들어오는 문(인그레스 게이트웨이)은 사이드카가 아니라 혼자 도는 Envoy 다. Istio 에서 그 문을 여는 방법은 두 가지다 — 이미 떠 있는 게이트웨이를 골라 설정을 얹는 Istio Gateway, 그리고 Gateway 리소스 하나로 게이트웨이를 새로 세우는 쿠버네티스 Gateway API.

왜 이게 필요했나

사이드카는 파드 안에서 나가고 들어오는 트래픽을 다룬다. 클러스터 밖 사용자의 요청은 어느 파드의 사이드카도 아닌 곳에서 받아야 하고, 거기서 TLS 를 풀고, 호스트 이름으로 나누고, 이상한 경로를 막아야 한다. 쿠버네티스의 Ingress 리소스는 그 일을 하기엔 표현이 모자랐다 — 헤더 조건, 가중치, TLS 방식이 전부 컨트롤러마다 다른 애너테이션이었다.

Istio 는 처음에 자기 API(Gateway + VirtualService)로 이 문제를 풀었고, 쿠버네티스는 그 경험을 모아 벤더 중립의 Gateway API 를 만들었다. Istio 문서는 Gateway API 를 앞으로의 기본 트래픽 관리 API 로 삼겠다고 밝힌다. 그래서 지금은 두 방식이 함께 쓰이고, 같은 메시에 문이 둘 생기는 일이 흔하다.

어떻게 동작하나

Istio Gateway — 게이트웨이를 고르고, 받을 것을 정한다.

Gateway mall-gw          selector: istio=ingressgateway   ← 이미 떠 있는 파드를 고른다
  servers: 80 HTTP  mall.example.com
           443 HTTPS mall.example.com  credentialName: mall-cred
VirtualService mall-ingress   gateways: [mall-gw]          ← 어디로 보낼지는 여기서

Gateway 만 있으면 게이트웨이는 받긴 하지만 보낼 곳을 몰라 404 를 준다. VirtualService 가 gateways 에 그 이름을 적어야 둘이 이어진다.

TLS 는 SDS 로 받는다. credentialName 은 파일 경로가 아니라 Secret 이름이다. istiod 가 그 Secret 을 읽어 게이트웨이 Envoy 에 SDS 로 내려보내므로, 인증서를 갈아 끼워도 게이트웨이를 재시작하지 않는다. 대신 Secret 은 게이트웨이 파드와 같은 네임스페이스에 있어야 한다.

Gateway API — Gateway 가 게이트웨이를 세운다.

	Istio Gateway	Gateway API Gateway
게이트웨이 파드	미리 설치된 것을 셀렉터로 고른다	Gateway 마다 `<이름>-istio` Deployment·Service 를 만든다
선 곳	대개 istio-system	Gateway 가 있는 네임스페이스
라우팅	VirtualService(`gateways:`)	HTTPRoute(`parentRefs:`)
세부 조정	IstioOperator·Helm 값	`infrastructure.parametersRef` 의 ConfigMap

게이트웨이를 스스로 세운다는 것은 팀마다 자기 문을 따로 늘리고 줄일 수 있다는 뜻이다. 그만큼 파드가 늘고, 무엇보다 문마다 정책을 따로 걸어야 한다.

인가 정책도 워크로드에 붙는다. 게이트웨이는 Envoy 워크로드라 AuthorizationPolicy 를 셀렉터로 붙일 수 있고, 거기서 막은 요청은 메시 안으로 들어오지 않는다. 하지만 셀렉터가 istio: ingressgateway 라면 Gateway API 가 새로 세운 게이트웨이에는 걸리지 않는다.

현장에서 만나는 모습

"Gateway 를 만들었는데 Programmed 가 안 됩니다." 자동 배포된 서비스가 LoadBalancer 주소를 받지 못하면 그렇다. 클라우드라면 로드밸런서 할당량, 온프레미스라면 LB 구현이 없는 경우가 흔하다. 이 VM 의 k3s 에서는 80 포트를 이미 다른 게이트웨이가 차지해 새 서비스가 <pending> 에 머문다.

"인증서를 바꿨는데 옛 인증서가 보입니다." Secret 을 다른 네임스페이스에 만들었거나 이름이 credentialName 과 다르다. istioctl proxy-config secret 으로 게이트웨이가 실제로 받은 인증서를 보면 바로 가려진다.

"관리 경로를 막았는데 새 게이트웨이로는 들어옵니다." 문을 새로 열면서 경비를 옮겨 세우지 않은 경우다. 게이트웨이를 추가할 때 인가 정책의 셀렉터(또는 targetRefs)를 함께 검토해야 하는 이유다.

공식 문서: Ingress Gateways · Secure Gateways · Kubernetes Gateway API · Authorization on ingress gateways

다음 실습에서 할 것

VM 안의 진짜 메시(k3s + Istio 1.31.0)에 앱 두 벌을 올리고, Istio Gateway 로 HTTP·HTTPS 문을 연 뒤, Gateway API 로 두 번째 문을 세워 헤더와 가중치로 나눈다. 두 게이트웨이가 어디에 서 있는지 비교하고, 첫 문에 건 /admin 차단이 두 번째 문에는 걸리지 않는 것을 상태 코드로 확인한다.