day-log

Istio Ambient mode가 1.24에서 GA 된 게 벌써 1년 반 전이다. 우리 팀도 사이드카 지옥에서 벗어나려고 작년 말부터 조금씩 옮겨왔는데, 처음에는 그냥 "사이드카가 사라진 서비스 메시" 정도로 이해하고 시작했다. 그러다 프로덕션에서 이상한 이슈 몇 개 만나면서 결국 ztunnel 내부를 뜯어보게 됐다. 이 글은 그 과정에서 정리한 내용이다.한 가지 미리 얘기하자면, 이 글은 "Ambient가 좋다/나쁘다" 얘기는 아니다. 내부 동작이 어떻게 되어 있는지, 그리고 왜 그렇게 설계됐는지에 대한 노트에 가깝다.ztunnel은 왜 노드마다 하나만 뜨는가Ambient mode의 첫 번째 특징은 데이터 플레인이 두 층으로 쪼개져 있다는 것이다. L4(TCP, mTLS)는 ztunnel이, L7(H..

Istio ambient mode가 1.24에서 GA된 지 반년 좀 넘었다. 우리 팀은 sidecar 기반으로 운영해온 클러스터가 3개 있고, 신규로 붙일 클러스터가 하나 더 생기면서 자연스럽게 "이번엔 ambient로 갈까?"라는 논의가 시작됐다. 결론부터 말하면 신규 클러스터는 ambient, 기존 3개는 당분간 sidecar 유지다. 왜 그런 판단을 했는지 정리한다.솔직히 처음엔 나도 "ztunnel이 좀 무섭다"는 인상이 있었다. 노드 단위로 프록시가 돌고, 특정 노드가 죽으면 그 노드에 있는 모든 워크로드의 mTLS가 흔들리는 거 아닌가 하는 걱정. 근데 몇 주 파보면서 그건 좀 오해였다.리소스 관점: 이건 진짜 크다sidecar 방식 클러스터에서 Envoy가 잡아먹는 리소스가 얼마나 되는지 실..

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

기존 Gateway 모델의 한계올해 2월에 Gateway API v1.5가 나왔고, ListenerSet이 드디어 Standard 채널로 올라왔다. 우리 팀에서는 v1.4 시절부터 Experimental로 깔짝거리며 써봤는데, 이제 GA니까 본격적으로 도입했다. 막상 옮겨보니 단순한 기능 추가가 아니라 멀티팀 환경에서 Gateway 관리 모델 자체가 바뀌는 변화였다.이 글은 ListenerSet이 뭔지, 왜 필요한지, 그리고 기존 Gateway에서 어떻게 갈아끼는지 정리한 가이드다. Istio나 Envoy Gateway 같은 구현체에 따라 세부 동작이 다르긴 한데, 기본 개념은 동일하다.Gateway API에서 Gateway 리소스 하나는 보통 플랫폼 팀이 소유한다. Listener를 여러 개 박아두고,..

작년 이맘때쯤 progressive delivery를 본격적으로 도입하기로 결정했다. 그 때만 해도 우리 팀은 "둘 다 비슷한 거 아니야?"라는 분위기였고, 사실 데모만 보면 정말 비슷해 보였다. 캐너리, 블루그린, 메트릭 기반 자동 promotion. 똑같은 단어들이 양쪽 문서에 다 나온다.그래서 우리는 좀 무책임한 결정을 했다. 둘 다 써보기로 했다. 일부 서비스는 Flagger, 일부는 Argo Rollouts. 1년이 지난 지금, 한쪽으로 통일하기로 했고, 그 과정에서 알게 된 차이들을 정리해 본다.시작 환경우리 환경을 먼저 짧게 적는다. 비교는 결국 환경 의존적이라서.EKS 1.32 클러스터 두 대 (스테이지/프로덕션)서비스 메시는 Istio (ambient 아니고 sidecar)GitOps는 ..

올해 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 좋다, 옮겨라"는 류의 이야기는 아니다. 어떻게 끊김 없이 옮길지에 대한 실전 절차를 정리한다. 단번에 바꾸지 않는다...

요즘 사내에서 sidecar 없는 서비스 메시 이야기가 자주 나온다. 우리 팀도 작년 4분기에 Istio sidecar 모드를 운영하다가 메모리 footprint와 업그레이드 부담에 지쳐서 sidecarless 옵션을 진지하게 검토하기 시작했다. 후보는 두 개로 좁혀졌다. Istio Ambient Mode와 Cilium Service Mesh.둘 다 sidecar를 없앤다는 큰 그림은 같은데 접근 방식이 꽤 다르다. 어느 쪽이 우리 팀에 맞는지 판단하기까지 두 달 정도 PoC를 돌렸고, 그 과정에서 알게 된 것들을 정리한다. 결론부터 말하면 우리는 아직 한쪽을 완전히 못 정했다. 그래서 이 글은 깔끔한 권고문이 아니다.데이터 플레인이 어디서 도는가가장 큰 차이는 트래픽이 처리되는 위치다.Istio Amb..

작년 말부터 Istio Ambient Mode를 진지하게 보기 시작했다. 1.22에서 Beta로 올라오고, 1.24~1.25 거치면서 단일 클러스터 한정으로는 production ready라는 얘기가 공식 문서에도 들어갔다. 우리 팀에서도 "그러면 슬슬 옮겨야 하는 거 아니냐"는 얘기가 나왔고, 6개월 정도 PoC와 일부 트래픽 마이그레이션을 진행했다.결론부터 말하면 새 클러스터는 Ambient로 깔고, 기존 sidecar 클러스터는 당분간 그대로 둔다로 정리됐다. 그 과정에서 정리된 비교를 남긴다.데이터 플레인 구조의 차이Sidecar 모드는 다들 알다시피 Pod마다 envoy 컨테이너 하나 더 붙는다. 100개 Pod 띄우면 envoy도 100개. 메모리, CPU, 부팅 시간 다 곱하기 N이 된다.A..