새 컨트롤 플레인을 올렸는데 아무 파드도 옮겨 가지 않았다

목표

Istio 컨트롤 플레인을 리비전(revision) 으로 두 벌 나란히 올리고, 네임스페이스 라벨·default 태그로
워크로드를 옛 리비전(stable)에서 새 리비전(canary)으로 옮긴 뒤, 공유 자원을 지키면서 옛 리비전을 걷어 냅니다.
설치 맞춤(IstioOperator)도 렌더링 결과로 확인합니다.

왜 중요한가

인플레이스 업그레이드는 컨트롤 플레인을 한 번에 바꿉니다. 문제가 생기면 메시 전체가 함께 흔들립니다. 카나리 업그레이드는
새 컨트롤 플레인을 옆에 세우고 네임스페이스 단위로 옮기므로 되돌리기가 쉽지만, 그만큼 "지금 이 네임스페이스는 어느
컨트롤 플레인이 주입하나" 를 정확히 알아야 합니다. 현장에서 자주 나는 사고는 셋입니다.

• 리비전만 설치했더니 istio-injection=enabled 네임스페이스에 사이드카가 붙지 않는다(default 태그가 없다).
• istio.io/rev=canary 를 붙였는데 옛 라벨이 남아 여전히 stable 이 주입한다(istio-injection 이 우선한다).
• 옛 리비전 매니페스트를 통째로 지웠더니 공유 CRD 까지 지워져 VirtualService 가 전부 사라진다.

이 실습 환경에서 진짜인 것과 아닌 것

이 파드의 클러스터는 kwok 입니다. API 서버·웹훅 선택·CRD 는 진짜이고 istiod 프로세스와 컨테이너는 없습니다.
그래서 파드 생성을 --dry-run=server 로 요청하면 API 서버가 네임스페이스 라벨로 주입 웹훅을 실제로 골라 부르고,
istiod 가 없어 호출이 실패하면서 어느 웹훅이 어느 istiod 서비스로 가려 했는지 를 오류 메시지에 남깁니다.
이것을 판정 근거로 씁니다. 반대로 사이드카가 새 istiod 에 실제로 붙는지는 이 환경에서 볼 수 없습니다
(그것은 VM 실습 "메시가 실제로 강제하는 것을 본다" 에서 다룹니다). 두 리비전은 같은 istioctl 1.24.2 로 만듭니다.

단계

1. IstioOperator 로 맞춤 설치 설정을 쓰고 매니페스트를 렌더링합니다.
2. 리비전 stable 컨트롤 플레인을 적용합니다.
3. 리비전 설치만으로는 istio-injection=enabled 가 주입되지 않는 것을 확인하고 default 태그로 해결합니다.
4. 같은 맞춤으로 canary 리비전을 올리고, 설치만으로는 아무 네임스페이스도 옮겨 가지 않는 것을 확인합니다.
5. payments 네임스페이스를 canary 로 옮깁니다(옛 라벨 함정).
6. canary 주입 설정으로 오프라인 주입해 사이드카가 어느 컨트롤 플레인에 붙도록 만들어지는지 봅니다.
7. default 태그를 canary 로 옮겨 legacy 네임스페이스를 한꺼번에 옮깁니다.
8. 공유 자원을 남기고 stable 만 걷어 냅니다.

참고

• 작업 파일은 /root/ica-upgrade/ 에 둡니다. 주입 웹훅 호출은 10초 제한이라 dry-run 한 번에 10초쯤 걸립니다.
• 웹훅 설정 읽기: kubectl get mutatingwebhookconfiguration <이름> -o yaml 의 namespaceSelector·clientConfig.service.
• 태그 목록: istioctl tag list.
• 공식 문서:

[Canary Upgrades](https://istio.io/latest/docs/setup/upgrade/canary/) ·
[Customizing the installation configuration](https://istio.io/latest/docs/setup/additional-setup/customize-installation/) ·
[Installing the Sidecar](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/) ·
[istioctl 명령 참조](https://istio.io/latest/docs/reference/commands/istioctl/) ·
[Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)

단계 8개

1. 설치하기 전에 무엇이 깔릴지 먼저 뽑아 보기
2. 리비전 stable 컨트롤 플레인 올리기
3. istio-injection=enabled 인데 사이드카가 붙지 않는다
4. 새 컨트롤 플레인을 올렸는데 아무도 옮겨 가지 않았다
5. 라벨을 바꿨는데 여전히 옛 컨트롤 플레인으로 간다
6. 재시작해야 옮겨 간다는 말은 어디에 쓰여 있나
7. 옛 라벨을 쓰는 팀까지 한 번에 옮기기
8. 옛 컨트롤 플레인을 지웠더니 설정까지 사라질 뻔했다