day-log

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

작년 봄에 시크릿 관리 체계를 갈아엎으면서 ESO(External Secrets Operator)랑 SOPS를 둘 다 도입했다. 처음엔 하나로 통일하자는 의견이 강했는데, 1년 굴려보니 둘 중 하나만으로는 답이 안 나오더라. 결국 우리 팀은 둘을 역할로 갈라놓고 쓰는 쪽으로 정착했다.최근에 신규 팀 합류한 사람한테 이 구조를 설명할 일이 있었는데, 막상 글로 정리해두니 우리도 모호하게 쓰고 있던 부분이 꽤 보였다. 그래서 한번 정리해본다.우리 환경 간단히EKS 클러스터 4개 (dev/stage/prod 2개 — 리전 분리)ArgoCD 기반 GitOpsAWS Secrets Manager, Parameter Store 둘 다 사용 중코드 저장소는 GitHub Enterprise원래는 sealed-secret..

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

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

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 ..

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

작년에 신규 EKS 클러스터를 띄우면서 한 가지 결정을 미뤘다. 워크로드 IAM을 IRSA로 갈지 Pod Identity로 갈지. 그때는 "어차피 둘 다 지원되니까 나중에 보자"고 미뤘는데, 올해 들어 클러스터가 4개로 늘어나면서 더는 미룰 수 없는 상태가 됐다.지난 두 달 동안 stage 환경 전체를 Pod Identity로 옮겨보고, prod의 일부 워크로드도 마이그레이션을 시작했다. 결론부터 말하면 우리 팀은 신규 워크로드는 전부 Pod Identity로, 기존 IRSA는 천천히 전환 중이다. 왜 그런 결정을 했는지, 어떤 케이스에서는 IRSA가 더 나았는지 정리해본다.비교의 배경: 우리는 어떤 환경이었나먼저 우리 팀 환경을 짧게 적어둔다. 비교 결과는 환경에 따라 다르게 읽힐 수 있어서다.EKS ..

지난주에 우리 팀 OpenTelemetry Collector 파드들이 갑자기 OOMKill 잔치를 벌였다. 평소 워킹셋이 1.2GB 정도였는데, 어느 날 새벽부터 4GB까지 치솟더니 limit(6GB)을 넘기고 죽기 시작했다. 트래픽이 갑자기 늘어난 것도 아니고 설정을 건드린 것도 아니었다. 그라파나 패널 보면서 "아 이거 또 시작이네" 싶었다.결론부터 말하자면 batch processor의 send_batch_size를 잘못 키운 게 시작이었고, 거기에 exporter queue가 백프레셔를 못 받아주면서 메모리가 무한정 쌓였다. 글 안에 다 풀어쓰겠지만, 비슷한 증상 보시는 분들은 일단 memory_limiter부터 위에 끼워두시는 걸 권한다.증상 — 처음 3시간 동안 본 것오전 5시 23분에 첫 페..