푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 71편 · 1 / 8 페이지)
-
쿠버네티스 운영 함정 4가지 — 하룻밤 디버깅 노트
5/15 저녁 텔레그램 알림으로 시작된 한 통의 메시지 — “⚠️ Pod 132개 중 4개 CrashLoopBackOff”. 이 한 줄에서 출발해 자정 넘어까지 4가지 서로 다른 종류의 함정에 빠졌다 빠져나왔다. 각각의 함정이 K3s/K8s 운영하는 사람이라면 한 번쯤은 만나는 패턴이라 정리해둔다.
-
쿠버네티스 × ELK — 둘이 같이 굴러야 하는 이유, 실제 운영 시나리오, 기대 효과
쿠버네티스에 ELK 를 붙이는 건 단순히 “로그 좀 보기 좋게” 가 아닙니다. 컨테이너 워크로드의 운영 구조 자체 가 로그 집계 시스템을 필수 부품으로 요구합니다. 어제 5-노드 K3s 홈랩에 ECK 기반 ELK 스택을 깐 후 일주일도 안 됐는데, 이미 운영 패턴이 달라진 게 체감됩니다. 둘의 상관관계, 실 운영 시나리오, 그리고 기대 효과를 정리합니다.
-
Jenkins vs GitHub Actions — Docker 빌드부터 Kubernetes 배포까지 자동화 실전 비교
CI/CD 도구를 처음 고르는 분, 또는 Jenkins 만 알다가 GitHub Actions 로 넘어가려는 분, 반대로 Actions 만 써본 분이 사내 Jenkins 와 마주쳤을 때 — 결국 같은 질문에 부딪힙니다. “내 코드 push 가 어떻게 컨테이너가 되고, 어떻게 Pod 으로 돌아가나?”
-
청각재활 시스템 관리 자동화 완성 — 면접관 1-클릭부터 ELK 알람까지 하루 만에
ASAT (Auditive Spatial Adaptive Training — 청각재활 훈련 시스템) 은 이명 환자와 청각 재활 대상자를 위한 연구용 웹 애플리케이션입니다. Java 25 + Spring Boot 4 + Next.js 16 스택에 PostgreSQL/Redis/MinIO 보조 인프라, 5-노드 K3s 홈랩 위에서 GitOps 로 운영합니다. 어제 오후부터 오늘 새벽까지 하루 안에 관리·운영 자동화 사이클 전체 를 완성했고, 그 기록을 정리합니다.
-
쿠버네티스 7일차 — 종합 프로젝트: 작은 SaaS 운영
드디어 7일차. 지금까지 배운 모든 것을 한 프로젝트로 묶습니다. 풀스택 SaaS 한 개를 쿠버네티스 위에 깔고, 무중단 배포 + 모니터링 + 보안까지 한 흐름으로.
-
ELK 를 5-노드 K3s 홈랩에 깐다 — hot/warm/cold 3-노드 ES + Fluent Bit + Telegram 알람
5 노드 K3s 홈랩에 운영중인 24+ 네임스페이스의 컨테이너 로그를 한 곳에 모아 검색·분석·알람까지 받을 수 있도록 ELK 스택을 통째로 GitOps 로 배포한 기록입니다. Loki 가 깔려있다고 메모리에 적혀있었는데 막상 들어가 보니 클러스터 스코프 로그 집계가 없었고, “메트릭은 있지만 로그가 없는” 관측 공백을 ELK 로 채웠습니다.
-
K3s vs K8s — 같은 것, 다른 것, 그리고 5노드 온프레미스에서 K3s 를 고른 이유
“K3s 가 K8s 의 경량 버전이라던데 실제로 뭐가 다른가?” 라는 질문은 K8s 를 처음 도입할 때 꼭 한 번 마주칩니다. 결론부터 말하면 K3s 는 K8s 의 fork 가 아니라 K8s 100% 호환 distribution 입니다. 같은 API, 같은 manifest, 같은 kubectl. 다른 건 패키징 / 의존성 / 기본 컴포넌트 선택. 본인이 5노드 온프레미스 클러스터에 K3s 를 고른 이유는 그 차이가 정확히 본인 시나리오에 맞아떨어졌기 때문입니다.
-
K8s 가 의도적으로 비워둔 자리 — Secret 관리 3rd-party 생태계 정리
Kubernetes 의
Secret리소스를 처음 만났을 때 “이게 secret 관리의 답” 이라고 생각했습니다. base64 디코드 한 줄로 모든 게 평문이라는 걸 알기 전까진. 이 글은 K8s 가 네이티브로 무엇을 제공하고 무엇을 의도적으로 비워뒀는지, 그리고 그 빈자리를 채우는 3rd-party 들이 어떤 trade-off 를 제시하는지 정리한 글입니다. -
K3s self-heal 실증 — 운영 중인 클러스터의 restart 카운터를 직접 보다
K3s 도입할 때 가장 먼저 학습한 개념이 “Pod 가 죽으면 자동 재시작 / 노드가 죽으면 자동 재배치” 였습니다. 그런데 정작 운영하면서 “이게 실제로 발동된 적이 있나?” 를 직접 확인한 적이 없었습니다. 5 노드 K3s 클러스터에 23일째 + (가장 짧은 노드 3일째) 워크로드 118 개를 굴리고 있는 시점, restart 카운터 스냅샷을 떠보니 K3s 가 조용히 일을 하고 있었다는 증거가 곳곳에 남아 있었습니다.
-
쿠버네티스 6일차 — 보안 + RBAC + NetworkPolicy
운영하다 보면 만나는 가장 무서운 문장: