{
  "tier": "public",
  "base": "",
  "generated": "2026-07-03T13:42:19",
  "domains": [
    {
      "id": "devtools",
      "title": "Dev Tooling — Neovim & tmux",
      "desc": "DevOps editor/terminal setup: LazyVim (LSP for yaml/bash/docker/terraform) and tmux.",
      "icon": "🛠️",
      "url": "/public/devtools/",
      "count": 3,
      "updated": "2026-06-29",
      "topics": [
        {
          "id": "nvim",
          "label": "Neovim / LazyVim",
          "count": 2
        },
        {
          "id": "tmux",
          "label": "tmux",
          "count": 1
        }
      ],
      "docs": [
        {
          "title": "Neovim + LazyVim DevOps 환경 구성",
          "desc": "날짜: 2026-02-21 목적: DevOps/SRE 작업(YAML, Bash, Dockerfile, Terraform, JSON)에 최적화된 nvim IDE 환경",
          "url": "/public/devtools/nvim__guide-lazyvim-devops-setup.html",
          "domain": "devtools",
          "topic": "nvim",
          "type": "guide",
          "mtime": 1782679020
        },
        {
          "title": "Neovim + LazyVim 사용 가이드",
          "desc": "날짜: 2026-02-21 대상: DevOps/SRE 워크플로우 (YAML, Bash, Dockerfile, Terraform, JSON)",
          "url": "/public/devtools/nvim__guide-lazyvim-usage.html",
          "domain": "devtools",
          "topic": "nvim",
          "type": "guide",
          "mtime": 1782679020
        },
        {
          "title": "tmux 설치 및 설정 구성",
          "desc": "sudo apt install -y tmux tmux 3.4-1ubuntu0.1 설치됨.",
          "url": "/public/devtools/tmux__guide-setup-and-plugins.html",
          "domain": "devtools",
          "topic": "tmux",
          "type": "guide",
          "mtime": 1782679020
        }
      ]
    },
    {
      "id": "etcd",
      "title": "etcd HA & Recovery",
      "desc": "3-node etcd cluster lab on KVM: kubespray HA control plane, failure injection, snapshot backup/restore.",
      "icon": "🗄️",
      "url": "/public/etcd/",
      "count": 6,
      "updated": "2026-06-29",
      "topics": [
        {
          "id": "etcd",
          "label": "etcd HA / Recovery",
          "count": 6
        }
      ],
      "docs": [
        {
          "title": "k8s-etcd-lab",
          "desc": "KVM 기반 3-노드 Kubernetes 클러스터를 구성하고 etcd 장애 시나리오를 실험하는 로컬 랩 환경입니다.",
          "url": "/public/etcd/etcd__MOC-lab-overview.html",
          "domain": "etcd",
          "topic": "etcd",
          "type": "MOC",
          "mtime": 1782679038
        },
        {
          "title": "03. kubespray 배포 가이드",
          "desc": "kubespray는 Ansible 기반의 프로덕션급 Kubernetes 클러스터 배포 도구입니다.",
          "url": "/public/etcd/etcd__guide-kubespray-deploy.html",
          "domain": "etcd",
          "topic": "etcd",
          "type": "guide",
          "mtime": 1782679038
        },
        {
          "title": "01. 사전 준비",
          "desc": "",
          "url": "/public/etcd/etcd__guide-prerequisites.html",
          "domain": "etcd",
          "topic": "etcd",
          "type": "guide",
          "mtime": 1782679038
        },
        {
          "title": "02. VM 구성 가이드",
          "desc": "Host (203.0.113.2) └── libvirt NAT 네트워크: k8s-lab (203.0.113.0/24) ├── k8s-ctrl1 203.0.113.11 (control-plane + etcd) ├── k8s-ctrl2 203.0.113.12 (control-plane +…",
          "url": "/public/etcd/etcd__guide-vm-setup.html",
          "domain": "etcd",
          "topic": "etcd",
          "type": "guide",
          "mtime": 1782679038
        },
        {
          "title": "05. etcd 복구 절차",
          "desc": "etcd 데이터가 살아있고 단순히 프로세스가 죽은 경우입니다.",
          "url": "/public/etcd/etcd__runbook-recovery.html",
          "domain": "etcd",
          "topic": "etcd",
          "type": "runbook",
          "mtime": 1782679038
        },
        {
          "title": "04. etcd 장애 실험 시나리오",
          "desc": "3-node etcd 클러스터: - 쿼럼(과반수) = 2 - 1개 장애: 쿼럼 유지 (2/3 살아있음) → 클러스터 정상 운영 - 2개 장애: 쿼럼 붕괴 (1/3만 살아있음) → 클러스터 읽기 전용 / 쓰기 불가 - 3개 장애: 완전 다운 장애 허용 공식: floor((n-1)/2)…",
          "url": "/public/etcd/etcd__src-failure-experiments.html",
          "domain": "etcd",
          "topic": "etcd",
          "type": "src",
          "mtime": 1782679038
        }
      ]
    },
    {
      "id": "istio",
      "title": "Istio & Service Mesh",
      "desc": "Service mesh deep-dive — graceful termination, egress gateways, xDS/Envoy internals, and mTLS identity. Sanitized field notes from hands-on labs.",
      "icon": "🕸️",
      "url": "/public/istio/",
      "count": 58,
      "updated": "2026-07-02",
      "topics": [
        {
          "id": "arch",
          "label": "Architecture & Control Plane",
          "count": 8
        },
        {
          "id": "gt",
          "label": "Graceful Termination",
          "count": 13
        },
        {
          "id": "gw",
          "label": "Gateways & Egress",
          "count": 20
        },
        {
          "id": "sec",
          "label": "Security & mTLS",
          "count": 4
        },
        {
          "id": "xds",
          "label": "xDS & Envoy",
          "count": 13
        }
      ],
      "docs": [
        {
          "title": "istiod 성능은 변경률·할당 리소스·워크로드 수·설정 크기 네 요인의 곱으로 결정되고, Sidecar 리소스로 설정 범위를 좁히는 것이 가장 효과적인 단일 레버다",
          "desc": "istiod를 \"control plane\"이라는 추상명사가 아니라 설정 컴파일러 + 분배기로 보면, 부하의 출처와 튜닝 레버가 한눈에 선다. 이 문서는 (1) istiod 부하를 결정하는 네 요인이 곱셈으로 결합한다는 멘탈모델, (2) event→debounce→snapshot→pus…",
          "url": "/public/istio/arch__note-control-plane-performance-factors.html",
          "domain": "istio",
          "topic": "arch",
          "type": "note",
          "mtime": 1781036187
        },
        {
          "title": "control plane과 data plane의 설치·수명주기를 분리하면 istiod 업그레이드가 data plane에 투명해진다",
          "desc": "\"Istio를 업그레이드한다\"가 왜 \"mesh 전체를 한 번에 흔드는 일\"이 아니라 \"proxy를 하나씩 새 control plane으로 옮기는 일\"이 될 수 있는지를 다룬다. 결론부터: istiod(control plane)와 Envoy(data plane)는 xDS라는 느슨한 gR…",
          "url": "/public/istio/arch__note-install-cp-dp-decoupling.html",
          "domain": "istio",
          "topic": "arch",
          "type": "note",
          "mtime": 1781036188
        },
        {
          "title": "Phantom workload는 컨트롤 플레인의 endpoint 전파 지연으로 stale 스냅샷을 믿는 데이터 플레인이 이미 사라진 워크로드로 트래픽을 보내는 현상이다",
          "desc": "Phantom workload는 버그가 아니라 메시 아키텍처의 본질적 트레이드오프 — 데이터 플레인 설정의 최종 일관성(eventual consistency) — 가 시간 축에 투영된 현상이다. Pod가 사라진 시점과 그 사실이 모든 Envoy의 EDS 스냅샷에 반영되는 시점 사이에는…",
          "url": "/public/istio/arch__note-phantom-workloads.html",
          "domain": "istio",
          "topic": "arch",
          "type": "note",
          "mtime": 1781036169
        },
        {
          "title": "클러스터 콜드부팅 복구 — \"no route to host\" 전체 노드가 항상 cloud-init 장애는 아니다",
          "desc": "control-plane /etc/hosts 장애 런북과 증상이 닮았다 — kubectl이 전 노드에 no route to host. 하지만 원인은 완전히 다르다: 그 문서는 게스트 OS 안의 이름해석이 죽은 것이고, 이번은 노드를 담은 KVM VM 자체가 꺼져 있던 것이다. 이 문서…",
          "url": "/public/istio/arch__runbook-cold-boot-recovery.html",
          "domain": "istio",
          "topic": "arch",
          "type": "runbook",
          "mtime": 1782888733
        },
        {
          "title": "클러스터 control-plane 장애 — lb-apiserver.kubernetes.local 이름해석 소실",
          "desc": "Istio 재설치 중 istiod가 0/1로 안 뜨는 원인을 추적하다, 그게 Istio 문제가 아니라 kubespray control-plane 전체가 ~9일째 마비였음을 밝혀낸 장애 분석·수리 런북. 단일 실패점은 /etc/hosts의 단 한 줄, 범인은 cloud-init, 그리고…",
          "url": "/public/istio/arch__runbook-controlplane-outage.html",
          "domain": "istio",
          "topic": "arch",
          "type": "runbook",
          "mtime": 1782641076
        },
        {
          "title": "Istio 1.30.0 — 기존 설치 teardown + Helm 클린 재설치",
          "desc": "홈랩 클러스터의 깨진 Istio 1.30.0 설치를 전부 제거하고 순수 Helm chart(base → istiod → ingress/egress)로 클린 재설치한 런북. 흐름 0단계(설치·구조)의 실제 실행 기록 — 본 아카이브 전체가 이 설치 위에서 동작한다. 하나의 그림: Ist…",
          "url": "/public/istio/arch__runbook-helm-reinstall.html",
          "domain": "istio",
          "topic": "arch",
          "type": "runbook",
          "mtime": 1782641156
        },
        {
          "title": "Istio 대규모 운영 플레이북 — multi-cluster·config scope·upgrade·LLMOps (출처: ChatGPT \"Istio 운영 노하우\" 대화 + Istio 1.30 공식 문서)",
          "desc": "한 그림으로: Istio 운영은 \"Istio를 Envoy 설정 컴파일러(K8s 상태 + CRD → istiod → xDS → 모든 proxy)로 보고, 모든 장애를 YAML → istiod → xDS → Envoy config → response flag로 내려가며 추적하는 것\"이다.…",
          "url": "/public/istio/arch__src-operations-playbook.html",
          "domain": "istio",
          "topic": "arch",
          "type": "src",
          "mtime": 1781036262
        },
        {
          "title": "Istio Phantom Workloads 처리 방법",
          "desc": "Phantom workload는 이미 사라진 Pod의 endpoint IP가 Envoy의 EDS-CLA에 stale로 남아 트래픽이 죽은 IP로 흘러 발생하는 유령 라우팅이다. 머릿속에 담을 단 하나의 그림: \"이벤트 발생 → 새 EDS 도달\" 사이의 시간축 윈도(phantom win…",
          "url": "/public/istio/arch__src-phantom-workloads.html",
          "domain": "istio",
          "topic": "arch",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "MOC — Istio Graceful Termination",
          "desc": "이 MOC는 homelab Istio graceful-termination 실험의 허브이자, 그 실험이 \"왜 이렇게 설계됐는가\"를 한 번에 세워주는 멘탈 모델 게이트웨이다. 핵심 결론 한 줄: 서비스 팀은 LB를 직접 명령할 권한이 없으므로, \"끊김 없는 Pod 종료\"는 health…",
          "url": "/public/istio/gt__MOC-graceful-termination.html",
          "domain": "istio",
          "topic": "gt",
          "type": "MOC",
          "mtime": 1782641076
        },
        {
          "title": "Apps Walkthrough — backend + hc + graceful-drain.sh",
          "desc": "graceful termination은 \"Pod를 끈다\"가 단일 행위가 아니라, 서로 분리된 4개 신호(LB health, K8s readiness, Envoy listener, in-flight 요청)를 정해진 순서로 하나씩 끄는 것이라는 사실을 코드로 증명하는 문서다. 홈랩 실험의…",
          "url": "/public/istio/gt__src-apps-walkthrough.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1781036287
        },
        {
          "title": "Envoy Graceful Drain",
          "desc": "Pod 종료 시 502를 없애는 Envoy 데이터플레인 진입점은 admin API POST /drain_listeners?graceful&skip_exit 하나다. 핵심 오해를 먼저 깬다: 이 API는 in-flight 요청을 \"보호\"하지 않는다. 새 연결 유입만 discourage해…",
          "url": "/public/istio/gt__src-envoy-drain-listeners.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "HAProxy Walkthrough — L7 offload + on-marked-down",
          "desc": "홈랩 graceful termination 실험의 haproxy-current.cfg(143줄)를 읽는다. 단, 목적은 cfg 줄 해설이 아니라 한 문장의 멘탈모델을 세우는 것: 실험의 전부는 한 backend(443→IGW)에서 벌어지는 \"누가 먼저 끊느냐\"의 경합이다 — pod의…",
          "url": "/public/istio/gt__src-haproxy-walkthrough.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "Manifests Walkthrough — IGW 커스텀 Deployment + Service + Gateway/VS",
          "desc": "홈랩 graceful termination 실험의 manifests/ 7개 파일을 \"왜 이 값인가\"까지 해부한 정본 워크스루다. 하나의 그림으로 잡을 것: 이 매니페스트의 모든 숫자와 모든 path·selector·externalTrafficPolicy는 단 두 축에서 파생된다 — (…",
          "url": "/public/istio/gt__src-manifests-walkthrough.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "Quickstart — 5분 안에 실험 다시 돌리기",
          "desc": "홈랩 Istio graceful-termination 실험을 다시 펼쳐 빠르게 재현하기 위한 명령 시퀀스 + 검증 모음이다. 핵심 결론 한 줄: 모든 재현은 모드를 토글하고 → 종료 이벤트를 만들고 → 그 순간의 in-flight 요청 결과를 측정하는 동일한 3-스텝 루프이며, cur…",
          "url": "/public/istio/gt__src-quickstart.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "Istio Graceful Termination 사내 도입 런북 (홈랩 실험 → 사내 적용 가이드)",
          "desc": "홈랩 graceful-termination 실험 결과를 프로덕션 IGW 환경에 이식하는 6단계 런북이다. 머릿속에 담을 한 장면: LB는 backend의 살아있음 여부를 오직 health check 응답으로만 판정한다 — 그래서 LB를 직접 명령할 권한이 없어도, hc 사이드카가 pr…",
          "url": "/public/istio/gt__src-runbook.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "Istio Graceful Termination 테스트 하니스 코드 워크스루 (출처: 홈랩 실험 코드 정리)",
          "desc": "홈랩 Istio graceful-termination 실험의 tests/ 디렉터리(5개 실행 스크립트 + 공통 라이브러리)를 코드 레벨로 해부한다. 이 하니스가 측정하려는 단 하나의 명제 — \"in-flight 요청 drain이 LB의 backend DOWN 마킹보다 먼저 끝나는가\"…",
          "url": "/public/istio/gt__src-tests-walkthrough.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "W1. Big Picture — 트래픽 경로 + 6 events + 4 시나리오",
          "desc": "graceful-termination 학습 시리즈(W1~W6)의 첫 hub 노트. 무중단 Pod 종료를 한 문장으로 환원한다: 우리는 LB를 직접 제어할 수 없고 오직 health 신호(200/503) 하나만 LB에 줄 수 있으므로, \"끊김 없는 종료\"는 6개 timestamp를 옳은…",
          "url": "/public/istio/gt__src-w1-big-picture.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "W2. Backend + hc + drain.sh — Go 코드 메커니즘 (출처: 홈랩 graceful termination 학습 시리즈 W2)",
          "desc": "머릿속에 담을 한 장: health endpoint의 응답 코드는 LB의 backend pool membership을 제어하는 원격 스위치다. hc 사이드카는 5-state FSM(OPEN/DRAINING/CLOSING/CLOSED/FAULT)으로 이 스위치를 쥐고, drain.sh는…",
          "url": "/public/istio/gt__src-w2-hc-fsm.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1781036310
        },
        {
          "title": "W3. IGW 커스텀 Deployment 설계 — K8s 매니페스트 구조",
          "desc": "홈랩 graceful termination 시리즈 W3. IGW를 Helm 표준 대신 커스텀 Deployment로 구성해 hc 사이드카·volume·probe·preStop·Service NodePort 설계를 manifest 레벨에서 직접 제어한다. 결론(붙잡을 한 그림): 이 Po…",
          "url": "/public/istio/gt__src-w3-igw-deployment.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "W5. 테스트 시나리오 4종 설계 의도 + artifacts 해석",
          "desc": "graceful termination을 \"증명\"하려면 먼저 disruption을 측정 가능한 양으로 만드는 실험 설계가 필요하다. 이 문서는 그 설계를 다룬다 — 4개 시나리오(S1~S4)가 각각 어떤 단일 변수를 격리하고, 실행 후 artifacts(curl/pcap/timeline…",
          "url": "/public/istio/gt__src-w5-test-scenarios.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "W6. 프로덕션 적용 가이드 — 실험 결론 → 온프렘 매핑",
          "desc": "머릿속 한 장: 서비스 팀은 LB를 직접 명령할 권한이 없지만 health 응답(200↔503)은 제어할 수 있다 — hc 사이드카 + graceful-drain.sh가 Envoy의 rq_active==0이 될 때까지 health 200을 붙잡아 LB의 backend 제거 시점을 간접…",
          "url": "/public/istio/gt__src-w6-production-apply.html",
          "domain": "istio",
          "topic": "gt",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "Istio Egress Gateway 도입 가이드 — Passthrough vs mTLS Passthrough",
          "desc": "대상: 플랫폼/인프라/보안 담당자 환경: on-prem Kubernetes, Istio 1.30.0 (sidecar mode), PCI-DSS 준수 IDC 결정 요약: mTLS Passthrough(ISTIO_MUTUAL) 패턴 채택. proxy 도입에 따른 TCP 운영 이슈는 방식과…",
          "url": "/public/istio/gw__guide-egress-adoption-passthrough-vs-mtls.html",
          "domain": "istio",
          "topic": "gw",
          "type": "guide",
          "mtime": 1781069599
        },
        {
          "title": "Egress 4-CRD 직관 — \"한 번의 curl = 두 hop\", 4개를 어떤 순서로 어떻게 채우나",
          "desc": "egress gateway 설정이 \"Gateway·VirtualService·ServiceEntry·DestinationRule을 왜 4개나, 어느 필드를 어디에\"로 막히는 이유는 멘탈모델 없이 필드부터 보기 때문이다. 이 문서는 거꾸로 간다 — 먼저 \"한 번의 외부 호출이 두 hop…",
          "url": "/public/istio/gw__guide-egress-crd-mental-model.html",
          "domain": "istio",
          "topic": "gw",
          "type": "guide",
          "mtime": 1781070035
        },
        {
          "title": "GSLB 뒤 DNS resolution 재현 랩 — \"세션이 끊길 수도 있다\"를 눈으로 보기",
          "desc": "ServiceEntry resolution 정본은 DNS(STRICT_DNS)와 DNS_ROUND_ROBIN(LOGICAL_DNS)의 차이를 이론으로 정리했다. 이 문서는 그 이론을 자기완결형 랩으로 라이브 재현한다 — 공유 인프라(egress gateway·cluster CoreDN…",
          "url": "/public/istio/gw__guide-egress-dns-gslb-repro-lab.html",
          "domain": "istio",
          "topic": "gw",
          "type": "guide",
          "mtime": 1782946375
        },
        {
          "title": "이중 egress gateway — passthrough와 mTLS를 별도 ns·별도 pod로 나란히",
          "desc": "단일 egress gateway를 멀티-gateway 토폴로지로 일반화하면서, 두 egress 패턴(① TLS PASSTHROUGH, ② outer 메시 mTLS + inner 앱 TLS)을 서로 다른 namespace의 서로 다른 gateway pod로 동시에 띄워 직접 비교한 ho…",
          "url": "/public/istio/gw__guide-egress-dual-gateway.html",
          "domain": "istio",
          "topic": "gw",
          "type": "guide",
          "mtime": 1781070055
        },
        {
          "title": "Istio 1.30 Egress Gateway — 외부 HTTPS 통신 설치·구성·테스트 가이드",
          "desc": "homelab(kubespray bare-metal, k8s v1.30.6, CNI Calico, Istio 1.30.0)에서 egress gateway를 Helm으로 구성하고, 앱이 직접 https://를 호출하는 TLS Passthrough(SNI 라우팅) 시나리오를 끝까지 구성·…",
          "url": "/public/istio/gw__guide-egress-gateway-https.html",
          "domain": "istio",
          "topic": "gw",
          "type": "guide",
          "mtime": 1781036324
        },
        {
          "title": "Egress TCP 병목 재현 랩 — 한계를 줄여서 부딪힌다",
          "desc": "TCP 병목 정본의 한계 수치(Envoy 1024, 포트 28k, conntrack 26만)는 그대로 재현하려면 연결 수만 개가 필요하다. 이 랩의 기법은 반대다 — 한계를 5~20으로 줄여서, 같은 메커니즘을 연결 수십 개로 관찰한다. 재현 4종 각각이 운영에서 만날 실패 시그니처(…",
          "url": "/public/istio/gw__guide-egress-tcp-failure-reproduction.html",
          "domain": "istio",
          "topic": "gw",
          "type": "guide",
          "mtime": 1782641358
        },
        {
          "title": "Istio 회로 차단은 connection pool 한도로 부하를 빠르게 잘라내고 outlier detection으로 unhealthy 인스턴스를 격리해 연쇄 장애를 끊는다",
          "desc": "Istio의 \"circuit breaking\"은 단일 기능이 아니라 두 개의 독립된 방어선이다 — ① connectionPool 한도(동시성·pending·retry 상한 = Envoy circuit_breakers)로 클라이언트가 upstream을 과부하시키지 못하게 빠르게 실패시키…",
          "url": "/public/istio/gw__note-circuit-breaking-mechanisms.html",
          "domain": "istio",
          "topic": "gw",
          "type": "note",
          "mtime": 1781036351
        },
        {
          "title": "east-west gateway는 목적지 클러스터를 SNI에 인코딩해, mTLS를 복호화하지 않고 암호화된 채로 원격 워크로드까지 프록시한다",
          "desc": "east-west gateway는 mTLS를 풀지 않고 봉투 겉면(ClientHello의 SNI)에 적힌 목적지만 읽어 다음 hop으로 넘기는 L4 SNI 라우터다. 멀티클러스터(network 분리) 메시에서 한 클러스터의 sidecar가 다른 클러스터의 워크로드를 부를 때, side…",
          "url": "/public/istio/gw__note-eastwest-gateway-sni.html",
          "domain": "istio",
          "topic": "gw",
          "type": "note",
          "mtime": 1781036337
        },
        {
          "title": "Egress 신원, 이중 TLS 없이 — passthrough + Calico가 HTTPS over mTLS를 대체하는 근거",
          "desc": "\"egress에서 호출 워크로드 신원을 통제하려면 HTTPS over mTLS(이중 TLS)가 필요하다\"는 통념에 대한 반론. 멘탈모델 한 줄: 강제(enforcement)는 어차피 chokepoint(egress gateway)에서 일어난다 — 패턴 선택은 \"그 앞에서 호출자를 어떻…",
          "url": "/public/istio/gw__note-egress-identity-without-mtls.html",
          "domain": "istio",
          "topic": "gw",
          "type": "note",
          "mtime": 1781070010
        },
        {
          "title": "Egress route 스코핑 — metadata.namespace는 적용 범위가 아니다",
          "desc": "Istio traffic 리소스의 metadata.namespace는 \"어디에 저장했는가\"(소유 경계)이지 \"어느 proxy에 적용되는가\"(적용 범위)가 아니다. 적용 범위는 gateways · exportTo · sourceNamespace/sourceLabels · Sidecar.…",
          "url": "/public/istio/gw__note-egress-vs-scoping.html",
          "domain": "istio",
          "topic": "gw",
          "type": "note",
          "mtime": 1781036336
        },
        {
          "title": "Sidecar 리소스는 '좁은 범위가 넓은 범위를 통째로 이기는' override 계층으로, 사이드카에 푸시할 설정을 좁혀 성능과 egress 거버넌스를 동시에 얻는다",
          "desc": "Istio의 기본 가정은 \"메시 안 모든 워크로드가 다른 모든 워크로드에 접근 가능\"이다. 그래서 istiod는 각 Envoy에 메시 전체 설정을 푸시하고, 규모가 커지면 이것이 메모리·xDS push·istiod CPU를 동시에 압박한다. Sidecar 리소스는 두 개의 서로 다른…",
          "url": "/public/istio/gw__note-sidecar-scope.html",
          "domain": "istio",
          "topic": "gw",
          "type": "note",
          "mtime": 1781037022
        },
        {
          "title": "Runbook — ServiceEntry resolution: DNS 동작과 진단 (STRICT_DNS)",
          "desc": "외부 도메인(httpbin.org)을 ServiceEntry(resolution: DNS)로 등록하면 istiod가 이를 Envoy의 STRICT_DNS cluster로 변환한다. 이 문서는 그 변환·DNS 갱신 메커니즘, \"죽은 IP\" 처리, ambient DNS 질의 경로를 홈랩…",
          "url": "/public/istio/gw__report-2026-06-07_dns-resolution.html",
          "domain": "istio",
          "topic": "gw",
          "type": "report",
          "mtime": 1781036434
        },
        {
          "title": "Test Report — Ingress / Egress Gateway 동작 검증",
          "desc": "홈랩 클러스터에서 Ingress·Egress gateway 동작을 실측 검증한 리포트. 하나의 그림: gateway는 메시 경계에 선 전용 Envoy proxy다. ingress는 자기가 TLS를 끝내므로(termination) L7 전체가 보여 host/path로 분기하고, egre…",
          "url": "/public/istio/gw__report-2026-06-07_ingress-egress.html",
          "domain": "istio",
          "topic": "gw",
          "type": "report",
          "mtime": 1782641076
        },
        {
          "title": "Test Report — Egress Gateway \"HTTPS over mTLS\" (ISTIO_MUTUAL)",
          "desc": "egress gateway에서 sidecar↔gw 구간만 Istio mTLS(ISTIO_MUTUAL)로 감싸 게이트웨이가 호출자의 SPIFFE 신원을 검증하면서, 앱이 보낸 HTTPS는 외부까지 end-to-end로 보존되는 \"이중 TLS\" 패턴을 홈랩에서 실측 검증한 리포트. 결론:…",
          "url": "/public/istio/gw__report-2026-06-08_egress-mtls.html",
          "domain": "istio",
          "topic": "gw",
          "type": "report",
          "mtime": 1781036456
        },
        {
          "title": "Egress Gateway 필드 매뉴얼 — HTTPS passthrough 중심 (출처: LLM 답변 + Istio 1.30 공식 문서)",
          "desc": "머릿속에 둘 단 하나의 그림(ANCHOR): egress gateway는 외부 트래픽을 유도하는 라우팅 수렴점일 뿐 강제 장치가 아니며, 외부 구간의 TLS를 누가 종단하느냐가 게이트웨이의 가시성·앱 변경·암호화 범위를 한꺼번에 결정한다. 앱이 끝까지 TLS를 쥐면(https) 게이트…",
          "url": "/public/istio/gw__src-egress-gateway.html",
          "domain": "istio",
          "topic": "gw",
          "type": "src",
          "mtime": 1782641076
        },
        {
          "title": "Egress 외부 endpoint 프로토콜별 Istio 설정 — HTTP vs HTTPS",
          "desc": "외부로 나가는 트래픽의 endpoint가 평문 HTTP일 때와 HTTPS일 때 ServiceEntry / Gateway / VirtualService / DestinationRule을 어떻게 설정하고, 왜 한쪽 설정을 다른 쪽에 그대로 쓰면 깨지는지를 Envoy 필터 체인 수준에서 정…",
          "url": "/public/istio/gw__src-egress-http-vs-https.html",
          "domain": "istio",
          "topic": "gw",
          "type": "src",
          "mtime": 1781036481
        },
        {
          "title": "Egress \"HTTPS over mTLS\" (ISTIO_MUTUAL) — 구조·CRD·장단점·활용·운영",
          "desc": "머릿속에 넣을 한 장의 그림: 이 패턴은 \"end-to-end 암호화 보존\"과 \"egress에서 호출자 신원 식별\"이라는 서로 독립인 두 축의 교집합 칸이다 — 둘 다 Yes일 때만 정답인 좁은 셀. 구현은 이중 TLS: 앱은 그대로 https://(inner end-to-end TL…",
          "url": "/public/istio/gw__src-egress-https-over-mtls.html",
          "domain": "istio",
          "topic": "gw",
          "type": "src",
          "mtime": 1781046384
        },
        {
          "title": "Egress Gateway 운영 가이드 — passthrough + ISTIO_MUTUAL (출처: LLM 답변 + Istio 1.30 공식 문서)",
          "desc": "앱이 HTTPS로 직접 호출(end-to-end TLS 유지) + 게이트웨이는 PASSTHROUGH(복호화 안 함) + proxy→egress 구간은 ISTIO_MUTUAL로 mTLS. 결론부터: 이 게이트웨이가 보는 것은 \"암호화된 장기 TCP 스트림\" 하나뿐이고, 모니터링(L4+S…",
          "url": "/public/istio/gw__src-egress-operations.html",
          "domain": "istio",
          "topic": "gw",
          "type": "src",
          "mtime": 1781069898
        },
        {
          "title": "Egress TCP 병목 정본 — L4 proxy가 연결을 모으면 무엇이 고갈되는가",
          "desc": "egress gateway 도입은 mTLS 여부와 무관하게 L4 proxy 하나를 전사 외부행 경로에 끼워 넣는 일이다. 이 문서는 그때 발생하는 TCP 병목 5종을 — Envoy 연결 상한 → ephemeral port/TIME_WAIT → conntrack → 중간장비 half-o…",
          "url": "/public/istio/gw__src-egress-tcp-bottlenecks.html",
          "domain": "istio",
          "topic": "gw",
          "type": "src",
          "mtime": 1781069728
        },
        {
          "title": "Istio Sidecar CRD 적용 범위(scope) 설정 방법",
          "desc": "Sidecar 리소스는 한 워크로드 Envoy가 받는 설정을 좁혀 config를 경량화하고, outboundTrafficPolicy와 결합해 egress 거버넌스를 만든다. 멘탈모델 하나: scope는 Mesh / Namespace / Workload 세 단계지만 어느 Pod에든 적용…",
          "url": "/public/istio/gw__src-sidecar-scope.html",
          "domain": "istio",
          "topic": "gw",
          "type": "src",
          "mtime": 1781036459
        },
        {
          "title": "Egress 신원 기반 통제 — mTLS 신원이 공용 gateway에 멀티테넌시를 만든다",
          "desc": "\"egress gateway만 세우면 외부 통신이 통제된다\"는 직관의 빈칸을 메우는 문서. 방화벽·NetworkPolicy는 \"외부로 나가는 유일한 경로가 gateway인가\"(Q1) 에만 답하고, \"그 gateway를 누가, 어느 목적지로 쓸 수 있나\"(Q2) 에는 답하지 못한다. Q…",
          "url": "/public/istio/sec__guide-egress-mtls-identity-control.html",
          "domain": "istio",
          "topic": "sec",
          "type": "guide",
          "mtime": 1782641358
        },
        {
          "title": "Istio는 SPIFFE 표준으로 워크로드 신원을 X.509 SVID의 SAN에 박아 mTLS 인증의 토대로 삼는다",
          "desc": "Istio의 workload identity는 IP·hostname·header가 아니라 SPIFFE ID(spiffe://<trust-domain>/ns/<ns>/sa/<sa>)다. 이 ID는 X.509 인증서(SVID)의 SAN(URI type) 에 박혀 발급되고, mTLS han…",
          "url": "/public/istio/sec__note-mtls-spiffe-identity.html",
          "domain": "istio",
          "topic": "sec",
          "type": "note",
          "mtime": 1781036474
        },
        {
          "title": "Istio 보안은 PeerAuthentication·RequestAuthentication·AuthorizationPolicy 세 리소스가 \"transport 인증 · end-user 인증 · 인가\"의 역할을 분담한다",
          "desc": "Istio의 워크로드 보안은 한 리소스가 아니라 세 CRD의 분업으로 성립한다. PeerAuthentication은 서비스 간 transport 계층(mTLS)을 강제해 peer identity(SPIFFE)를 확보하고, RequestAuthentication은 요청에 실린 JWT를…",
          "url": "/public/istio/sec__note-security-resource-trio.html",
          "domain": "istio",
          "topic": "sec",
          "type": "note",
          "mtime": 1781036490
        },
        {
          "title": "AuthorizationPolicy 멘탈모델 — inbound 적용·mTLS identity·HTTP vs TCP·egress (출처: ChatGPT \"Istio 운영 노하우\" 대화 + Istio 1.30 공식 문서)",
          "desc": "AuthorizationPolicy를 \"왜 그렇게 평가되는가\"의 멘탈모델로 다룬다. 결론부터: 이 정책은 client의 outbound를 막는 게 아니라, selector가 고른 workload의 inbound listener에 RBAC filter를 심어 \"그 서버로 들어오는 요청\"…",
          "url": "/public/istio/sec__src-authorizationpolicy-mental-model.html",
          "domain": "istio",
          "topic": "sec",
          "type": "src",
          "mtime": 1781036523
        },
        {
          "title": "데이터 플레인은 eventually consistent하게 동기화되고, proxy-status의 SYNCED/NOT SENT/STALE가 각 xDS 타입별 컨트롤 플레인 sync 상태를 드러낸다",
          "desc": "Istio 데이터 플레인(Envoy proxy 무리)은 컨트롤 플레인(istiod)과 강한 일관성이 아니라 최종 일관성(eventual consistency) 으로 맞춰진다. 그래서 \"설정을 apply했다\"와 \"그 설정이 모든 proxy에 반영됐다\"는 별개의 사건이고, 둘 사이엔 항상…",
          "url": "/public/istio/xds__note-data-plane-sync-state.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036471
        },
        {
          "title": "Envoy Admin API(config_dump/clusters/stats)는 데이터 플레인이 실제로 적용한 설정과 런타임 상태를 보는 1차 진단 도구다",
          "desc": "istioctl·Kiali·access log가 모두 \"추상화된 뷰\"라면, Envoy Admin API는 데이터 플레인의 그라운드 트루스(ground truth) 다. istiod가 \"의도한 설정\"과 Envoy가 \"실제로 적용한 설정\"이 갈라질 때(STALE/NACK), 그 갈라짐은…",
          "url": "/public/istio/xds__note-envoy-admin-api-diagnosis.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036499
        },
        {
          "title": "Envoy는 listener의 network filter와 HCM의 HTTP filter chain으로 요청을 처리하며, Lua·Wasm·external processing으로 재컴파일 없이 확장된다",
          "desc": "Envoy의 요청 처리는 두 겹의 filter chain이다 — L4(connection) 단의 network filter chain과, 그 안의 HTTP connection manager(HCM)가 여는 L7 HTTP filter chain. 이 한 장의 그림만 잡으면 두 가지가 동…",
          "url": "/public/istio/xds__note-envoy-filter-chain-extension.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036495
        },
        {
          "title": "Envoy 요청 라우팅은 listener→route→cluster→endpoint 체인을 따르며 istioctl proxy-config로 각 단계를 짚어 오설정을 찾는다",
          "desc": "Envoy가 요청 하나를 처리하는 경로는 항상 Listener → Route → Cluster → Endpoint (+ mTLS면 Secret) 라는 고정된 체인이다. 그래서 장애 진단은 자유로운 추리가 아니라 \"이 고정 체인의 어느 단계에서 끊겼는가\" 하나만 묻는 결정적 절차가 된다…",
          "url": "/public/istio/xds__note-envoy-routing-chain-debugging.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036522
        },
        {
          "title": "Envoy 정적 설정은 부트스트랩 시점에 고정되고 동적 설정은 컨트롤 플레인이 런타임에 푸시해 재시작 없이 반영한다",
          "desc": "머릿속에 담을 한 장: 정적은 \"xDS를 받는 통로\", 동적은 \"그 통로로 흘러드는 트래픽 설정\"이다. 정적(static)은 프로세스가 부팅하며 읽는 부트스트랩 YAML에 박제돼 재시작 전까지 불변이고, 동적(dynamic)은 컨트롤 플레인이 xDS로 런타임에 밀어넣어 프로세스 재시작…",
          "url": "/public/istio/xds__note-envoy-static-vs-dynamic-config.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036520
        },
        {
          "title": "파일 기반 xDS는 DiscoveryResponse 포맷·move 교체만 감지하고 EDS의 \"클러스터당 CLA 1개\" 제약 때문에 디버깅이 까다롭다",
          "desc": "머릿속에 둘 한 장면: 파일 기반 xDS는 gRPC ADS의 구독 계약을 그대로 둔 채 전송(transport)만 \"로컬 파일\"로 바꾼 것이다. 그래서 세 가지 좁은 제약은 따로 생긴 규칙이 아니라 모두 그 계약에서 흘러나온다 — ① 파일은 인라인 조각이 아니라 루트에 resource…",
          "url": "/public/istio/xds__note-file-based-xds-constraints.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036574
        },
        {
          "title": "xDS는 Envoy 설정을 LDS/RDS/CDS/EDS/SDS 계층으로 나누고 ADS가 이를 단일 스트림으로 묶어 적용 순서를 보장한다",
          "desc": "Envoy의 동적 설정은 단일 덩어리가 아니라 5개 xDS API(LDS/RDS/CDS/EDS/SDS)로 분리되어 \"리스닝 지점 / 라우팅 / upstream pool / 실제 endpoint / TLS secret\"이라는 서로 다른 계층을 각각 담당한다. 이 분리는 부분 업데이트를…",
          "url": "/public/istio/xds__note-xds-api-layers.html",
          "domain": "istio",
          "topic": "xds",
          "type": "note",
          "mtime": 1781036586
        },
        {
          "title": "Envoy Cluster 해부 — 포트 4-layer, subset, DestinationRule 매핑 (출처: \"Istio 운영 노하우\" 정리 + Istio 1.30 공식 문서)",
          "desc": "Envoy cluster는 \"이 트래픽을 어느 upstream으로, 어떻게 보낼까\"를 답하는 단 하나의 객체다 — discovery·LB·connection pool·circuit breaker·outlier detection·TLS를 전부 품는다. 그리고 사람이 쓰는 Destinat…",
          "url": "/public/istio/xds__src-cluster-anatomy.html",
          "domain": "istio",
          "topic": "xds",
          "type": "src",
          "mtime": 1781036678
        },
        {
          "title": "Istio CR 멘탈 모델 — CR은 입력, Envoy config가 진실 (출처: LLM 답변 + Istio 1.30 공식 문서)",
          "desc": "Istio CR을 외우는 가장 빠른 길은 각 CR을 따로 암기하는 게 아니라, \"CR을 만들면 Envoy 설정의 어느 칸이 채워지는가\" 를 하나의 데이터 흐름으로 이해하는 것. 이 문서는 그 한 축으로 모든 CR을 꿰어, CR을 보면 Envoy에 무엇이 박힐지 자연스럽게 떠오르게 만드…",
          "url": "/public/istio/xds__src-cr-xds-model.html",
          "domain": "istio",
          "topic": "xds",
          "type": "src",
          "mtime": 1781036680
        },
        {
          "title": "Envoy Response Flags 운영 레퍼런스 (출처: Istio 1.30 공식 문서 — Envoy access log response flags)",
          "desc": "status code는 \"결과\"만, response flag는 그 결과가 Envoy 처리 파이프라인의 어느 단계에서 났는지를 알려준다. 같은 503도 flag(UF/UH/UO/NR)에 따라 원인 부서가 완전히 다르다 — 그래서 503을 보면 status가 아니라 flag를 본다. 이…",
          "url": "/public/istio/xds__src-envoy-response-flags.html",
          "domain": "istio",
          "topic": "xds",
          "type": "src",
          "mtime": 1781036643
        },
        {
          "title": "Envoy 정적/동적(xDS) 설정 실습 — Istio in Action Ch.3.2 (출처: 책 + 실습기록 + 공식문서)",
          "desc": "Envoy 설정은 listener → route → cluster → endpoint가 서로를 이름으로 참조하는 한 줄 사슬이다. 정적 모드는 이 사슬을 bootstrap에 통째로 인라인하고, 동적 모드(xDS)는 같은 사슬의 각 노드를 컨트롤 플레인이 런타임에 push로 채운다 —…",
          "url": "/public/istio/xds__src-envoy-static-dynamic-xds-lab.html",
          "domain": "istio",
          "topic": "xds",
          "type": "src",
          "mtime": 1781036636
        },
        {
          "title": "Sidecar 트래픽 캡처 — iptables/nftables와 15001·15006",
          "desc": "mesh의 모든 기능(mTLS·route·authz·telemetry)은 \"app의 모든 패킷이 Envoy를 지나간다\"는 단 하나의 전제 위에 서 있다. 그 전제를 app 코드 수정 없이 강제하는 장치가 커널 netfilter(iptables/nftables) redirection이다…",
          "url": "/public/istio/xds__src-sidecar-traffic-capture.html",
          "domain": "istio",
          "topic": "xds",
          "type": "src",
          "mtime": 1781036661
        },
        {
          "title": "xDS 5계층과 istioctl 진단 — LDS/RDS/CDS/EDS/SDS (출처: Istio 1.30 공식 문서 + 홈랩 검증)",
          "desc": "istiod는 컴파일러다. K8s 상태 + Istio CRD를 입력으로 받아 Envoy 설정(Listener/Route/Cluster/Endpoint/Secret)으로 컴파일하고, xDS 채널로 각 프록시에 push한다. 그래서 모든 트래픽 장애는 \"이 5계층 중 어디서 끊겼나\"로 환…",
          "url": "/public/istio/xds__src-xds-layers-and-diagnosis.html",
          "domain": "istio",
          "topic": "xds",
          "type": "src",
          "mtime": 1781036683
        }
      ]
    },
    {
      "id": "istio-egress",
      "title": "Istio Egress",
      "desc": "Istio egress(외부로 나가는 트래픽) 전용 아카이브 — 4-CRD 멘탈모델부터 DNS/GSLB resolution, mTLS 신원, TCP 장애 재현까지 주제별로 정리. 사내 egress gateway 도입 전 홈랩 선검증 산출물.",
      "icon": "🚪",
      "url": "/public/istio-egress/",
      "count": 24,
      "updated": "2026-07-03",
      "topics": [
        {
          "id": "map",
          "label": "지도 · 개요",
          "count": 1
        },
        {
          "id": "mm",
          "label": "멘탈모델",
          "count": 5
        },
        {
          "id": "cfg",
          "label": "구성 · 재현 랩",
          "count": 7
        },
        {
          "id": "id",
          "label": "신원 · mTLS",
          "count": 3
        },
        {
          "id": "ref",
          "label": "필드 정본",
          "count": 5
        },
        {
          "id": "rpt",
          "label": "실측 리포트",
          "count": 3
        }
      ],
      "docs": [
        {
          "title": "Istio Egress — 문서 지도",
          "desc": "Istio egress(외부로 나가는 트래픽) 문서를 주제별로 모은 아카이브의 지도(MOC)다. 좌측 카탈로그의 6개 토픽(지도 → 멘탈모델 → 구성·재현 랩 → 신원·mTLS → 필드 정본 → 실측 리포트)이 그대로 읽는 순서이고, 이 페이지는 각 문서에 한두 줄 설명을 붙인 큐레이…",
          "url": "/public/istio-egress/map__MOC-egress-overview.html",
          "domain": "istio-egress",
          "topic": "map",
          "type": "MOC",
          "mtime": 1783053739
        },
        {
          "title": "Egress 4-CRD 직관 — \"한 번의 curl = 두 hop\", 4개를 어떤 순서로 어떻게 채우나",
          "desc": "egress gateway 설정이 \"Gateway·VirtualService·ServiceEntry·DestinationRule을 왜 4개나, 어느 필드를 어디에\"로 막히는 이유는 멘탈모델 없이 필드부터 보기 때문이다. 이 문서는 거꾸로 간다 — 먼저 \"한 번의 외부 호출이 두 hop…",
          "url": "/public/istio-egress/mm__guide-crd-mental-model.html",
          "domain": "istio-egress",
          "topic": "mm",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "DestinationRule 만들기 — 기초부터 심화까지",
          "desc": "DR은 \"어디로 보낼지\"(VS의 일)가 아니라 \"도착이 결정된 목적지와 어떻게 통신할지\"를 정하는 리소스다. host 문자열이 서비스 레지스트리와 매칭되어 Envoy cluster에 컴파일되는 전 과정, trafficPolicy 필드가 cluster의 어느 칸으로 흩어지는지, 레벨 3…",
          "url": "/public/istio-egress/mm__guide-destinationrule-fundamentals.html",
          "domain": "istio-egress",
          "topic": "mm",
          "type": "guide",
          "mtime": 1783053595
        },
        {
          "title": "Sidecar 리소스는 '좁은 범위가 넓은 범위를 통째로 이기는' override 계층으로, 사이드카에 푸시할 설정을 좁혀 성능과 egress 거버넌스를 동시에 얻는다",
          "desc": "Istio의 기본 가정은 \"메시 안 모든 워크로드가 다른 모든 워크로드에 접근 가능\"이다. 그래서 istiod는 각 Envoy에 메시 전체 설정을 푸시하고, 규모가 커지면 이것이 메모리·xDS push·istiod CPU를 동시에 압박한다. Sidecar 리소스는 두 개의 서로 다른…",
          "url": "/public/istio-egress/mm__note-sidecar-scope.html",
          "domain": "istio-egress",
          "topic": "mm",
          "type": "note",
          "mtime": 1782946807
        },
        {
          "title": "Egress route 스코핑 — metadata.namespace는 적용 범위가 아니다",
          "desc": "Istio traffic 리소스의 metadata.namespace는 \"어디에 저장했는가\"(소유 경계)이지 \"어느 proxy에 적용되는가\"(적용 범위)가 아니다. 적용 범위는 gateways · exportTo · sourceNamespace/sourceLabels · Sidecar.…",
          "url": "/public/istio-egress/mm__note-vs-scoping.html",
          "domain": "istio-egress",
          "topic": "mm",
          "type": "note",
          "mtime": 1782946807
        },
        {
          "title": "Istio Sidecar CRD 적용 범위(scope) 설정 방법",
          "desc": "Sidecar 리소스는 한 워크로드 Envoy가 받는 설정을 좁혀 config를 경량화하고, outboundTrafficPolicy와 결합해 egress 거버넌스를 만든다. 멘탈모델 하나: scope는 Mesh / Namespace / Workload 세 단계지만 어느 Pod에든 적용…",
          "url": "/public/istio-egress/mm__src-sidecar-scope.html",
          "domain": "istio-egress",
          "topic": "mm",
          "type": "src",
          "mtime": 1782946807
        },
        {
          "title": "Istio Egress Gateway 도입 가이드 — Passthrough vs mTLS Passthrough",
          "desc": "대상: 플랫폼/인프라/보안 담당자 환경: on-prem Kubernetes, Istio 1.30.0 (sidecar mode), PCI-DSS 준수 IDC 결정 요약: mTLS Passthrough(ISTIO_MUTUAL) 패턴 채택. proxy 도입에 따른 TCP 운영 이슈는 방식과…",
          "url": "/public/istio-egress/cfg__guide-adoption-passthrough-vs-mtls.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "GSLB 뒤 DNS resolution 재현 랩 — \"세션이 끊길 수도 있다\"를 눈으로 보기",
          "desc": "ServiceEntry resolution 정본은 DNS(STRICT_DNS)와 DNS_ROUND_ROBIN(LOGICAL_DNS)의 차이를 이론으로 정리했다. 이 문서는 그 이론을 자기완결형 랩으로 라이브 재현한다 — 공유 인프라(egress gateway·cluster CoreDN…",
          "url": "/public/istio-egress/cfg__guide-dns-gslb-repro-lab.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "이중 egress gateway — passthrough와 mTLS를 별도 ns·별도 pod로 나란히",
          "desc": "단일 egress gateway를 멀티-gateway 토폴로지로 일반화하면서, 두 egress 패턴(① TLS PASSTHROUGH, ② outer 메시 mTLS + inner 앱 TLS)을 서로 다른 namespace의 서로 다른 gateway pod로 동시에 띄워 직접 비교한 ho…",
          "url": "/public/istio-egress/cfg__guide-dual-gateway.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "Egress TCP 문제별 처방전 — 어떤 문제에, 어떤 설정을, 어디에, 어떻게",
          "desc": "TCP 병목 정본이 \"왜 병목이 생기는가\"의 정본이라면, 이 문서는 egressgateway에서 실제로 발생하는 TCP 문제 5가지를 하나씩 놓고 — 증상 → 어떤 설정을 → 어디에(리소스) → 어떻게(YAML) → 검증 — 순서로 처방하는 실행 문서다. 예시 채널 하나 (peak 동…",
          "url": "/public/istio-egress/cfg__guide-egress-tcp-tuning.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782984733
        },
        {
          "title": "Istio 1.30 Egress Gateway — 외부 HTTPS 통신 설치·구성·테스트 가이드",
          "desc": "homelab(kubespray bare-metal, k8s v1.30.6, CNI Calico, Istio 1.30.0)에서 egress gateway를 Helm으로 구성하고, 앱이 직접 https://를 호출하는 TLS Passthrough(SNI 라우팅) 시나리오를 끝까지 구성·…",
          "url": "/public/istio-egress/cfg__guide-gateway-https.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "Pod 커널 파라미터 정본 — 호스트 sysctl은 왜 pod에 안 먹히고, unsafe sysctl은 어떻게 넣는가",
          "desc": "TCP 병목 정본 §06은 완화 운영값이 4개 레이어(DR / pod sysctl / 노드 sysctl / Helm)에 분산된다고 정리했다. 이 문서는 그중 pod sysctl 레이어 하나를 메커니즘 레벨로 전개한다 — 호스트 /etc/sysctl.d가 pod에 전파되지 않는 이유(n…",
          "url": "/public/istio-egress/cfg__guide-pod-sysctl-netns.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782983438
        },
        {
          "title": "Egress TCP 병목 재현 랩 — 한계를 줄여서 부딪힌다",
          "desc": "TCP 병목 정본의 한계 수치(Envoy 1024, 포트 28k, conntrack 26만)는 그대로 재현하려면 연결 수만 개가 필요하다. 이 랩의 기법은 반대다 — 한계를 5~20으로 줄여서, 같은 메커니즘을 연결 수십 개로 관찰한다. 재현 4종 각각이 운영에서 만날 실패 시그니처(…",
          "url": "/public/istio-egress/cfg__guide-tcp-failure-reproduction.html",
          "domain": "istio-egress",
          "topic": "cfg",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "Egress 신원 기반 통제 — mTLS 신원이 공용 gateway에 멀티테넌시를 만든다",
          "desc": "\"egress gateway만 세우면 외부 통신이 통제된다\"는 직관의 빈칸을 메우는 문서. 방화벽·NetworkPolicy는 \"외부로 나가는 유일한 경로가 gateway인가\"(Q1) 에만 답하고, \"그 gateway를 누가, 어느 목적지로 쓸 수 있나\"(Q2) 에는 답하지 못한다. Q…",
          "url": "/public/istio-egress/id__guide-mtls-identity-control.html",
          "domain": "istio-egress",
          "topic": "id",
          "type": "guide",
          "mtime": 1782946807
        },
        {
          "title": "Egress 신원, 이중 TLS 없이 — passthrough + Calico가 HTTPS over mTLS를 대체하는 근거",
          "desc": "\"egress에서 호출 워크로드 신원을 통제하려면 HTTPS over mTLS(이중 TLS)가 필요하다\"는 통념에 대한 반론. 멘탈모델 한 줄: 강제(enforcement)는 어차피 chokepoint(egress gateway)에서 일어난다 — 패턴 선택은 \"그 앞에서 호출자를 어떻…",
          "url": "/public/istio-egress/id__note-identity-without-mtls.html",
          "domain": "istio-egress",
          "topic": "id",
          "type": "note",
          "mtime": 1782946807
        },
        {
          "title": "Egress \"HTTPS over mTLS\" (ISTIO_MUTUAL) — 구조·CRD·장단점·활용·운영",
          "desc": "머릿속에 넣을 한 장의 그림: 이 패턴은 \"end-to-end 암호화 보존\"과 \"egress에서 호출자 신원 식별\"이라는 서로 독립인 두 축의 교집합 칸이다 — 둘 다 Yes일 때만 정답인 좁은 셀. 구현은 이중 TLS: 앱은 그대로 https://(inner end-to-end TL…",
          "url": "/public/istio-egress/id__src-https-over-mtls.html",
          "domain": "istio-egress",
          "topic": "id",
          "type": "src",
          "mtime": 1782946807
        },
        {
          "title": "tcpKeepalive 필드 노트 — time / interval / probes는 각각 무엇을 제어하는가",
          "desc": "DR connectionPool.tcp.tcpKeepalive의 세 필드는 Envoy가 만든 개념이 아니라 리눅스 커널의 TCP keepalive 소켓 옵션 3개에 1:1 매핑된다. Envoy는 upstream 소켓에 옵션을 설정만 하고, probe를 보내는 주체는 커널이다. 이 한…",
          "url": "/public/istio-egress/ref__note-tcp-keepalive-fields.html",
          "domain": "istio-egress",
          "topic": "ref",
          "type": "note",
          "mtime": 1783052927
        },
        {
          "title": "Egress Gateway 필드 매뉴얼 — HTTPS passthrough 중심 (출처: LLM 답변 + Istio 1.30 공식 문서)",
          "desc": "머릿속에 둘 단 하나의 그림(ANCHOR): egress gateway는 외부 트래픽을 유도하는 라우팅 수렴점일 뿐 강제 장치가 아니며, 외부 구간의 TLS를 누가 종단하느냐가 게이트웨이의 가시성·앱 변경·암호화 범위를 한꺼번에 결정한다. 앱이 끝까지 TLS를 쥐면(https) 게이트…",
          "url": "/public/istio-egress/ref__src-egress-gateway.html",
          "domain": "istio-egress",
          "topic": "ref",
          "type": "src",
          "mtime": 1782946807
        },
        {
          "title": "Egress 외부 endpoint 프로토콜별 Istio 설정 — HTTP vs HTTPS",
          "desc": "외부로 나가는 트래픽의 endpoint가 평문 HTTP일 때와 HTTPS일 때 ServiceEntry / Gateway / VirtualService / DestinationRule을 어떻게 설정하고, 왜 한쪽 설정을 다른 쪽에 그대로 쓰면 깨지는지를 Envoy 필터 체인 수준에서 정…",
          "url": "/public/istio-egress/ref__src-http-vs-https.html",
          "domain": "istio-egress",
          "topic": "ref",
          "type": "src",
          "mtime": 1782946807
        },
        {
          "title": "Egress Gateway 운영 가이드 — passthrough + ISTIO_MUTUAL (출처: LLM 답변 + Istio 1.30 공식 문서)",
          "desc": "앱이 HTTPS로 직접 호출(end-to-end TLS 유지) + 게이트웨이는 PASSTHROUGH(복호화 안 함) + proxy→egress 구간은 ISTIO_MUTUAL로 mTLS. 결론부터: 이 게이트웨이가 보는 것은 \"암호화된 장기 TCP 스트림\" 하나뿐이고, 모니터링(L4+S…",
          "url": "/public/istio-egress/ref__src-operations.html",
          "domain": "istio-egress",
          "topic": "ref",
          "type": "src",
          "mtime": 1782946807
        },
        {
          "title": "Egress TCP 병목 정본 — L4 proxy가 연결을 모으면 무엇이 고갈되는가",
          "desc": "egress gateway 도입은 mTLS 여부와 무관하게 L4 proxy 하나를 전사 외부행 경로에 끼워 넣는 일이다. 이 문서는 그때 발생하는 TCP 병목 5종을 — Envoy 연결 상한 → ephemeral port/TIME_WAIT → conntrack → 중간장비 half-o…",
          "url": "/public/istio-egress/ref__src-tcp-bottlenecks.html",
          "domain": "istio-egress",
          "topic": "ref",
          "type": "src",
          "mtime": 1782984867
        },
        {
          "title": "Runbook — ServiceEntry resolution: DNS 동작과 진단 (STRICT_DNS)",
          "desc": "외부 도메인(httpbin.org)을 ServiceEntry(resolution: DNS)로 등록하면 istiod가 이를 Envoy의 STRICT_DNS cluster로 변환한다. 이 문서는 그 변환·DNS 갱신 메커니즘, \"죽은 IP\" 처리, ambient DNS 질의 경로를 홈랩…",
          "url": "/public/istio-egress/rpt__report-2026-06-07_dns-resolution.html",
          "domain": "istio-egress",
          "topic": "rpt",
          "type": "report",
          "mtime": 1782946807
        },
        {
          "title": "Test Report — Ingress / Egress Gateway 동작 검증",
          "desc": "홈랩 클러스터에서 Ingress·Egress gateway 동작을 실측 검증한 리포트. 하나의 그림: gateway는 메시 경계에 선 전용 Envoy proxy다. ingress는 자기가 TLS를 끝내므로(termination) L7 전체가 보여 host/path로 분기하고, egre…",
          "url": "/public/istio-egress/rpt__report-2026-06-07_ingress-egress.html",
          "domain": "istio-egress",
          "topic": "rpt",
          "type": "report",
          "mtime": 1782946807
        },
        {
          "title": "Test Report — Egress Gateway \"HTTPS over mTLS\" (ISTIO_MUTUAL)",
          "desc": "egress gateway에서 sidecar↔gw 구간만 Istio mTLS(ISTIO_MUTUAL)로 감싸 게이트웨이가 호출자의 SPIFFE 신원을 검증하면서, 앱이 보낸 HTTPS는 외부까지 end-to-end로 보존되는 \"이중 TLS\" 패턴을 홈랩에서 실측 검증한 리포트. 결론:…",
          "url": "/public/istio-egress/rpt__report-2026-06-08_egress-mtls.html",
          "domain": "istio-egress",
          "topic": "rpt",
          "type": "report",
          "mtime": 1782946807
        }
      ]
    },
    {
      "id": "k8s",
      "title": "Kubernetes",
      "desc": "Kubernetes lab notes for the homelab: kind cluster setup and usage plus libvirt VM-based control-plane labs, including VM-to-bridge network troubleshooting. (shareable subset, redacted)",
      "icon": "☸️",
      "url": "/public/k8s/",
      "count": 5,
      "updated": "2026-07-02",
      "topics": [
        {
          "id": "k8s",
          "label": "Kubernetes (kind / VM labs)",
          "count": 5
        }
      ],
      "docs": [
        {
          "title": "KIND Lab Usage Guide",
          "desc": "Verified: 2026-03-02 환경: Ubuntu 24.04 LTS, Docker 29.2.1, KIND v0.31.0",
          "url": "/public/k8s/k8s__guide-kind-usage.html",
          "domain": "k8s",
          "topic": "k8s",
          "type": "guide",
          "mtime": 1782685065
        },
        {
          "title": "virsh + cloud-init VM 생성 가이드",
          "desc": "작성일: 2026-03-05 환경: Ubuntu 24.04 호스트, libvirt/KVM, cloud-init",
          "url": "/public/k8s/k8s__guide-virsh-vm-creation.html",
          "domain": "k8s",
          "topic": "k8s",
          "type": "guide",
          "mtime": 1782685065
        },
        {
          "title": "ArgoCD Application 네임스페이스 Watch 범위",
          "desc": "작성일: 2026-07-02 | 컴포넌트: argocd-server, argocd-application-controller, argocd-applicationset-controller",
          "url": "/public/k8s/k8s__ref-argocd-application-namespace-scope.html",
          "domain": "k8s",
          "topic": "k8s",
          "type": "ref",
          "mtime": 1782982087
        },
        {
          "title": "k8s-cp1 VM 네트워크 접속 불가 트러블슈팅",
          "desc": "작성일: 2026-03-05",
          "url": "/public/k8s/k8s__runbook-cp1-vm-network-troubleshooting.html",
          "domain": "k8s",
          "topic": "k8s",
          "type": "runbook",
          "mtime": 1782685065
        },
        {
          "title": "Runbook: KIND-Based Local Kubernetes Lab Setup",
          "desc": "Date: 2026-03-02 KIND: v0.31.0 Kubernetes: v1.34.3 (single-node, control-plane only) Cluster Name: lab (context: kind-lab)",
          "url": "/public/k8s/k8s__runbook-kind-lab-setup.html",
          "domain": "k8s",
          "topic": "k8s",
          "type": "runbook",
          "mtime": 1782685065
        }
      ]
    },
    {
      "id": "kernel",
      "title": "Linux Kernel",
      "desc": "Kernel internals field notes — CFS/EEVDF scheduler deep-dive.",
      "icon": "🐧",
      "url": "/public/kernel/",
      "count": 1,
      "updated": "2026-06-29",
      "topics": [
        {
          "id": "sched",
          "label": "Scheduling",
          "count": 1
        }
      ],
      "docs": [
        {
          "title": "Linux CFS Scheduler 완전 정리 (Kernel 6.x 기준)",
          "desc": "작성일: 2026-02-21 커널 버전: 6.17.0-14-generic (Ubuntu 24.04.4 LTS) 목적: CFS 동작 원리, 한계, EEVDF 전환 배경까지 이해",
          "url": "/public/kernel/sched__note-cfs-eevdf-scheduler.html",
          "domain": "kernel",
          "topic": "sched",
          "type": "note",
          "mtime": 1782679019
        }
      ]
    },
    {
      "id": "networking",
      "title": "Networking",
      "desc": "Proxy & TLS field notes — HTTP CONNECT tunneling and TLS 1.3 over Squid.",
      "icon": "🌐",
      "url": "/public/networking/",
      "count": 2,
      "updated": "2026-06-29",
      "topics": [
        {
          "id": "tunnel",
          "label": "Tunneling & Proxies",
          "count": 2
        }
      ],
      "docs": [
        {
          "title": "HTTP Tunneling",
          "desc": "HTTP Tunneling은 HTTP 프로토콜을 통로(터널)로 사용하여, 원래 HTTP가 아닌 트래픽을 전달하는 기법이다.",
          "url": "/public/networking/tunnel__note-http-tunneling-basics.html",
          "domain": "networking",
          "topic": "tunnel",
          "type": "note",
          "mtime": 1782679019
        },
        {
          "title": "TLS 1.3 over HTTP Tunneling via Squid — 무엇이 문제인가",
          "desc": "기업 환경에서 Squid 같은 Forward Proxy는 보안·감사·캐싱 목적으로 HTTPS 트래픽을 관찰하거나 검사한다. 그런데 TLS 1.3이 도입되면서, 기존에 프록시가 의존하던 여러 관찰 포인트가 사라졌다.",
          "url": "/public/networking/tunnel__note-tls13-over-squid.html",
          "domain": "networking",
          "topic": "tunnel",
          "type": "note",
          "mtime": 1782679020
        }
      ]
    },
    {
      "id": "virsh",
      "title": "KVM / libvirt",
      "desc": "KVM / libvirt operations: a virsh command guide and a homelab VM provisioning reference (cloud-init guests on the host bridge). (shareable subset, redacted)",
      "icon": "🖥️",
      "url": "/public/virsh/",
      "count": 1,
      "updated": "2026-06-29",
      "topics": [
        {
          "id": "kvm",
          "label": "KVM / libvirt",
          "count": 1
        }
      ],
      "docs": [
        {
          "title": "virsh를 이용한 KVM/QEMU VM 관리 가이드",
          "desc": "session vs system 모드: qemu:///session은 일반 사용자 권한으로 동작하며 네트워크 기능이 제한됩니다. 브릿지 네트워크 등 고급 네트워킹이 필요하면 qemu:///system을 사용해야 합니다.",
          "url": "/public/virsh/kvm__guide-virsh.html",
          "domain": "virsh",
          "topic": "kvm",
          "type": "guide",
          "mtime": 1782685129
        }
      ]
    }
  ]
}