업그레이드는 이름표를 옮기는 일이다

한 줄 요약

리비전(revision)으로 설치하면 새 판의 컨트롤 플레인이 옛 판 옆에 선다. 워크로드는 리비전 태그만 알게 하고, 업그레이드는 태그가 가리키는 곳을 옮긴 뒤 워크로드를 재시작하는 일이 된다. 옛 판을 지우기 전까지는 되돌리기가 태그 한 줄이다.

왜 이게 필요했나

Istio 를 제자리에서 올리면(in-place) istiod 가 바뀌는 순간 메시 전체가 새 컨트롤 플레인에 붙는다. 새 판에 문제가 있으면 모든 워크로드가 한꺼번에 영향을 받고, 되돌리려면 옛 판을 다시 설치해야 한다. 사이드카는 파드가 만들어질 때 주입되므로, 컨트롤 플레인을 바꾼 뒤 모든 파드를 재시작할 때까지 두 판의 프록시가 섞여 도는 시간도 피할 수 없다.

리비전은 그 섞이는 시간을 통제된 순서로 바꾼다. 새 판을 별도의 이름(istiod-1-31-0)으로 세우고, 한 네임스페이스씩 옮기며 지켜보고, 모두 옮긴 뒤에 옛 판을 지운다.

어떻게 동작하나

리비전 설치 — istioctl install --set revision=1-31-0 은 이름에 리비전이 붙은 istiod 와 주입 웹훅(istio-sidecar-injector-1-31-0)을 만든다. 옛 리비전의 것은 그대로 남는다.

어느 판의 사이드카를 받을지는 네임스페이스 라벨이 정한다.

라벨	뜻
istio.io/rev=1-31-0	그 리비전의 웹훅이 주입한다
istio.io/rev=prod-stable	태그 prod-stable 이 가리키는 리비전이 주입한다
istio-injection=enabled	default 태그(또는 리비전 없는 설치)가 주입한다

태그는 웹훅 하나다. istioctl tag set prod-stable --revision 1-31-0 은 istio-revision-tag-prod-stable 이라는 주입 웹훅이 1-31-0 의 istiod 를 부르게 만든다. 워크로드 라벨이 prod-stable 을 가리키고 있으면, 태그를 옮기는 것만으로 다음에 만들어지는 파드가 새 판을 받는다. 이미 떠 있는 파드는 재시작해야 바뀐다.

그래서 순서는 이렇다.

1. precheck                    새 판이 이 클러스터에 올라가도 되는가
2. 새 리비전 설치               istiod-1-31-0 가 옆에 선다 (트래픽 변화 없음)
3. 카나리 네임스페이스 이동      라벨을 1-31-0 으로 + 재시작 → 섞인 상태에서 통신 확인
4. 태그 이동 + 나머지 재시작     prod-stable → 1-31-0
5. 되돌리기 연습               태그를 옛 리비전으로 옮겨 재시작 → 다시 앞으로
6. 옛 리비전 제거              모든 프록시가 옮긴 뒤 uninstall --revision 1-30-5

두 판의 프록시가 섞이는 동안에도 통신이 되는 것은 공식 문서가 밝힌 호환 규칙 덕분이다 — 데이터 플레인끼리는 지금 모든 판 사이에 호환되고(앞으로 바뀔 수 있다는 단서가 붙어 있다), 컨트롤 플레인은 데이터 플레인보다 한 판 앞설 수는 있어도 뒤처질 수는 없다. 그래서 문서는 판 차이 자체를 없애는 리비전 방식을 권하고, 옮기는 순서도 '컨트롤 플레인을 먼저, 프록시를 나중에' 다.

현장에서 만나는 모습

"라벨을 바꿨는데 프록시 판이 그대로입니다." 파드를 재시작하지 않았다. 주입은 파드 생성 시점의 일이다.

"옛 리비전을 지웠더니 일부 파드가 설정을 못 받습니다." 재시작하지 않은 파드가 옛 istiod 에 붙어 있었다. 지우기 전에 istioctl proxy-status 로 옛 리비전에 붙은 프록시가 없는지 본다.

"새 리비전을 설치했는데 기존 파드에는 아무 변화가 없습니다." 정상이다. 리비전 설치는 트래픽을 바꾸지 않는다 — 떠 있는 파드는 여전히 옛 istiod 에 붙어 있고, 새 웹훅은 라벨이 그 리비전을 가리키는 네임스페이스에서 파드가 새로 만들어질 때만 불린다.

"태그를 안 쓰고 리비전 이름을 네임스페이스마다 적어 두었습니다." 업그레이드 때마다 모든 네임스페이스 라벨을 고쳐야 한다. 태그는 그 일을 한 줄로 줄인다.

공식 문서: Canary Upgrades · Supported releases · istioctl tag · istioctl x precheck

다음 실습에서 할 것

조리법이 리비전 1-30-5 로만 설치해 둔 메시에서 precheck 를 돌리고, 1.31.0 을 리비전 1-31-0 으로 옆에 세운다. canary 네임스페이스만 먼저 옮겨 두 판이 섞인 채로 통신하는 것을 확인하고, 태그를 옮겨 나머지를 올린 뒤 되돌리기를 한 번 연습한다. 마지막으로 옛 리비전을 지운다.