Istio on homelab89

DestinationRule 만들기 — 기초부터 심화까지

Fri, 03 Jul 2026 00:00:00 +0000

ABSTRACT

DR은 “어디로 보낼지”(VS의 일)가 아니라 **“도착이 결정된 목적지와 어떻게 통신할지”**를 정하는 리소스다. host 문자열이 서비스 레지스트리와 매칭되어 Envoy cluster에 컴파일되는 전 과정, trafficPolicy 필드가 cluster의 어느 칸으로 흩어지는지, 레벨 3층(top/subset/port)의 병합 규칙(“통째 교체”), 같은 host 다중 DR의 조용한 병합, 그리고 만들었으면 반드시 도는 검증 3단계까지. 모든 예시는 홈랩 실측(2026-07-03, mesh-test namespace)이다.

tcpKeepalive 필드 노트 — time / interval / probes는 각각 무엇을 제어하는가

Fri, 03 Jul 2026 00:00:00 +0000

ABSTRACT

DR connectionPool.tcp.tcpKeepalive의 세 필드는 Envoy가 만든 개념이 아니라 리눅스 커널의 TCP keepalive 소켓 옵션 3개에 1:1 매핑된다. Envoy는 upstream 소켓에 옵션을 설정만 하고, probe를 보내는 주체는 커널이다. 이 한 설정이 서로 다른 두 역할(중간장비 세션 유지 / 죽은 상대 감지)을 겸한다는 것, 그리고 각 역할을 결정하는 필드가 다르다는 것이 이 노트의 본체다.

Egress 4-CRD 직관 — "한 번의 curl = 두 hop", 4개를 어떤 순서로 어떻게 채우나

Thu, 02 Jul 2026 00:00:00 +0000

ABSTRACT

egress gateway 설정이 “Gateway·VirtualService·ServiceEntry·DestinationRule을 왜 4개나, 어느 필드를 어디에"로 막히는 이유는 멘탈모델 없이 필드부터 보기 때문이다. 이 문서는 거꾸로 간다 — 먼저 “한 번의 외부 호출이 두 hop으로 쪼개지고, 4개 CRD는 각자 다른 hop의 다른 질문에 답하는 부품"이라는 그림을 세운 뒤, 실제로 두 패턴(passthrough / outer-mTLS)을 어떤 순서로 어떻게 만들었는지를 그때의 YAML과 함께 따라간다. 결론: 4개는 따로 노는 게 아니라 두 hop을 굴리기 위한 질문 4개이고, 패턴 전환은 “3개 델타"일 뿐이다. 필드 단위 레퍼런스(=사전)는 Egress Gateway 정본·HTTPS over mTLS 해부, 검증 랩은 이중 gateway 가이드.

Egress TCP 문제별 처방전 — 어떤 문제에, 어떤 설정을, 어디에, 어떻게

Thu, 02 Jul 2026 00:00:00 +0000

ABSTRACT

TCP 병목 정본이 “왜 병목이 생기는가"의 정본이라면, 이 문서는 egressgateway에서 실제로 발생하는 TCP 문제 5가지를 하나씩 놓고 — 증상 → 어떤 설정을 → 어디에(리소스) → 어떻게(YAML) → 검증 — 순서로 처방하는 실행 문서다. 예시 채널 하나 (peak 동시 연결 1,500 / 신규 250 conn/s / FW idle timeout 30분 / Calico natOutgoing on)의 실측값으로 모든 숫자를 도출하고, 마지막에 4개 레이어 전체 YAML 종합본을 둔다. 값을 복사하지 말고 도출식을 복사할 것.

Egress 신원 기반 통제 — mTLS 신원이 공용 gateway에 멀티테넌시를 만든다

Thu, 02 Jul 2026 00:00:00 +0000

ABSTRACT

“egress gateway만 세우면 외부 통신이 통제된다"는 직관의 빈칸을 메우는 문서. 방화벽·NetworkPolicy는 “외부로 나가는 유일한 경로가 gateway인가”(Q1) 에만 답하고, “그 gateway를 누가, 어느 목적지로 쓸 수 있나”(Q2) 에는 답하지 못한다. Q2의 판정 재료가 mesh mTLS가 운반하는 SPIFFE 신원이고, 판정 장치가 gateway 위의 AuthorizationPolicy(principal × SNI) 다. 이 문서는 ① 그 논리를 통제 체인(경로 강제 → 검문소 → 신원 판정)으로 세우고 ② SA 2개가 서로 다른 목적지만 허용받는 테스트 클러스터 전체 구성(YAML 주석 포함)과 검증·함정까지 따라간다. 이중 TLS 구조 자체의 해부는 HTTPS over mTLS 정본, 4-CRD 직관은 Egress 4-CRD 멘탈모델이 정본 — 본 문서는 그 구조 위에 올라가는 “통제” 를 다룬다.

Quickstart — 5분 안에 실험 다시 돌리기

Sun, 28 Jun 2026 00:00:00 +0000

ABSTRACT

홈랩 Istio graceful-termination 실험을 다시 펼쳐 빠르게 재현하기 위한 명령 시퀀스 + 검증 모음이다. 핵심 결론 한 줄: 모든 재현은 모드를 토글하고 → 종료 이벤트를 만들고 → 그 순간의 in-flight 요청 결과를 측정하는 동일한 3-스텝 루프이며, current↔improved의 expect 라인 차이가 곧 가설의 증거다. 메커니즘 설명은 big picture에, 시나리오 정본 정의(S2 포함)는 test scenarios에 있다.

Istio 회로 차단은 connection pool 한도로 부하를 빠르게 잘라내고 outlier detection으로 unhealthy 인스턴스를 격리해 연쇄 장애를 끊는다

Wed, 10 Jun 2026 00:00:00 +0000

이 문서가 다루는 것

Istio의 “circuit breaking"은 단일 기능이 아니라 두 개의 독립된 방어선이다 — ① connectionPool 한도(동시성·pending·retry 상한 = Envoy circuit_breakers)로 클라이언트가 upstream을 과부하시키지 못하게 빠르게 실패시키고, ② outlierDetection으로 에러를 뱉는 endpoint를 LB pool에서 일시 격리한다. 둘 다 CircuitBreaker CRD가 아니라 DestinationRule trafficPolicy 에 정의되고 istiod가 Envoy cluster로 컴파일한다. 이 note는 왜 이 메커니즘이 존재하고 어떻게 동작하는가에 집중하고, 필드별 컴파일 매핑·전체 YAML 레퍼런스는 Envoy Cluster 해부로 위임한다.

Istio는 SPIFFE 표준으로 워크로드 신원을 X.509 SVID의 SAN에 박아 mTLS 인증의 토대로 삼는다

Wed, 10 Jun 2026 00:00:00 +0000

이 문서가 다루는 것

Istio의 workload identity는 IP·hostname·header가 아니라 SPIFFE ID(spiffe://<trust-domain>/ns/<ns>/sa/<sa>)다. 이 ID는 X.509 인증서(SVID)의 SAN(URI type) 에 박혀 발급되고, mTLS handshake에서 양측이 서로의 SVID를 trust bundle(CA root)로 검증한다. 검증된 SPIFFE ID가 곧 source.principal로 이어져 인가(authz)의 입력이 된다. 즉 mTLS는 “암호화"가 아니라 검증 가능한 신원의 운반 수단이며, 그 신원이 없으면 principal 기반 정책 자체가 성립하지 않는다. 인증서는 istio-agent가 SDS로 메모리상에서 발급·로테이션하므로 디스크에 평문 key가 떨어지지 않는다.

Phantom workload는 컨트롤 플레인의 endpoint 전파 지연으로 stale 스냅샷을 믿는 데이터 플레인이 이미 사라진 워크로드로 트래픽을 보내는 현상이다

Wed, 10 Jun 2026 00:00:00 +0000

ABSTRACT

Phantom workload는 버그가 아니라 메시 아키텍처의 본질적 트레이드오프 — 데이터 플레인 설정의 최종 일관성(eventual consistency) — 가 시간 축에 투영된 현상이다. Pod가 사라진 시점과 그 사실이 모든 Envoy의 EDS 스냅샷에 반영되는 시점 사이에는 항상 전파 지연(propagation lag) 윈도가 존재하고, 그 윈도 안에서 Envoy는 죽은 IP를 healthy로 믿고 트래픽을 보낸다. 이 note는 왜 phantom이 구조적으로 불가피한가 라는 멘탈모델에 집중한다. 단계별 발생 표·완화 YAML·운영 detail은 Phantom workloads 처리에 위임한다.

xDS는 Envoy 설정을 LDS/RDS/CDS/EDS/SDS 계층으로 나누고 ADS가 이를 단일 스트림으로 묶어 적용 순서를 보장한다

Wed, 10 Jun 2026 00:00:00 +0000

이 문서가 다루는 것

Envoy의 동적 설정은 단일 덩어리가 아니라 5개 xDS API(LDS/RDS/CDS/EDS/SDS)로 분리되어 “리스닝 지점 / 라우팅 / upstream pool / 실제 endpoint / TLS secret"이라는 서로 다른 계층을 각각 담당한다. 이 분리는 부분 업데이트를 가능하게 하지만 동시에 순서 문제를 낳는다 — route가 아직 없는 cluster를 가리키면 트래픽이 깨진다. ADS(Aggregated Discovery Service) 가 이 여러 xDS를 하나의 gRPC 스트림으로 묶어 적용 순서를 보장함으로써 그 문제를 푼다. 이 문서는 그 개념·멘탈모델에 집중하고, istioctl proxy-config로 각 계층을 진단하는 운영 상세는 xDS 5계층과 istioctl 진단으로 위임한다.