day-log

지난주에 진짜 며칠을 날렸다. 결론부터 말하면 범인은 ndots:5 였는데, 이 얘기 어디선가 다들 한 번씩은 들어봤을 거다. 근데 막상 우리 클러스터에서 실제로 터지니까 원인 찾는 데 이틀이 걸렸다. 이번엔 그 과정에 대한 기록이다.증상: 새벽 3시에 켜진 페이지노드 40대 규모의 EKS 클러스터에서 결제 관련 서비스 P99 레이턴시가 갑자기 튀기 시작했다. 평소엔 60ms 언저리였는데, 어느 순간부터 800ms까지 스파이크가 찍힌다. 새벽 3시에 폰이 울려서 잠이 확 깼다.처음 든 생각은 "또 RDS인가"였다. 요즘 우리 팀에선 뭐만 느려지면 일단 DB부터 의심하는 게 습관이 됐거든. 근데 커넥션 풀도, slow query 로그도, RDS CloudWatch도 다 깔끔했다. 애플리케이션 로그를 뒤져봐..

노드 drain 걸었는데 특정 파드가 계속 evict 안 되고 남아 있던 적, 다들 한 번쯤 있을 거다. 반대로 drain 명령 하나로 서비스가 순간적으로 다 내려가서 알람이 우수수 뜬 경험도. 이 두 상황 사이의 균형을 잡아주는 게 PodDisruptionBudget(PDB)인데, 막상 실무에서 어떻게 세팅해야 할지는 문서만 봐서는 잘 안 잡힌다.우리 팀도 노드 수십 대짜리 EKS 클러스터에서 Karpenter로 consolidation을 돌리면서 몇 번 삽질을 했다. PDB 하나 잘못 걸어서 consolidation이 몇 시간씩 멈춰 있던 적도 있고. 그래서 지금 팀 안에서 굳어진 룰 위주로 정리해본다.minAvailable vs maxUnavailable, 뭘 쓸까이거 은근히 헷갈리는데, 결론부터 ..

Kubernetes Service가 어떻게 Pod에 트래픽을 흘려보내는지, 표면적으로는 다들 안다. Service → Endpoints → Pod IP 이렇게 이어진다는 그림 말이다. 그런데 실제로 v1.33 기준으로 클러스터 안에서 벌어지는 일은 이 그림과 조금 다르다. Endpoints API는 이제 사실상 legacy로 밀려나 있고, 그 자리를 EndpointSlice가 완전히 차지했다. 최근에 우리 팀 신규 클러스터를 1.33으로 올리면서 노드 350대짜리 스테이징에서 Service 업데이트 지연을 재현하다가, 이 내부 동작을 다시 파고들 일이 있었다. 오늘은 그 정리다.이 글은 짧지 않다. Service의 실체가 궁금하거나, kube-proxy 성능이 왜 클러스터 규모에 따라 갑자기 무너지는지 ..

지난주 화요일 새벽 3시 12분. 폰이 울렸다. 결제 서비스에서 upstream timeout이 폭발하고 있다는 페이지. 잠결에 노트북 열었을 때 나는 진짜 결제 API가 죽은 줄 알았다.처음 본 지표Grafana 대시보드를 열어보니 결제 API 자체는 멀쩡했다. P99 레이턴시가 평소 80ms에서 4초로 튀었을 뿐, 컨테이너는 다 살아있고 로그에도 별다른 에러가 없었다. 근데 트래픽은 확실히 흐르지 못하고 있었다. 뭔가 이상해서 istio access log를 뒤져보니 upstream 접속 자체가 안 되는 케이스가 계속 찍히고 있었다.노드 자체 리소스는 여유로웠다. CPU 40%, 메모리는 60%대. 그런데 왜?정신이 살짝 들어서 kube-system 네임스페이스를 봤다. CoreDNS 파드 로그가 도..

kubectl이 갑자기 Too Many Requests를 뱉기 시작하면 대부분 첫 반응은 비슷하다. "누가 또 apiserver 두들기고 있냐." 그리고 나서 metrics를 보면 특정 컨트롤러가 리스트 요청을 폭주하고 있거나, 새 오퍼레이터가 배포되면서 watch를 무한 재연결하고 있거나 그런 식이다.근데 그때 이런 의문이 든다. 왜 kubelet의 상태 업데이트는 여전히 잘 되는데 내 kubectl은 막힐까? 왜 어떤 요청은 큐잉되고 어떤 요청은 즉시 429가 뜰까? 이 뒤에는 API Priority and Fairness — 줄여서 APF — 라는 녀석이 돌아가고 있다. 사실 v1.29에서 GA된 지 좀 됐는데, 실제로 이걸 튜닝하거나 내부를 뜯어본 사람은 생각보다 적다. 최근에 EKS 컨트롤 플레..

지난주 화요일 새벽 4시쯤, 알림이 두 개 연달아 왔다. 하나는 pod pending 알림, 하나는 P99 레이턴시 알림. 눈이 번쩍 떠져서 노트북을 켰다.우리 팀은 몇 달 전부터 Karpenter를 v1.x로 올려두고 spot-to-spot consolidation을 활성화해서 쓰고 있다. 비용은 확실히 줄었다. 근데 그 새벽에는 대가를 치렀다. 노드 12대 중 7대가 30분 사이에 인터럽트를 받으면서 순차적으로 죽었고, 그 와중에 Karpenter는 계속 새 spot을 붙였다 떼기를 반복하고 있었다.처음에는 그냥 spot 인터럽트인 줄 알았다AWS spot은 원래 죽는다. 그건 알고 시작한 거니까. 그래서 처음에는 "아 오늘 그 존이 좀 빡센가 보다" 하고 넘어갈 뻔했다. 근데 로그를 보니 이상했다...

cert-manager 깔아두고 Let's Encrypt 인증서 받는 거, 처음엔 다들 HTTP01로 시작한다. 튜토리얼이 다 그렇게 되어 있고, 일단 ingress 붙이면 되니까. 근데 운영 좀 하다 보면 슬슬 짜증이 난다. 와일드카드가 안 된다거나, 클러스터 내부용 도메인인데 80포트가 안 뚫린다거나. 그래서 DNS01로 옮기는데, 이게 또 권한 관리가 따로 필요해서 처음엔 헤맨다.이 글은 그 분기점에서 어떤 걸 쓰면 좋은지, 그리고 둘을 섞어 쓸 때 흔히 만나는 함정 몇 개를 정리해본다. 우리 팀에서 작년에 ingress 컨트롤러 갈아엎으면서 DNS01로 거의 다 옮겼는데, 그 과정에서 배운 것들이다.HTTP01이 어울리는 상황생각보다 단순한데, 두 가지 조건이 동시에 만족되면 HTTP01이 제일 ..

이번 분기 OKR 중에 "데이터플레인 통합" 항목이 하나 있었다. 우리는 그동안 kube-proxy(iptables 모드) + Calico CNI 조합을 써왔는데, 네트워크폴리시 관측이 약하고 iptables 룰이 노드당 8천 줄을 넘기 시작하면서 syncProxyRules 지연이 P95 기준 1.2초까지 튀는 날이 가끔 있었다. 다른 팀이 먼저 Cilium 으로 갈아탔길래, 우리도 다음 주에 도입하기로 했다.결론부터 말하면 도입은 했다. 그런데 도입 첫날 새벽 2시에 보안팀한테 "audit log 의 source IP 가 전부 노드 IP 로 찍히는데 뭔가 잘못된 거 아니냐" 라는 메시지를 받았고, 거기서부터 24시간이 좀 정신없었다.1차 시도 — kubeProxyReplacement=true 만 켜고 ..

지난주 화요일 새벽 두 시, 휴대폰이 울렸다. P0 알람. 결제 API의 P99 레이턴시가 1.2초를 넘기고 있었고, 50x 비율이 3분 동안 8%까지 올라갔다 떨어졌다. 잠이 확 깼다.대시보드를 열어보니 노드가 한꺼번에 세 대가 빠지고 있었다. 우리 클러스터는 노드 24대 규모인데, Karpenter consolidation이 동시에 세 대를 cordoning + draining 중이었다. Pod Disruption Budget도 걸어뒀고, terminationGracePeriodSeconds도 충분히 잡아뒀는데도 결제 서비스 두 개 인스턴스가 같은 노드에 몰려 있던 게 문제였다. 새벽 2시는 트래픽이 낮긴 해도 결제는 0이 아니다. 일본/동남아 유저들이 깨어 있다.왜 새벽에 한꺼번에 빠졌나Karpen..

지난 4월쯤이었다. 슬랙에 누가 링크 하나를 던졌다. ingress-nginx 메인테이너들이 더 이상 best-effort 유지보수도 못한다고 공지를 올렸다는 거였다. 처음에는 "에이, 그래도 굴러는 가겠지" 했다. 우리 클러스터 8개에 다 깔려 있고, ingress 리소스만 200개가 넘는데. 근데 그 주에 보안팀에서 CVE 패치 일정을 묻는 메일이 왔고, 그제서야 정신이 들었다. 사실상 EOL 된 컨트롤러를 들고 가는 건 시간 문제일 뿐이라는 걸.그래서 Gateway API로 가기로 했다. 5월 초부터 6월 말까지, 약 두 달 동안 삽질한 이야기를 적어둔다. 누군가는 비슷한 상황일 테니까.처음에 안일하게 생각했던 것Gateway API가 v1.5까지 나왔고 standard로 거의 다 올라왔다는 글을 ..