DestinationRule subset × port 교차 생성
원리와 포트 스코핑 전략

핵심 요약

왜 교차 생성되는가

DR subset의 스키마는 name · labels · trafficPolicy 세 필드가 전부임. "이 subset은 3128 전용"이라고 선언할 자리가 없음. 포트별 subset이라는 의도는 리소스에 표현되지 않고, istiod는 다음 규칙으로 CDS를 생성함:

따라서 pc cluster에 443용으로 만든 subset이 3128 포트 행으로도 보이는 것은 정확히 이 규칙의 결과임. 문제는 존재 자체가 아니라, 이 중 일부가 "설정상 존재하지만 실제로는 동작 불가능한 조합"이라는 점임 (→ 06).

EDS는 label만 본다 — HEALTHY의 실제 의미

pc endpoint에서 의도 밖 조합의 endpoint까지 HEALTHY로 보이는 이유도 같은 축 분리에서 나옴.

• EDS 선정 — outbound|3128|tls-gw|...의 endpoint = "tls-gw label Pod들 + 3128의 targetPort". 그 Pod가 443만 listen해도 목록에 들어감.
• HEALTHY 판정 — readiness probe가 앱 포트(예: 443)만 체크하면, 3128 조합 cluster에서도 같은 Pod가 HEALTHY로 표시됨. "HEALTHY ≠ 이 cluster로 통신 가능"이 핵심 구분임.

Service selector vs subset labels — Pod를 나눠야 하는가

둘 다 "Pod를 고르는 조건"일 뿐 Pod 배치를 강제하지 않음. 한 Pod가 여러 Service에 잡히는 것도, 여러 subset에 잡히는 것도 정상임. 따라서 "label이 다르니 Pod를 나눠야 한다"는 순서가 반대임 — Pod가 실제로 다른 워크로드인지가 먼저이고, label은 그 사실의 표현 수단임.

판별: 두 subset의 labels가 실제로 누구를 가리키는가

kubectl get pods -n egress -l app=squid --show-labels
kubectl get pods -n egress -l app=tls-gw --show-labels
# 같은 Pod가 나옴 → 상황 2 (단일 워크로드, 포트 구분 목적의 label이었음)
# 다른 Pod가 나옴 → 상황 1 (이미 분리된 워크로드)

해결 전략 3안

표는 색인이며, 각 안의 메커니즘과 트레이드오프는 아래 해설 참조.

1안 — Service(host) 분리, Pod 공유

포트 스코핑은 Service의 책임이므로 "포트당 하나의 host"로 모델링함. cluster는 host 단위로 생성되므로 host가 갈라지는 순간 각 host엔 자기 포트만 존재하고, 그룹 구분이 host로 표현되므로 subset 자체가 불필요해짐. 상황 1이면 selector를 그룹별로, 상황 2면 동일 selector로 작성함 (→ 03). 리소스 추가는 Service 오브젝트뿐이라 무장애 전환과도 충돌 없음.

2안 — Pod까지 분리

cross product 해소만이 목적이면 과잉임. 선택 기준은 별개의 운영 요구 — 리소스 경합 분리, 장애 반경 축소, HPA 개별 스케일링, 노드 배치(egress 노드 집약) 차이 — 가 있는지임. Squid 경유 TCP 터널 트래픽과 TLS 트래픽의 부하 특성이 크게 다르면 고려함.

3안 — 수용 + 라우팅 통제

조합 cluster는 트래픽에 무해함 — 라우팅되지 않는 cluster는 config로만 존재함. VS에서 destination.port.number를 항상 명시해 유효한 (port, subset) 조합만 참조하면 됨. 비용은 두 가지: ① proxy 메모리·xDS push 크기 증가 (Service·subset 수에 곱으로 비례), ② 사람 실수로 잘못된 조합을 라우팅할 위험 — 이 위험을 설정 리뷰(GitOps PR)로 막을 수 있는지가 채택 기준임. 포트별 정책 차이는 subset이 아니라 trafficPolicy.portLevelSettings로 표현함:

trafficPolicy:
  portLevelSettings:
  - port: { number: 3128 }
    tls: { mode: DISABLE }         # CONNECT 평문 터널
  - port: { number: 443 }
    tls: { mode: ISTIO_MUTUAL }

보조 수단 — Sidecar 리소스의 egress[](host+port 단위 import 제한)로 소비자 proxy에 밀리는 cluster 수를 줄일 수 있음. 단 이는 config push 절감 수단이지 subset-포트 매핑 수단이 아니며 관리 복잡도가 오르므로 1·3안으로 해결 안 될 때만 검토함.

완전한 예제 — 1안 (상황 2: 동일 selector)

# 같은 Deployment(egress-gw, 3128·443 모두 listen)를 두 Service가 공유
apiVersion: v1
kind: Service
metadata:
  name: squid-path
  namespace: egress
spec:
  selector: { app: egress-gw }         # 동일 selector
  ports:
  - name: tcp-proxy
    port: 3128
    targetPort: 3128
---
apiVersion: v1
kind: Service
metadata:
  name: tls-path
  namespace: egress
spec:
  selector: { app: egress-gw }         # 동일 selector
  ports:
  - name: tls
    port: 443
    targetPort: 8443
---
# DR은 host별로 — subset 없이 정책만
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: squid-path
  namespace: egress
spec:
  host: squid-path.egress.svc.cluster.local
  trafficPolicy:
    tls: { mode: DISABLE }
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: tls-path
  namespace: egress
spec:
  host: tls-path.egress.svc.cluster.local
  trafficPolicy:
    tls: { mode: ISTIO_MUTUAL }

검증

# 1. host별로 자기 포트 cluster만 존재하는지
istioctl proxy-config cluster deploy/<caller> -n <ns> --fqdn squid-path.egress.svc.cluster.local
# 예상: PORT=3128 행만 존재. 443 행 없음

istioctl proxy-config cluster deploy/<caller> -n <ns> --port 443
# 예상: tls-path만 표시, squid-path 미표시

# 2. 두 host의 endpoint가 같은 Pod IP를 가리키는지 (Pod 공유 확인)
istioctl proxy-config endpoint deploy/<caller> -n <ns> \
  --cluster "outbound|3128||squid-path.egress.svc.cluster.local"
istioctl proxy-config endpoint deploy/<caller> -n <ns> \
  --cluster "outbound|443||tls-path.egress.svc.cluster.local"
# 예상: 동일한 Pod IP 집합, 포트만 3128 / 8443으로 다름

# 3. 정적 검증
istioctl analyze -n egress
# 예상: No validation issues found

실패 케이스 — 의도 밖 조합으로 라우팅 시 503 UF

VS에서 실수로 port: 3128 + 443만 listen하는 Pod의 subset으로 라우팅한 경우의 관측 시그니처:

kubectl logs deploy/<caller> -c istio-proxy | grep ' 503 '
# "... 503 UF ..." — UpstreamConnectionFailure

# cluster·endpoint가 모두 정상으로 보이면 listen 포트를 실측함
kubectl exec <pod> -n egress -c <app> -- ss -tlnp
# 예상: 443(8443)만 LISTEN, 3128 없음 → 조합 오류 확정

판단 플로우