클러스터로 들어오는 모든 트래픽이 지나는 관문을 교체했습니다. 서비스는 그동안 계속 돌아갔습니다.
왜 바꿨나
기존 인그레스는 잘 돌고 있었습니다. 문제는 설정이 어디에 있는지였습니다.
공용 라우팅 규칙 일부가 특정 애플리케이션의 배포 설정 안에 원시 YAML 로 숨어 있었습니다. 그 앱과 아무 상관 없는 다른 서비스의 경로가 거기 들어 있었고, 그 앱을 건드리면 관계없는 서비스가 영향을 받았습니다. 실제로 그것 때문에 개발계 장애가 났습니다.
라우팅을 앱에서 떼어내 인프라 저장소로 옮기면서, 겸사겸사 인그레스도 바꾸기로 했습니다.
두 번에 나눠서 했다
같은 날 둘 다 하지 않았습니다. 개발계에서 먼저 끝내고 닷새를 기다렸습니다.
기다린 이유는 단순합니다. 인그레스 교체는 되돌리기가 쉽지 않고, 문제가 바로 드러나지 않는 종류가 섞여 있습니다. 특정 헤더를 쓰는 경로, 웹소켓, 리다이렉트 규칙, 인증서 갱신 — 이런 건 배포 직후가 아니라 며칠 뒤에 드러납니다.
개발계에서 닷새를 굴리고 아무 일도 없었을 때 운영으로 갔습니다.
운영에서는 방식을 바꿨다
개발계는 새 로드밸런서를 띄우고 DNS 를 옮기는 방식으로 했습니다. 간단하고 되돌리기도 쉽습니다.
운영은 그렇게 할 수 없었습니다. 이미 고정 IP 가 잡혀 있고, 그 주소가 외부에 알려져 있었습니다. DNS 를 바꾸면 전파되는 동안 양쪽이 공존하고, 캐시된 클라이언트는 옛 주소를 계속 씁니다.
그래서 새 인그레스를 기존 것 옆에 먼저 띄우고, 준비가 끝난 뒤 고정 IP 자체를 넘겨받았습니다. 주소는 그대로고 뒤에 있는 것만 바뀝니다. 클라이언트 입장에서는 아무 일도 일어나지 않습니다.
순서는 이랬습니다.
- 새 인그레스를 기존 것과 나란히 띄운다
- 운영 도메인들을 새 쪽 규칙으로 연결한다 — 아직 트래픽은 안 온다
- 고정 IP 를 새 쪽으로 승계한다 ← 여기서 실제로 전환된다
- 병행 상태로 두었던 규칙을 저장소로 흡수한다
- 기존 인그레스를 제거한다
- 쓰지 않게 된 옛 IP 예약을 회수한다
6 번이 사족처럼 보이지만 아닙니다. 클라우드에서 쓰지 않는 고정 IP 는 붙어 있지 않을 때 오히려 과금됩니다. 정리하지 않으면 매달 조용히 나갑니다.
DNS 먼저, 로드밸런서 나중
전환 중에 지킨 원칙이 하나 있습니다. 레코드를 먼저 지우고 로드밸런서를 나중에 지운다.
반대로 하면 그 사이에 DNS 레코드가 사라진 주소를 가리킵니다. 클라우드 IP 는 회수되면 다른 계정에 다시 나갈 수 있고, 그 상태에서 우리 도메인이 남의 서버를 가리키게 됩니다. 서브도메인 탈취가 이렇게 일어납니다.
정리하는 김에 이미 대상이 없어진 유령 레코드 몇 개도 함께 지웠습니다.
관리 화면은 로그인 뒤로
새 인그레스에는 관리 대시보드가 딸려 옵니다. 편하지만 그대로 열어 두면 클러스터 라우팅 구성이 전부 노출됩니다.
인증 프록시 뒤에 두어 사내 계정으로만 들어가게 했습니다. 대시보드 자체는 인증 기능이 없으므로, 앞에 세우는 방식 말고는 답이 없습니다.
결과
운영 도메인 여섯 개가 새 인그레스로 넘어갔고, 기존 인그레스는 완전히 제거됐습니다. 인증서는 자동 발급·갱신 체계에 그대로 얹혔습니다.
전환 중 서비스는 멈추지 않았습니다. 닷새를 기다린 것이 이 작업에서 가장 잘한 결정이었습니다.