day-log

ephemeral container를 붙이면 끝난다오늘 알게 된 건데, 의외로 kubectl debug 안 써본 분들 꽤 많더라.우리 팀은 보안팀 권고로 작년부터 베이스 이미지를 distroless로 통일했다. 공격 표면 줄이고 CVE 대응 줄이는 데는 좋은데, 막상 운영 중에 컨테이너 안으로 들어가서 뭐 좀 보려고 하면 막막하다. kubectl exec -it pod sh 치면 OCI runtime exec failed: exec: "sh": executable file not found in $PATH 떨어지는 그 상황. 옛날에는 이걸 우회하려고 디버깅용 -debug 태그 이미지를 따로 빌드해서 RollingUpdate로 갈아끼우는 짓을 했다. 지금 생각하면 좀 한심한데, 그땐 그게 최선처럼 보였다...

지난 3주 동안 사내 LLM 추론 서비스를 KServe + vLLM 조합으로 K8s에 올렸다. 결과만 말하면 "어찌어찌 굴러는 가는데, 처음 일주일은 거의 매일 야근"이었다. 글로 정리해두지 않으면 또 까먹을 것 같아서 적어둔다.배경부터 짧게 풀자면, 우리 팀은 자체 호스팅 LLM 추론을 sagemaker나 bedrock 대신 EKS 위에 올리기로 했다. 비용도 비용이지만, 모델 빈번한 교체 + 사내 RAG 데이터와의 결합 때문에 직접 운영이 불가피했다. NVIDIA L40S 노드 4대로 시작했고, 모델은 처음에 Llama 3.1 8B, 그다음 70B로 키워가는 시나리오였다.1. 첫 번째 벽 — 이미지 풀(Pull)에 12분vLLM 공식 이미지(vllm/vllm-openai:latest)가 거의 9GB ..

요즘 멀티 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 ..

쿠버네티스 클러스터가 어느 정도 커지면 DNS가 가장 먼저 비명을 지른다. 우리 팀도 노드 80대 규모 EKS에서 CoreDNS QPS가 2만을 넘기면서 P99 레이턴시가 200ms 가까이 튀는 걸 보고 나서야 손을 댔다. NodeLocal DNSCache는 들어봤는데, autopath는 의외로 안 쓰는 팀이 많더라. 이 둘을 같이 써야 진짜 효과가 난다.이 글은 두 컴포넌트를 같이 도입하는 가이드다. 각각의 역할, 설정 순서, 그리고 같이 쓸 때 주의할 점까지 정리했다.ndots:5가 만드는 N+1 쿼리 문제쿠버네티스 파드에 들어가서 cat /etc/resolv.conf를 찍어보면 이런 게 나온다.search default.svc.cluster.local svc.cluster.local cluster...

지난주 화요일 새벽이었다. EKS 클러스터 1.32 → 1.33 업그레이드를 돌리는 중이었는데, 노드 드레인이 4시간째 안 끝나고 있다는 슬랙 알림을 받았다. 새벽 3시였고, 솔직히 처음엔 드레인이 원래 좀 오래 걸리니까 그러려니 했다. 4시간이라는 숫자를 본 순간 멘탈이 한 번 흔들렸다.평소 같으면 워커 노드 한 대 드레인하는 데 길어야 10분 정도였다. 그런데 이번엔 한 노드에 박혀서 안 빠지는 파드가 있었고, 그 파드 하나가 전체 업그레이드 파이프라인을 막고 있었다. 결국 원인은 PDB(PodDisruptionBudget) 하나였다. 짧게 말하면 그렇고, 길게 말하면 우리 팀의 PDB 관리 방식 전체가 문제였다.처음 발견한 증상노드를 cordon하고 drain을 돌렸는데 이런 메시지가 계속 떴다.e..

Helm lookup 함수, ArgoCD랑 같이 쓰면 함정 있다오늘 동료가 PR 리뷰 부탁한다고 해서 봤는데, Helm chart에서 lookup 함수를 쓰는 부분이 있었다. 클러스터에 이미 떠 있는 ConfigMap을 읽어서 그 값을 기반으로 다른 리소스를 만드는 패턴. 코드는 깔끔했고 로컬 helm install로도 잘 돌았는데, 내가 한 마디 했다. "이거 ArgoCD에서 안 될걸요."근데 동료는 "어 저번에 다른 차트에서도 비슷하게 썼는데 됐는데?"라고 했고, 결국 같이 한 번 더 들여다보기로 했다. 그 김에 정리.lookup이 뭐였더라lookup은 Helm 3에서 추가된 템플릿 함수다. 차트 렌더링 시점에 K8s API 서버를 쳐서 기존 리소스를 읽어올 수 있다. 예를 들면 이런 식.{{- $e..

지난 분기에 컨트롤 플레인 한 노드에서 etcd defrag을 잘못 돌리다가 API 서버가 5초간 5xx를 토해낸 적이 있다. 그 뒤로 팀 내부에서 "etcd 만지지 말자"는 분위기가 잠깐 있었는데, 사실 그건 답이 아니다. defrag을 안 돌리면 결국 디스크가 커지고 read latency가 슬금슬금 올라간다. 문제는 동작 원리를 잘 모르는 상태에서 그냥 cron만 돌리는 거였다.이 글에서는 etcd가 MVCC를 어떻게 구현하는지, compaction과 defrag이 정확히 무슨 일을 하는지, 그리고 K8s API 서버 입장에서 그 영향이 어디서 어떻게 보이는지 정리해본다. 운영 가이드 글은 인터넷에 차고 넘치는데, 정작 "왜"가 빠져있어서 매번 어색하게 cron 주기만 조정하게 된다.MVCC, 그러..

오늘 알게 된 것도 아니고, 알고는 있는데 막상 새벽에 장애 터지면 까먹는 옵션 하나를 정리해두려고 한다. kubectl debug --target. 같이 일하는 주니어한테 알려주니까 "어 이게 되네요?" 하길래.흔한 상황운영 중인 Pod에서 네트워크가 이상하다. DNS는 되는데 특정 외부 IP로만 connect timeout. 컨테이너는 distroless라서 kubectl exec로 들어가도 쉘이 없다. 사이드카로 디버깅 컨테이너 박아서 재배포? 새벽 두 시에 그건 좀 그렇다.이럴 때 쓰는 게 ephemeral container, 그리고 kubectl debug다. K8s 1.25에서 GA된 후로 죽 안정적이다. 근데 의외로 --target 옵션을 안 쓰고 그냥 띄워서 "어 왜 안 보이지" 하는 경우..

작년쯤 Kubernetes 1.30이 풀리고 ValidatingAdmissionPolicy(이하 VAP)가 정식으로 GA되었을 때, 솔직히 의심이 좀 있었다. CEL로 정책을 쓴다는 발상 자체는 깔끔한데, Kyverno 같은 PaC(Policy-as-Code) 엔진이 이미 잘 돌아가는 클러스터에서 굳이 또 한 겹을 더 얹을 필요가 있나 싶었다. 그러다 작년 말쯤 우리 팀에서도 일부 정책을 VAP로 옮기는 실험을 시작했고, 6개월쯤 지난 지금 시점에 정리해두면 좋겠다는 생각이 들었다.결론부터 적자면, 모든 걸 VAP로 옮길 일은 없다. 그럼에도 옮길 가치가 있는 정책이 분명히 있다. 그 경계가 어디에 있는지가 이 글의 본론이다.왜 VAP를 썼나원래 우리 클러스터에서는 Kyverno 하나로 모든 admiss..

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