day-log

클러스터 트래픽이 늘 때 우리 팀이 가장 먼저 듣는 얘기는 보통 이거다. "노드 부족한 거 아니에요?" 근데 막상 들여다보면 노드는 멀쩡한데 DNS 쪽에서 병목이 생긴 경우가 절반쯤 된다. 특히 EKS에서 default 설정 그대로 굴리고 있으면 CoreDNS는 2개 파드로 묶여서 같은 AZ에 떨어져 있는 일도 흔하다.이 글은 EKS CoreDNS를 운영하면서 트래픽이 늘기 시작했을 때 가장 먼저 점검해야 하는 3가지를 정리한 가이드다. 정말로 노드를 더 붙이기 전에, DNS 레이어부터 들여다보자는 얘기.1. CoreDNS 파드 분산 — topologySpreadConstraints이게 의외로 묻혀 있는 변화인데, EKS의 CoreDNS add-on이 v1.9.3-eksbuild.11 그리고 v1.10...

지난주 목요일 새벽 2시 47분. 알림 톡이 울려서 핸드폰을 봤더니 ArgoCD에서 동시에 11개 애플리케이션의 sync가 Degraded로 떨어졌다는 메시지였다. 처음엔 또 누군가가 이미지 태그를 잘못 박았겠지 싶었다. 새벽에 배포 멘션이 와있던 팀이 두 팀이었고, 자동 sync wave가 한꺼번에 돌고 있었으니까.그런데 콘솔을 열어보니 좀 이상했다. Pod 이벤트에 ImagePullBackOff가 줄줄이 떠있는데, 에러 메시지가 익숙하지 않았다.Failed to pull image ".dkr.ecr.ap-northeast-2.amazonaws.com/svc-foo:v1.42.0":rpc error: code = Unknown desc = failed to pull and unpack image:fai..

작년 말 GA 된 EKS Auto Mode를 우리 팀도 새 클러스터에 적용했다. 몇 주 굴려보고 운영에서 부딪힌 부분들이 꽤 있어서, 도입을 고민하는 분들에게 도움이 될 만한 실무 가이드를 정리했다. 마케팅 문구가 아닌 "현실에서 뭐가 좋고 뭐가 아픈가" 관점이다.처음 듣는 분을 위해 간단히 설명하면, EKS Auto Mode는 컴퓨트(노드), 네트워킹(VPC CNI/로드밸런서), 스토리지(EBS CSI), Karpenter, Pod Identity Agent 같은 클러스터 구성요소를 AWS가 관리형으로 묶어서 제공하는 모드다. 우리가 직접 Helm chart를 깔고 IRSA를 매핑하던 작업이 거의 사라진다. 대신 자유도는 줄어든다.1. 사전 준비: 우리 클러스터가 적합한가도입 전에 다음 체크리스트를 먼..

지난주 화요일 새벽 4시쯤 전화가 울렸다. 메시지 큐 컨슈머 한 대가 S3 PutObject에서 ExpiredTokenException 을 계속 뱉고 있다고. 멘탈이 살짝 나갔다. IRSA로 깔끔하게 인증 붙여놨다고 믿고 있던 워크로드였는데.결론부터 말하면 ServiceAccount projected token이 만료된 뒤 kubelet이 새 토큰을 디스크에 갈아 끼웠는데, 우리 컨슈머 안에 들어있던 SDK는 이걸 다시 읽지 않고 죽은 토큰을 1년 가까이 메모리에 들고 있었다. 정확히는 캐시가 너무 충실했던 게 문제였다.우리가 잘못 알고 있던 부분Kubernetes 1.22 이후로 BoundServiceAccountTokenVolume 이 GA되면서 Pod이 마운트하는 토큰은 모두 projected 형태..

EKS를 몇 년째 운영하다 보면 한 번쯤은 이런 순간이 온다. 누군가 kubectl delete ns prod-something을 잘못 쳤거나, GitOps 동기화가 꼬여서 ConfigMap이 통째로 날아갔거나. 우리 팀에서는 작년에 한 번 비슷한 사고가 났다. ArgoCD가 잘못된 브랜치를 source로 잡아서 네임스페이스 하나를 prune 해버린 거다. 다행히 ETCD 덤프가 있었지만, 복구하는 데 반나절을 썼다.그 사건 이후로 Velero를 정식으로 도입했다. 이번 글은 EKS 환경에서 Velero를 0에서부터 세팅하고 운영하는 실전 가이드다. 공식 문서에 나오는 기본 설치 말고, 실제 운영 들어갔을 때 부딪히는 부분 위주로 적었다.왜 Velero인가EKS 백업 옵션은 몇 가지가 있다. AWS Ba..

ALB의 gRPC 지원은 꽤 알려져 있다. Target group protocol version을 GRPC로 바꾸고, health check 경로를 /grpc.health.v1.Health/Check로 잡으면 끝. 근데 사내에서 ALB를 안 쓰고 NLB로 가야 하는 상황이 생긴다. 클라이언트가 mTLS를 끝단까지 가져가야 하거나, ALB로는 못 받는 별난 트래픽이 섞여 있거나, 비용 문제거나.이 글은 그 NLB + gRPC 조합에서 우리 팀이 며칠 헤맨 얘기를 정리한 거다. 결론부터 말하면 ALPN 정책 한 줄이 빠지면 TLS handshake는 되는데 gRPC만 안 된다. 로그도 별 게 안 남는다.NLB가 gRPC를 "지원"한다는 말의 의미NLB는 L4다. HTTP/2 프레임을 해석하지 않는다. 그래서..

월요일 아침에 출근하니 재무팀에서 슬랙이 와있었다. "지난달 AWS 비용 한 번만 확인 부탁드려요." 평소엔 무시할 만한 변동이었는데 이번엔 NAT Gateway 라인 하나만 전월 대비 3.2배가 찍혀 있었다. 다른 항목은 거의 그대로였다. 보자마자 멘탈이 살짝 흔들렸다. 우리 팀은 분기 비용 가이드라인이 있어서 한 항목이 갑자기 튀면 그게 곧 회고 거리다.여기에 진단부터 해결까지 일주일 동안 삽질한 기록을 남긴다. 결론부터 말하면 범인은 단순했고, 우리가 그동안 NAT Gateway 트래픽 구성을 너무 안 들여다본 게 진짜 문제였다.첫 번째 가설: 누가 풀데이터를 빨아 가나처음엔 누군가 새 워크로드 띄우면서 외부 데이터셋이라도 받아오는 줄 알았다. 그런데 워크로드 추가된 거 없었다. 노드 수도 그대로(..

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

작년에 신규 EKS 클러스터를 띄우면서 한 가지 결정을 미뤘다. 워크로드 IAM을 IRSA로 갈지 Pod Identity로 갈지. 그때는 "어차피 둘 다 지원되니까 나중에 보자"고 미뤘는데, 올해 들어 클러스터가 4개로 늘어나면서 더는 미룰 수 없는 상태가 됐다.지난 두 달 동안 stage 환경 전체를 Pod Identity로 옮겨보고, prod의 일부 워크로드도 마이그레이션을 시작했다. 결론부터 말하면 우리 팀은 신규 워크로드는 전부 Pod Identity로, 기존 IRSA는 천천히 전환 중이다. 왜 그런 결정을 했는지, 어떤 케이스에서는 IRSA가 더 나았는지 정리해본다.비교의 배경: 우리는 어떤 환경이었나먼저 우리 팀 환경을 짧게 적어둔다. 비교 결과는 환경에 따라 다르게 읽힐 수 있어서다.EKS ..

처음에 기대했던 것작년 가을, 우리 팀은 VPC를 5개 운영 중이었다. 메인 워크로드 VPC, 데이터 분석 VPC, 사내 도구 VPC, 보안 격리 VPC, 그리고 신규 사업 VPC. 각 VPC끼리 서비스를 호출해야 하는 케이스가 슬슬 늘어나면서 PrivateLink와 Transit Gateway가 거미줄처럼 얽혀 있었다. 어떤 서비스가 어디에 노출돼 있는지 추적하는 게 자체로 일이었다. 이 시점에 VPC Lattice를 도입하기로 결정했고, 지금은 약 6개월째 운영 중이다. 잘한 결정인지 묻는다면 솔직히 반반이다.이 글은 칭찬도 비판도 섞인 후기다. 도입을 검토 중인 분이라면 좀 도움이 될 것 같다.마케팅 페이지만 보면 정말 끌린다. VPC끼리 서비스를 노출하는데 NLB나 PrivateLink Endpo..