Envoy Gateway 모범 사례: 운영 전에 미래의 나를 좀 도와주자

"돌아간다"와 "시스템이 실제로 안정적이다"는 완전히 다른 우주입니다. ingress 계층 사고의 대부분은 Envoy Gateway가 부족해서가 아니라, 설정을 너무 가볍게 잡아 운영이 끝없는 놀라움 상자로 바뀌기 때문에 생깁니다. 이 글에서는 가장 실용적인 권장사항을 체크리스트 형태로 정리합니다.

권장 사항

1. Gateway 소유자와 Route 소유자를 명확히 나누기

여러 사람이 관여한다면 책임을 분리하세요:

플랫폼 팀이 GatewayClass, Gateway를 관리
앱 팀은 각자의 HTTPRoute를 관리

이점은 명확합니다. ingress 계층의 보안과 노출 범위를 모든 앱이 제멋대로 바꾸지 못하게 하면서도, 앱 팀은 라우팅 유연성을 유지할 수 있습니다. 이것이 Gateway API 설계를 쓸 가치가 있는 이유입니다. 다시 거대한 단일 YAML 덩어리로 납작하게 만들지 마세요.

2. 처음부터 TLS를 기본값으로 취급하기

"일단 HTTP로 시작하고 HTTPS는 나중에 붙이자"라고 생각하지 마세요. 그 "나중"은 거의 항상 금요일 밤 긴급 작업으로 돌아옵니다.

최소한 다음은 갖추세요:

외부 listener는 기본적으로 HTTPS
인증서 소스는 관리 절차가 명확함
테스트, self-signed, 운영 CA 워크플로는 분리됨

이미 cert-manager가 있다면 연동하세요. 인증서 갱신 때마다 Secret을 손으로 patch하는 것보다 자동 회전이 훨씬 믿을 만합니다.

3. Route 규칙은 명시적으로 쓰기, 편의성만 보고 과도하게 최적화하지 말기

이런 규칙은 편하긴 하지만 블랙홀로 변하기 쉽습니다:

rules:
  - backendRefs:
      - name: backend
        port: 8080

틀린 건 아닙니다. 하지만 시스템이 커질수록 이런 "전부 받기" 규칙이 많아지면 디버깅이 고통스러워집니다. hostnames를 쓸 수 있다면 쓰고, path를 쓸 수 있다면 분명하게 써두세요.

4. 트래픽은 조금씩 잘라 보내기, 한 번에 올인하지 말기

새 버전을 배포할 때는 먼저 작은 비율만 보내세요:

backendRefs:
  - name: api-v1
    port: 8080
    weight: 90
  - name: api-v2
    port: 8080
    weight: 10

이 방식은 "서비스 selector를 한 번에 통째로 뒤집는 것"보다 훨씬 부드럽습니다. 문제가 생겼을 때 롤백도 훨씬 빠릅니다. 새벽 3시에는 이 차이가 정말 크게 느껴집니다.

5. `status`와 이벤트를 확인하는 습관 들이기

YAML만 읽어서는 부족합니다. 컨트롤러가 실제로 설정을 받아들였는지 봐야 합니다:

kubectl get gateway -A
kubectl get httproute -A
kubectl describe gateway eg
kubectl describe httproute app-route

이런 문제들은 spec만 보고는 잘 보이지 않습니다:

Route가 accepted 되지 않음
네임스페이스 간 참조가 막힘
Listener 상태 이상

가장 최악인 상황은 버그 자체가 아니라, "적용된 줄 알았는데 애초에 받아들여지지도 않은 경우"입니다.

흔한 함정

함정 1: Envoy Gateway를 멍청한 포워딩 블랙박스로 취급하기

이건 단순히 패킷을 A에서 B로 옮기는 도구가 아닙니다. 공식 문서도 이를 Kubernetes 네이티브 API Gateway로 위치시키며, 여기에 더 많은 트래픽 정책과 보안 정책을 쌓을 수 있다고 설명합니다. 단지 Ingress 대체재로만 쓰면 잠재력을 지나치게 덜 쓰는 셈입니다.

함정 2: `ReferenceGrant` 없이 네임스페이스 간 인증서를 참조하기

많은 사람이 certificateRefs가 namespace 필드를 지원하는 걸 보고 곧바로 다른 네임스페이스를 가리킨 뒤, 왜 아무 일도 일어나지 않는지 궁금해합니다. 대개 귀신이 장난치는 게 아니라 ReferenceGrant가 빠진 것입니다.

함정 3: 해피 패스만 테스트하기

이것만 테스트하지 마세요:

curl http://... 한 번 성공

이것도 함께 테스트하세요:

서로 다른 hostname
서로 다른 path
TLS 인증서 유효성
트래픽 분할 비율이 기대대로 동작하는지

ingress 계층은 해피 패스는 멀쩡해 보여도 엣지 케이스가 바로 깨질 때 가장 위험합니다.

함정 4: 데모 설정을 운영에 그대로 가져가기

공식 quickstart는 학습용으로 아주 훌륭하지만, 어디까지나 quickstart입니다. 운영 환경에서는 최소한 다음을 추가해야 합니다:

인증서 자동화
모니터링과 알림
변경 관리 프로세스
Route 네이밍 규칙

그렇지 않으면 오늘의 quickstart가 내일의 quick-fall이 됩니다.

최소한의 배포 전 체크리스트

라이브 전에는 이것을 확인하세요:

Gateway listener가 HTTP / HTTPS를 명확히 분리하는가?
인증서 Secret과 회전 절차가 분명한가?
HTTPRoute에 명확한 hostnames / matches가 있는가?
중요한 변경은 작은 트래픽 컷으로 배포되는가?
status와 이벤트만으로 문제를 빠르게 찾을 수 있는가?

이 다섯 가지가 갖춰져 있다면, 이미 "일단 되니까 괜찮다" 수준보다 훨씬 높은 곳에서 운영하고 있는 겁니다.

한 줄 요약

Envoy Gateway의 진짜 가치는 단순히 트래픽을 라우팅하는 데 있지 않습니다. ingress 계층 구성을 더 표준화하고, 더 분리 가능하게 만들고, 더 거버넌스 가능하게 만드는 데 있습니다. 기능은 일시적이지만 운영은 장기전입니다. 미래의 나를 배려하는 일은 실제로 중요합니다.

다음 단계

혹시 아직 머릿속에 이런 질문이 남아 있다면:

"개념은 알겠는데, 새 요구사항이 들어오면 실제로 어떤 route 타입을 골라야 하지?"

다음 글이 치트시트입니다: 👉 Route 타입 치트시트