day-log

올해 2월에 Kyverno 1.17이 나오면서 재밌는 변화가 하나 있었다. ClusterPolicy와 CleanupPolicy가 공식적으로 Deprecated로 마킹된 것. 아직 지워지진 않았지만, Kyverno 팀이 CEL(Common Expression Language) 중심 아키텍처로 방향을 확 틀었다는 신호다. 우리 팀은 지난달부터 조금씩 이 전환을 시작했는데, 처음 시작하는 팀들을 위해 몇 가지 정리해두려고 한다.왜 갑자기 CEL인가간단히 말하면, Kubernetes 자체가 1.30부터 ValidatingAdmissionPolicy(VAP)를 GA로 넣으면서 admission control 계층에 CEL 기반 표현식을 표준으로 밀기 시작했다. Kyverno가 오랫동안 자체 DSL로 정책을 표현해..

ndots:5, 왜 우리 Pod은 DNS 하나 찍는 데 다섯 번을 물어보는가DNS 지연 얘기를 하면 다들 NodeLocal DNSCache부터 붙이라고 한다. 맞는 얘기다. 근데 그 앞에 왜 이런 일이 벌어지는지 원리를 짚고 넘어가는 사람은 의외로 적더라. 우리 팀도 몇 달 전 P99가 튀는 걸 잡으렬고 노드로컬 캐시부터 붙였는데, 그때는 됐지만 나중에 다른 클러스터에 적용할 때 왜 되는지 설명을 못 해서 좀 창피했다.그래서 이 글은 ndots가 뭐고, 왜 하필 5이며, 그 값 하나가 어떻게 매 요청마다 5~6번의 DNS lookup을 유발하는지 밑바닥부터 파본다. 최근 Medium 등에서 "ndots:5 latency tax"라는 표현이 다시 돌기 시작한 것도 이유가 있다.resolv.conf가 실제로..

지난 화요일 밤이었다. 정확히는 수요일 새벽 2시 40분. 폰이 진동했고, 나는 다음날 반차를 쓸까 진지하게 고민 중이었다.Karpenter를 도입한 지 4개월쯤 됐다. 처음에는 얌전하게 consolidationPolicy: WhenEmpty로 돌렸는데, 팀 내부에서 "이럴 거면 왜 Karpenter 썼냐"는 얘기가 슬슬 나왔다. 우리 EKS 클러스터는 노드 30대 규모, 대부분 m6i 계열이었고 야간에는 40% 정도 놀고 있었다. AWS 비용 리뷰에서 매번 얻어맞다 보니 결국 이번 분기에 WhenEmptyOrUnderutilized로 넘어가기로 했다. Karpenter 문서에 최근 이게 코스트 민감한 팀의 기본값이라고까지 적혀 있었으니 뭐 걱정할 게 있겠나 싶었다.그날 새벽에 걸린 알람은 Payment..

카나리 배포 도구를 다시 고를 일이 생겼다. 원래 팀에서 자체 스크립트로 트래픽을 조금씩 옮기던 방식을 쓰고 있었는데, 서비스가 늘어나면서 이런 로직을 CD 파이프라인에 직접 박아 넣는 게 한계에 왔다. "이제 진짜 프로그레시브 딜리버리 컨트롤러를 붙이자"는 결론에 도달했고, 후보는 사실상 둘이었다. Argo Rollouts와 Flagger.둘 다 CNCF 프로젝트고, 둘 다 production 레퍼런스가 충분하다. 근데 이 둘이 문제를 푸는 방식이 꽤 다르다. 한 달 정도 병렬로 굴려보고 결국 하나를 골랐는데, 그 과정에서 정리한 내용을 남겨둔다.워크로드를 대하는 태도가 다르다가장 큰 구조적 차이는 이거다. Argo Rollouts는 Deployment 리소스를 Rollout이라는 커스텀 리소스로 대체..

이거 모르는 분 꽤 많더라. 요즘 이미지 최적화한다고 distroless로 다 갈아엎는 팀이 늘어나면서, 정작 장애 났을 때 파드 안에 들어갈 방법이 없어서 당황하는 경우를 몇 번 봤다. kubectl exec 때려도 sh not found 뜨고, 로그만 봐서는 원인 파악이 안 되는 상황.kubectl debug 로 ephemeral container 붙이면 된다. 1.25에서 GA 됐고 지금은 안정적이다. 오늘 자주 쓰는 패턴 3개만 정리한다.1. distroless 파드에 셸 붙이기가장 흔한 케이스. target 컨테이너의 프로세스/네트워크 네임스페이스를 공유하는 임시 컨테이너를 하나 띄운다.kubectl debug -it my-pod \ --image=nicolaka/netshoot \ --ta..

지난주 새벽에 겪은 이야기다. 프로덕션 EKS 두 개 중 한 쪽에서 신규 파드가 시크릿을 못 읽는다는 알림이 왔다. 처음엔 대수롭지 않게 봤는데, 결국 External Secrets Operator(ESO) 전체 sync가 멈춰 있는 상태였다. 우리 팀이 ESO를 IRSA + AWS Secrets Manager 조합으로 3년 넘게 쓰고 있는데, 이런 식으로 죽는 건 처음이었다.증상은 조용했다관측 가능한 신호가 애매했다. kubectl get externalsecret -A 를 찍으면 상태는 죄다 SecretSyncedError 였다. 근데 컨트롤러 파드는 살아 있고, CPU도 정상이고, 리더 election 로그도 잘 남고 있었다. Prometheus에서 externalsecret_sync_calls_e..

컨테이너 이미지를 pull하고 시작할 때, 표면적으로는 그냥 kubectl apply 한 방이면 끝나는 것처럼 보인다. 근데 사실 그 아래에서는 containerd가 snapshotter라는 놈을 통해 파일시스템 레이어를 조립하고 마운트하는 꽤 정교한 과정이 돌아간다. 대부분은 overlay2를 그냥 쓰고 지나가지만, 몇 달 전부터 우리 팀에서 콜드스타트 지연을 잡느라 stargz-snapshotter를 검토하면서, 이 계층이 실제로 뭘 하고 있는지 다시 파헤쳐볼 일이 생겼다.지난 2월에 stargz 관련 lazy pulling이 다시 주목받으면서 관련 글이 여럿 올라왔는데, 대부분 "빠르다"에서 멈춰 있다. 사실 내부적으로 뭐가 바뀌는지 짚어봐야 언제 써야 하는지 판단할 수 있다. 그래서 이번 글에서는..

작년 이맘때만 해도 우리 팀은 Cluster Autoscaler(CAS)만 썼다. 노드 그룹 5개 정도로 쪼개놓고, 크기 별로 알아서 스케일링되게 두는 방식. 나쁘지 않았다. 진짜로. 근데 클러스터가 200노드를 넘어가고, 배치 잡이랑 온라인 워크로드가 같은 클러스터에서 뒤섞이기 시작하면서 이야기가 달라졌다.이 글은 두 오토스케일러를 놓고 실무에서 어떤 게 다르고, 우리는 왜 결국 Karpenter로 갈아탔는지 정리해본 것이다. Karpenter 홍보글은 아니고, CAS가 여전히 낫다고 판단한 지점도 같이 적어둔다.구조가 근본적으로 다르다CAS는 "노드 그룹을 스케일한다". Karpenter는 "필요한 노드를 직접 만든다". 이거 한 줄이 사실상 전부다.CAS는 EKS 노드 그룹이든 GKE 노드 풀이든,..

지난 화요일 새벽 3시쯤이었다. 알람이 울렸다. P99 latency가 400ms를 넘겼다는 알림. 자다 깨서 노트북을 열었을 때 제일 먼저 든 생각은 "또 뭐가 문제냐"였다.우리 EKS 클러스터는 노드 40대 정도 되고, 트래픽이 특별히 튀지도 않았다. Grafana에서 애플리케이션 CPU도 여유롭고, DB 지표도 정상. 근데 왜 느려졌지? 한참 파고 나서야 원인이 나왔다. DNS였다. CoreDNS 파드는 CPU 20%도 안 쓰고 있는데 DNS 응답이 느렸다. 좀 어이가 없었다.처음엔 CoreDNS 스케일업을 의심했다당연히 첫 반응은 "CoreDNS 파드 수 늘려야겠다"였다. 그런데 grafana를 보니 CoreDNS 자체는 문제가 없었다. coredns_dns_request_duration_seco..