02 · 다시 길을 고르는 문 — 게이트웨이에서 사이드카까지

외부 요청은 게이트웨이에서 HTTP로 읽힌 뒤, 선택된 파드의 사이드카로 향합니다. 아래는 NLB에 TCP 리스너를 둔 사이드카 모드의 경로입니다.

NLB에서 고르는 게이트웨이

게이트웨이 앞에서는 아직 HTTP를 읽지 않습니다. NLB는 TLS를 풀거나 Host 헤더를 읽지 않으므로, 뒤에 도메인이 열 개 있어도 443 포트로 들어오는 연결만 봅니다.

NLB는 연결을 게이트웨이 파드 쪽으로 나눕니다. instance 대상 모드는 노드의 NodePort를 거쳐 kube-proxy 규칙이 파드를 고르고, ip 대상 모드는 파드 IP를 직접 등록해 노드 홉이 빠집니다. 어느 쪽이든 분산 단위는 연결이라 장수 연결이 한 게이트웨이에 쏠릴 수 있습니다.

여기서는 TLS를 게이트웨이까지 통과시킵니다. NLB에 TLS 리스너를 두면 NLB에서 TLS가 끝나므로 01편의 TLS 종료 위치와 구분해야 합니다.

설정이 바뀌는 자리, 요청이 흐르는 자리

게이트웨이도 사이드카와 같은 Envoy이고, 받을 포트와 보낼 곳은 컨트롤 플레인인 istiod가 정합니다. 아래는 Istio 공식 아키텍처 문서의 사이드카 모드 그림과 같은 배치로 다시 그린 것입니다.

istiod는 쿠버네티스 API에서 Service·Endpoint와 Istio CRD를 watch하다가 변경이 생기면 영향받는 프록시에 설정을 밀어 줍니다. 프록시가 istiod로 열어 둔 gRPC 스트림으로 listener·route·cluster·endpoint 설정(LDS·RDS·CDS·EDS)과 mTLS 인증서(SDS)를 받습니다. 인증서를 서명하는 CA도 istiod입니다. 요청은 이 스트림을 타지 않고 위 줄의 실선으로 흐릅니다.

스트림이 장수 연결이라 istiod를 늘려도 기존 스트림은 새 파드로 옮겨가지 않습니다(스케일링과 커넥션 재분배, istiod 해부).

istiod는 설정을 만들고, Envoy는 요청을 처리합니다. 아래 설정의 Gateway는 기존 게이트웨이 파드를 고르고 443의 TLS 수신 조건을 정의합니다. VirtualService는 그 Gateway에 연결할 HTTP 경로를 정의합니다.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata: { name: web-gateway, namespace: istio-ingress }
spec:
  selector: { istio: ingressgateway }
  servers:
  - port: { number: 443, name: https, protocol: HTTPS }
    tls: { mode: SIMPLE, credentialName: web-cert }
    hosts: ["shop.example.com"]
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: shop, namespace: shop }
spec:
  hosts: ["shop.example.com"]
  gateways: ["istio-ingress/web-gateway"]
  http:
  - match: [{ uri: { prefix: /cart } }]
    route:
    - destination:
        host: cart.shop.svc.cluster.local
        port: { number: 8080 }

web-cert Secret은 게이트웨이 Deployment의 네임스페이스에 둡니다. 게이트웨이 파드의 istio-agent가 이 Secret을 읽어 SDS로 Envoy에 전달합니다.

gateways를 생략하면 기본 대상은 mesh이므로 이 게이트웨이에는 경로가 붙지 않습니다. 또 Gateway에 적은 443이 Envoy의 수신 포트인 것도 아닙니다. istiod가 Service의 포트를 targetPort로 바꿔 listener를 만들기 때문이며, targetPort가 8443이면 listener도 8443입니다.

Service 이름에서 파드 IP까지

/cart가 맞으면 route는 cart:8080의 cluster를 고릅니다. Envoy는 istiod가 EDS로 내린 엔드포인트에서 파드를 골라 파드 IP:8080으로 연결합니다. 이 홉은 ClusterIP로 보내지 않으므로 Service DNAT를 거치지 않습니다. 그림의 IP는 설명용 예시입니다.

설정 반영은 listener → route → cluster → endpoint 순으로 확인합니다. 엔드포인트가 비었는지, 상태가 HEALTHY인지까지 봅니다.

# <게이트웨이-파드>는 실제 파드 이름으로 교체
istioctl proxy-config listener <게이트웨이-파드> -n istio-ingress
istioctl proxy-config route <게이트웨이-파드> -n istio-ingress
istioctl proxy-config cluster <게이트웨이-파드> -n istio-ingress --fqdn cart.shop.svc.cluster.local
istioctl proxy-config endpoint <게이트웨이-파드> -n istio-ingress   --cluster 'outbound|8080||cart.shop.svc.cluster.local'

TLS를 종료하는 HTTPS 서버의 route 이름은 https.<포트>.<포트 이름>.<Gateway 이름>.<네임스페이스>라서 이 예시에서는 https.443.https.web-gateway.istio-ingress입니다. cluster 이름의 가운데 빈칸은 subset 자리입니다.

listener에 포트가 없으면 Gateway가 이 파드를 고르지 못한 것입니다. route에 /cart가 없다면 VirtualService가 이 Gateway에 연결되지 않은 것입니다. 각 설정이 xDS의 어느 종류로 번역되는지는 13 Envoy 조립에 정리되어 있습니다.

endpoint 조회에서는 파드 IP가 보이고 STATUS가 HEALTHY인지 봅니다. 파드가 Ready가 아니거나 Service 셀렉터가 틀리면 목록이 비고, 게이트웨이는 보낼 곳이 없어 503을 돌려줍니다. 이 상황을 구분하는 방법은 05편에서 이어집니다.

외부 TLS와 내부 mTLS

외부 TLS와 내부 mTLS는 별개의 연결입니다. 외부에는 도메인 인증서를, 내부에는 게이트웨이 자신의 워크로드 인증서를 씁니다. 대상이 메시 프록시이고 TLS 정책이 허용하는 구성에서 auto mTLS가 적용됩니다.

SIMPLE은 TLS를 끝내 HTTP를 읽습니다. PASSTHROUGH는 SNI로 암호화된 연결을 넘기므로 경로·헤더 분기는 할 수 없고 route 설정 이름도 생기지 않습니다. AUTO_PASSTHROUGH는 VirtualService 없이 SNI로 목적지를 찾습니다. 클라이언트 인증서까지 확인하는 모드는 MUTUAL과 OPTIONAL_MUTUAL입니다.

두 프록시의 인증과 수신 정책은 03편에서 이어집니다.

앱 앞에서 거치는 15006

네트워크의 목적지는 파드 IP:8080이지만, 파드의 리다이렉트 규칙이 먼저 :15006으로 돌립니다. 15006에서는 virtualInbound listener가 원래 목적지 포트에 맞는 필터 체인을 고르고 mTLS를 종료합니다. HTTP 포트라면 여기서도 L7로 읽습니다.

복호화한 요청은 inbound|8080||을 거쳐 기본 구성에서 파드 IP:8080의 앱으로 갑니다. 이 cluster는 원래 목적지 주소를 그대로 쓰므로 앱은 자기 파드 IP의 8080에서 요청을 받습니다. Istio 1.10 이전에는 localhost로 넘겨 127.0.0.1에만 바인딩한 앱도 받았지만, 지금은 그런 앱에 닿지 않습니다.

대상 파드에서도 수신 listener와 앱으로 넘기는 cluster를 확인합니다.

istioctl proxy-config listener <대상-파드> -n shop --port 15006
istioctl proxy-config cluster  <대상-파드> -n shop --direction inbound

리다이렉트 규칙은 요청 전에 준비됩니다. 기본 구성에서는 istio-init init 컨테이너가 NET_ADMIN·NET_RAW 권한으로 규칙을 설치하고, Istio CNI를 쓰면 노드 에이전트가 같은 일을 하며 istio-validation이 검사만 맡습니다.

파드 어노테이션 traffic.sidecar.istio.io/excludeInboundPorts로 제외한 포트는 앱에 직접 닿으므로 사이드카의 mTLS·관측도 거치지 않습니다.

Gateway API와 ambient의 경계

Kubernetes Gateway API에서는 Gateway가 기본적으로 Service·Deployment까지 만들고, HTTPRoute.parentRefs가 경로를 연결합니다. 다른 네임스페이스의 Route를 붙일 때는 allowedRoutes도 허용해야 합니다. Envoy의 요청 처리와 진단 순서는 같습니다(Gateway API 비교).

Istio의 Gateway API 컨트롤러는 이 리소스를 내부의 Istio Gateway·VirtualService로 바꾸므로, 앞서 쓴 istioctl proxy-config로 같은 방식으로 확인합니다.

ambient 목적지에는 파드 사이드카가 없으므로 위의 15006 그림을 그대로 적용하지 않습니다. 노드의 ztunnel과 HBONE 경로를 봐야 합니다. HBONE은 관례상 15008에서 받습니다.

인그레스 요청은 목적지 waypoint가 있어도 기본적으로 건너뛰며, 메시 내부 호출과 같은 L7 정책을 적용하려면 Service나 네임스페이스에 istio.io/ingress-use-waypoint: "true"를 붙여야 합니다. 네임스페이스 라벨은 1.25부터입니다(waypoint 공식 문서).

이전 01 L4와 L7 · 다음 03 사이드카와 사이드카 사이

참고 자료

• AWS Load Balancer Controller — NLB 대상 모드
• Istio — Gateway와 TLS 모드
• Istio — Envoy 설정 확인
• Istio — 인증서를 사용하는 게이트웨이
• Istio — 앱 인바운드의 네트워크 변경
• Istio — 아키텍처