day-log

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이 핵심이다. 대상 컨테이너의 프로세스 네임스페이..

멀티클러스터 네트워킹 붙일 일이 생겼다. 처음엔 별 생각 없었는데, 막상 후보를 놓고 보니 결정이 애매했다. Cilium ClusterMesh랑 Submariner. 둘 다 CNCF 프로젝트고, 둘 다 "서비스가 클러스터 경계를 넘어서 통신하게 해준다"는 결과물은 비슷하다.근데 실제로 붙여보면 완전 다른 물건이다. 우리 팀은 결국 ClusterMesh로 갔지만, 그게 정답이라고는 못 하겠다. 상황에 따라 다르다.왜 이 결정을 해야 했나우리 쪽은 EKS 두 개 리전에 걸쳐 있다. 서울 + 도쿄. 원래는 리전간 통신이 필요 없었는데, 이번에 특정 서비스(주문/결제 쪽)를 DR 목적으로 양쪽에 띄우기로 하면서 상황이 바뀌었다.요구사항이 이랬다:서비스가 다른 리전 클러스터의 파드도 endpoint로 인식해야 함..

라이선스 이슈로 시끄러웠던 게 벌써 2년 전이다. 그때는 "일단 지켜보자"로 넘어간 팀이 많았는데, 요즘 다시 이 얘기가 올라온다. 나도 최근에 팀 내부에서 마이그레이션 검토를 했고, 결과적으로는 OpenTofu 쪽으로 기울었다. 이유를 정리해본다.지금 어디까지 왔나Terraform은 1.15 라인이 stable, 1.16이 alpha다. OpenTofu는 1.12.2가 stable. 버전 넘버만 보면 Terraform이 앞서가는 것 같지만 실제 CLI 오픈소스 기능은 그 반대다.HashiCorp가 BSL로 넘어간 뒤 IBM에 인수됐고, 오픈소스 CLI에는 신규 기능이 거의 안 들어간다. 대신 HCP Terraform(관리형)과 AI 어시스트 쪽으로 투자가 몰려 있다. 반면 OpenTofu는 Linux ..

트러블슈팅 하다가 오늘 알게 됐다. 정확히 말하면 "알고는 있었는데 안 쓰고 있었다"에 가깝다. 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된 이..

로그 파이프라인 재설계 얘기가 팀 내부에서 다시 나왔다. 3년 전에 Fluentd로 깔아둔 걸 언제까지 끌고 갈지, 지금 시점에서 갈아탄다면 Fluent Bit이냐 Vector냐. 두 도구 모두 몇 달씩 붙잡고 굴려봤기 때문에 이 참에 정리해두려고 한다.결론부터 말하면 "무조건 이거"는 없다. 다만 우리 팀이 어떤 상황에서 뭘 골랐는지, 왜 그랬는지는 명확하게 얘기할 수 있다.두 도구를 다시 보자Fluent Bit은 C로 짜였고 CNCF 공식 프로젝트다. Kubernetes 생태계 안에서는 사실상 표준처럼 자리잡은 지 오래다. 바이너리 크기 작고, 메모리 몇십 MB로 노드마다 DaemonSet으로 깔아둬도 티가 안 난다. Kubernetes metadata filter가 안정적이고, tail input의..

Terraform state 정리, 아직도 terraform state mv 로컬에서 치고 있는지? 우리 팀도 얼마 전까지는 그랬다. 리소스 하나 옮길 때마다 누군가 로컬에서 state 조작을 하고, PR에는 코드만 올라가고, "state는 내가 미리 옮겨놨어요" 슬랙 메시지가 흘러가고. 그러다 한 명이 실수하면 다음 사람이 apply 돌릴 때 리소스가 destroy/create 로 뜬다. 새벽에.이 문제를 해결하려고 나온 게 declarative state 관리 블록 세 개다. moved (1.1+), import (1.5+), removed (1.7+). 이름만 들으면 뻔한데, 실제로 팀 컨벤션으로 못박아 놓으면 state 관련 사고가 눈에 띄게 줄어든다. 최근 Terraform 1.11 대까지 오면..

지난주 화요일 새벽 3시 반쯤, 슬랙 알림에 깼다. "CI 전체 실패 중" 이라는 온콜 메시지. 눈 비비고 노트북 열었더니 GitHub Actions 화면이 온통 빨간색이었다. 로그를 열어보니 다들 같은 메시지를 뱉고 있었다.No space left on device우리 팀은 self-hosted runner를 EC2 위에 올려서 쓴다. 처음 세팅했을 때부터 "언젠가 디스크 문제 터진다"는 거 알고 있었는데, 대응을 미루다가 결국 새벽에 얻어맞은 케이스였다. 그날 겪은 삽질을 정리해둔다.상황우리 러너 구성은 대략 이랬다.c6i.2xlarge EC2 3대, ephemeral 아니고 long-runninggp3 100GB 루트 볼륨 하나Docker in Docker로 이미지 빌드/테스트하루 평균 400개 정..

한 달 반쯤 팀 내부에서 계속 논쟁이 있었다. Grafana Agent가 EOL 방향으로 가면서 Alloy로 갈아탈지, 아니면 이참에 그냥 순정 OpenTelemetry Collector(otelcol)로 통일할지. 결론부터 말하면 우리는 양쪽 다 쓴다. 딱 정하는 게 실무에서는 오히려 이상한 답이었다. 왜 그런 결론이 났는지 정리해둔다.왜 이 논쟁이 지금 튀어나왔나Grafana Agent가 2025년 말에 사실상 유지보수 모드로 들어갔고, 팀이 쓰던 Agent Flow 설정을 어디로 옮기느냐가 실질적인 문제였다. 자연스러운 후보는 두 개.하나는 Grafana Alloy. Agent Flow의 후속이니 마이그레이션 문서도 잘 정리돼 있고, alloy convert 명령으로 기존 config를 그대로 밀어..