day-log

우리 팀이 자주 쓰는 형태오늘 점심에 동료가 "운영 Pod에 strace 한 번만 떠보면 알 것 같은데 못 들어간다"고 한참 끙끙대길래 옆에서 봤다. distroless 이미지라 shell이 없고, 그렇다고 ephemeral container를 그냥 띄우자니 같은 PID namespace가 아니라 프로세스가 안 보인다는 거였다. 사실 이거 의외로 많이들 모르고 지나가더라.kubectl debug에 --copy-to랑 --share-processes를 같이 주면 거의 다 해결된다. 1.30 GA 이후로 옵션 동작도 안정돼서 운영에서 그냥 쓰면 된다.원본 Pod는 그대로 두고, 동일한 spec의 복제 Pod에 디버그 컨테이너를 끼워넣는 방식. 트래픽 받는 Pod 직접 손대지 않아도 된다.kubectl deb..

작년 봄에 우리 팀 CI/CD 표준을 정리하면서 GitHub Actions의 Reusable Workflow와 Composite Action을 둘 다 도입했다. 그땐 "쓰임새가 다르니까 둘 다 쓰자"가 결론이었는데, 1년 굴려보니 둘의 경계가 처음 생각보다 훨씬 명확하게 갈렸다. 그리고 최근 GitHub이 2026 Actions 보안 로드맵을 발표하면서 Composite action의 nested dependency 노출 방식, scoped secrets 같은 변경이 들어오기 시작해서, 이참에 한번 정리해두면 좋을 것 같다.이 글은 단순히 둘의 문법 차이를 비교하는 글은 아니다. 실제로 우리 팀이 어떤 기준으로 갈라 썼고, 어디서 후회했고, 지금 어떻게 운영하는지에 대한 회고에 가깝다.단도직입적으로, 우..

이거 모르는 분 의외로 많더라. 어제도 사내 슬랙에서 비슷한 질문이 올라왔다. "etcd defrag CronJob 돌리는데 가끔 API 서버가 잠깐 죽어요." 그럴 만했다.오늘은 짧게 한 가지만 정리한다. etcd defragmentation을 CronJob으로 자동화할 때 빠뜨리기 쉬운 포인트.compaction과 defrag는 다른 거다먼저 용어부터. 둘이 같은 줄 알고 쓰는 사람이 꽤 있다.compaction: 오래된 revision을 논리적으로 지운다. 디스크 파일은 안 줄어든다. 자동으로 돌릴 수 있다 (--auto-compaction-mode=periodic --auto-compaction-retention=8h 같은 식). kube-apiserver가 5분마다 자동 compaction을 호..

오늘 알게 된 거 아니고, 사실 꽤 됐는데 의외로 모르는 분이 많더라. 지난주에도 동료가 "JVM 앱이 livenessProbe 때문에 자꾸 재시작된다, initialDelaySeconds를 300초로 박았는데도 가끔 죽는다"는 얘길 했다. 그때 startupProbe 얘기를 꺼내면서 "어 진짜? 그런 게 있었어?"라는 반응이 나왔다. 1.20부터 GA였는데도 말이다.근데 이게 한두 명 얘기가 아니라서, 짧게 정리해둔다.initialDelaySeconds로 버티는 게 왜 문제냐흔히 쓰는 패턴이 이거다.livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 180 periodSeconds: 10 failureThresh..

Terraform 코드를 팀에서 같이 굴리다 보면 결국 부딪히는 문제가 있다. 누가 어디서 plan을 돌렸는지 모르고, 로컬에서 apply 친 사람이 state를 깨먹고, PR 리뷰는 코드만 보고 끝나는데 정작 실제 변경 영향은 머지된 뒤에야 보인다. 이걸 해결하는 도구가 Atlantis다. PR에 plan 결과를 코멘트로 붙이고, atlantis apply 같은 명령어로 머지 직전에 실행을 위임한다.이 글은 Atlantis를 GitHub과 EKS 위에 셀프호스팅으로 띄우는 가이드다. 우리 팀에서 최근에 v0.42.0으로 올렸는데, OpenTofu 지원이 정식으로 들어가면서 마이그레이션 부담이 좀 줄었다. 그 과정에서 정리한 내용이다.왜 또 Atlantis인가요즘은 Spacelift, Env0, Scal..

요즘 멀티 AZ 운영하는 팀이라면 topologySpreadConstraints 한 번쯤은 다 써봤을 것이다. 근데 이거, 평상시엔 멀쩡한데 rolling update만 하면 한쪽 AZ로 쏠리는 경험 다들 있지 않나? 이게 사실 알고리즘적인 이유가 있다. 1.27부터 베타로 들어온 matchLabelKeys와 1.30에서 GA된 minDomains로 거의 해결된다. 우리 팀에서 한 달 전쯤 정리한 내용을 공유한다.흔히 보는 증상12노드, 3 AZ 클러스터에서 replicas 6짜리 Deployment를 돌린다고 치자. spec은 이렇게 들어가 있다.topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone ..

지난주 새벽 3시, 알람으로 깨서 백업 잡이 또 깨진 걸 확인했다. PVC 30개 짜리 워크로드 백업이 두 시간 째 매달려 있었고, node-agent 데몬셋의 메모리는 8Gi를 찍고 OOM. 이게 벌써 이번 분기 들어 세 번째다. 1.14에서 1.15로 올린 다음부터 백업 패턴이 이상해졌고, 솔직히 말하면 우리 팀은 한 달 가까이 이 마이그레이션을 우습게 봤다.원인은 단순하지 않았다. Velero 1.15에서 데이터 업로드 액션이 node-agent에서 떨어져 나와 DataUpload 단위 마이크로서비스 파드로 분리됐는데, 그 변화가 우리 클러스터 토폴로지와 안 맞았다. 이 글은 그 한 달간의 삽질을 정리한 노트다.처음에 뭐가 바뀐 건지 제대로 안 봤다릴리즈 노트를 한 번은 읽었다. "data move..

3월 20일자로 ingress-nginx가 공식 EOL이 됐다. 같은 날 ingress2gateway 1.0이 GA로 풀렸다. 두 이벤트가 같은 날 풀린 게 우연이 아니다 — 업스트림에서 "이제 진짜 옮길 때다"라고 못박은 거다.EOL 전부터 우리 팀도 마이그레이션을 시도했는데, 0.x 시절 ingress2gateway는 ingress-nginx 어노테이션을 3개밖에 못 바꿨다. 그래서 일단 미뤄두고 있었는데 1.0이 나오면서 30개 이상 지원으로 확 늘었다. 마침 옮길 만한 시점이다 싶어서, 지난 2주간 스테이징 → 프로덕션 일부 클러스터까지 옮겨봤다. 그 과정 정리.옮기기 전에 알아둘 것Gateway API는 Ingress 리소스 하나에 다 욱여넣었던 라우팅 + 어노테이션 정글을 두 단계로 쪼갠다. ..

월말마다 AWS 비용 리포트 보다가 NAT Gateway 항목에서 한숨 쉬어본 적 있다면 이 글이 도움이 될지도 모르겠다. 우리 팀도 작년에 비슷한 상황이었고, VPC Endpoint 몇 개 깔아둔 것만으로 NAT 처리 비용이 한 달 기준 40% 가까이 빠졌다. 거창한 아키텍처 변경 없이.이번 4월 AWS 비용 가이드들을 다시 훑어봤는데 NAT Gateway 단가는 여전히 시간당 $0.045, GB당 $0.045다. 게이트웨이 하나 띄워놓으면 가만히 있어도 월 $32. 거기에 처리량까지 붙으니 트래픽 많은 클러스터는 NAT 항목 하나가 인스턴스 비용을 추월하는 일도 흔하다. 이 글은 그 비용을 내리는 가장 확실한 방법인 VPC Endpoint 적용 가이드다.어디부터 손대야 하나VPC Endpoint는 두..