day-log

ambient mode가 Istio 1.24에서 GA된 게 2024년 말이다. 지난주에 우리 팀도 일부 네임스페이스를 sidecar에서 ambient로 옮기는 작업을 마무리했다. 옮기고 나서 가장 많이 받은 질문이 "그래서 mTLS는 누가 거는 거냐", "L7 정책은 어디서 검사되냐"였다. 문서를 봐도 그림 한 장으로 퉁쳐버리니까 막상 트러블슈팅을 시작하면 답답하다.그래서 이 글은 패킷이 Pod A에서 떠나서 Pod B에 도착할 때까지, 정확히 어떤 컴포넌트가 어떤 순서로 끼어드는지를 우리 팀이 확인하면서 정리한 내용이다. Istio 공식 문서가 적당히 추상화한 부분을 한 단계 더 내려가서 본다.sidecar 없는 데이터플레인이라는 말의 진짜 의미ambient mode의 가장 큰 광고 문구는 "sidec..

올해 KubeCon EU에서 가장 많이 들었던 단어 중 하나가 ambient mode였다. 사이드카 없이 mesh를 한다는 컨셉은 매력적이지만, "사이드카가 사라진 자리에서 트래픽은 도대체 어떤 경로를 타는가?"가 제대로 그려지지 않으면 운영이 어렵다. 우리 팀도 4월부터 스테이징 클러스터에 ambient mode를 깔고 한 달 넘게 트래픽 흐름을 들여다봤는데, 사실 내부적으로는 생각보다 단순하지 않다.이 글은 그 한 달 동안 tcpdump와 ztunnel 로그를 번갈아 보면서 정리한 내용이다. 1.24 기준이고, 일부는 1.25-rc 노트도 섞여 있다.ztunnel이 뜨는 순간 노드에서 일어나는 일ambient를 활성화하면 DaemonSet으로 ztunnel이 노드마다 한 개씩 깔린다. 그런데 ztun..

1. Ambient로 옮기기 전에 확인할 것Ambient mode가 Istio 1.24에서 GA로 찍힌 게 작년 말이다. 그동안 1.25, 1.26을 거치면서 production 사용 사례도 꽤 쌓였고, 2026년 초부터는 "이제 슬슬 옮겨도 되겠다"는 분위기가 우리 팀 안에서도 잡혔다. 사이드카가 안 좋아서가 아니라, Pod 하나당 envoy 컨테이너 하나씩 붙는 모델이 노드 수 200대 넘어가면서 점점 답답해졌다. 메모리 사용량의 상당 부분이 사이드카 envoy였고, 무엇보다 사이드카 버전 올릴 때마다 전체 Pod restart가 필요한 게 가장 큰 문제였다.이 글은 "Ambient 좋다, 옮겨라"는 류의 이야기는 아니다. 어떻게 끊김 없이 옮길지에 대한 실전 절차를 정리한다. 단번에 바꾸지 않는다...