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 깔아두고 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..