근묵자흑

Periodic Job 패턴이란?쿠버네티스 패턴 책의 8장에서 다루는 Periodic Job 패턴은 Batch Job 패턴을 확장하여 시간적 요소를 추가한 것입니다. 쉽게 말해, 리눅스의 cron처럼 정해진 시간에 자동으로 작업을 실행하는 패턴입니다. 이를 통해 매일 새벽 3시에 데이터베이스를 백업하거나, 매시간 외부 API에서 데이터를 가져오는 등의 작업을 자동화할 수 있습니다.왜 주기적 작업이 필요한가?책에서는 현대 시스템이 실시간 이벤트 기반으로 동작하는 추세임에도 불구하고, 여전히 정기적인 작업 스케줄링이 필요한 이유를 설명합니다.예를 들어, 여러분이 온라인 쇼핑몰을 운영한다고 생각해보세요. 실시간으로 주문을 처리하는 것도 중요하지만, 다음과 같은 정기적인 작업들도 필요합니다:매일 새벽: 데이터베..

매일 수백만 건의 로그를 처리하거나, 수천 개의 이미지를 변환하거나, 복잡한 ML 모델을 훈련시켜야 한다면?쿠버네티스 Job은 이런 배치 작업을 위한 솔루션이 될 수 있습니다.Kubernetes 1.31 버전에서 GA가 된 Pod Failure Policy와 1.30에서 도입된 Success Policy는 배치 작업의 기능 또한 관련 내용을추가했습니다.Kubernetes Job이란?쿠버네티스에서 파드(Pod)를 실행하는 방법은 여러 가지가 있습니다. ReplicaSet은 웹 서버처럼 계속 실행되어야 하는 애플리케이션에 적합하고, DaemonSet은 모든 노드에서 로그 수집기를 실행하는 데 사용됩니다.그렇다면 한 번 실행하고 완료되는 작업은 어떻게 처리할까? 데이터베이스 마이그레이션, 배치 데이터 처리, ..

쿠버네티스에서 Pod가 어느 노드에 배치될지 결정하는 것은 애플리케이션의 성능, 가용성, 비용에 직접적인 영향을 미칩니다.이번 포스트에서는 Kubernetes Patterns 6장의 Automated Placement 패턴을 Minikube 환경에서 직접 테스트하며 각 배치 전략의 실제 동작을 확인해보겠습니다.테스트 환경이번장의 실습 코드는 GitHub 저장소에서 확인할 수 있습니다.Minikube 멀티노드 클러스터 설정먼저 3개 노드를 가진 Minikube 클러스터를 생성합니다:# 3노드 Minikube 클러스터 생성minikube start --nodes 3 --cpus 2 --memory 2048 --driver=docker# 노드 확인kubectl get nodes실행 결과:NAME ..

클라우드 네이티브 환경에서 컨테이너의 수명주기 관리는 단순히 "시작"과 "종료"만으로는 충분하지 않습니다. 이 장에서는 Kubernetes의 Managed Lifecycle 패턴을 실제 코드와 테스트를 통해 깊이 있게 살펴보겠습니다. 왜 Managed Lifecycle이 중요한가?실제 운영 환경에서 마주치는 상황들을 생각해보세요:Rolling Update 중 데이터 손실: 진행 중인 요청이 완료되지 않은 채 Pod가 종료Cold Start 문제: Java 애플리케이션이 준비되기 전에 트래픽 수신상태 저장 실패: 갑작스러운 종료로 인한 데이터 불일치연결 누수: 외부 서비스 연결이 제대로 해제되지 않음이러한 문제들을 해결하는 것이 바로 Managed Lifecycle 패턴입니다.실습을 통한 Managed L..

운영 환경에서 Kubernetes 애플리케이션을 실행할 때 가장 중요한 것 중 하나는 애플리케이션의 건강 상태를 정확히 파악하는 것입니다. 단순히 컨테이너가 실행 중이라고 해서 애플리케이션이 정상적으로 작동한다고 볼 수 없죠. 메모리 누수, 데드락, 무한 루프 등 다양한 문제가 발생할 수 있기 때문입니다.📚 Health Probe가 필요한 이유실제 장애 시나리오제가 경험한 실제 사례를 하나 공유하겠습니다. Java 애플리케이션이 OutOfMemoryError를 발생시켰지만, JVM 프로세스는 여전히 실행 중이었습니다. Kubernetes는 프로세스가 살아있다고 판단해 재시작하지 않았고, 결과적으로 서비스는 완전히 중단되었죠.이런 문제를 해결하기 위해 Kubernetes는 세 가지 Health Probe..

왜 선언적 배포인가?여러분이 개발한 애플리케이션을 Kubernetes에 배포한다고 상상해보세요. 새 버전을 출시할 때마다 이런 고민을 하게 됩니다."서비스 중단 없이 업데이트할 수 있을까?""문제가 생기면 빠르게 롤백할 수 있을까?""일부 사용자에게만 먼저 테스트해볼 수 없을까?"이 모든 질문의 답이 바로 선언적 배포 패턴에 있습니다.명령형 vs 선언적: 패러다임의 전환# 명령형 방식 (Imperative) - "어떻게" 할지 일일이 지시kubectl create deployment my-app --image=nginx:1.0kubectl scale deployment my-app --replicas=3kubectl set image deployment/my-app nginx=nginx:2.0kubect..