YG Tech Blog

왜 Infrastructure as Code(IaC)가 중요한가📰 ArticleInfrastructure as Code (IaC) has become a standard practice in DevOps.It allows teams to manage infrastructure using code rather than manual configuration, which increases consistency, scalability, and repeatability.➡️ Infrastructure as Code(IaC)는 DevOps에서 표준적인 실천 방식이 되었으며,팀이 수동 설정이 아닌 코드를 통해 인프라를 관리할 수 있도록 해줍니다.이를 통해 인프라의 일관성, 확장성, 반복 가능성이 향상됩니다.Usin..

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을 새로 생성할 수 있음 (노드 상태 감지 후 재시도)✅ 이 과정은 빠르게 전환되지 않으며,..

이번에는 모니터링 시스템의 보안과 성능 최적화에 대해 알아보겠습니다. 모니터링 시스템은 클러스터 전반의 중요한 정보에 접근할 수 있기 때문에 보안이 매우 중요하며, 대규모 환경에서는 모니터링 시스템 자체의 성능이 병목이 되지 않도록 최적화가 필요합니다. 이 글에서는 Prometheus와 Grafana를 중심으로 보안을 강화하면서도 최적의 성능을 유지하는 방법에 대해 살펴보겠습니다.📌 모니터링 시스템의 보안 위협 및 취약점쿠버네티스 환경에서 모니터링 시스템이 직면하는 보안 위협과 잠재적 취약점에 대해 알아보겠습니다.✅ 주요 보안 위협 모델 모니터링 시스템이 직면할 수 있는 다양한 보안 위협을 이해하는 것이 중요합니다.무단 접근 위험인증되지 않은 사용자의 메트릭 접근민감한 비즈니스 데이터 노출내부 시스템 ..

이번 글에서는 대규모 쿠버네티스 환경에서 모니터링 시스템의 성능을 극대화하는 전략에 대해 알아보겠습니다. 클러스터가 커지고 워크로드가 복잡해질수록 모니터링 시스템 자체의 성능과 확장성이 중요한 과제가 됩니다. 이 글에서는 Prometheus와 Grafana를 포함한 모니터링 스택의 성능을 최적화하고, 대규모 환경에서도 안정적으로 운영하기 위한 고급 설정 방법을 살펴보겠습니다.📌 고성능 모니터링의 필요성과 도전 과제대규모 쿠버네티스 환경에서 모니터링 시스템이 직면하는 문제와 이를 해결하기 위한 접근 방식을 알아보겠습니다.✅ 모니터링 시스템의 성능 병목 현상모니터링 시스템이 확장됨에 따라 발생하는 주요 병목 지점과 그 원인에 대해 살펴보겠습니다.  샘플 수집 부하대규모 클러스터의 수천 개 엔드포인트짧은 스..