YG Tech Blog

1️⃣ 개요 DaemonSet은 클러스터의 모든 노드에 Pod를 배포하는 강력한 도구이지만, 업데이트 전략을 적절히 구성하지 않으면애플리케이션이 일시적으로 중단되거나 비효율적으로 배포될 수 있습니다. 이번 글에서는 DaemonSet의 업데이트 전략의 개념을 이해하고, 무중단 롤링 배포(Rolling Update)를 적용하는 방법을 소개합니다.  2️⃣ DaemonSet 업데이트 전략이 필요한 이유상황문제점업데이트 전략 필요성이미지 버전 변경기존 Pod가 중단되고 새로 생성됨순차적 롤링 배포 필요환경 변수 변경모든 노드에서 한 번에 재시작트래픽 손실 가능설정 누락 시업데이트 적용되지 않음전략 명시 필요✅ 업데이트 전략을 명확히 설정하지 않으면 수동 업데이트를 반복해야 하며, 장애나 서비스 중단 가능성이 커..

1️⃣ 개요 Kubernetes에서 DaemonSet은 클러스터의 모든 노드에서 특정 Pod를 실행하는 데 사용되는 컨트롤러입니다.일반적으로 모니터링, 로그 수집, 네트워크 관리와 같은 노드 기반 서비스를 배포할 때 활용됩니다. 이번 글에서는 DaemonSet의 기본 개념과 일반적인 활용 사례를 정리하겠습니다. 🚀 2️⃣ DaemonSet이란? 📌 DaemonSet의 주요 특징특징설명모든 노드에서 실행클러스터 내 모든 노드에서 동일한 Pod가 실행됨노드 추가 시 자동 배포새로운 노드가 추가되면 자동으로 해당 Pod가 실행됨노드별 단일 Pod 유지각 노드에서 하나의 DaemonSet Pod만 실행됨수동 삭제 없이 유지DaemonSet을 삭제할 때까지 Pod가 유지됨✅ DaemonSet을 활용하면 노드별..

1️⃣ 개요 StatefulSet은 일반적으로 데이터를 저장하고 상태를 유지하는 애플리케이션(예: 데이터베이스, 메시지 브로커 등)에 사용됩니다.그러나, 트래픽 증가 시 Pod 개수를 자동으로 조정해야 하는 경우에도 StatefulSet을 활용할 수 있습니다. 이번 글에서는 StatefulSet에 Horizontal Pod Autoscaler(HPA)를 적용하는 방법과, 고려해야 할 주요 사항을 설명하겠습니다. 🚀 2️⃣ StatefulSet에서 HPA가 필요한 이유 📌 StatefulSet에서 HPA가 필요한 주요 이유상황설명트래픽 급증API 서버, 캐시 서버(예: Redis) 등에서 갑작스러운 트래픽 증가 대응CPU/메모리 부하 증가일정 수준 이상의 리소스 사용량을 초과하면 자동으로 Pod 개수 ..

1️⃣ 개요 StatefulSet은 데이터 영속성을 유지하면서 확장 가능한 애플리케이션을 배포하는 데 최적화된 Kubernetes 리소스입니다.특히, 대용량 데이터를 다루는 데이터베이스(MySQL, PostgreSQL), 메시지 브로커(Kafka, RabbitMQ), 분산 저장소(Elasticsearch, Ceph) 등의 운영에서는 성능 최적화가 필수적입니다. 이번 글에서는 StatefulSet을 활용하여 고성능 데이터 저장소를 운영하는 전략과 튜닝 방법을 정리하겠습니다. 🚀 2️⃣ StatefulSet을 활용한 데이터 저장소 운영 시 고려해야 할 사항 📌 StatefulSet 기반 데이터 저장소 운영 시 주요 고려 사항항목설명최적화 방법스토리지 IOPS데이터베이스나 로그 저장소의 입출력 성능고성능 ..

1️⃣ 개요 StatefulSet을 운영할 때 Persistent Volume(PV)이 어떻게 유지되고 삭제되는지를 정확히 이해하는 것이 중요합니다.특히, StatefulSet은 Pod가 삭제되더라도 동일한 데이터를 유지해야 하기 때문에 PV의 Reclaim(재활용) 정책을 신중하게 설정해야 합니다. 이번 글에서는 Kubernetes Persistent Volume의 Reclaim 정책을 설명하고, StatefulSet에서 적절한 PV Reclaim 전략을 적용하는 방법을 정리하겠습니다. 🚀 2️⃣ Persistent Volume Reclaim 정책이란? 📌 Persistent Volume(PV) Reclaim 정책은 PVC(Persistent Volume Claim) 삭제 후 PV의 동작을 결정하는..

1️⃣ 개요 StatefulSet 기반 애플리케이션(데이터베이스, 메시지 브로커, 캐시 시스템 등)을 운영할 때, 서비스 간 트래픽 제어, 보안, 모니터링 기능을 강화하기 위해 Service Mesh(Istio, Linkerd)를 활용하는 경우가 많습니다.그러나 StatefulSet은 일반적인 Deployment와는 다르게 고유한 네트워크 아이덴티티(Pod 이름, Headless Service)를 가지므로, Service Mesh와 연동할 때 고려해야 할 사항이 있습니다. 이번 글에서는 StatefulSet을 Istio 및 Linkerd와 연동하는 방법과 적용 시 고려해야 할 사항을 정리하겠습니다. 🚀 2️⃣ StatefulSet에서 Service Mesh를 활용하는 이유 📌 StatefulSet과 ..

1️⃣ 개요 StatefulSet을 운영할 때 Pod 장애, 스토리지 오류, 네트워크 문제 등으로 인해 서비스가 정상적으로 운영되지 않을 수 있습니다.특히 StatefulSet은 각 Pod가 고유한 ID와 Persistent Volume을 유지해야 하므로, 장애 발생 시 복구 전략을 신중하게 설계해야 합니다. 이번 글에서는 StatefulSet에서 발생할 수 있는 주요 장애 유형을 정리하고, Auto Healing(자동 복구) 설정 방법을 설명하겠습니다. 🚀 2️⃣ StatefulSet에서 발생할 수 있는 장애 유형 📌 StatefulSet 운영 중 발생할 수 있는 주요 장애 유형과 원인 장애 유형설명해결 방법Pod 장애Pod가 CrashLoopBackOff 상태가 됨Liveness Probe 및 A..

1️⃣ 개요 StatefulSet을 운영하는 애플리케이션(데이터베이스, 메시지 브로커, 분산 스토리지 등)은 단일 가용 영역(Availability Zone, AZ) 장애 시에도 서비스가 지속적으로 운영될 수 있도록 Multi-AZ 환경에서 배포하는 것이 중요합니다. 이번 글에서는 StatefulSet을 Multi-AZ 환경에서 배포하는 전략과, 네트워크 및 스토리지 고려 사항을 포함한 실전 적용 방법을 정리하겠습니다. 🚀 2️⃣ StatefulSet에서 Multi-AZ 배포가 필요한 이유 📌 Multi-AZ 배포의 주요 필요성 이유설명가용성 향상특정 AZ에서 장애 발생 시에도 다른 AZ에서 서비스 지속데이터 손실 방지여러 AZ에 데이터 복제하여 장애 발생 시 복구 가능부하 분산 최적화특정 AZ에만 ..

1️⃣ 개요 StatefulSet을 운영할 때 애플리케이션이 정상적으로 작동하는지 모니터링하는 것이 중요합니다.특히, Readiness Probe와 Liveness Probe를 올바르게 설정하면 장애 감지 및 복구가 자동으로 이루어질 수 있습니다. 이번 글에서는 StatefulSet의 Readiness & Liveness Probe 개념과, 데이터베이스 및 메시지 브로커에서 Probe를 최적화하는 방법을 설명하겠습니다. 🚀 2️⃣ Readiness Probe vs Liveness Probe 개념 정리 📌 Readiness & Liveness Probe의 차이점Probe 유형목적작동 방식Readiness Probe애플리케이션이 트래픽을 받을 준비가 되었는지 확인실패하면 Service에서 Pod 제외Li..

1️⃣ 개요 StatefulSet을 운영하다 보면 기존 StatefulSet을 새로운 클러스터로 이동하거나, 스토리지 백엔드를 변경하는 등의 마이그레이션이 필요할 수 있습니다.그러나 Stateful 애플리케이션은 데이터 일관성을 유지해야 하며, 중단 없이 안전하게 마이그레이션하는 것이 매우 중요합니다. 이번 글에서는 StatefulSet을 무중단으로 마이그레이션하는 다양한 전략과 실전 적용 방법을 정리하겠습니다. 🚀 2️⃣ StatefulSet 마이그레이션이 필요한 주요 시나리오 📌 StatefulSet을 마이그레이션해야 하는 주요 이유 상황설명클러스터 업그레이드새로운 Kubernetes 버전의 클러스터로 이동해야 하는 경우스토리지 백엔드 변경기존 스토리지를 NFS, Ceph, Portworx 등으로..