서비스 메시인 Istio의 Ambient Mesh는 사이드카를 사용하지 않는 방식입니다. Istio는 사이드카를 이용해서 서비스 메시를 제공하는데 Kubernetes에서 Pod을 띄울 때 서비스 팟외에 istio-proxy 컨테이너를 같이 띄우는 사이드카 방식을 사용합니다. 이렇게 사이드카로 뜬 istio-proxy가 서비스 팟으로 들어오고 나가는 트래픽이 모두 Istio를 커지면서 서비스 디스커버리를 해주거나 트래픽 관리를 할 수있게 됩니다.

이 사이드카 방식은 모든 Pod에 추가로 istio-proxy 컨테이너가 떠야 하기 때문에 컴퓨팅 자원이 많이 필요합니다. Pod이 1,000개라면 서비스 메시를 위해 추가로 컨테이너도 1,000개가 떠야합니다.

이러한 자원을 아끼기 위해 오랫동안 업계에서는 사이드카 없는 방법을 연구했고 그렇게 하나씩 결과물이 나오는 상황에서 Istio가 사이드카가 없는 방법으로 개발하고 있는 것이 Ambient Mesh입니다.

이 글은 Ambient Mesh의 진행 과정을 설명하는 글입니다. Ambient Mesh는 작년 알파를 출시하고 Ambient Mesh의 가치는 증명했지만 초기에 구현했던 메커니즘이 다른 CNI들과 충돌하는 것을 알게 되었다고 합니다. 사용자들이 사용하는 CNI가 다양하기 때문에 사용자들이 모든 CNI와 호환되기를 원한다는 것을 알게 되어 베타 버전을 릴리스 하기 전에 이부분을 해결하는 것이 가장 중요한 문제가 되었다고 합니다.

초기에 구현했던 istio-cni는 기본 CNI 구현이 아니라 클러스터의 CNI를 확장하는 노드 에이전트이기 때문에 클러스터의 기본 CNI 네트워크와 충돌할 수도 있고 네트워크 정책도 솽황에 따라 제대로 적용되지 않을 수도 있었습니다. 그래서 초기 구현이 요구사항을 만족할 수 없다는 걸 깨닫게 되고 새로운 방법을 찾기 시작했습니다.

그러던 중 사이드카를 모방해서 파드의 네트워크 네임스페이스에서 리다이렉션을 구성하는 아이디어를 나왔고 Linux 소켓을 이용해서 다른 네임스페이스의 수신 소켓을 생성하고 소유할 수 있다는 것을 알게되어 이를 이용해서 구현하기로 했다고 합니다. 그렇게 구현한 결과 사이드카 없이도 모든 트래픽 캡처와 리다이렉션이 파드의 네임스페이스 내에서 발생하는 것처럼 할 수 있게 되었고 이는 마치 사이드카 프록시가 있는 것처럼 보이게 만들 수 있게 되었습니다.

https://istio.io/latest/blog/2024/inpod-traffic-redirection-ambient/