day-log

cert-manager 무한 재발급 루프에 걸린 새벽 이야기새벽 3시. 폰이 울린다. 프로덕션 클러스터의 API 게이트웨이 인증서가 만료 2시간 전이라는 알림. 이상하다. cert-manager가 알아서 갱신했어야 정상인데. 눈을 비비면서 노트북을 열었다.처음엔 그냥 일시적인 문제인 줄 알았다kubectl get certificates -A 를 쳐봤다. Ready=False. kubectl describe로 이벤트를 보니 CertificateRequest가 계속 생성되고, 몇 초 뒤에 다시 실패하고, 또 다시 만들고... 초당 한 개꼴로 새 CR이 찍히고 있었다.$ kubectl get certificaterequests -n gateway | wc -l 38473847개. 헛웃음이 나왔다. 이 ..

cert-manager 깔아두고 Let's Encrypt 인증서 받는 거, 처음엔 다들 HTTP01로 시작한다. 튜토리얼이 다 그렇게 되어 있고, 일단 ingress 붙이면 되니까. 근데 운영 좀 하다 보면 슬슬 짜증이 난다. 와일드카드가 안 된다거나, 클러스터 내부용 도메인인데 80포트가 안 뚫린다거나. 그래서 DNS01로 옮기는데, 이게 또 권한 관리가 따로 필요해서 처음엔 헤맨다.이 글은 그 분기점에서 어떤 걸 쓰면 좋은지, 그리고 둘을 섞어 쓸 때 흔히 만나는 함정 몇 개를 정리해본다. 우리 팀에서 작년에 ingress 컨트롤러 갈아엎으면서 DNS01로 거의 다 옮겼는데, 그 과정에서 배운 것들이다.HTTP01이 어울리는 상황생각보다 단순한데, 두 가지 조건이 동시에 만족되면 HTTP01이 제일 ..

한 줄 요약cert-manager 1.17부터 ACME challenge authorization timeout이 1분 → 2분으로 늘었다. 그동안 가끔씩 사라지던 그 timeout, 1.17 올리면 꽤 줄어든다.어떤 상황에서 만났나우리 팀 클러스터 중 하나가 EKS이고, NLB 뒤에 ingress-nginx, 그 뒤에 cert-manager로 Let's Encrypt 인증서를 발급받는 흔한 구성이다. 그런데 한 달에 한두 번 정도 갱신 시점에 이런 로그가 떴다.Failed to wait for order resource to become ready: order is in "errored" state:Failed to wait for authorization: context deadline exceede..

작년 말에 우리 팀은 사내 서비스용 도메인의 TLS 인증서를 ACM에서 cert-manager로 옮겼다. EKS 클러스터가 늘어나면서 ALB마다 ACM 인증서 attach하고 갱신 알람 처리하는 게 점점 귀찮아진 게 직접적인 이유였고, 비용보다는 운영 부담 쪽이 컸다. 6개월쯤 굴려보니 마이그레이션 직후엔 안 보이던 문제들이 슬슬 보이기 시작해서, 정리해 두면 누군가는 덜 헤맬 것 같아 글로 남긴다.먼저 짚고 가야 할 거 하나. Wildcard 인증서(*.internal.example.com)는 HTTP01 challenge로 못 받는다. DNS01만 된다. 이건 Let's Encrypt 정책이라 우회할 방법이 없다. 그래서 cert-manager + Route53(우리 환경 기준) 조합이 사실상 표준 ..