day-log

지난 주말 새벽 3시, 알림이 울려서 눈을 떴다. 사내 스테이징 API 게이트웨이가 TLS handshake failure를 뱉고 있었다. 그때만 해도 "그냥 인증서 문제겠지, 아침에 보자" 하고 다시 누웠는데, 아침이 되니 프로덕션까지 같은 증상이 번지고 있었다.결론부터 말하면 cert-manager는 인증서를 잘 발급하고 있었다. Kubernetes Secret도 잘 갱신됐다. 그런데 워크로드가 새 인증서를 안 읽고 있었다. 이 삽질 이야기를 정리해둔다.처음엔 cert-manager를 의심했다먼저 한 게 이거다.kubectl describe certificate api-gateway-tls -n gatewaykubectl get certificaterequest -n gateway --sort-by=..

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 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(우리 환경 기준) 조합이 사실상 표준 ..