day-log

1.36 Pod-level in-place resize, 사이드카 많은 Pod일수록 의미가 크다지난달 Kubernetes 1.36이 나오면서 In-Place Pod Resize에 한 가지 작은 게이트가 추가됐다. InPlacePodLevelResourcesVerticalScaling. 1.35에서 컨테이너 단위 in-place resize가 GA 된 직후라 잘 안 보이지만, 사이드카가 덕지덕지 붙은 Pod를 운영하는 입장에선 이게 더 반갑다. 오늘은 그 얘기를 짧게.뭐가 달라졌나기존 in-place resize는 컨테이너 하나하나의 resources.requests/limits를 따로 바꿔야 했다. Pod에 컨테이너가 3개면 patch도 3번. 그것도 모자라서, 사이드카가 자기 limit에 먼저 걸려 t..

작년 말에 우리 팀이 EKS Auto Mode로 갈아탔다. 정확히는 새로 만드는 서비스 클러스터 한 대를 Auto Mode로 띄워서 운영해본 게 6개월 정도 됐다. 기존 클러스터들은 Karpenter + 자체 노드 그룹으로 굴리고 있었고, 솔직히 큰 불만은 없었다. 그런데 신규 팀에서 클러스터를 자꾸 늘리는 상황이 되니까, 모든 클러스터마다 Karpenter 버전 맞추고, CoreDNS HPA 손보고, VPC CNI 업그레이드 줄 세우는 게 점점 부담이었다. "이거 AWS가 다 해주겠다는데 한번 맡겨보자"는 분위기였다.6개월 동안 잘 굴러간 부분도 있고, 새벽에 멘탈이 나간 부분도 있어서 정리해둔다. 누가 똑같은 선택을 앞두고 있다면 이 글이 조금이라도 시간을 아껴주면 좋겠다.도입 직후 — "이거 너무 ..

새벽 3시 47분. 핸드폰이 미친 듯이 울렸다.PagerDuty가 동시에 네 건. P99 레이턴시, 5xx 비율, 큐 적체, 그리고 결제 워커 alive 체크 실패까지 줄줄이 빨간색. 잠이 깰 새도 없었다. 노트북을 열고 Grafana부터 켰는데, 노드 수가 떡 하니 23대에서 6대로 떨어져 있었다. 누가 그랬을까. 범인은 나였다. 정확히는, 일주일 전 내가 만진 Karpenter 설정이.무슨 짓을 했길래배경부터. 우리 팀은 EKS에서 Karpenter로 노드를 굴린다. NodePool 두 개 — 일반 워크로드용 default, 그리고 결제/주문 같은 stability-sensitive 워크로드용 payments. 한 달 전쯤 FinOps 압박이 들어왔다. "비용 너무 많이 나온다, 야간에 트래픽 적은 ..

지난주 새벽의 작은 사고지난주에 작은 사고가 있었다. 큰 장애는 아니었는데, 디버깅하면서 내가 너무 기본값을 신뢰하고 있었다는 걸 깨달았다. CronJob failedJobsHistoryLimit 얘기다.상황은 이랬다. 데이터 동기화용 CronJob이 매 5분마다 도는데, 모니터링 대시보드에서 어느 새벽부터 실패 카운트가 슬슬 올라가고 있었다. 한 시간쯤 지나서 PagerDuty가 울렸고, 출근 전이라 자느라 못 봤다. 아침에 일어나서 보니 한 시간 동안 12번 실패한 상태였다.로그를 보러 갔는데당연히 kubectl logs부터 쳤다. Pod가 이미 사라진 상태. 그렇지, CronJob은 Job을 만들고, Job이 Pod를 만든다. Pod는 사라져도 Job 객체는 남아있어야 하니까 그쪽을 보자.$ kub..

요즘 사내에서 sidecar 없는 서비스 메시 이야기가 자주 나온다. 우리 팀도 작년 4분기에 Istio sidecar 모드를 운영하다가 메모리 footprint와 업그레이드 부담에 지쳐서 sidecarless 옵션을 진지하게 검토하기 시작했다. 후보는 두 개로 좁혀졌다. Istio Ambient Mode와 Cilium Service Mesh.둘 다 sidecar를 없앤다는 큰 그림은 같은데 접근 방식이 꽤 다르다. 어느 쪽이 우리 팀에 맞는지 판단하기까지 두 달 정도 PoC를 돌렸고, 그 과정에서 알게 된 것들을 정리한다. 결론부터 말하면 우리는 아직 한쪽을 완전히 못 정했다. 그래서 이 글은 깔끔한 권고문이 아니다.데이터 플레인이 어디서 도는가가장 큰 차이는 트래픽이 처리되는 위치다.Istio Amb..

작년 말부터 Istio Ambient Mode를 진지하게 보기 시작했다. 1.22에서 Beta로 올라오고, 1.24~1.25 거치면서 단일 클러스터 한정으로는 production ready라는 얘기가 공식 문서에도 들어갔다. 우리 팀에서도 "그러면 슬슬 옮겨야 하는 거 아니냐"는 얘기가 나왔고, 6개월 정도 PoC와 일부 트래픽 마이그레이션을 진행했다.결론부터 말하면 새 클러스터는 Ambient로 깔고, 기존 sidecar 클러스터는 당분간 그대로 둔다로 정리됐다. 그 과정에서 정리된 비교를 남긴다.데이터 플레인 구조의 차이Sidecar 모드는 다들 알다시피 Pod마다 envoy 컨테이너 하나 더 붙는다. 100개 Pod 띄우면 envoy도 100개. 메모리, CPU, 부팅 시간 다 곱하기 N이 된다.A..

쿠버네티스에 정책 엔진 하나는 깔아야 한다는 얘기가 나온 게 벌써 몇 년째인지 모르겠다. 우리 팀도 처음엔 "PSP 사라지면 그때 가서 보자"고 미뤘는데, 결국 PSP 제거되고, NetworkPolicy 강제도 필요해지고, 이미지 서명 검증 요건까지 붙으면서 더 이상 미룰 수가 없었다.선택지는 사실상 둘이다. Kyverno 아니면 OPA Gatekeeper. 둘 다 CNCF 프로젝트고, 둘 다 어드미션 컨트롤러로 동작한다. 그래서 처음엔 "어차피 비슷하겠지" 싶었는데, 직접 양쪽을 작은 클러스터에 나눠 깔고 두어 달 굴려보니 꽤 결이 다른 도구라는 걸 알게 됐다. 이 글은 그 비교 노트다.정책을 어떻게 쓰는가 — YAML vs Rego이 차이가 가장 크다.Gatekeeper는 OPA를 베이스로 깔고 있어..