YG Tech Blog

1️⃣ 개요 CronJob은 Kubernetes에서 주기적으로 실행되는 작업을 자동화하기 위한 리소스입니다.작업의 반복 주기를 정의할 때 사용하는 방식이 바로 Cron 표현식입니다. 하지만 표현식의 오해, 잘못된 설정, 타임존 미반영 등으로 인해 원하지 않는 시간에 작업이 실행되거나 누락되는 경우가 자주 발생합니다. 이 글에서는 CronJob의 시간 설정을 정확히 이해하고, 표현식 작성과 운영 시 주의할 점을 다룹니다. 2️⃣ Cron 표현식의 구조# 형식: 분 시 일 월 요일# 예시: "0 3 * * 1" → 매주 월요일 오전 3시 필드 순서의미범위분 (Minute)작업 실행 시각 (분 단위)0~59시 (Hour)작업 실행 시각 (시 단위, 24시간제)0~23일 (Day of Month)매월 며칠에 실..

1️⃣ 개요 Job은 일회성 또는 반복되지 않는 특정 작업을 실행하는 데 활용됩니다.이러한 작업은 보통 환경 변수, 설정 파일, 인증 정보 등을 필요로 하며,이를 하드코딩하지 않고 외부 리소스(ConfigMap, Secret) 로 분리하는 것이 좋습니다. 이번 글에서는 Job이 ConfigMap, Secret과 연동하여 실행 환경을 외부화하는 구성 전략을 소개합니다. 2️⃣ 환경 외부화가 필요한 이유항목이유설정 관리 일관성Job 외부에서 설정 값을 변경 가능보안 강화민감 정보는 Secret으로 관리재사용성 향상동일한 Job 템플릿을 다른 설정으로 재사용운영 안정성설정 누락이나 오타 방지✅ 설정을 외부화하면 Job이 더 유연하고 재사용 가능한 리소스가 됩니다. 3️⃣ ConfigMap을 환경 변수로 주입하..

1️⃣ 개요 Kubernetes에서는 일회성 작업은 Job,주기적으로 반복 실행되는 작업은 CronJob 리소스를 통해 실행할 수 있습니다. 하지만 아래와 같은 상황에서 혼란이 생길 수 있습니다: • 주기적 실행이 필요한데 Job을 계속 수동 생성하고 있음 • 반복성이 없는 작업인데 CronJob으로 구성됨 • 반복 실행 중 일부 작업이 누락되거나 중복 실행됨 이 글에서는 Job과 CronJob의 선택 기준과 함께,Job을 CronJob으로 전환할 때 고려해야 할 전략을 설명합니다. 2️⃣ 리소스 선택 기준 비교항목JobCronJob목적한 번만 실행되는 작업반복적으로 실행되는 작업실행 방식수동 생성 또는 자동화 도구로 실행일정(schedule)에 따라 자동 실행실패 시 대응재시도 횟수 설정 필요Job 내..

1️⃣ 개요 Kubernetes에서 Job 리소스는 작업이 완료되면 Completed, 실패하면 Failed 상태로 전환됩니다.그러나 다음과 같은 경우에는 Job이 계속 남아있는 상태로 클러스터 자원을 차지할 수 있습니다: • 실패했지만 backoffLimit을 넘기지 않음 • 완료되었으나 TTL이 설정되지 않음 • 외부 시스템과 연동이 되지 않아 상태 처리가 누락됨 이 글에서는 Job 컨트롤러가 Job을 어떻게 관리하고,불완전한 Job 리소스를 안전하게 정리하는 방법을 소개합니다. 2️⃣ Job의 상태 흐름 요약[Job 생성] ↓[Pod 실행] ↓[성공] → Job 상태: Completed[실패] → 재시도 → backoffLimit 초과 → Job 상태: Failed 상태의미Active현재 실행 ..

1️⃣ 개요 Kubernetes에서 Job 리소스는 작업 완료 후 Pod이 자동으로 종료됩니다.이로 인해, Job 실행 중 남긴 로그는 별도 처리 없이 유실될 수 있으며,특히 Pod이 완료되거나 삭제되면 kubectl logs 명령으로도 확인할 수 없게 됩니다. 이 글에서는 Job 실행 로그를 안전하게 수집하고 보존하는 전략을 정리합니다. 2️⃣ Job 로그가 사라지는 이유원인설명Pod 완료 시 종료Job은 성공 시 Pod을 종료함TTL 설정 시 자동 삭제ttlSecondsAfterFinished 설정으로 일정 시간 후 Pod 삭제로그 수집기 미연동로그를 외부로 전송하지 않으면 로그는 노드 디스크에만 존재kubectl logs 대상 없음삭제된 Pod에 대해 로그 조회 불가✅ Job은 일시적인 리소스이기 ..

1️⃣ 개요 Kubernetes Job은 단일 작업을 수행하는 데 그치지 않고,여러 개의 Pod을 병렬로 실행하여 병렬 처리를 수행할 수 있습니다.이를 위해 사용하는 핵심 파라미터가 바로: • completions: 전체 작업 완료 횟수 • parallelism: 동시에 실행할 Pod 수 이 글에서는 이 두 파라미터를 조합하여 다양한 병렬 처리 패턴을 설계하는 방법을 설명합니다. 2️⃣ 개념 비교항목설명completions전체 완료되어야 할 작업 수(Pod 수)parallelism동시에 실행할 최대 Pod 수 (병렬도)기본값1특징Pod이 종료될 때마다 하나의 완료로 간주✅ 이 두 값은 함께 조절되어야 의미가 있으며, completions ≥ parallelism 조건이 일반적입니다. 3️⃣ 예제: 5개 ..

1️⃣ 개요 Job은 일회성 작업 또는 배치 작업을 위한 중요한 리소스입니다.하지만 Job 실행 중 해당 Pod이 올라간 노드가 장애(예: 전원 다운, 네트워크 단절) 상태가 되면, Job의 처리 흐름이 중단될 수 있습니다. 이 글에서는 Job이 노드 장애 상황에서 어떻게 반응하는지, 그리고복구를 위해 어떤 설정을 적용해야 하는지에 대해 설명합니다. 2️⃣ 기본 동작 원리조건Kubernetes의 기본 반응Job Pod 실행 중 노드가 다운됨해당 Pod이 Unknown 또는 Terminating 상태로 유지됨Kubelet이 응답 불가 상태Pod이 삭제되지 않고 그대로 남음일정 시간 경과 후Controller가 Pod을 새로 생성할 수 있음 (노드 상태 감지 후 재시도)✅ 이 과정은 빠르게 전환되지 않으며,..

1️⃣ 개요Job 리소스를 구성할 때 많이 사용되는 두 가지 설정이 있습니다:backoffLimit: 실패 시 재시도 횟수activeDeadlineSeconds: Job 전체 실행의 최대 허용 시간이 두 옵션은 비슷해 보이지만 완전히 다른 기준으로 Job의 생존을 제어합니다.이 글에서는 두 항목의 차이점과 함께, 실제 운영 환경에서 어떻게 조합하는 것이 효과적인지 전략적으로 설명합니다.2️⃣ 두 설정의 차이 정리 항목 backoffLimit activeDeadlineSeconds 기준실패 횟수실행 시간작동 대상실패한 Pod 기준Job 전체 기준목적최대 재시도 횟수 제한무한 실행 방지 (타임아웃)기본값6없음 (무제한)제어 방법실패마다 1회 증가Job 생성 시부터 시간 카운트✅ 두 설정은 병렬로 작동하며..

1️⃣ 개요Kubernetes에서 Job 리소스는 일회성 작업 또는 반복 불필요한 처리 작업을 위해 사용됩니다.하지만 Pod이 중간에 실패하거나, 예외 상황이 발생했을 때 Job이 실패로 끝나지 않도록 구성하는 전략이 중요합니다.이번 글에서는 Job 리소스가 Pod 실패 상황에서 어떻게 반응하는지, 그리고성공 보장을 위한 재시도 설정 방법에 대해 자세히 살펴보겠습니다.2️⃣ Job 기본 개념 요약 항목 설명 목적1회성 또는 완료 시 종료되는 작업 실행기본 Pod 수1개완료 기준지정된 수의 completions 도달 시실패 대응기본적으로 실패한 Pod은 자동 재시도되지 않음 (명시 필요)✅ 즉, Job을 신뢰성 있게 구성하려면 명시적으로 재시도 조건을 설정해야 합니다.3️⃣ 재시도 전략 설정 항목들 설정..

1️⃣ 개요Kubernetes에서 Pod을 배포하는 대표적인 리소스로는 ReplicaSet과 DaemonSet이 있습니다.둘 다 여러 개의 Pod을 생성하는 역할을 하지만, Pod의 배포 방식과 목적은 완전히 다릅니다.이 글에서는 DaemonSet과 ReplicaSet의 개념적 차이, 스케줄링 방식, 운영 목적의 차이점을 비교하여둘 중 어떤 리소스를 선택해야 하는지 명확히 이해할 수 있도록 구성하였습니다.2️⃣ 역할 차이 요약 항목 DaemonSet ReplicaSet Pod 수 조절 방식노드 수에 따라 자동 결정 (1개/노드)수동으로 .spec.replicas 수 지정배포 대상클러스터의 모든 노드 (혹은 특정 조건의 노드)스케줄링 가능한 노드 중 임의 선택목적노드 기반 작업 (모니터링, 로그 수집 ..