day-log

kube-proxy nftables 모드, 사실 내부적으로는 이렇게 돌아간다

Kubernetes 1.33에서 kube-proxy의 nftables 모드가 GA로 승격됐다. 우리 팀도 iptables 모드에서 nftables 모드로 옮기는 논의를 시작했는데, 막상 "왜 nftables가 iptables보다 빠른가"라는 질문에 답이 잘 안 나왔다. "룰 개수가 줄어드니까 빠르지" 정도로 부족했다. 그래서 KEP-3866과 실제 룰 덤프를 뜯어보며 정리했다. 이 글은 그 결과다.기본적으로 아직 iptables가 kube-proxy의 기본 모드로 남아있고, 명시적으로 --proxy-mode nftables를 줘야 nftables 모드가 켜진다. 커널은 5.13 이상이 필요하다. 이 부분은 공식 블로그에도 명확히 적혀 있다.왜 iptables 모드가 느렸는가먼저 iptables 모드의 구..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. 아니 정확히는 알긴 아는데 실제로 프로덕션에서 써본 적 없는 분들. 나도 얼마 전까지 그러다.distroless 이미지 쓰는 서비스에서 이슈가 났다. 컨테이너 내부에서 curl 한 번만 때려보고 싶은데 kubectl exec -it pod -- sh 하면 당연히 sh: no such file or directory. 그렇다고 이미지를 alpine 기반으로 다시 말아 재배포? 프로덕션에서 그건 좀. 그럴 때 kubectl debug가 답이다.기본 사용법kubectl debug -it my-app-pod \ --image=busybox:1.36 \ --target=app \ -- sh--target=app이 핵심이다. 대상 컨테이너의 프로세스 네임스페이..

DRA(Dynamic Resource Allocation) 가 1.34에서 드디어 GA로 올라갔다. 그 사이에 1.35, 1.36까지 나오면서 드라이버 생태계도 꽤 안정화됐고, 최근 KubeCon에서도 "이제는 device plugin 대신 DRA를 쓸 시기"라는 얘기가 자주 나온다. 우리 팀도 GPU 워크로드가 늘면서 기존 nvidia.com/gpu 정수 카운트 방식으로는 감당이 안 되는 케이스가 생겨서, 최근 두 주 동안 DRA로 옮겨봤다. 이 글은 그 이관 과정을 정리한 가이드다.왜 device plugin으로는 부족했나기존 device plugin 방식은 GPU를 정수 개수로만 노출한다. 그래서 "메모리 20GB 이상인 GPU 아무거나", "MIG로 잘라진 slice", "같은 노드 안에서 NVL..

지난주 화요일 새벽 2시쯤이었나. 알림이 울렸다. 특정 서비스의 P99 레이턴시가 800ms를 넘긴다는 알람이었다. 노드 16대짜리 프로덕션 클러스터에서, 특정 결제 API 파드가 30초 간격으로 8개에서 22개, 다시 10개, 또 25개... 이런 식으로 계속 오르락내리락 하고 있었다.솔직히 처음엔 트래픽 스파이크인 줄 알았다. 근데 그라파나 대시보드를 열어보니 그건 아니었다. RPS는 완만하게 오르는 중이었다. 그런데 파드 수가 미친 듯이 진동하고 있었다. 이게 바로 HPA flapping이다. 이론으로만 알던 걸 새벽 2시에 만나게 되니 정말 반가웠다(반갑지 않았다).처음엔 임계값을 만졌다가장 먼저 시도한 건 CPU targetAverageUtilization을 60에서 75로 올린 것이었다. "임..

트러블슈팅 하다가 오늘 알게 됐다. 정확히 말하면 "알고는 있었는데 안 쓰고 있었다"에 가깝다. kubectl events --for 얘기다.왜 이제서야 쓰나지금까지 특정 Pod의 이벤트만 보려면 이렇게 했다.kubectl get events --field-selector involvedObject.name=web-pod-abc,involvedObject.kind=Pod -n prod솔직히 매번 field-selector 문법이 헷갈렸다. involvedObject.name이었나 regarding.name이었나. Pod 이름을 오타 내면 결과가 조용히 비어있고, 그러면 또 오타를 의심하게 된다. 삽질 시간의 절반이 이 selector 맞추기였다.그런데 kubectl events는 v1.28에서 GA된 이..

지난주 화요일 오전 10시쯤, 데이터팀 슬랙에 핑이 왔다. "혹시 정산 배치 어제도 안 돈 것 같은데, 뭐 바뀐 거 있어요?" 처음엔 별 생각 없이 로그부터 봤다. 어제, 그저께, 그그저께. 세 번 다 스케줄 시각에 Job이 아예 생성되지 않은 상태였다. Pod가 실패한 게 아니라 Job 자체가 없었다. 이거 뭐지, 하는 마음으로 CronJob describe를 걸었다.문제 상황문제의 CronJob은 매일 새벽 3시에 도는 정산 집계 배치였다. schedule은 0 3 * * *, concurrencyPolicy는 Forbid. 원래 잘 돌던 놈이었는데, 일주일쯤 전에 내가 매니페스트를 손댔다. 이유는 이랬다.기존 설정은 startingDeadlineSeconds가 없었다. 배치가 오래 걸리는 날에 다음..

HPA(Horizontal Pod Autoscaler)를 쓰다 보면 어느 순간 벽에 부딪히는 순간이 온다. CPU가 안 튀는데 큐가 밀리거나, 새벽에는 파드가 0개여도 되는데 굳이 1개는 떠 있어야 한다거나, 아예 커스텀 메트릭 어댑터를 붙이자니 설정이 지저분해지는 그런 순간들.우리 팀도 6개월쯤 CPU 기반 HPA로 버티다가 결국 KEDA로 넘어왔다. 이 글은 그 과정에서 정리한 실무 가이드다. 최근 0.35 코어 의존성으로 올라오면서 events.k8s.io API로 이벤트를 남기는 방식이 바뀌었는데, 이런 세부 변화들도 같이 짚고 넘어가겠다.HPA로 왜 부족한가HPA는 리소스(CPU/메모리)나 커스텀 메트릭을 기반으로 파드 수를 조정한다. 문제는 이게 "지금 파드가 얼마나 힘든가"를 기반으로 한다는..

오늘 알게 된 건데, 아직도 Istio sidecar나 Vault agent를 그냥 containers[]에 박아넣고 쓰시는 분들 꽤 많더라. 우리 팀도 그랬다. 근데 최근 클러스터 1.33 올리면서 native sidecar (초기 컨테이너 restartPolicy: Always)로 싹 옮겼는데, 딱 하나 함정이 있어서 공유한다.뭐가 좋아졌나원래 sidecar 패턴의 고질병이 두 개였다. 하나는 앱 컨테이너보다 sidecar가 늦게 뜨면 초기 요청이 실패하는 거. 또 하나는 Job에서 sidecar가 안 죽어서 Pod가 Completed로 안 넘어가는 거. Vault agent injector 쓰는 팀이면 다들 겪어봤을 거다.Kubernetes 1.33에서 native sidecar가 stable 됐고..

작년 이맘때까지 우리 EKS 클러스터는 Cluster Autoscaler로 잘 돌아가고 있었다. 노드 그룹 세팅도 안정적이었고, 크게 불만도 없었다. 그런데 반년 전쯤 트래픽 패턴이 바뀌면서 상황이 달라졌다. 낮에는 몰리고 밤에는 뚝 떨어지는 변동 폭이 커졌고, 갑자기 배포되는 배치 잡도 늘었다. 그때부터 노드가 이상하게 많이 뜨기 시작했고, 청구서를 볼 때마다 한숨이 나왔다.결국 Karpenter로 옮겼다. 최근에 v1이 정식으로 나오면서 API도 정리됐고, 실전에 쓸 만하다는 얘기가 많아진 시점이었다. 옮기고 나서 두 달쯤 지난 지금, 그 비교를 정리해두려고 한다.스케줄링 철학이 다르다이게 제일 큰 차이다. Cluster Autoscaler는 노드 그룹 단위로 사고한다. 어떤 파드가 pending이면..

작년쯤부터 팀 클러스터에 PriorityClass를 슬금슬금 붙이기 시작했다. 배치 잡이 야간 스케줄러를 물고 늘어져서 온라인 워크로드가 스케줄이 안 되는 일이 종종 생겼고, 그때마다 "그냥 우선순위 붙이면 되지 않나?" 하는 이야기가 나왔다. 문서 그대로 priority: 1000000 짜리 클래스를 만들고 붙였는데, 실제로 클러스터가 밀릴 만한 상황이 왔을 때 예상대로 안 밀린 경우가 몇 번 있었다. 그래서 kube-scheduler의 preemption 코드를 찬찬히 뜯어봤고, 그 과정에서 "아, 이래서 이게 안 됐구나" 싶은 지점이 몇 개 나왔다. 오늘은 그 내용을 정리해보려고 한다.이 글은 사용법이 아니라 안쪽 이야기다. Preemption이 어떤 순서로, 어떤 기준으로 pod들을 죽일 후보로 ..