개발일기장

Github Actions Runner Controller(ARC) 학습 정리Github Action Runner Controller(ARC)를 운영하기 위해 공식 문서를 읽으면서 학습한 내용을 정리해본다.https://github.com/actions/actions-runner-controllerhttps://docs.github.com/en/enterprise-server@3.17/actions/concepts/runners/actions-runner-controller1. ARC란 무엇인가?Action Runner Controller(ARC)는 GitHub Actions의 Self Hosted Runner를 Kubernetes 환경에서 관리하기 위한 Controller이다.기존 Self Hosted..

회사에서 인프라 비용을 절감해야 하는 임무가 생겼다. 그 당시 했던 일부 작업들을 간단히 남겨놓는다. 낭비되는 비용도 많았고, 이외 방안들은 인프라 안정성과 트레이드오프가 있었다. 읽기 전 참고로 알아두면 좋을 것 같다.절감 대상 찾는 방법감으로 줄이면 효과가 없다. Cost Explorer에서 서비스별, 태그별로 쪼개서 어디서 나오는지 먼저 확인했다.크게 세 가지가 눈에 띄었다.Data Transfer 비용. 같은 리전 안에서도 AZ가 다르면 과금이 발생한다. VPC Flow Logs로 트래픽 흐름을 보니 Cross-AZ 비용이 생각보다 컸다. Dev 클러스터가 굳이 Multi-AZ일 이유가 없었다.안 쓰는 EBS. 볼륨 크기를 크게 잡아두고 실제로는 5%만 쓰고 있는 경우가 여럿 있었다. AWS는 E..

리눅스 위에서 컨테이너를 올려서 k8s 를 사용하지만 근본적으로는 이게 어떻게 동작하는지 알아볼 필요가 있다고 생각한다그래서 추천받은 영상을 보고 끄적거린 강의노트를 토대로 AI와 작성해보았다. (영상이 너무 훌룡해서 2시간 반이 굉장히 짧게 느껴질정도였다)https://www.youtube.com/watch?v=lVtgqmjv4BQ 1. 파일시스템 격리 — chroot의 한계chroot: 경로를 "속이는" 것가장 원시적인 격리 방법은 chroot다. 특정 디렉토리를 / 처럼 보이게 속이는 것이다.[호스트 실제 파일시스템]/├── bin/├── etc/├── home/└── container_root/ ← chroot로 이 디렉토리를 /로 속임 ├── bin/ └── etc/근데 c..

"노드 그룹 하나 새로 만들면 되겠지" 하고 가볍게 시작한 작업이, 전체 서비스 504 에러로 이어졌습니다. 이 글은 그 삽질의 기록이자, EKS를 운영한다면 반드시 알아야 할 IMDS Hop Limit 이슈에 대한 정리입니다. 무슨 작업을 하려고 했나EKS 클러스터에서 기존 Node Group을 새 인스턴스 타입으로 교체하려고 했습니다. 단순한 작업이었습니다. 새 Node Group을 만들고, 파드들이 옮겨가면, 기존 노드를 드레인하고 삭제하면 끝.그래서 EKS API로 새 Node Group를 생성했는데, Launch Template은 따로 지정하지 않았습니다. "EKS가 알아서 잘 해주겠지"라는 안일한 생각이었죠.Phase 1: 장애 발생새 노드가 Ready 상태가 되길래 잘 된 줄 알았습니다. 하..

TL;DR동일한 EC2 인스턴스에서 CloudWatch CPU 0%, Grafana CPU 100%가 동시에 관측되었다.이는 오류가 아니라 측정 레이어의 차이 때문이다CloudWatch: 하이퍼바이저(Nitro)가 외부에서 vCPU 실행 시간 기준으로 측정 I/O 대기는 CPU 사용으로 집계하지 않음 Grafana(Linux Top): 인스턴스 내부 /proc/stat 기반 iowait도 non-idle(= busy)로 포함 문제 제기최근 특정 서비스에서 장애가 발생했다.CPU 기반으로 동작하는 AutoScaling이 기대와 다르게 반응했고, 원인을 추적하는 과정에서 이상한 지표가 관측됐다. 다만, 동일한 시간대에Amazon CloudWatch에서는 해당 EC2 CPU는 거의 0%(NoData)였다.G..

8월(상반기 회고에서도 좀 썼었지만.) 해커톤을 나갔었다.해커톤을 나가본적이 없었는데 드디어 나가봤다1박2일동안 거의 죽을 맛이였지만 스마게가 워낙 밥도 잘 챙겨줘서..정말 먹고 개발하고 좋았다AI 잘 몰랐는데 이때 RAG기반 챗봇 만들어서 대충 LLM AI와 약간 친해진것 같아서 그거 하나로 의의가 있었다. 사실 아이디어 자체는 특이하지 않았기떄문에 우승은 못했다. 다만 다른 팀 아이디어 구경하는게 진짜 재밌었고나는 웹 기반 개발만해서 웹 세상에 갇혀있었는데 언리얼 엔진을 이용하거나, 카메라를 이용하거나, 아두이노, 맥 앱 등 다른 세상을 볼 수 있어서 한대 맞은것 같은데 기분이 들었다. 우물 안 개구리가 이런 기분일까? 9월 혼자 운영하던 SRE(라고 하기엔 애매하지만 그라파나 운영) 8월에 SRE..

2025.12.21 - [k8s] - k8s에서 Secret 관리는 어떻게 하는게 좋을까? : External Secret Operator 선택기 지난번 기고했던 글에서 ESO를 쓰기로 했다.어떻게 쓰는지 기술적으로 정리해보자 TL;DRSecrets Manager에 비밀 생성IRSA Role + ServiceAccount 연결Helm Chart로 ESO 설치(ArgoCD로 관리)ClusterSecretStore / SecretStore 생성ExternalSecret / ClusterExternalSecret 생성앱은 만들어진 Kubernetes Secret만 마운트해서 사용 전체 아키텍처 흐름 A) 멀티 네임스페이스 구조 (ClusterSecretStore 기반)클러스터 전체에서 공통으로 Secrets..

Secret 관리 선택External Secret Operator선택요구사항Kubernetes Secret은 기본적으로 base64 인코딩된 값으로 etcd에 저장되기 때문에 암호화 설정(encryption at rest)이 없을 경우 보안적 노출 위험이 존재한다.기존에는 Sealed Secret을 이용해 GitOps 기반으로 암호화된 Secret을 관리했지만, Sealed Secret 생성 과정에서 반드시 필요한 ‘raw Secret(평문)’을 어디서 안전하게 생성·보관·회수할지에 대한 문제가 명확히 해결되지 않았다.Secret을 저장하는 위치 또한 중앙화가 필요하며, 인증·권한·감사·회전(rotation) 등을 포함한 “보안 체계”가 함께 존재해야 한다.AWS Secret Manager를 선택함우리 ..

Hub & Spoke ArgoCD 구성 가이드여러 AWS 계정 / 여러 EKS 클러스터를 중앙에서 관리하는 CD 과정인, Hub & Spoke ArgoCD 구조를 구축하기 위한 전체 과정을 설명한다.Hub: SRE 전용 EKS (중앙 ArgoCD 운영)Spoke: 실제 서비스가 배포되는 EKS들Hub ArgoCD는 IAM Role AssumeRole(크로스 계정) 방식으로 Spoke를 제어한다1. Hub 클러스터 설정1.1 ArgoCD 설치 (Helm)Hub EKS에는 ArgoCD를 Helm chart로 설치한다.🔗 values 파일 [링크]📌 설치 명령어helm upgrade argocd argo/argo-cd \\ -n argocd \\ -f argocd.yaml \\ --version=8...

2025.10.24 - [k8s] - Tempo Ingester Pod OOM 이슈 해결기 : CPU Throttling Tempo Ingester Pod OOM 이슈 해결기 : CPU Throttling최근 tempo-ingester의 pod가 out of memory 상태에 빠졌었다.그 당시 메모리가 크게 튀었다.단순히 메모리가 부족한가? 싶어서 메모리를 늘렸지만 문제는 여전히 지속되었다.원인을 분석하던 중, cpu 에sienna1022.tistory.com pod의 limit은 linux의 cgroup을 이용하여 제약이 걸리는걸 알았는데, 과연 사용자가 manifest로 k8s에 정의한게 어떻게 리눅스까지 적용되는지 궁금해서 코드를 다 까보며 딥다이브 하였다. 여정기manifest 정의 → kub..