day-log

오늘 알게 된 건데, Prometheus 3.8에서 native histogram이 드디어 stable로 올라왔다. 나처럼 몇 년째 "언젠간 써봐야지" 하고 미뤄두신 분들 꽤 있을 것 같아서 짧게 정리해둔다.왜 지금이냐기존 classic histogram 써본 분들은 아마 버킷 설계에서 한 번쯤 멘붕 겪어봤을 거다. 레이턴시 분포가 어떻게 생겼는지도 모르고 le 버킷을 깎아야 하고, 세밀하게 하자니 카디널리티 폭발, 대충 하자니 P99가 거짓말을 한다. 이걸 수년째 "일단 이 정도면 됐지" 하면서 쓰고 있었다.Native histogram은 버킷 경계를 exponential하게 자동 생성한다. 즉 설정 한 줄로 버킷 설계가 끝난다. 거기에 Remote Write 2.0에서 native form 그대로 전..

OpenTofu 1.0이 나온 게 2024년 초였다. 당시 팀에서 "일단 지켜보자"고 결정한 뒤로 약 2년이 지났고, 그 사이에 우리 팀은 한쪽 서비스 군을 OpenTofu로 옮겨봤다. 나머지는 여전히 Terraform이다. 의도한 건 아니고 어쩌다 보니 그렇게 됐는데, 결과적으로는 같은 조직 안에서 둘을 병행 운영하는 꽤 좋은 비교 실험이 됐다.요즘 들어 "이제 OpenTofu로 갈아타야 하는 거 아니냐"는 질문을 사내외에서 자주 받는다. 특히 작년 12월에 IBM이 HashiCorp 인수 마무리하면서 분위기가 또 한 번 바뀌었다. 이 글은 그 질문에 대한 내 나름의 답이다. 결론부터 말하면 "상황에 따라 다르다"는 재미없는 답이 맞는데, 적어도 어떤 상황에서 뭘 고려해야 하는지는 좀 정리가 됐다.2년..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. Terraform 1.10부터 S3 backend에 native state locking이 들어왔다. 그동안 DynamoDB 테이블 하나 따로 만들어서 lock 걸던 그거, 이제 안 해도 된다.우리 팀도 스테이지/프로덕션 합쳐서 DynamoDB lock 테이블 5개를 굴리고 있었는데, 최근에 신규 모듈 정리하면서 이걸 다 걷어냈다. 후기 짧게 남긴다.뭐가 달라졌나기존에는 backend "s3" 블록에 dynamodb_table을 반드시 지정해야 동시성 제어가 됐다. 1.10부터는 use_lockfile = true 한 줄이면 끝. S3 객체 자체에 conditional write로 lock 파일을 만들어 거는 방식이다.terraform { backend..

지난달에 결국 Karpenter로 갈아탔다. 팀에서 반년 넘게 "다음 분기에 해야지" 하며 미뤄왔던 숙제였는데, 예상대로 쉽지 않았다. 이 글은 자랑이 아니라 그냥 기록이다. 비슷한 고민 하는 분들에게 조금이라도 도움이 됐으면 해서 적는다.Karpenter가 v1.0 GA 찍은 지도 벌써 한참 됐고, 최근에는 OCI provider까지 GA 나오면서 더 이상 "AWS 전용 실험 프로젝트" 소리는 못 듣는 상황이다. 그래도 막상 프로덕션에 올려보면 문서에 안 나오는 함정이 꽤 있다.왜 옮겼나솔직히 Cluster Autoscaler(CAS)가 못 쓸 물건은 아니다. 노드 18대 규모에서 몇 년을 잘 돌았다. 문제는 배치 잡 비중이 커지면서부터였다.우리 팀은 데이터 파이프라인 일부가 Kubernetes Job..

클러스터가 3개를 넘어가면서 ArgoCD Application 매니페스트를 하나하나 만들어 관리하는 게 현실적으로 불가능해진 경험이 있을 것이다. dev, staging, production에 각각 마이크로서비스 10개만 배포해도 Application YAML이 30개다. 여기에 리전별 클러스터까지 추가되면 관리 포인트가 기하급수적으로 늘어난다.ArgoCD ApplicationSet Controller는 이 문제를 정면으로 해결한다. 템플릿 하나로 여러 클러스터, 여러 환경에 Application을 자동 생성하고 라이프사이클까지 관리할 수 있다. 이 글에서는 실무에서 바로 적용할 수 있는 ApplicationSet 패턴들을 다룬다.ApplicationSet이 필요한 이유기존 방식에서는 새 클러스터를 추가..

운영 환경에서 Pod가 CrashLoopBackOff에 빠지거나, 네트워크 연결이 안 되거나, 파일시스템 상태를 확인해야 할 때가 있습니다. 문제는 대부분의 프로덕션 컨테이너 이미지에는 curl, dig, netstat 같은 디버깅 도구가 없다는 것입니다.distroless 이미지나 최소화된 Alpine 기반 이미지를 사용하면 보안과 이미지 크기 면에서 이점이 있지만, 장애 상황에서 원인을 파악하기가 까다로워집니다. kubectl debug는 이런 상황을 위해 만들어진 도구입니다.이 글에서는 kubectl debug의 세 가지 모드를 실전 예제와 함께 살펴보겠습니다.Ephemeral Container로 실행 중인 Pod 디버깅가장 많이 쓰이는 패턴입니다. 실행 중인 Pod에 임시 컨테이너(Ephemera..

들어가며Kubernetes 클러스터를 운영하다 보면 가장 자주 마주치는 에러 중 하나가 바로 CrashLoopBackOff입니다. Pod가 시작되자마자 죽고, 다시 시작되고, 또 죽는 무한 루프에 빠진 상태죠. 특히 새벽에 알림이 울릴 때 이 상태를 보면 심장이 철렁합니다.문제는 CrashLoopBackOff 자체가 원인이 아니라 증상이라는 점입니다. 실제 원인은 OOMKilled, 설정 오류, 의존성 실패 등 다양합니다. 오늘은 실무에서 이 상태를 체계적으로 진단하고 해결하는 방법을 정리합니다.CrashLoopBackOff란?Kubernetes는 컨테이너가 비정상 종료되면 restartPolicy에 따라 자동으로 재시작합니다. 그런데 컨테이너가 반복적으로 실패하면 kubelet은 재시작 간격을 점점 늘..