day-log

지난 4월쯤이었다. 슬랙에 누가 링크 하나를 던졌다. ingress-nginx 메인테이너들이 더 이상 best-effort 유지보수도 못한다고 공지를 올렸다는 거였다. 처음에는 "에이, 그래도 굴러는 가겠지" 했다. 우리 클러스터 8개에 다 깔려 있고, ingress 리소스만 200개가 넘는데. 근데 그 주에 보안팀에서 CVE 패치 일정을 묻는 메일이 왔고, 그제서야 정신이 들었다. 사실상 EOL 된 컨트롤러를 들고 가는 건 시간 문제일 뿐이라는 걸.그래서 Gateway API로 가기로 했다. 5월 초부터 6월 말까지, 약 두 달 동안 삽질한 이야기를 적어둔다. 누군가는 비슷한 상황일 테니까.처음에 안일하게 생각했던 것Gateway API가 v1.5까지 나왔고 standard로 거의 다 올라왔다는 글을 ..

쓰던 Velero 백업 파이프라인이 restic 기반이면 슬슬 갈아탈 때가 됐다. v1.15에서 restic이 deprecated로 마킹된 게 작년 말이고, v1.16에서는 새로운 file system backup의 기본 업로더가 Kopia다. 거기다 PV 백업 흐름 자체도 CSI snapshot data movement 쪽으로 무게추가 옮겨가는 중이라, 운영 환경을 그대로 두면 1~2년 안에 업그레이드 경로에서 발이 묶일 수 있다.이 글은 EKS 클러스터에서 돌아가는 restic 기반 Velero를 Kopia + CSI data mover 조합으로 옮기는 실전 절차다. 우리 팀이 노드 50대짜리 프로덕션 클러스터에서 한 달에 걸쳐 진행한 작업을 정리한 거라, 가능한 단계마다 함정도 같이 적었다.왜 지금..

오늘 후배가 kubectl get events --sort-by='.metadata.creationTimestamp' -n prod 를 또 한참 두드리고 있길래 옆에서 한마디 했다. "그거 그냥 kubectl events -n prod 하면 돼요." 진짜 표정이 굳더라. 의외로 모르는 분 꽤 많아서 짧게 정리한다.kubectl events, 그게 뭔데kubectl events 는 events.k8s.io/v1 API 가 v1.19에서 들어오면서 별도로 추가된 명령어다. 처음에는 alpha였는데 이제는 우리가 운영하는 1.32 정도 클러스터에서는 그냥 당연히 쓸 수 있다. kubectl get events 가 events.k8s.io/v1 와 core/v1 둘 다 보여주는 만능 명령이라면, kubectl ..

지난주 화요일 새벽 2시 47분, 슬랙 알림이 무더기로 떴다. P99 레이턴시 그래프가 평소 80ms 근처에서 600ms 위로 튕겨 올라가더니, API 5xx 비율이 0.1%에서 4%까지 치솟았다. 결제 트래픽이 한창 몰리는 시간대였다.처음엔 또 어디서 메모리가 새는 건가 싶었다. 근데 컨테이너 메모리는 멀쩡했고, CPU도 평소 수준이었다. 그러다 어떤 마이크로서비스 로그를 까보니 거의 모든 요청에 dial tcp: lookup api.stripe.com on 10.96.0.10:53: i/o timeout 같은 줄이 박혀 있었다. DNS였다.첫 의심: CoreDNS 파드가 죽었나당연한 수순으로 kubectl -n kube-system get pods -l k8s-app=kube-dns 부터 쳐봤다. 다..

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

들어가며3년 전쯤만 해도 "CNI는 그냥 Calico 깔자"가 답이었다. 안정적이고 자료 많고 문제 생기면 iptables 룰 뜯어보면 됐다. 그런데 최근 1년 사이에 분위기가 좀 바뀌었다. GKE Dataplane V2가 Cilium 기반이고, AKS도 "Azure CNI Powered by Cilium"을 권장 옵션으로 밀고 있다. EKS는 기본은 여전히 AWS VPC CNI지만 Cilium을 얹는 사례가 눈에 띄게 늘었다.우리 팀도 작년 하반기에 새 클러스터 두 개를 띄우면서 Cilium으로 갈아탔다. 기존 클러스터는 Calico를 계속 쓰고 있어서, 1년 정도 두 개를 같이 운영하면서 느낀 걸 정리해본다. 결론부터 말하면 "신규는 Cilium, 기존은 굳이 안 옮긴다"이긴 한데, 이게 모든 팀에 ..

오늘 알게 된 건데, 의외로 모르는 분 꽤 많더라. Pod의 graceful shutdown 늘리려고 PreStop hook에 sleep 박는 그 패턴 말이다. 우리도 한참 그렇게 썼는데, 사실 1.29부터는 그럴 필요가 없어졌다.기존 방식의 함정전형적인 zero-downtime 배포 트릭이다. Service에서 endpoint가 빠지는 동안에도 잠깐 트래픽이 계속 들어오니까, SIGTERM 받기 전에 몇 초 버텨주자는 거다.lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 10"]근데 이거 distroless 이미지 쓰는 순간 깨진다. sh도 없고 sleep도 없으니까. 우리 팀은 작년에 보안팀이 모든 이미지를 distroless..

오늘 알게 된 건데, 이거 모르는 분 의외로 많더라. kubectl debug 쓸 때 --copy-to 옵션 말이다.distroless 컨테이너 디버깅 글들 검색하면 거의 다 --copy-to 예제가 나온다. 근데 운영 파드를 진짜로 디버깅해본 분들은 알겠지만, 이게 좀 위험하다.두 가지 모드, 뭐가 다른가kubectl debug는 크게 두 가지로 쓸 수 있다.1. ephemeral container 주입 (기본)kubectl debug -it my-pod \ --image=busybox:1.36 \ --target=app원본 파드에 임시 컨테이너를 하나 더 끼워 넣는다. PID/network namespace를 공유하니까 ps, netstat, /proc/$PID/... 다 보인다. 원본 컨테이너는..

오늘 알게 된 건데, 1.34부터 kuberc가 beta 승격됐다. 이게 뭐냐면, kubectl 전용 사용자 설정 파일이다. 별칭하고 기본 옵션을 따로 관리할 수 있게 해준다.솔직히 우리 팀은 ~/.zshrc나 ~/.bashrc에 alias k=kubectl, alias kgp='kubectl get pods' 같은 걸 한 30줄씩 박아두고 살았는데, 이거 좀 지저분하다. 새 노트북 받을 때마다 dotfiles 복사하고, 팀 신입한테 "이거 깔아라" 시키는 것도 일이다.kuberc는 그 자리를 대체할 수 있는 공식 방법이다. kubectl 자체가 읽어서 처리한다.어떻게 생겼나~/.kube/kuberc 한 파일이다. 위치만 약속하면 끝.apiVersion: kubectl.config.k8s.io/v1bet..

기존 Gateway 모델의 한계올해 2월에 Gateway API v1.5가 나왔고, ListenerSet이 드디어 Standard 채널로 올라왔다. 우리 팀에서는 v1.4 시절부터 Experimental로 깔짝거리며 써봤는데, 이제 GA니까 본격적으로 도입했다. 막상 옮겨보니 단순한 기능 추가가 아니라 멀티팀 환경에서 Gateway 관리 모델 자체가 바뀌는 변화였다.이 글은 ListenerSet이 뭔지, 왜 필요한지, 그리고 기존 Gateway에서 어떻게 갈아끼는지 정리한 가이드다. Istio나 Envoy Gateway 같은 구현체에 따라 세부 동작이 다르긴 한데, 기본 개념은 동일하다.Gateway API에서 Gateway 리소스 하나는 보통 플랫폼 팀이 소유한다. Listener를 여러 개 박아두고,..