day-log

이거 모르는 분 꽤 많더라. 어제 팀원이 "distroless 이미지로 바꿨더니 이제 파드 안 들여다볼 수가 없어요"라고 물어봐서, 그 자리에서 알려준 팁. 사실 별 것도 아닌데 정리해두면 다음에 또 물어보는 사람 나오니까.상황distroless 베이스로 만든 컨테이너는 셸도 없고 cat도 없다. 그러니 kubectl exec -it pod -- sh 는 당연히 안 먹힌다. 예전에는 어쩔 수 없이 debug용 이미지 하나 더 만들거나, 파드를 아예 복제해서 이미지만 갈아끼우거나 했었다. 근데 Kubernetes 1.25부터 ephemeral container가 stable 됐고, kubectl debug 로 훨씬 편해졌다.문제는 그냥 kubectl debug pod/foo -it --image=busyb..

Istio ambient mode가 1.24에서 GA된 지 반년 좀 넘었다. 우리 팀은 sidecar 기반으로 운영해온 클러스터가 3개 있고, 신규로 붙일 클러스터가 하나 더 생기면서 자연스럽게 "이번엔 ambient로 갈까?"라는 논의가 시작됐다. 결론부터 말하면 신규 클러스터는 ambient, 기존 3개는 당분간 sidecar 유지다. 왜 그런 판단을 했는지 정리한다.솔직히 처음엔 나도 "ztunnel이 좀 무섭다"는 인상이 있었다. 노드 단위로 프록시가 돌고, 특정 노드가 죽으면 그 노드에 있는 모든 워크로드의 mTLS가 흔들리는 거 아닌가 하는 걱정. 근데 몇 주 파보면서 그건 좀 오해였다.리소스 관점: 이건 진짜 크다sidecar 방식 클러스터에서 Envoy가 잡아먹는 리소스가 얼마나 되는지 실..

Kubernetes에 시크릿을 어떻게 넣을지 팀 내부에서 얘기가 몇 번 오갔다. Sealed Secrets는 GitOps랑 궁합이 좋긴 한데 로테이션이 귀찮고, kubectl create secret은 GitOps 원칙에 어긋난다. 결국 우리 팀은 External Secrets Operator(ESO) + AWS Secrets Manager 조합으로 갔다. 6개월 정도 운영해보니 손이 덜 가서 만족스럽다.이 글은 ESO를 처음 도입할 때 필요한 IRSA 설정, ClusterSecretStore/SecretStore 결정, 그리고 실무에서 자주 걸리는 몇 가지 함정을 정리했다. 최근 v0.10 대에서 문법이 조금씩 바뀐 부분도 반영했다.왜 ESO인가간단히 말하면 AWS Secrets Manager를 원본(..

작년 말부터 팀 내부에서 카나리 배포 도구 얘기가 계속 돌았다. 우리 서비스는 그동안 그냥 Deployment의 RollingUpdate maxSurge/maxUnavailable 조합으로만 배포해왔는데, 최근에 P99 레이턴시가 순간적으로 튀는 케이스가 반복되면서 "이거 그냥 롤링 업데이트로는 안 잡히겠다"는 얘기가 나왔다. 새 버전이 트래픽을 5%만 받아본 뒤 지표 보고 승격시키는 구조로 가야 한다는 데는 합의가 됐는데, 문제는 Argo Rollouts를 쓸지 Flagger를 쓸지였다.한 달 정도 두 도구를 실제로 스테이징에 붙여보고 최근에 결론을 냈다. 이 글은 그 과정에서 정리한 노트다. 둘 중 하나가 절대 옳다는 얘기가 아니라, 어떤 상황에서 어느 쪽이 덜 아픈지 정도의 이야기다.근본적인 접근 ..

지난주 화요일 새벽 3시 12분. 폰이 울렸다. 결제 서비스에서 upstream timeout이 폭발하고 있다는 페이지. 잠결에 노트북 열었을 때 나는 진짜 결제 API가 죽은 줄 알았다.처음 본 지표Grafana 대시보드를 열어보니 결제 API 자체는 멀쩡했다. P99 레이턴시가 평소 80ms에서 4초로 튀었을 뿐, 컨테이너는 다 살아있고 로그에도 별다른 에러가 없었다. 근데 트래픽은 확실히 흐르지 못하고 있었다. 뭔가 이상해서 istio access log를 뒤져보니 upstream 접속 자체가 안 되는 케이스가 계속 찍히고 있었다.노드 자체 리소스는 여유로웠다. CPU 40%, 메모리는 60%대. 그런데 왜?정신이 살짝 들어서 kube-system 네임스페이스를 봤다. CoreDNS 파드 로그가 도..

OTel Collector 배포할 때 처음에는 다들 하나만 띄우고 시작한다. 우리 팀도 그러다. Deployment 하나 만들어서 어플리케이션들이 다 거기로 OTLP 쏘게. 초기엔 잘 돌아간다. 그러다 트래픽 늘고, tail sampling 붙이고, k8s 노드 라벨을 span에 붙이기 시작하면 슬슬 얘가 무너진다.이번 글은 그 다음 단계 — Agent(DaemonSet) + Gateway(Deployment) 두 층 구조로 가는 실전 셋업이다. 최근 릴리스 몇 개(현재 v0.154 기준)에서 바뀐 것들도 같이 정리한다.왜 두 층인가한 층으로 유지하다 보면 결국 이런 문제가 나온다.첫째, 노드 로컬 정보를 붙이기 어렵다. Pod의 IP는 알지만 노드 이름, 커널 버전, 인스턴스 타입 같은 건 어디선가 리..

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

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 옵션이 추가돼서 큰 모노..