day-log

kubectl -o kyaml, 이거 모르는 분 꽤 많더라

오늘 알게 된 건데, 요즘 팀 내부에서 kubectl get -o yaml로 뽑은 매니페스트를 그대로 GitOps 저장소에 붙여넣는 걸 좀 조심하자는 얘기가 나왔다. 이유는 뻔한데, YAML의 그 유명한 "노르웨이 문제(no가 false로 파싱되는 그거)"랑 문자열 따옴표 누락 때문이다. 근데 나만 몰랐던 게, 이걸 상당 부분 해결해주는 kyaml 출력 포맷이 이미 kubectl에 들어와 있었다.KYAML이 뭔데Kubernetes 1.34에서 alpha로 들어온 YAML의 엄격한 서브셋(dialect)이다. 큰 특징 세 가지만 기억하면 된다.모든 문자열은 큰따옴표로 강제 인용된다. no, yes, on, off 같은 값이 실수로 boolean으로 캐스팅되지 않는다.리스트/맵은 flow 스타일([], {}..

EKS Auto Mode가 나온 지 1년 반쯤 됐다. 초기엔 "AWS가 Karpenter 위에 껍데기 하나 씌운 거 아냐?"라는 반응이 많았는데, 올해 초부터 zonal shift, EFA 지원, CloudWatch 로깅까지 붙으면서 이제 진지하게 검토해볼 만한 옵션이 됐다.우리 팀도 얼마 전에 스테이징 클러스터 하나를 Auto Mode로 옮겼다. 이 글은 그 과정에서 정리한 내용이다. "왜 쓰는지" 같은 마케팅 얘기는 최대한 빼고, 실제로 뭘 바꿔야 하고 뭘 조심해야 하는지에 집중한다.뭘 대신 관리해주는지부터Auto Mode를 켜면 AWS가 아래를 관리한다.컴퓨트: Managed Node Group 대신 Karpenter가 노드를 띄운다. AMI는 Bottlerocket 고정, 21일마다 강제 재활용네..

Kubernetes 1.33에서 kube-proxy의 nftables 모드가 GA로 승격됐다. 우리 팀도 iptables 모드에서 nftables 모드로 옮기는 논의를 시작했는데, 막상 "왜 nftables가 iptables보다 빠른가"라는 질문에 답이 잘 안 나왔다. "룰 개수가 줄어드니까 빠르지" 정도로 부족했다. 그래서 KEP-3866과 실제 룰 덤프를 뜯어보며 정리했다. 이 글은 그 결과다.기본적으로 아직 iptables가 kube-proxy의 기본 모드로 남아있고, 명시적으로 --proxy-mode nftables를 줘야 nftables 모드가 켜진다. 커널은 5.13 이상이 필요하다. 이 부분은 공식 블로그에도 명확히 적혀 있다.왜 iptables 모드가 느렸는가먼저 iptables 모드의 구..

지난주에 인프라 비용 리뷰가 있었다. 평소 같으면 EC2랑 NAT Gateway 위주로 훑고 지나갔을 자리인데, 이번엔 AWS Secrets Manager 라인이 유난히 눈에 띄었다. 전월 대비 4배. 절대 금액이 큰 건 아닌데(정확히는 $180 정도), 갑자기 4배가 뛴 게 이상해서 파보다가 며칠 날렸다.결론부터 말하면 범인은 External Secrets Operator였다. 정확히는 ExternalSecret 리소스에 박아둔 refreshInterval: 15s.왜 15초로 뒀었나원래 이 값은 팀에서 붙인 게 아니고, 초창기에 ESO를 도입한 사람이 "빠르게 반영되면 좋겠지" 하고 넣어둔 걸 아무도 안 건드린 채 굴러왔다. 몇 년 지나면서 ExternalSecret 개수도 슬금슬금 늘어서 지금 확인..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. 아니 정확히는 알긴 아는데 실제로 프로덕션에서 써본 적 없는 분들. 나도 얼마 전까지 그러다.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이 핵심이다. 대상 컨테이너의 프로세스 네임스페이..

지난주 화요일 새벽 2시쯤이었나. 알림이 울렸다. 특정 서비스의 P99 레이턴시가 800ms를 넘긴다는 알람이었다. 노드 16대짜리 프로덕션 클러스터에서, 특정 결제 API 파드가 30초 간격으로 8개에서 22개, 다시 10개, 또 25개... 이런 식으로 계속 오르락내리락 하고 있었다.솔직히 처음엔 트래픽 스파이크인 줄 알았다. 근데 그라파나 대시보드를 열어보니 그건 아니었다. RPS는 완만하게 오르는 중이었다. 그런데 파드 수가 미친 듯이 진동하고 있었다. 이게 바로 HPA flapping이다. 이론으로만 알던 걸 새벽 2시에 만나게 되니 정말 반가웠다(반갑지 않았다).처음엔 임계값을 만졌다가장 먼저 시도한 건 CPU targetAverageUtilization을 60에서 75로 올린 것이었다. "임..

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

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

지난주 화요일 오전 10시쯤, 데이터팀 슬랙에 핑이 왔다. "혹시 정산 배치 어제도 안 돈 것 같은데, 뭐 바뀐 거 있어요?" 처음엔 별 생각 없이 로그부터 봤다. 어제, 그저께, 그그저께. 세 번 다 스케줄 시각에 Job이 아예 생성되지 않은 상태였다. Pod가 실패한 게 아니라 Job 자체가 없었다. 이거 뭐지, 하는 마음으로 CronJob describe를 걸었다.문제 상황문제의 CronJob은 매일 새벽 3시에 도는 정산 집계 배치였다. schedule은 0 3 * * *, concurrencyPolicy는 Forbid. 원래 잘 돌던 놈이었는데, 일주일쯤 전에 내가 매니페스트를 손댔다. 이유는 이랬다.기존 설정은 startingDeadlineSeconds가 없었다. 배치가 오래 걸리는 날에 다음..