
Istio 3-2편: Partially Enrolled Pod와 Untaint Controller
Ambient mode에서 Pod은 Ready인데 mesh 트래픽이 실패하는 partially enrolled 문제를 다뤘습니다. istio-cni 준비 전에는 일반 Pod이 스케줄되지 않도록 startup taint와 untaint-controller를 활용했습니다.

Ambient mode에서 Pod은 Ready인데 mesh 트래픽이 실패하는 partially enrolled 문제를 다뤘습니다. istio-cni 준비 전에는 일반 Pod이 스케줄되지 않도록 startup taint와 untaint-controller를 활용했습니다.

Istio Ambient mode에서 워크로드 재시작 시 간헐적 503이 발생한 원인을 추적했습니다. 오래된 HBONE connection 재사용과 ztunnel의 graceful close 부재가 핵심이었고, reset retry로 증상을 완화했습니다.

Istio Ambient mode에서 Pod IP 재사용과 stale connection 재사용이 겹쳐 간헐적 503이 발생했습니다. 로그와 pcap, socket을 교차 검증하고 reset retry로 증상을 완화했습니다.

Kubernetes 환경에 LLM 서빙 최적화 기술을 도입하며 발생한 충돌과 해결 과정을 공유했습니다. Istio, 스케줄러, Pod 보호 정책과의 실전 문제를 진단한 사례입니다.

Istio Ambient mode의 요청 흐름을 Envoy config와 트래픽 경로로 단계별로 해부했습니다.\nHBONE, ztunnel, Waypoint가 어떻게 구현되는지 실제 설정 기준으로 설명했습니다.

Istio Ambient mode의 요청 흐름을 Envoy config와 트래픽 경로로 해부했습니다. Gateway, Waypoint, ztunnel이 어떻게 HBONE과 리다이렉션을 구현하는지 정리했습니다.

채널코퍼레이션이 Istio를 프로덕션에 도입하며 Sidecar 대신 Ambient mode를 선택한 배경을 정리했습니다. 또한 ztunnel, waypoint, HBONE 기반의 동작 원리와 장단점을 개괄했습니다.

Istio 서비스 메시 도입 배경과 Ambient mode 선택 이유를 정리했습니다. Sidecar보다 자원 효율과 확장성이 좋지만, 운영 복잡도와 장애 영향 범위 확대라는 단점도 함께 다뤘습니다.
Stage 환경에서 Locust 트래픽을 기반으로 카오스 실험 결과를 정리했습니다. Pod 지연과 외부 API 차단이 서비스와 사용자 경험에 미치는 영향을 확인하고 개선 포인트를 도출했습니다.


EKS에서 Istio Ambient Mode를 이용해 사이드카 오버헤드를 줄이고 리소스 효율성을 높이는 방법을 소개했습니다. Ztunnel과 Waypoint로 보안, 관찰성, 트래픽 제어를 유연하게 구성하는 과정을 설명했습니다.

요기요의 카오스 엔지니어링 도입 과정과 실험 설계 방법을 공유했습니다. Istio와 권한 설정 이슈를 해결하며 AWS FIS로 네트워크 지연 주입을 성공시켰습니다.


사내 빅데이터 플랫폼에서 Istio Ambient Mesh를 검토했지만, 대규모 분산 트랜잭션 환경에는 적합하지 않다고 판단했습니다. ztunnel 병목과 CNI 제약 때문에 다른 네트워크 최적화 방안을 추가 검증하기로 했습니다.