# [작업 F-0] 48-serviceentry-passthrough.yaml(STRICT_DNS)의 LOGICAL_DNS 대응쌍.
# 40/41(strict/logical, HTTP 경로) 패턴과 동일한 아이디어를 passthrough(L4/TLS SNI) 경로에 적용.
#
#  48은 resolution: DNS(STRICT_DNS) → host 제거 시 drain. 이 SE는 resolution만
#  DNS_ROUND_ROBIN(LOGICAL_DNS)으로 바꾼 변형이다 — host/port/protocol/exportTo는 48과 동일하게
#  유지해 "resolution 값 하나만 바꿨을 때 passthrough(raw TCP proxy) 클러스터가 어떻게 달라지는가"만
#  분리해서 본다. LOGICAL_DNS는 신규 커넥션만 최신 DNS를 따르고 기존 커넥션은 drain하지 않으므로,
#  40초 in-flight TCP 스트림 도중 DNS flip이 나도 membership_change/upstream_cx_destroy 델타가
#  0에 가까울 것으로 예상(D-2에서 STRICT_DNS + passthrough도 이미 생존 확인됨 — TCP는
#  connection pool 개념이 없어 CDS/EDS 갱신과 무관하게 기존 raw 커넥션을 그대로 들고 있기 때문).
#  이 SE는 그 예상이 LOGICAL에서도 동일한 메커니즘(신규 커넥션만 갱신)으로 재확인되는지 실측용.
#
#  ⚠ LOGICAL_DNS는 lb_endpoint가 1개여야 한다 — A record가 multi-IP면 CDS NACK(같은 push의
#  listener까지 통째로 드롭, memory: dual-gateway-egress-lab). gslb-pt.lab.internal은 항상
#  backend pod IP 단일 레코드만 쓰므로(48의 실측 함정 주석 참조) 이 조건은 자동으로 만족된다.
#
#  ⚠ 48-serviceentry-passthrough.yaml 과 host(gslb-pt.lab.internal)가 같아 동시 적용 불가 —
#  정확히 하나만 apply. exportTo:["."] 로 dns-lab 내부 한정(48과 동일, gateway 전역 영향 차단).
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: gslb-passthrough-logical
  namespace: dns-lab
spec:
  exportTo: ["."]
  hosts: ["gslb-pt.lab.internal"]
  location: MESH_EXTERNAL
  ports:
    - { number: 443, name: tls, protocol: TLS }
  resolution: DNS_ROUND_ROBIN