day-log

들어가며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..

지난주 화요일 새벽 3시 12분. 폰이 진동했다. PagerDuty다.알림 내용은 단순했다. "checkout-api 50x error rate spike". 처음에는 트래픽 이슈인가 싶었는데, 그래프를 열어보니 패턴이 이상했다. 트래픽은 평소 새벽 수준 그대로인데 5xx만 튀고 있었다. P99 레이턴시도 2초를 넘기고 있었다.결론부터 말하면 Karpenter consolidation 정책을 잘못 건드린 게 원인이었다. WhenEmptyOrUnderutilized를 그대로 두고 consolidateAfter를 30초로 줄였더니, 새벽 트래픽이 잠깐 빠질 때마다 노드가 통째로 갈리면서 stateful한 워크로드들이 같이 흔들렸다.우리가 뭘 바꿨길래며칠 전에 비용 최적화 한답시고 NodePool 설정을 손봤..

External Secrets Operator(ESO)를 처음 도입하면 보통 ExternalSecret 리소스부터 만든다. AWS Secrets Manager나 Vault에 있는 시크릿을 Kubernetes Secret으로 끌어오는 흐름. 이 정도는 어렵지 않다. 그런데 운영을 6개월쯤 하다 보면 다음 두 가지가 슬슬 필요해진다.첫째, 클러스터에서 생성한 시크릿(예: 앱이 동적으로 만든 API 키)을 외부 시크릿 저장소로 밀어 올리고 싶어진다. 둘째, 클러스터 단위로 한 번만 SecretStore를 정의하고 여러 네임스페이스에서 공유하고 싶어진다. 전자가 PushSecret, 후자가 ClusterSecretStore다.이 글은 두 리소스를 실무에 적용할 때 빠지기 쉬운 함정과, 우리 팀에서 정착시킨 패턴..

ArgoCD ApplicationSet은 보통 "여러 클러스터에 같은 앱을 자동으로 배포해주는 도구" 정도로 설명된다. 우리 팀도 처음엔 그렇게 썼다. List generator로 환경 별 파라미터 넘기고, 템플릿에 변수 박아 넣고. 잘 돌아갔다. 문제가 터지기 전까지는.작년 가을, 멀티 리전에 깔린 60개 가까운 Application이 사일런트하게 drift나기 시작했다. ApplicationSet 매니페스트는 그대로인데 일부 Application만 sync 상태가 이상했다. 그때 처음으로 ApplicationSet 컨트롤러 코드를 직접 까봤다. 그러고 보니 이 컨트롤러, 생각보다 단순하지 않다.reconcile 루프의 4단계ApplicationSet 컨트롤러를 한 줄로 요약하면 "Application..

오늘 알게 된 건데, 이거 모르는 분 의외로 많더라. 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/... 다 보인다. 원본 컨테이너는..

오늘 알게 된 건데, 아직도 노드마다 /etc/containerd/config.toml 안에 레지스트리별 auth를 박아두고 운영하는 팀이 생각보다 많다. 우리 팀도 작년까지 그랬다. 사내 Harbor, ECR, GHCR, Docker Hub 미러까지 네 개를 한 파일에 우겨넣다 보니 누가 한 줄만 잘못 건드려도 컨테이너런타임 재시작이 필요했다.근데 containerd 1.5에서 추가되고 1.7 이후로는 사실상 표준이 된 config_path 방식 쓰면 이 짓을 안 해도 된다. 노드 재시작 없이, hot reload로 레지스트리 설정만 바꿀 수 있다.핵심은 디렉터리 구조/etc/containerd/config.toml에는 딱 한 줄만 둔다.[plugins."io.containerd.grpc.v1.cri"..

지난주 수요일 새벽이었다. 새벽 2시쯤 자다가 슬랙 멘션 알림에 깼다. "어제 오후 4시부터 지금까지 로그가 안 보여요." 운영팀 야간 담당자였다. 휴대폰 화면 밝기에 눈이 시리면서도 멘탈은 이미 깨어버린 상태. 우리 클러스터는 노드 80대 규모에 Loki 3.7.x를 미러 모드로 돌리고 있었고, 하루에 1.5TB 정도의 로그를 받는다. 그게 7시간 동안 사라졌다는 얘기다.솔직히 처음엔 좀 의심했다. "진짜 7시간 동안 아무도 모를 수가 있나?" 근데 확인해보니 진짜였다. Grafana에서 last 24h로 보면 오후 4시 지점에서 갑자기 라인이 뚝 끊겨 있었다. 그래프가 그렇게 정직하게 끊긴 건 처음 봤다.ingester pod 상태부터 봤다가장 먼저 한 일은 ingester pod의 상태 확인이었다...

오늘 알게 된 건데, 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..

Pod Identity가 정식으로 나온 지 이제 2년 반쯤 됐다. 그동안 우리 팀에서는 IRSA로 굴러가는 클러스터 4개, Pod Identity로 새로 띄운 클러스터 3개를 운영해봤다. 솔직히 처음에는 "OIDC 트러스트 한 줄 더 박는 게 그렇게 귀찮은 일인가?" 싶었는데, 클러스터가 늘어나면서 생각이 좀 바뀌었다.최근 6월 기준으로 Medium에 다시 비교 글이 올라오길래(이게 또 새로 입사하는 친구들이 가장 많이 찾는 주제다) 우리 팀 내부 결정 기록을 정리해서 공유한다. 결론부터 적으면, 새 워크로드는 Pod Identity, 단 Fargate에 띄울 거면 IRSA. 그리고 둘은 같은 클러스터에서 공존시켜도 별 문제 없다.트러스트 정책의 무게IRSA의 진짜 비용은 IAM role 자체가 아니라 ..