인증서와 DNS 를 손에서 뗐다

2026/08/07클라우드 인프라 구축·전환cert-manager · external-dns · Kubernetes · Cloud DNS

인증서 만료로 서비스가 멈추는 사고는 흔합니다. 그리고 거의 항상 예방 가능했던 사고입니다. 달력에 적어 두는 것으로는 부족합니다. 사람이 바뀌고, 도메인이 늘고, 적어 둔 것을 잊습니다.

자동화한 것

인증서는 발급과 갱신이 클러스터 안에서 자동으로 돕니다. 와일드카드 인증서를 쓰므로 서브도메인이 늘어도 추가 작업이 없습니다.

DNS 레코드는 배포에서 자동으로 만들어집니다. 서비스를 올리면 레코드가 생기고, 내리면 회수됩니다. 콘솔에 들어가 손으로 추가하지 않습니다.

자동화가 오히려 위험한 지점

레코드를 자동으로 회수한다는 것은 잘못 지우면 자동으로 사라진다는 뜻이기도 합니다. 그래서 정리 순서에 원칙을 뒀습니다.

레코드를 먼저 지우고 로드밸런서를 나중에 지운다. 반대로 하면 그 사이에 DNS 가 이미 사라진 주소를 가리킵니다. 클라우드 IP 는 회수되면 다른 계정으로 다시 나갈 수 있고, 그 상태에서 우리 도메인이 남의 서버를 가리키게 됩니다.

이건 이론이 아닙니다. 정리하다 보니 대상이 이미 없어진 유령 레코드가 몇 개 실제로 있었습니다. 선제적으로 지웠습니다.

자동화해도 사람이 봐야 하는 것

이전 배포 도구에서 넘겨받은 설정 하나에 인증서 발급기 이름이 자리표시자 그대로 들어 있었습니다.

증상이 없었습니다. 기존 인증서가 아직 유효했으니까요. 갱신 시점이 와야 드러날 종류였고, 그때는 서비스가 멈춘 뒤입니다.

자동화는 "설정이 맞다면" 돌아갑니다. 설정이 틀렸는지는 자동화가 알려주지 않습니다. 이관 직후에 값을 한 줄씩 읽어 보는 것 말고 방법이 없었습니다.

곁가지로 고친 것

인증서를 쓰는 곳과 다른 네임스페이스의 인증서를 가리키던 설정도 있었습니다. 쿠버네티스에서 TLS 인증서는 같은 네임스페이스에 있어야 합니다. 없는 것을 가리키니 인그레스가 기본 자체서명 인증서를 내주고 있었고, 다들 브라우저 경고를 보면서도 "내부용이니까"로 넘기고 있었습니다.

와일드카드를 여러 네임스페이스에서 쓰려면 각 네임스페이스에 인증서를 따로 만들어야 합니다. 이것도 이관 전부터 깨져 있던 것이었습니다.