day-log

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은 원래 죽는다. 그건 알고 시작한 거니까. 그래서 처음에는 "아 오늘 그 존이 좀 빡센가 보다" 하고 넘어갈 뻔했다. 근데 로그를 보니 이상했다...

이거 모르는 분 꽤 많더라. RUN --mount=type=cache 한 줄로 npm/pip install 시간을 절반 이하로 줄일 수 있다. 그런데 실무에서 제대로 세팅한 걸 보기는 의외로 드물다.뭐가 문제냐기본 Dockerfile로 이미지 빌드하면, COPY package*.json ./ 다음에 RUN npm ci 하는 패턴을 쓸 거다. 여기서 lock 파일이 바뀌면 그 아래 레이어 캐시가 전부 무효화되고, npm ci가 처음부터 다시 돈다. 패키지 하나 추가했을 뿐인데 400개 다운로드를 다시 하는 셈이다.우리 팀은 프론트 모노레포에 workspace 20개가 물려 있는데, 어떤 워크스페이스 하나만 라이브러리 하나 올려도 CI 이미지 빌드가 3분 넘게 걸렸다. 노드 하나 이슈면 그러려니 하는데 매번..

지난주 화요일 새벽 2시 반쯤이었다. 온콜 알림이 왔고, Prometheus 인스턴스 두 대가 연달아 OOM으로 죽었다는 내용이었다. 눈을 비비고 노트북을 열었는데, Grafana는 이미 죽어 있었다. 데이터 소스가 죽었으니 당연한 일이었다. 그 다음 두 시간 반 동안 내가 겪은 얘기다.처음엔 그냥 재시작하면 될 줄 알았다당시 우리 스택은 이랬다. 노드 24대 EKS 클러스터, kube-prometheus-stack으로 배포한 Prometheus 두 대 HA 구성, 메모리 리소스 리밋은 각각 16GB. 평상시 series 개수는 대략 480만 정도. 리텐션 15일. remote_write로 장기 저장소에 밀어넣고 있었다.일단 재시작. WAL replay가 시작됐는데, 이게 도무지 끝나지가 않았다. 평소엔..

Falco를 클러스터에 깔아본 사람은 많지만, 이게 정확히 어떤 식으로 syscall을 잡아내는지 끝까지 따라가본 사람은 의외로 적다. 우리 팀에서도 한동안은 "그냥 eBPF로 커널 이벤트 본다더라" 수준의 이해로 운영했다. 그러다가 노드 일부에서 syscall drop이 튀기 시작했고, 원인을 디버깅하다 보니 결국 probe 내부 구조까지 파게 됐다. 이번 글은 그때 정리한 내용을 풀어서 쓴 것이다.사실 내부적으로는 Falco가 모든 일을 직접 하지 않는다. 사용자 공간에서 룰을 평가하는 falco 데몬과, 커널 공간에서 syscall을 가로채는 probe가 분리돼 있다. 우리가 보통 Helm 차트 옵션에서 driver.kind: modern_ebpf라고 한 줄 적고 넘어가는 그 probe가, 실은 꽤..

ArgoCD ApplicationSet으로 멀티 환경 배포 자동화하기ArgoCD를 처음 도입했을 때는 환경마다 Application 리소스를 따로 만들어 썼다. dev, staging, prod 세 환경에 마이크로서비스 12개. 단순 계산으로 36개. 여기에 신규 환경이라도 하나 늘면 또 12개를 복사 붙여넣기. 처음엔 견딜만 했는데, 팀이 커지면서 이 반복 작업이 진짜 골치 아파졌다.ApplicationSet은 이 문제를 푸는 도구다. 한 번 정의해두면 generator가 알아서 N개의 Application을 만들어준다. 이번 글에서는 우리 팀이 실제 운영하면서 정착시킨 패턴을 정리해본다. 참고로 최근 ArgoCD 3.3에서 ApplicationSet의 shallow clone 옵션이 추가돼서 큰 모노..

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 만 켜고 ..

옮기기 전에 체크할 것EKS Pod Identity가 GA된 게 2023년 말이니까 벌써 2년 반쯤 됐다. 처음 나왔을 때는 "굳이 IRSA에서 갈아탈 이유가 있나" 싶었는데, 클러스터 수가 10개를 넘어가면서 OIDC provider를 매번 등록하고 trust policy의 sub 클레임을 클러스터마다 갈아끼우는 게 슬슬 짜증나기 시작했다. 올해 들어 우리 팀도 본격적으로 옮기기 시작했고, 이제 절반쯤 마이그레이션한 상태다.이 글은 "왜 옮겨야 하나"보다는 "어떻게 옮기나"에 집중한다. 결론부터 말하면 한 번에 다 갈아엎을 필요는 없다. 같은 클러스터, 같은 네임스페이스에서 IRSA와 Pod Identity가 공존한다.먼저 마이그레이션을 시작하기 전에 확인해야 할 게 몇 가지 있다.EKS 클러스터 버전..