古い版を消す前に一度戻してみる

한국어 원문으로 표시합니다.

목표

Istio 1.30.5 를 쓰는 진짜 메시를 리비전 카나리 방식으로 1.31.0 으로 올린다. 두 컨트롤 플레인을 나란히 세우고, 한 네임스페이스만 먼저 옮기고, 태그로 나머지를 옮긴 뒤 되돌리기를 연습하고, 마지막에 옛 판을 지운다.

왜 중요한가

컨트롤 플레인 업그레이드는 메시 전체의 설정 공급원을 바꾸는 일이다. 제자리 업그레이드는 문제가 생기면 모두가 한꺼번에 겪고 되돌리기도 어렵다. 리비전과 태그를 쓰면 영향 범위를 네임스페이스 단위로 좁히고 되돌리기를 한 줄로 만들 수 있다 — 단, 순서를 지킬 때만 그렇다.

단계

kubectl apply -f /opt/fixtures/istlab/upgrade-app.yaml 로 재료(shop 의 web, canary 의 client — 두 네임스페이스 모두 istio.io/rev=prod-stable)를 올리고 준비될 때까지 기다리세요. 그다음 /root/istlab-upgrade/01-before.txt 에 web_proxy=·client_proxy=(각 파드 istio-proxy 이미지의 태그)와 prod_stable=(istioctl tag list 에서 태그 prod-stable 이 가리키는 리비전) 세 줄을 적으세요.
istioctl x precheck 의 출력을 /root/istlab-upgrade/02-precheck.txt 에 저장하세요.
1.31.0 을 리비전 1-31-0 으로 설치하세요 — istioctl install --set profile=minimal --set revision=1-31-0 --set meshConfig.accessLogFile=/dev/stdout -y. 설치 뒤 두 istiod(istiod-1-30-5·istiod-1-31-0)가 함께 떠 있어야 하고, 워크로드는 아직 아무것도 바뀌지 않아야 합니다.
canary 네임스페이스의 라벨을 istio.io/rev=1-31-0 으로 바꾸고 client 를 재시작하세요. 그다음 /root/istlab-upgrade/04-mixed.txt 에 client_proxy=·web_proxy=(각 프록시 이미지 태그)와 code=(client 에서 http://web.shop/ 의 상태 코드) 세 줄을 적으세요.
태그 prod-stable 과 default 를 둘 다 리비전 1-31-0 으로 옮기세요(istioctl tag set <태그> --revision 1-31-0 --overwrite). 그다음 canary 의 라벨을 다시 istio.io/rev=prod-stable 로 돌려 두고, shop 의 web 을 재시작해 1.31.0 프록시를 받게 하세요.
지우기 전에 되돌릴 수 있는지 확인하세요 — 태그 prod-stable 을 1-30-5 로 옮기고 web 을 재시작해 프록시 태그를 /root/istlab-upgrade/06-rollback.txt 에 after_rollback= 으로 적은 뒤, 다시 1-31-0 으로 옮기고 web 을 재시작해 after_forward= 로 덧붙이세요.
모든 프록시가 1.31.0 인 것을 확인한 뒤 istioctl uninstall --revision 1-30-5 -y 로 옛 리비전을 지우고, istiod-1-30-5 Deployment 와 주입 웹훅 istio-sidecar-injector-1-30-5 가 사라질 때까지 기다리세요. 그 뒤에도 canary 의 client 에서 http://web.shop/ 은 200 이어야 합니다.
/root/istlab-upgrade/08-report.md 에 다섯 줄 — old_revision=·new_revision=(리비전 이름), mixed_versions_code=(4단계의 code), rollback_version=(6단계 after_rollback), old_injector_left=(지금 istio-sidecar-injector-1-30-5 웹훅이 남아 있으면 yes) — 을 적고 그 아래 배운 것을 네 줄 이상 적으세요.

참고

이 VM 은 준비에 2~4분 걸립니다. 리비전 1-30-5(태그 prod-stable)만 설치되어 있고, 1.31.0 배포판은 /usr/local/istio-1.31.0 에 받아 두었습니다. 로그인 셸의 istioctl 은 1.31.0 입니다.
프록시 판은 istioctl proxy-status 의 VERSION 칸이나 파드의 istio-proxy 이미지 태그로 봅니다. 재시작 직후의 proxy-status 는 잠시 옛 파드를 보여 줄 수 있으니 이미지로 확인하는 편이 확실합니다.
라벨을 바꾼 뒤에는 반드시 kubectl rollout restart 로 파드를 다시 만드세요. 주입은 파드가 만들어질 때 일어납니다.
흔한 실수 — 되돌리기를 확인하기 전에 옛 리비전을 지우는 것. 그 뒤로는 되돌리려면 옛 판을 다시 설치해야 합니다.

지금 무엇이 무엇을 가리키는지 적는다

kubectl apply -f /opt/fixtures/istlab/upgrade-app.yaml 로 재료(shop 의 web, canary 의 client — 두 네임스페이스 모두 istio.io/rev=prod-stable)를 올리고 준비될 때까지 기다리세요. 그다음 /root/istlab-upgrade/01-before.txt 에 web_proxy=·client_proxy=(각 파드 istio-proxy 이미지의 태그)와 prod_stable=(istioctl tag list 에서 태그 prod-stable 이 가리키는 리비전) 세 줄을 적으세요.

이 VM 의 컨트롤 플레인은 리비전 1-30-5 로만 설치되어 있고, 워크로드는 리비전 이름이 아니라 태그 prod-stable 로 주입을 받습니다. 태그는 '지금 운영에 쓰는 리비전' 을 가리키는 이름표라, 업그레이드는 워크로드 라벨을 하나하나 고치는 일이 아니라 이 이름표를 옮기는 일이 됩니다. 이 VM 의 istioctl 은 1.31.0 이지만 태그 목록은 버전과 상관없이 읽힙니다.

올리기 전에 묻는다 — precheck

istioctl x precheck 의 출력을 /root/istlab-upgrade/02-precheck.txt 에 저장하세요.

precheck 는 클러스터가 새 판을 받을 준비가 되었는지(쿠버네티스 판, 권한, 옛 설정의 폐기 예정 필드 등)를 살핍니다. 여기서 경고가 나오면 설치보다 그것을 먼저 고치는 것이 순서입니다. 1.31.0 의 istioctl 로 돌리면 1.31.0 기준으로 봅니다.

새 판을 옛 판 옆에 세운다

1.31.0 을 리비전 1-31-0 으로 설치하세요 — istioctl install --set profile=minimal --set revision=1-31-0 --set meshConfig.accessLogFile=/dev/stdout -y. 설치 뒤 두 istiod(istiod-1-30-5·istiod-1-31-0)가 함께 떠 있어야 하고, 워크로드는 아직 아무것도 바뀌지 않아야 합니다.

리비전으로 설치하면 이름에 리비전이 붙은 istiod 와 주입 웹훅(istio-sidecar-injector-1-31-0)이 새로 생기고 옛 것은 그대로 남습니다. 어느 네임스페이스도 새 리비전을 가리키지 않으므로 이 순간 트래픽에는 아무 변화가 없습니다 — 그래서 설치 자체는 언제든 안전하게 할 수 있습니다. istioctl tag list 에 새 리비전이 태그 없이 한 줄 나타납니다.

한 네임스페이스만 새 판으로 옮긴다

canary 네임스페이스의 라벨을 istio.io/rev=1-31-0 으로 바꾸고 client 를 재시작하세요. 그다음 /root/istlab-upgrade/04-mixed.txt 에 client_proxy=·web_proxy=(각 프록시 이미지 태그)와 code=(client 에서 http://web.shop/ 의 상태 코드) 세 줄을 적으세요.

라벨만 바꿔서는 아무 일도 일어나지 않습니다. 사이드카는 파드가 만들어질 때 주입되므로 재시작해야 새 리비전의 프록시를 받습니다. 이렇게 한 네임스페이스만 먼저 옮기는 것이 카나리입니다 — 문제가 생겨도 그 네임스페이스만 되돌리면 됩니다. 공식 문서는 데이터 플레인끼리는 지금 모든 판 사이에 호환된다고 밝히므로(앞으로 바뀔 수 있다는 단서와 함께) 섞인 채로도 mTLS 가 맺어져야 합니다.

이름표를 옮긴다 — 태그로 나머지를 올린다

태그 prod-stable 과 default 를 둘 다 리비전 1-31-0 으로 옮기세요(istioctl tag set <태그> --revision 1-31-0 --overwrite). 그다음 canary 의 라벨을 다시 istio.io/rev=prod-stable 로 돌려 두고, shop 의 web 을 재시작해 1.31.0 프록시를 받게 하세요.

태그는 사실 주입 웹훅 하나입니다(istio-revision-tag-prod-stable). 태그를 옮기면 그 웹훅이 가리키는 istiod 가 바뀌고, 그 태그를 쓰는 네임스페이스에서 새로 만들어지는 파드는 새 리비전의 프록시를 받습니다. 카나리로 옮겨 두었던 canary 도 태그로 돌려 두면, 앞으로는 태그 하나만 관리하면 됩니다. default 태그는 istio-injection=enabled 라벨을 쓰는 네임스페이스와 istioctl 의 기본 대상을 정합니다.

되돌리기를 연습해 둔다

지우기 전에 되돌릴 수 있는지 확인하세요 — 태그 prod-stable 을 1-30-5 로 옮기고 web 을 재시작해 프록시 태그를 /root/istlab-upgrade/06-rollback.txt 에 after_rollback= 으로 적은 뒤, 다시 1-31-0 으로 옮기고 web 을 재시작해 after_forward= 로 덧붙이세요.

옛 리비전이 살아 있는 동안에는 되돌리기가 태그 한 줄과 재시작 한 번입니다. 옛 리비전을 지운 뒤에는 그 판을 다시 설치해야 합니다. 그래서 운영에서는 새 판으로 충분히 지낸 뒤에야 옛 리비전을 지우고, 그 전에 되돌리는 길이 실제로 되는지 한 번 해 봅니다. 재시작 뒤 프록시가 바뀌었는지는 파드의 istio-proxy 이미지로 확인합니다.

모두 옮겨 간 뒤에 옛 판을 지운다

모든 프록시가 1.31.0 인 것을 확인한 뒤 istioctl uninstall --revision 1-30-5 -y 로 옛 리비전을 지우고, istiod-1-30-5 Deployment 와 주입 웹훅 istio-sidecar-injector-1-30-5 가 사라질 때까지 기다리세요. 그 뒤에도 canary 의 client 에서 http://web.shop/ 은 200 이어야 합니다.

리비전을 지정한 uninstall 은 그 리비전의 컨트롤 플레인만 지우고 다른 리비전과 워크로드는 건드리지 않습니다. 아직 옛 리비전 프록시를 쓰는 파드가 남아 있다면 그 파드들은 설정을 받을 곳을 잃습니다 — 그래서 지우기 전에 istioctl proxy-status 와 파드 이미지로 남은 것이 없는지 확인합니다. 지운 직후에는 잠시 0/1 로 남아 보일 수 있으니 사라질 때까지 기다리세요.

업그레이드 기록을 남긴다

/root/istlab-upgrade/08-report.md 에 다섯 줄 — old_revision=·new_revision=(리비전 이름), mixed_versions_code=(4단계의 code), rollback_version=(6단계 after_rollback), old_injector_left=(지금 istio-sidecar-injector-1-30-5 웹훅이 남아 있으면 yes) — 을 적고 그 아래 배운 것을 네 줄 이상 적으세요.

설명 줄에는 '제자리(in-place) 업그레이드 대신 리비전을 쓰면 무엇을 얻는가' 와 '옛 리비전을 언제 지우는가' 를 자기 말로 적어 두세요.