1nfratech1nfra Tech

이번에는 Docker VM에서 돌던 작은 서비스 3개와 LMS(학습 관리 시스템)를 옮겼습니다. 이미 컨테이너로 돌던 서비스라 VM에서 쓰던 컨테이너 이미지를 그대로 썼습니다. 가장 신경 쓴 점은 노드 하나가 멈춰도 다른 워커에서 계속 동작하게 하는 것입니다. 이 글에서는 Docker 서비스를 옮긴 방법, 두 곳에서 동시에 돌면 안 되는 알림 봇을 옮기는 순서, LMS를 노드 장애에 견디게 만든 설계와 전환 과정을 정리합니다. 홈랩 재구성 시리즈 7편이며, 이전 글은 Zabbix 5.4를 7.0 LTS로 옮기고 Kubernetes까지 모니터링하기입니다.7편을 마친 시점의 구성입니다. Docker 서비스와 LMS를 옮기고, 노드가 멈춰도 다른 워커에서 다시 실행되게 했습니다1. Docker VM의 서비스 ..

kubeadm은 Kubernetes 공식 클러스터 설치 도구로, 노드를 준비한 뒤 init과 join으로 클러스터를 만듭니다. 마스터를 여러 대 두려면 처음부터 공통 API 주소를 정해야 하고, 네트워크(CNI)와 외부 노출에 필요한 구성 요소는 따로 설치합니다. 이 글에서는 Ubuntu 24.04 노드 5대로 마스터 3대 클러스터를 만들고, kube-vip로 API 가상 IP를, Cilium으로 kube-proxy 없는 네트워크를, MetalLB와 Gateway API로 외부 노출을 구성한 과정을 명령과 함께 정리합니다. 컨테이너부터 Kubernetes까지 시리즈 12편이며, 이전 글은 [Kubernetes] 리소스 requests, limits와 HPA 정리입니다. 이 클러스터를 홈랩에서 어떻게 설계..

홈랩의 모니터링 서버에서는 지원이 끝난 Zabbix 5.4를 사용했습니다. Zabbix 7.0은 더 새로운 MySQL과 PHP가 필요해서, 제자리 업그레이드 대신 새 VM을 만들어 DB를 옮기는 방식으로 이전했습니다. 모니터링이 멈춘 시간은 약 18분이었고, 이전한 뒤에는 Zabbix의 공식 연동으로 Kubernetes 클러스터까지 한 화면에서 확인할 수 있게 했습니다. 이 글에서는 새 VM으로 옮긴 이유와 전환 순서, 주의할 점, Kubernetes 모니터링과 웹 감시 설정을 정리합니다. 홈랩 재구성 시리즈 6편이며, 이전 글은 PHP 사이트 6개와 MySQL을 옮기고 Gateway 하나로 합치기입니다.6편을 마친 시점의 구성입니다. Zabbix를 7.0 버전이 설치된 새 VM으로 옮기고, 로드밸런서 ..

두 번째 이관 대상은 VM 한 대에서 포트로 나눠 운영하던 PHP 사이트 6개와 MySQL이었습니다. 사이트마다 이미지를 따로 만들고 DB는 StatefulSet으로 옮겼으며, 입구는 Gateway 하나로 합쳐 호스트 이름으로 사이트를 나눴습니다. VM처럼 포트 리스너로 나누는 방식도 시도했지만, Cilium Gateway에서는 사이트가 서로 섞여서 호스트 이름 방식으로 정했습니다. 이 글에서는 이미지 설계, MySQL 이관, Gateway 통합과 호스트 이름 라우팅을 정리합니다. 홈랩 재구성 시리즈 5편이며, 이전 글은 Jenkins와 Argo CD로 홈랩 CI/CD 구성하기입니다.5편을 마친 시점의 구성입니다. 입구를 Gateway 하나로 합치고 호스트 이름으로 사이트를 나눴습니다1. 이관 대상 항목..

처음 서비스를 옮길 때는 이미지를 노드에 직접 넣었습니다. 지금은 앱 소스를 GitHub에 push하면 Jenkins가 이미지를 만들어 클러스터 안의 이미지 저장소에 올리고, 배포용 Git 저장소의 이미지 태그를 고쳐 커밋합니다. 그러면 Argo CD가 그 커밋대로 클러스터에 배포합니다. 이 글에서는 내부 이미지 저장소와 노드 설정, 저장소 두 개와 권한 나누기, Jenkins 파이프라인, 소스를 Git으로 옮길 때 확인한 것, 자동 동기화에서 데이터를 지키는 설정을 정리합니다. 홈랩 재구성 시리즈 4편이며, 이전 글은 웹 서비스 VM을 Kubernetes로 옮기고 검증하기입니다.4편에서 붙인 배포 흐름입니다. 앱 저장소에 push하면 Jenkins가 빌드하고 Argo CD가 클러스터에 반영합니다1. 왜..

VM에서 돌던 서비스를 컨테이너로 옮길 때 가장 중요한 것은 옮긴 뒤에도 기존과 똑같이 동작하는지 확인하는 일입니다. 첫 대상인 웹 사이트에서는 전환 전에 문제 네 가지를 찾았습니다. 기존 VM과 응답을 비교해 HTTP 200만으로는 보이지 않던 문제 세 가지가 나왔고, 쓰기 기능 시험에서 하나가 더 나왔습니다. 이 글에서는 첫 대상을 고른 기준, 서비스가 쓰는 데이터(상태)를 나눈 방법, 기존 VM과 응답을 비교해 검증한 과정, 전환과 되돌리기 계획을 정리합니다. 홈랩 재구성 시리즈 3편이며, 이전 글은 홈랩 Kubernetes 클러스터 설계와 노드 배치입니다.3편을 마친 시점의 구성입니다. 첫 웹 사이트로 들어오는 요청은 NAS 프록시에서 클러스터로 바로 전달되고, 기존 VM은 꺼 두었습니다1. 첫 ..

물리 호스트가 2대뿐인 홈랩에 Kubernetes 클러스터를 설계할 때 가장 먼저 부딪히는 문제는 마스터 노드를 몇 대 두고 어디에 놓느냐입니다. 저는 마스터 3대와 워커 4대로 클러스터를 만들고, API 주소를 처음부터 가상 IP로 정해 노드를 옮기거나 늘려도 주소가 바뀌지 않게 했습니다. 이 글에서는 마스터 수를 정한 기준, 두 호스트에 노드를 나눠 둔 방법, 노드 OS와 구성 요소를 고른 이유, 버전을 고르는 기준을 정리합니다. 홈랩 재구성 시리즈 2편이며, 이전 글은 홈랩 인프라 현황과 Kubernetes로 옮기는 이유입니다.2편을 마친 시점의 구성입니다. Kubernetes 노드 7대를 두 호스트에 나눠 만들었고, 서비스는 아직 VM에서 동작합니다1. 설계 조건 조건내용호스트ESXi 호스트 2대..

제 홈랩의 VM은 ESXi 호스트 2대에서 한때 약 68대까지 늘었고, 정리를 거쳐 지금은 24대입니다. 하이퍼바이저는 지원이 끝났고, 서비스 VM의 절반 이상이 지원이 종료된 OS를 썼으며, 실제로 쓰는 자원은 할당량의 4분의 1에도 못 미쳤습니다. 그래서 서비스 VM을 컨테이너로 바꿔 Kubernetes 클러스터로 옮기기로 했습니다. 이 글에서는 현재 인프라 상태와 문제점, Kubernetes를 고른 이유, 옮기기 전에 정리한 것과 이전 계획을 다룹니다. 홈랩 재구성 시리즈의 1편입니다.1편을 마친 시점의 구성입니다. 요청은 로드밸런서 VM을 거쳐 서비스마다 따로 있는 VM으로 갔고, 쓰지 않는 VM과 파일부터 정리했습니다1. 현재 홈랩 구성물리 서버는 ESXi 호스트 2대이고 vCenter 1대로 ..

Helm은 여러 Kubernetes 매니페스트를 차트 하나로 묶고, 환경마다 다른 값만 바꿔 끼워 배포하게 해 주는 패키지 매니저입니다. 이 글에서는 차트의 구조와 템플릿 문법, 값이 적용되는 우선순위, 배포 이력을 남기는 릴리스와 롤백을 정리하고, 직접 만든 차트로 설치부터 롤백까지 확인합니다. Helm 4에서 바뀐 플래그와 Kustomize, ArgoCD와 함께 쓸 때 주의할 점도 함께 다룹니다.컨테이너부터 Kubernetes까지 시리즈의 3부 실무 글입니다. 차트 안에 들어가는 Deployment와 ConfigMap은 [Kubernetes] Pod, ReplicaSet, Deployment 정리와 [Kubernetes] ConfigMap과 Secret 정리에서 다뤘고, 전체 순서는 시리즈 목차에 있..

Kubernetes는 Pod가 CPU와 메모리를 얼마나 쓸지 알아야 노드에 알맞게 배치하고, 한 Pod가 노드 자원을 다 쓰지 못하게 막을 수 있습니다. 이 글에서는 requests와 limits의 차이, 한도를 넘었을 때의 동작, QoS 클래스를 정리하고, 부하에 따라 Pod 수를 조절하는 HPA를 kind에서 직접 확인합니다.컨테이너부터 Kubernetes까지 시리즈 11편입니다. 이전 글은 [Kubernetes] Volume, PV, PVC, StorageClass 정리이고, 전체 순서는 시리즈 목차에 있습니다.1. requests와 limits컨테이너마다 resources.requests와 resources.limits를 정할 수 있습니다. requests는 "최소 이만큼은 필요하다"는 예약이고,..