day-log

CNI 갈아탈까 말까 하는 고민은 누구나 한 번쯤 한다. 우리 팀도 작년 말부터 "Cilium 한번 가보자" 분위기가 있었고, 결국 6개월 가까이 PoC와 운영 시뮬레이션을 돌렸다. 결론부터 말하면, 메인 워크로드는 Calico에 남겼고 새로 구축한 ML 추론 클러스터만 Cilium으로 갔다. 같은 회사 안에서 CNI를 두 개 쓰게 된 셈인데, 이 글은 왜 그런 결정을 했는지에 대한 정리다.왜 갈아타고 싶었나우리 메인 EKS 클러스터는 노드 80대 규모. Calico를 3년 넘게 써왔고 큰 문제는 없었다. 그런데 최근 1년 사이 두 가지 가려운 부분이 생겼다.하나는 kube-proxy iptables 룰이 너무 길어진 거다. Service 수가 1,200개를 넘기면서 노드당 iptables 룰이 4만 줄..

지난주에 HPA behavior 필드를 손댄 적이 있다. 정확히 말하면 손댄 게 아니라, 누군가 친절하게 PR로 올려준 "스케일 다운 빠르게 하자"는 변경을 별생각 없이 머지한 게 시작이었다. 그날 오후부터 P99 레이턴시가 평소 80ms에서 320ms를 찍었고, 새벽 1시쯤 알람이 한 번 더 울리고 나서야 우리 팀은 이게 비용 최적화가 아니라 자해였다는 걸 인정했다.이 글은 그 삽질 회고다. 비슷한 PR 들어오면 한 번만 더 생각해 보시라는 의미에서 적어둔다.사건의 시작서비스는 API 트래픽이 출퇴근 시간대에 몰리는 전형적인 패턴이다. 노드 12대짜리 EKS 클러스터에서 Deployment 3개가 HPA로 묶여 있었고, 평소 replica가 8~30 사이를 왔다 갔다 했다. 비용을 줄이려면 트래픽이 빠..

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

스팟 인스턴스를 자주 쓰다 보면 kubelet이 노드 종료 시점에 어떻게 행동하는지가 늘 신경 쓰인다. 사실 nodelifecycle 컨트롤러가 Pod를 옮겨주기는 하지만, 그건 노드가 NotReady가 되고도 한참 뒤의 이야기다. 그 사이에 노드 위에 있던 Pod이 어떻게 끝나느냐는 전적으로 kubelet의 graceful node shutdown 동작에 달려 있다. 이 기능은 1.21에서 알파, 1.28에서 GA가 됐고, 1.24부터는 Pod priority별로 단계화도 가능해졌다. 그런데 막상 운영해보면 "켜 놨는데 안 도는 것 같다"는 케이스가 꽤 있다. 어디서 끊기는지 한번 따라가본다.systemd-inhibitor라는 비밀번호kubelet이 노드 종료를 감지하는 방식은 의외로 단순하다. 부팅 ..

Karpenter를 1년 넘게 운영하다 보니 "왜 이 인스턴스 타입을 골랐을까" 하는 순간이 종종 생긴다. m5.2xlarge면 충분해 보이는데 c6i.4xlarge를 띄운다거나, 분명히 비슷한 spec인데 어떤 Pod는 한 노드에 몰리고 어떤 Pod는 새 노드를 띄운다. 처음엔 그냥 "알아서 잘 해주겠지" 하고 넘어갔는데, 최근 Karpenter 1.11에서 Application Recovery Controller(ARC) zonal shift 통합이 들어오면서 zone 단위 회복 시나리오를 검토할 일이 생겼다. 이 김에 스케줄러 내부를 한 번 제대로 들여다봤다.사실 Karpenter의 스케줄링 로직은 pkg/controllers/provisioning/scheduling/scheduler.go 한 파..

오늘 알게 된 거 아니고, 사실 꽤 됐는데 의외로 모르는 분이 많더라. 지난주에도 동료가 "JVM 앱이 livenessProbe 때문에 자꾸 재시작된다, initialDelaySeconds를 300초로 박았는데도 가끔 죽는다"는 얘길 했다. 그때 startupProbe 얘기를 꺼내면서 "어 진짜? 그런 게 있었어?"라는 반응이 나왔다. 1.20부터 GA였는데도 말이다.근데 이게 한두 명 얘기가 아니라서, 짧게 정리해둔다.initialDelaySeconds로 버티는 게 왜 문제냐흔히 쓰는 패턴이 이거다.livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 180 periodSeconds: 10 failureThresh..

왜 또 kube-proxy 얘기인가kube-proxy는 Kubernetes에서 가장 오래된 컴포넌트 중 하나다. 그런데 사람들은 의외로 이 친구가 실제로 뭘 하는지 잘 모른다. Service ClusterIP로 패킷이 들어오면 Pod로 잘 가더라, 정도가 평균적인 이해다. 나도 한참 그랬다.올해 1.33에서 nftables 모드가 정식으로 GA가 됐고, 이제 Linux 노드에서는 공식 권장 모드가 nftables라는 분위기가 만들어졌다. 우리 팀에서도 다음 분기 클러스터 업그레이드 때 nftables로 넘어갈지를 두고 논의 중이다. 결정을 하려면 세 모드가 도대체 어떻게 다른지를 손에 쥐고 있어야 하는데, 매번 검색해서 보다 보니 한번 정리해두자 싶었다.이 글은 "어느 모드가 빠른가" 같은 표 비교가 아..

지난주 화요일 오전이었다. 평소처럼 백오피스 서비스 배포를 돌렸는데, 운영팀 슬랙에 "1분쯤 전에 잠깐 페이지가 안 떴어요"라는 메시지가 떴다. 처음 듣는 얘기는 아니다. 사실 우리 팀에서는 배포할 때 5xx가 한두 건 튀는 걸 그냥 "Kubernetes의 미세한 빈틈"이라고 부르며 넘기고 있었다. 근데 이번엔 운영팀 화면에 명확히 보일 정도로 길었다는 게 문제였다.Grafana로 들어가서 Ingress 컨트롤러의 5xx 그래프를 봤다. 배포 시점에 503이 약 7초간 spike. 평소에는 1초 미만이었는데 이번엔 길었다. 우리 환경은 EKS 1.32, NGINX Ingress Controller, replicas 6짜리 평범한 Deployment. 이쯤이면 "또 종료 시퀀스 문제겠지" 싶었지만, 막상 ..

KEDA SQS scaler에서 새벽에 만난 함정지난주 토요일 새벽 3시쯤이었다. 핸드폰 진동 한 번에 눈이 떠졌다. SQS DLQ 누적 알림. 큐 메시지가 12,000개 쌓여 있었고, 컨슈머 파드는 정확히 한 개. 분명 KEDA로 ScaledObject 걸어놨고, 두 달 동안 잘 돌던 워크로드인데 왜 안 늘어났을까. 멘탈이 좀 흔들렸다.그래서 뭐가 문제였나상황부터 정리하자. 우리 팀이 운영하는 컨슈머는 이미지 후처리(리사이즈 + 메타데이터 추출)를 하는 파이썬 워커다. SQS에서 메시지 꺼내서 S3 거쳐 DynamoDB 업데이트하는 평범한 패턴. KEDA 2.16으로 SQS scaler 붙여놨고 설정은 이랬다.apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetada..

워커노드 OS 얘기를 팀에서 다시 꺼낸 게 두 달쯤 됐다. 그동안은 EKS 기본인 AL2023을 별 생각 없이 썼는데, 멀티클라우드로 한 발 걸치는 작업이 시작되면서 "노드 OS를 통일하면 좋겠다"는 얘기가 나왔다. 후보는 두 개. Bottlerocket, 그리고 Talos. 이번 글은 정답을 내는 글은 아니고, 우리 팀이 한 달 정도 굴려보면서 정리한 비교 노트다.지난 가을 InfoQ에 Talos가 다시 한 번 크게 다뤄지면서 사내 분위기도 살짝 기울었는데, 막상 PoC를 돌려보니 그렇게 단순하진 않았다.두 OS의 출발점이 다르다Bottlerocket은 AWS에서 만든 "컨테이너 워크로드 전용 OS"다. EKS, ECS 둘 다 지원하고, 바이너리는 250개 정도. control container와 ad..