# [검증 전용, 51] "LOGICAL_DNS는 논리 endpoint 1개" 제약이 실제로 어디서 걸리는지 확인하는 임시 SE.
#
# 배경: README/41-serviceentry-logical.yaml의 함정 주석은 "A record가 multi-IP면 CDS NACK"이라고
# 적었으나, 2026-07-09 실측(docs/test-reports/2026-07-09_211314-dns-logical-multia.md 실측 A)
# 결과 이는 틀렸다 — 실제 DNS 응답이 2개 IP여도 LOGICAL_DNS는 NACK 없이 첫 IP만 골라 정상 동작한다
# (Envoy가 스스로 DNS를 질의하고 첫 결과만 쓰는 구조라 xDS 왕복 자체가 없다).
#
# 그렇다면 "논리 1개 제약"이 실제로 강제되는 지점은 어디인가? — 바로 여기, ServiceEntry에
# endpoints를 "명시적으로" 여러 개 선언하는 경우다. resolution: DNS_ROUND_ROBIN(-> Envoy
# LOGICAL_DNS)인데 endpoints가 2개면, istiod가 이걸 그대로 Cluster.load_assignment에 담아
# LOGICAL_DNS 타입 cluster에 endpoint 2개를 실어 push하게 된다. Envoy의 LOGICAL_DNS cluster는
# 정의상 load assignment에 endpoint가 정확히 1개여야 하므로(공식 문서: "a logical DNS cluster
# must have a single locality_lb_endpoint and a single lb_endpoint"), 여기서 검증 실패
# 지점이 admission(istiod validating webhook)인지, 통과 후 Envoy CDS NACK인지가 실측 B의 질문이었다.
#
# 답(2026-07-09 확정): admission이다. `kubectl apply --dry-run=server`가 즉시 거부한다 —
#   The ServiceEntry "gslb-logical-2ep" is invalid: spec: Invalid value: "object":
#   DNS_ROUND_ROBIN mode cannot have multiple endpoints
# CDS/xDS까지 가지도 않으므로 Envoy가 NACK할 기회 자체가 없다. 즉 이 SE는 실제로 클러스터에
# 생성된 적이 없다(dry-run만 수행, 아래 스펙은 재현 기록용).
#
# exportTo: ["."] 로 dns-lab 네임스페이스 내부로만 가시화 — gateway/mesh 전역 CDS 영향 차단.
# 확인 후 이 SE는 삭제한다(파일 자체는 재현 기록으로 보존).
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: gslb-logical-2ep
  namespace: dns-lab
spec:
  exportTo: ["."]
  hosts: ["gslb.lab.internal"]
  location: MESH_EXTERNAL
  ports:
    - { number: 80,  name: http,  protocol: HTTP }
    - { number: 443, name: https, protocol: HTTP }
  resolution: DNS_ROUND_ROBIN
  endpoints:
    - address: backend-a.dns-lab.svc.homelab.local
    - address: backend-b.dns-lab.svc.homelab.local