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 모드의 구..

Istio Ambient mode가 1.24에서 GA 된 게 벌써 1년 반 전이다. 우리 팀도 사이드카 지옥에서 벗어나려고 작년 말부터 조금씩 옮겨왔는데, 처음에는 그냥 "사이드카가 사라진 서비스 메시" 정도로 이해하고 시작했다. 그러다 프로덕션에서 이상한 이슈 몇 개 만나면서 결국 ztunnel 내부를 뜯어보게 됐다. 이 글은 그 과정에서 정리한 내용이다.한 가지 미리 얘기하자면, 이 글은 "Ambient가 좋다/나쁘다" 얘기는 아니다. 내부 동작이 어떻게 되어 있는지, 그리고 왜 그렇게 설계됐는지에 대한 노트에 가깝다.ztunnel은 왜 노드마다 하나만 뜨는가Ambient mode의 첫 번째 특징은 데이터 플레인이 두 층으로 쪼개져 있다는 것이다. L4(TCP, mTLS)는 ztunnel이, L7(H..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. topologySpreadConstraints에서 whenUnsatisfiable: ScheduleAnyway로 설정해두고 "AZ 골고루 퍼지겠지" 안심하다가 뒤통수 맞기 딱 좋다.우리 팀에서도 이번 주에 비슷한 일이 있었다. 3-AZ EKS에 6개 replica를 배포하는데 특정 AZ에 4개가 몰려서 나머지 두 AZ는 각각 1개씩. 스펙에 maxSkew: 1, whenUnsatisfiable: ScheduleAnyway가 분명히 박혀 있는데도 그랬다.왜 이런 일이 생기나ScheduleAnyway는 이름 그대로 소프트 제약이다. 스케줄러가 최선을 다해서 스프레드를 지키려 하지만, 다른 스코어링(리소스 여유, 이미지 로컬리티, 노드 셀렉터 우선순위 등)이 ..

배경: 기본 동작이 왜 종종 실무에 안 맞는가오늘 다룰 건 하나다. HorizontalPodAutoscaler(HPA) behavior 필드. 이거 모르는 사람 의외로 많아서 짧게 정리해둔다.우리 팀 클러스터에서는 오전 10시부터 트래픽이 슬금슬금 올라오는 서비스가 하나 있다. 점심 직후에 잠깐 훅 떨어졌다가 오후에 다시 올라온다. 그런데 HPA를 별다른 설정 없이 켜두면 12시 30분쯤 replica가 4→2로 급격히 떨어졌다가, 13시가 되면 또 CPU가 튀면서 부랴부랴 다시 올린다. 이게 하루에 두세 번씩 반복되니 pod 재기동이 잦아지고 P99가 흔들린다.원인은 기본 stabilization window. 지금 HPA v2 기본값은 scaleDown이 300초, scaleUp이 0초다. 5분짜리 ..

EKS 쓰다 보면 언젠가 한 번은 부딪히는 질문. 파드가 AWS 리소스에 접근할 때 IAM을 어떻게 붙일 것인가. 예전에는 답이 하나였다. IRSA. 근데 몇 년 전 Pod Identity가 나오고, 올해 초 우리 팀은 결국 이걸로 옮겼다. 왜 옮겼는지, 뭐가 좋고 뭐가 애매한지 정리해본다.IRSA는 그동안 잘 써왔는데솔직히 IRSA에 큰 불만은 없었다. OIDC provider 만들어놓고, ServiceAccount에 어노테이션 붙이고, IAM 역할의 trust policy에 그 SA를 넣어주면 끝. 몇 년째 잘 굴러왔다.문제는 클러스터가 늘어나면서 시작됐다. 우리 팀은 dev/staging/prod로 클러스터가 세 개, 여기에 데이터 팀이 요청한 별도 클러스터 하나가 더 붙어서 총 네 개다. 각 클러..

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

오늘 알게 된 건데, 의외로 모르는 분 꽤 있더라. kubectl 1.33부터 들어온 .kuberc 얘기.팀 단위로 kubeconfig를 공유해 본 사람은 다 한 번씩 짜증 났을 거다. 누군가 current-context를 prod로 바꿔놓고 그대로 푸시한 다음, 다른 사람이 dev에서 작업하다 prod 클러스터에 명령 날리는 그런 사고. 또 한 명은 alias k=kubectl을 셸에 박아두고, 다른 한 명은 kubectl get po -o wide를 매일 손가락으로 치고 있고. 개인 취향과 공용 자격증명이 같은 파일에 섞여 있는 게 문제다..kuberc(아직 alpha) 가 그 부분을 분리해 준다. ~/.kube/config에는 클러스터/사용자/컨텍스트만 두고, 내 개인 alias나 기본 플래그는 ~..

작년 이맘때쯤 progressive delivery를 본격적으로 도입하기로 결정했다. 그 때만 해도 우리 팀은 "둘 다 비슷한 거 아니야?"라는 분위기였고, 사실 데모만 보면 정말 비슷해 보였다. 캐너리, 블루그린, 메트릭 기반 자동 promotion. 똑같은 단어들이 양쪽 문서에 다 나온다.그래서 우리는 좀 무책임한 결정을 했다. 둘 다 써보기로 했다. 일부 서비스는 Flagger, 일부는 Argo Rollouts. 1년이 지난 지금, 한쪽으로 통일하기로 했고, 그 과정에서 알게 된 차이들을 정리해 본다.시작 환경우리 환경을 먼저 짧게 적는다. 비교는 결국 환경 의존적이라서.EKS 1.32 클러스터 두 대 (스테이지/프로덕션)서비스 메시는 Istio (ambient 아니고 sidecar)GitOps는 ..

Kustomize components, 모르는 분 많더라오늘 동료 PR 리뷰하다가 발견한 건데, base/overlay만 쓰고 components를 안 쓰는 분이 의외로 많다. Kustomize 공식 문서에도 들어있고 1.21 이후로는 stable인데 잘 안 알려진 듯. 짧게 정리해둔다.어떤 상황에서 쓰면 좋냐흔한 패턴 — base 하나에 overlay가 dev / staging / prod 이렇게 있다고 치자. 어느 날 누가 "prod랑 staging에는 sidecar 하나 붙여줘"라고 한다. 그러면 보통은 두 overlay에 같은 patch를 복붙한다. 며칠 뒤 또 다른 feature가 prod/staging 공통으로 들어오면? 또 복붙.이게 쌓이다 보면 overlay 디렉터리가 patch 파일 모음..