day-log

kubectl debug --profile, 이거 모르는 분 꽤 많더라

오늘 후배가 distroless 이미지로 돌아가는 파드를 디버깅하느라 새벽까지 헤매고 있길래 옆에서 한마디 했다. "그냥 --profile=netadmin 붙여." 그랬더니 표정이 묘했다. "그게 뭔데요?" 아... 이거 1.27에서 들어온 게 벌써 3년이 다 돼가는데 의외로 안 쓰는 사람이 많다. 짧게 정리한다.무슨 문제를 푸는가kubectl debug로 ephemeral container를 띄울 때 기본값은 권한이 거의 없다. 그래서 tcpdump나 iptables -L 같은 걸 돌리면 그냥 막힌다. 우리 팀에서도 처음엔 sidecar로 netshoot을 띄워놓던 시절이 있었는데, 그건 그것대로 메모리 잡아먹고 보안팀이 싫어한다.--profile 플래그는 이런 류의 권한 세트를 미리 정의해놓은 프리셋..

GitOps 도구 고민은 의외로 끝나지 않는다. 작년 이맘때 우리 팀은 ArgoCD를 쓰고 있었는데, 어쩌다보니 한 분기를 Flux로 갈아엎고 돌렸다가 결국 다시 ArgoCD로 돌아왔다. 비교 글은 인터넷에 차고 넘치지만, 둘 다 운영 환경에서 한 사이클씩 굴려본 입장에서 쓸 만한 글은 의외로 적었다. 그래서 정리해본다.전제부터 깔자. 우리 팀은 EKS 클러스터 7개(prod 3, staging 2, dev 2), 약 220개 마이크로서비스, 배포는 하루 평균 60건쯤이다. 큰 조직은 아니지만 작지도 않다. 이 규모에서 우리가 겪은 차이를 적는다.왜 갈아탔다가 다시 돌아왔나원래 ArgoCD 2.10대를 1년 정도 잘 쓰고 있었다. 그런데 ApplicationSet generator 설정이 점점 비대해지고..

마이그레이션 전에 점검할 것ingress-nginx가 결국 작년 3월에 EOL됐다. 깃허브 저장소는 archived 처리됐고, 보안 패치도 더 이상 안 나온다. 그동안 미루고 미뤘는데 이제는 정말 도망갈 데가 없다. 우리 팀도 6월 들어서야 본격적으로 Gateway API 마이그레이션을 시작했고, 이 글은 그 과정에서 정리한 가이드다.처음에는 막막했다. Ingress 리소스가 200개가 넘는데 이걸 일일이 손으로 옮긴다고? 다행히 SIG-Network에서 올해 3월에 ingress2gateway 1.0을 정식 릴리스했다. 이걸 쓰면 대부분의 Ingress 리소스가 자동으로 변환된다. 물론 자동 변환이 모든 걸 해결해주지는 않는다는 게 함정이지만.본격적으로 시작하기 전에 두 가지를 먼저 확인했다.첫 번째는..

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..

지난주 화요일 새벽 2시 40분. 전화 진동이 침대 옆에서 부르르 떨었다. 결제 서비스 일부 Pod가 CrashLoopBackOff에 걸려서 P0 알람이 떴다는 PagerDuty. 졸린 눈으로 노트북을 열었는데, 보자마자 머리가 띵해졌다. 어제 낮에 내가 mutating webhook 설정 하나를 손댄 게 떠올라서.이 글은 그날 새벽 한 시간 동안 뭘 했는지에 대한 회고다. Vault Agent Injector를 쓰는 팀이면 한 번쯤은 밟을만한 지뢰라 기록을 남긴다.상황: agent-inject-secret 어노테이션이 사라졌다우리 팀은 1년 정도 Vault Agent Injector 1.4.x로 DB 자격증명을 주입해왔다. 패턴은 흔하다.metadata: annotations: vault.has..

상황운영 중인 파드가 한 개 있다. 베이스 이미지는 gcr.io/distroless/static:nonroot. 셸은커녕 ls도 없다. 그런데 갑자기 이 파드만 외부 API 호출이 실패하기 시작한다. DNS 문제인지, 라우팅 문제인지, 인증서 문제인지 확인하고 싶다. 파드를 재시작하면 증상이 사라질 수도 있으니 살아있는 상태에서 보고 싶다. 자, 어떻게 할까?이거 모르는 분 꽤 많더라. 어제 후배가 "프로덕션 파드에 들어가서 curl 좀 찍어보고 싶은데 distroless라서 kubectl exec가 안 먹힌다"라고 슬랙에 글 올린 거 보고 깜짝 놀랐다. kubectl debug가 GA 된 게 1.25 (2022년 후반) 인데, 2026년 지금까지도 의외로 안 쓰는 사람이 많은 것 같아서 짧게 정리한다...

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

작년 말부터 트레이스 양이 폭증했다. 서비스가 늘어난 것도 있고, 한 요청이 마이크로서비스 7~8개를 거치다 보니 한 트랜잭션에 span이 200개 가까이 붙는 케이스도 생겼다. 그대로 Tempo에 다 밀어 넣었더니 스토리지 비용이 분기마다 1.6배씩 뛰었다. 샘플링을 손봐야 한다는 결론은 너무 자명했는데, 막상 head냐 tail이냐를 고르는 자리에선 팀 안에서도 의견이 갈렸다.결론부터 말하면 우리는 두 개를 섞었다. 그래서 이 글은 어느 한쪽이 정답이라는 얘기가 아니다. 각각의 결을 보고, 어디서 어떤 걸 골랐는지 정리한다.Head sampling — 빠르고 가난한 선택지Head sampling은 트레이스가 시작되는 시점, 그러니까 SDK가 root span을 만들 때 보낼지 말지를 결정한다. Par..

ECR pull rate limit에 한 번이라도 당해봤다면, 이 글이 도움이 될 거다. Spegel은 클러스터 안에서 노드끼리 이미지를 공유하게 해주는 stateless P2P OCI registry mirror다. 어느 노드 하나가 이미지를 받아두면, 같은 클러스터의 다른 노드들은 그 노드에서 끌어다 쓴다. 외부 레지스트리 호출이 확 줄어든다.최근 3월에 CoreWeave가 자기네 매니지드 쿠버네티스(CKS)에서 Spegel 튜토리얼을 공식 문서로 내놓을 정도로 P2P 이미지 분배는 더 이상 실험 단계가 아니다. K3s, RKE2는 아예 임베디드로 들어가 있고, AKS/EKS에서도 Helm으로 깔아서 잘 굴러간다. 우리 팀에서도 노드 80대 EKS 클러스터에 두 달째 돌리고 있는데, 한번 정리해두면 ..

지난주 새벽에 페이지가 울렸다. OTel Collector DaemonSet이 또 OOMKilled. 이번 분기에만 세 번째다. 솔직히 처음 두 번은 "그냥 limit을 올리지" 하고 넘어갔는데, 이번엔 메모리를 2Gi → 4Gi로 올렸는데도 또 죽으니까 멘탈이 살짝 나갔다.근본 원인을 보려고 새벽 3시에 노트북을 열었다. 결론부터 말하면 memory_limiter 설정과 GOMEMLIMIT이 둘 다 잘못 잡혀 있었고, batch processor의 순서까지 어긋나 있었다. 우리 팀은 1년 전에 OTel Collector를 처음 도입했을 때 공식 예제 그대로 복붙해 놓고 그동안 트래픽이 4배가 늘었는데도 손을 안 댔던 거다. 부끄럽다.일단 무슨 일이 일어났던 건가우리 클러스터는 노드 80대 정도 되고 각..