YG Tech Blog

1️⃣ Kubernetes에서 자동 확장이 필요한 이유? 애플리케이션의 트래픽은 예측하기 어렵습니다.사용자가 갑자기 증가하면 서비스 장애가 발생할 수 있고, 반대로 사용자가 적을 때 불필요한 리소스를 사용하면 비용이 낭비됩니다.  Kubernetes에서는 **HPA(Horizontal Pod Autoscaler)**를 사용하여 트래픽 변화에 맞춰 자동으로 Pod 개수를 조절할 수 있습니다. ✅ 트래픽이 많아지면 자동으로 Pod를 추가✅ 트래픽이 줄어들면 자동으로 Pod를 감소✅ CPU, 메모리 사용량을 기준으로 확장 가능 이제 Kubernetes에서 HPA를 설정하는 방법을 살펴보겠습니다!  2️⃣ Kubernetes HPA란? 📌 **HPA(Horizontal Pod Autoscaler)**는 Pod..

1️⃣ Kubernetes에서 모니터링과 로깅이 중요한 이유? 운영 중인 Kubernetes 애플리케이션이 정상적으로 동작하는지 확인하려면 모니터링과 로깅이 필수입니다.하지만 Kubernetes 환경에서는 Pod가 동적으로 생성되고 삭제되므로 기존 서버 기반의 모니터링 방식은 적용하기 어렵습니다. ✅ 모니터링: 클러스터, 노드, Pod, 애플리케이션의 상태를 실시간으로 확인✅ 로깅: 애플리케이션과 시스템에서 발생하는 이벤트를 기록하여 문제 해결  Kubernetes에서는 Prometheus + Grafana를 사용하여 모니터링하고,Loki + Promtail을 활용하여 로깅을 수집할 수 있습니다. 이제 Kubernetes에서 모니터링과 로깅을 설정하는 방법을 살펴보겠습니다!  2️⃣ Kubernetes ..

1️⃣ Kubernetes에서 Helm이 필요한 이유? Kubernetes에서 애플리케이션을 배포할 때, 여러 개의 YAML 파일을 관리해야 합니다. 예를 들어, 하나의 애플리케이션을 배포하려면 다음과 같은 리소스를 정의해야 합니다. 📌 기본 배포 구성 요소 • deployment.yaml → 애플리케이션 배포 • service.yaml → 네트워크 연결 (Service) • ingress.yaml → 도메인 연결 (Ingress) • configmap.yaml → 환경 변수 관리 ✅ 파일이 많아질수록 배포 및 관리가 어려워집니다.✅ Helm을 사용하면 하나의 Chart로 여러 개의 Kubernetes 리소스를 손쉽게 관리할 수 있습니다.  2️⃣ Helm이란? 📌 Helm은 Kubernetes 애플..

1️⃣ Kubernetes에서 Ingress가 필요한 이유? 이전 글에서 Kubernetes의 Service를 통해 Pod에 접근하는 방법을 배웠습니다.하지만 NodePort나 LoadBalancer는 다음과 같은 제한사항이 있습니다. ❌ NodePort • 포트(30000~32767)를 직접 사용해야 함 • 여러 서비스가 있을 경우 관리가 어려움 ❌ LoadBalancer • 클라우드 환경에서만 사용 가능 • 서비스마다 LoadBalancer가 필요하면 비용 증가 ✅ Ingress를 사용하면 하나의 LoadBalancer로 여러 서비스에 트래픽을 분배할 수 있습니다.✅ 도메인 기반으로 트래픽을 라우팅할 수도 있습니다.  2️⃣ Kubernetes Ingress란? 📌 Ingress는 외부 트래픽을 클..

1️⃣ Kubernetes에서 Service가 필요한 이유? Kubernetes에서 Pod는 동적으로 생성 및 삭제됩니다.즉, Pod의 IP 주소는 변경될 수 있기 때문에, 클라이언트가 특정 Pod에 직접 접근하는 것은 어렵습니다.  “어떤 Pod가 살아 있는지 모르는데, 어떻게 네트워크 통신을 할 수 있을까?” 🤔 ✅ 이 문제를 해결하기 위해 Kubernetes는 “Service”라는 개념을 제공합니다.✅ Service를 사용하면 Pod의 IP가 변하더라도, 항상 동일한 방식으로 접근할 수 있습니다.  2️⃣ Kubernetes에서 Service란? Kubernetes의 Service는 여러 개의 Pod를 하나의 네트워크 엔드포인트로 묶어주는 역할을 합니다.즉, Service는 특정 Label을 가진..

1️⃣ Kubernetes는 어떻게 동작할까? 이전 글에서 **Kubernetes의 기본 개념(Cluster, Node, Pod)**을 배웠습니다.이제 Kubernetes 클러스터의 전체 아키텍처를 깊이 있게 분석해 보겠습니다.  Kubernetes는 **Master Node(제어부)**와 **Worker Node(실행부)**로 구성됩니다.Master Node는 클러스터의 “두뇌” 역할을, Worker Node는 “일꾼” 역할을 수행합니다. 아래 다이어그램을 보며 함께 살펴볼까요? 👀  2️⃣ Kubernetes 아키텍처 개요 📌 Kubernetes 아키텍처의 주요 구성 요소+--------------------------+ +---------------------------+| 🏢 Mast..

1️⃣ Kubernetes는 어떻게 동작할까? Kubernetes는 단순한 컨테이너 오케스트레이션 툴이 아닙니다.Kubernetes는 컨테이너 애플리케이션을 효율적으로 관리하는 분산 시스템입니다.  “Kubernetes는 수천 개의 컨테이너를 자동으로 배포하고, 스케일링하며, 관리하는 역할을 합니다.” Kubernetes의 구조를 이해하려면, Pod, Node, Cluster 개념을 먼저 파악해야 합니다.이제 하나씩 살펴볼까요? 🚀  2️⃣ Kubernetes Cluster란? Kubernetes의 기본 단위는 **클러스터(Cluster)**입니다. 📌 Kubernetes 클러스터의 개념 • **클러스터(Cluster)**는 여러 개의 **노드(Node)**가 모여 하나의 시스템처럼 동작하는 구조입니..

1️⃣ Monolithic 아키텍처란? 과거 대부분의 애플리케이션은 모놀리식(Monolithic) 아키텍처로 개발되었습니다.모놀리식 아키텍처는 모든 기능이 하나의 애플리케이션 내부에서 동작하는 구조를 의미합니다. ✅ Monolithic 구조 예시 하나의 애플리케이션이 다음과 같은 기능을 포함하고 있다고 가정해 봅시다. 📌 쇼핑몰 애플리케이션+-------------------------+| 🛒 쇼핑몰 애플리케이션 ||-------------------------|| 🔍 상품 검색 || 🛍️ 장바구니 || 💳 결제 시스템 || 📦 주문 관리 |+-------------------------+✅ 모든 기능이 하나의 코드베이스..

1️⃣ 컨테이너의 발전과 새로운 문제들 Docker와 같은 컨테이너 기술 덕분에 애플리케이션을 쉽고 빠르게 배포할 수 있게 되었습니다.하지만, 컨테이너를 대량으로 운영하다 보면 수동 관리로는 해결할 수 없는 문제들이 발생하게 됩니다. 👉 예제 시나리오:📦 “내 애플리케이션을 Docker 컨테이너로 배포했어요!”✅ 실행이 잘 됩니다.❌ 하지만… 몇 가지 문제점이 발생합니다. ✅ 문제 1: 컨테이너 장애 발생 시 자동 복구가 필요함 • 특정 컨테이너가 예상치 못하게 종료된다면? • 개발자가 직접 다시 실행해야 할까요? ✅ 문제 2: 서비스 트래픽 증가에 따른 자동 확장이 필요함 • 쇼핑몰의 트래픽이 갑자기 폭증하면? • 미리 컨테이너를 많이 실행해 두어야 할까요? ✅ 문제 3: 컨테이너 간 네트워크 및 ..

1️⃣ Kubernetes의 등장 배경 현대 애플리케이션 개발에서는 컨테이너(Container) 기술이 필수 요소가 되었습니다.Docker 같은 컨테이너 기술 덕분에 애플리케이션을 어디서든 실행할 수 있지만,문제는 수백~수천 개의 컨테이너를 어떻게 관리할 것인가? 하는 것이었습니다. ✅ 컨테이너가 많아질수록 발생하는 문제: • 컨테이너가 실행 중인지 하나하나 확인해야 한다. • 컨테이너가 장애가 나면 자동으로 복구해야 한다. • 서비스 트래픽에 맞춰 컨테이너 개수를 자동으로 조정해야 한다. • 특정 컨테이너로 요청을 보낼 방법이 필요하다. 이 모든 문제를 해결하기 위해 컨테이너 오케스트레이션(Container Orchestration) 기술이 등장했고,그 중 가장 강력한 툴이 바로 **Kubernetes..