푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1666편 · 161 / 167 페이지)
-
쿠버네티스 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
운영하다 보면 만나는 가장 무서운 문장:
-
Docker Compose vs Kubernetes + ArgoCD GitOps — 30 개 서비스 운영 비교
작년까지 docker-compose 로 30 개 서비스를 운영하다가, 두 달 전 K3s + ArgoCD GitOps 로 전환했습니다. 오늘 새벽 한 시간 동안 settlement 앱의 Flyway 마이그레이션 버그를 디버깅하면서, “docker-compose 시절이었다면 어떻게 했을까” 와 “지금은 어떻게 했는가” 가 너무 선명하게 대조돼서 글로 남깁니다.
-
라이브 patch → Git 영구화 — selfHeal 안전화 운영 패턴 (settlement-staging 11 env 사례)
장애가 났을 때
kubectl set env/kubectl patch/kubectl edit으로 즉시 막는 게 운영의 본능입니다. 그런데 GitOps 체제에서 selfHeal 이 켜져 있으면, 그 라이브 변경은 다음 reconcile 사이클에서 깔끔하게 사라집니다. 5 분 동안 잘 동작하던 앱이 갑자기 다시 죽기 시작하는, 한 번 겪으면 잊을 수 없는 경험. -
ArgoCD 자체를 GitOps 로 셀프 관리 — App-of-Apps 패턴 실전
ArgoCD 로 30 개 서비스를 GitOps 운영하다 보면 자연스러운 질문이 생깁니다. “ArgoCD 자신의 Application CR 들은 누가 관리하지?” 새 서비스 하나 추가할 때마다
kubectl apply -f argocd-applications/foo.yaml을 손으로 치고 있다면, 그건 GitOps 가 아니라 그냥 git + kubectl 입니다. -
쿠버네티스 5일차 — 모니터링 + 로깅 (Prometheus / Grafana / Loki)
운영하다 보면 깨닫는 진실 하나: