프록시를 파드에서 떼면 무엇을 얻고 무엇을 나눠야 하나

한 줄 요약

앰비언트는 파드마다 두던 프록시를 노드의 L4 프록시로 옮기고, 요청 내용을 봐야 하는 기능만 waypoint 라는
별도의 L7 프록시에 맡기는 설계다 — 그래서 마이그레이션은 라벨 한 줄이 아니라 기능 목록에서 시작한다.

왜 다른 데이터플레인이 필요했나

사이드카 모델의 비용은 세 가지다. 첫째, 파드마다 컨테이너가 하나씩 늘어난다. 파드 2천 개면 프록시 2천 개이고
그만큼의 요청 자원이 예약된다. 둘째, 프록시를 넣거나 빼거나 판올림하려면 파드를 재시작해야 한다.
메시에 들어오는 일이 배포 이벤트가 되므로, 도입 자체가 각 팀의 배포 일정에 묶인다. 셋째, 프록시가
애플리케이션과 같은 파드에 있어 시작 순서·종료 순서·자원 경합 같은 문제가 따라붙는다.

앰비언트는 이 셋을 한꺼번에 피한다. 노드마다 두 가지를 깐다 — 트래픽을 파드에서 가로채는 구성요소와,
가로챈 트래픽을 상호 인증된 터널로 실어 나르는 L4 프록시다. 파드는 그대로 두고 **네임스페이스 라벨
한 줄**로 메시에 들어오거나 나간다. 재시작이 필요 없다.

두 층으로 갈리는 기능

여기서 정확히 알아야 할 것이 있다. 노드의 L4 프록시는 요청의 내용을 보지 않는다. 그래서 되는 것과
안 되는 것이 분명히 갈린다.

| 기능 | L4 프록시만으로 | waypoint 필요 |
| --- | --- | --- |
| 워크로드 사이 상호 인증과 암호화 | 된다 | — |
| 호출자 신원으로 허용·거부(L4) | 된다 | — |
| 포트·신원 기준 정책 | 된다 | — |
| HTTP 경로·헤더 기반 라우팅 | 안 된다 | 필요 |
| 메서드·경로 단위 인가 | 안 된다 | 필요 |
| 재시도·타임아웃·트래픽 분할 | 안 된다 | 필요 |

waypoint 는 Istio 전용 오브젝트가 아니라 Gateway API 의 Gateway 로 표현된다. 게이트웨이 클래스가
istio-waypoint 인 것이 그것을 waypoint 로 만들고, 리스너는 앰비언트가 파드 사이에 쓰는 터널 프로토콜을
그대로 받는다. 무엇을 위한 waypoint 인지는 라벨 istio.io/waypoint-for 가 말한다 — 서비스 앞에 세울지,
워크로드 앞에 세울지, 둘 다인지, 아무것도 아닌지.

전환은 어떻게 하나

라벨이 두 개라는 점이 함정이다. 사이드카는 주입 웹훅이 보는 라벨을, 앰비언트는 노드의 구성요소가 보는
라벨을 쓴다. 둘은 서로를 모른다. 그래서 네임스페이스에 둘 다 걸어 두어도 오류가 나지 않고, 그 네임스페이스의
파드가 어느 데이터플레인을 쓰는지가 정해지지 않은 상태가 된다. istioctl analyze 가 이 경우를 IST0123 으로
잡아 준다 — 전환 작업의 점검 항목에 이 명령을 넣어 두는 이유다.

순서는 이렇게 잡는다. 먼저 그 네임스페이스가 실제로 쓰는 메시 기능을 적는다. L7 기능이 하나라도 있으면
waypoint 를 먼저 세운다. 그다음 사이드카 라벨을 지우고 앰비언트 라벨을 건다. 되돌리기는 반대 순서다.
전환 중에는 두 모드가 한 클러스터에 공존하므로, 어느 네임스페이스가 어느 모드인지 세는 스크립트를
만들어 두는 편이 사람의 기억보다 낫다.

현장에서 만나는 모습

가장 흔한 사고는 "앰비언트로 옮겼더니 헤더 기반 라우팅이 먹지 않는다" 이다. 규칙은 그대로 있고 오류도
없다. 그 규칙을 강제할 L7 프록시가 그 자리에 없을 뿐이다. 두 층을 모르고 옮기면 반드시 만난다.

이 사고가 특히 고약한 이유는 조용하다는 점이다. L4 계층은 그대로 동작하므로 연결은 맺어지고
상호 인증도 걸린다. 끊기는 것은 요청 내용에 따라 갈라지던 경로뿐이라, 겉보기에는 메시가 잘 도는데
특정 버전으로 가야 할 트래픽만 엉뚱한 곳으로 간다. 로그에도 오류가 남지 않는다. 그래서 전환 계획에는
"이 네임스페이스가 쓰는 메시 오브젝트 목록" 이 반드시 들어가야 하고, 그중 L7 을 요구하는 것이 하나라도
있으면 waypoint 를 먼저 세운 뒤에 라벨을 바꾼다.

두 번째는 라벨을 지우지 않고 더한 경우다. 사이드카 라벨이 남아 있으면 새로 뜨는 파드에는 여전히 프록시가
주입된다. 화면에서는 전환이 끝난 것처럼 보이는데 실제로는 절반만 옮겨 간 상태이고, 이 상태는 배포가
일어날 때마다 조금씩 달라진다.

이 실습 환경의 한계

이 환경에서는 ztunnel 도 waypoint 도 실제로 띄울 수 없다. 그래서 터널을 지나는 트래픽이나 L4 인가가
정말 강제되는 장면은 볼 수 없다. 게다가 이 클러스터에는 Gateway API 의 CRD 가 없어서 waypoint 매니페스트를
생성할 수는 있어도 적용할 수는 없다. 이 사실을 감추지 않고 실습 안에서 직접 확인한다 — 적용이 실패하는
오류 문장이 waypoint 가 무엇 위에 서 있는지를 가장 분명하게 말해 주기 때문이다. 대신 프로파일 렌더,
라벨과 그 충돌 판정, waypoint 매니페스트의 필드는 전부 진짜 도구와 진짜 API 서버로 확인할 수 있다.

다음 실습에서 할 것

앰비언트 프로파일을 렌더해 사이드카 프로파일과 구성요소·신원을 견주고, 메시 설정에 무엇이 더 켜져 있는지
본다. 네임스페이스 라벨로 두 모드를 만들어 보고 둘을 겹쳤을 때 분석기가 무엇을 잡는지 확인한 뒤,
waypoint 매니페스트를 생성해 필드를 읽고 적용이 왜 실패하는지까지 본다. 마지막에는 클러스터의
네임스페이스를 모드별로 세는 점검표를 만든다.