1. 개요 쿠버네티스에서 CronJob을 사용하여 주기적으로 실행되는 작업을 관리할 때, 적절한 리소스 설정이 필요합니다. 특히, CPU 사용량이 예측할 수 없이 변동되는 경우 requests.cpu와 limits.cpu를 설정하여 안정적인 동작을 보장할 수 있습니다. 이 문서는 CronJob에서 CPU 리소스를 설정하는 방법을 설명합니다. 2. CronJob 정의 및 리소스 설정 아래는 requests.cpu와 limits.cpu를 설정한 CronJob 예제입니다. 더 읽기
Rancher에서 CronJob Suspend 로그를 CloudWatch에 남기는 방법
Rancher를 통해 Kubernetes CronJob을 suspend: true로 변경했을 때, CloudWatch에 해당 로그가 남지 않는 경우가 발생할 수 있습니다. 반면, suspend: false는 정상적으로 기록될 수 있습니다. 이런 문제를 해결하기 위해 Rancher에서 로그를 남기는 방법을 정리하였습니다. 1️⃣ Kubernetes 이벤트에서 suspend 변경 확인 먼저, Kubernetes 자체에서 suspend 변경 이벤트가 기록되는지 확인해야 합니다. 이를 위해 더 읽기
Kubernetes CronJob에서 nodeSelector와 nodeAffinity를 함께 사용하는 방법
Kubernetes의 CronJob을 특정 노드에 배포할 때, nodeSelector와 nodeAffinity를 조합하여 더욱 세밀한 노드 선택을 할 수 있습니다.이번 글에서는 기존 nodeSelector를 유지하면서 nodeAffinity를 추가하여 특정 조건을 만족하는 노드에서만 Pod가 실행되도록 설정하는 방법을 소개합니다. 기존 설정 (nodeSelector만 사용) 아래와 같은 CronJob 설정이 있다고 가정합니다.이 설정은 group=batch 라벨이 있는 노드에서만 실행됩니다. apiVersion: batch/v1kind: CronJobmetadata: 더 읽기
Kubernetes에서 특정 라벨을 가진 노드에 균등 분산하는 방법
Kubernetes 환경에서 특정 라벨을 가진 노드에 **Pod을 균등하게 분산(scheduling)**하는 방법을 정리합니다.이 글에서는 ext=test1 라벨을 가진 노드들에만 배포하면서, 특정 노드에 몰리지 않도록 균등 분산하는 방법을 다룹니다. 1️⃣ 문제 정의 📌 현재 노드 정보 노드 이름 ext 라벨 값 topology.kubernetes.io/zone ip-10-118-154-15 test1 ap-northeast-2c ip-10-118-153-114 test1 ap-northeast-2a ip-10-118-153-171 test2 ap-northeast-2a ✅ Pod을 ext=test1을 더 읽기
Kubernetes CronJob suspend 후 즉시 실행되는 원인과 해결 방법 & 노드 라벨 확인 방법
Kubernetes에서 CronJob을 suspend: true로 설정했다가 다시 suspend: false로 변경하면, 스케줄 시간이 아닌데도 즉시 실행되는 경우가 있습니다. 이 현상의 주요 원인과 해결 방법을 정리하겠습니다. 또한, Kubernetes 노드(Node)의 라벨(Label) 확인 방법도 함께 소개합니다. Kubernetes 노드 라벨 확인 방법 Kubernetes에서는 노드(Label)를 활용하여 워크로드를 특정 노드에 할당하거나, 스케줄링 정책을 적용할 수 있습니다. 노드의 라벨을 더 읽기
AWS Aurora MySQL 환경에서 HikariCP keepaliveTime 적용 조건과 커넥션 관리
내용 정정: Aurora MySQL이라는 이유만으로 HikariCP keepaliveTime이 불필요하다고 단정할 수 없습니다. DB·프록시·방화벽의 연결 제한, 드라이버와 HikariCP 버전에 따라 판단해야 합니다. 기존의 “Aurora Proxy” 표기는 AWS 서비스명인 RDS Proxy로 바로잡습니다. keepaliveTime이 하는 일 HikariCP가 풀의 유휴 연결을 주기적으로 확인하는 설정입니다. 사용 중인 쿼리의 실행 시간을 제한하거나 Failover로 끊긴 트랜잭션을 복구하지는 않습니다. 더 읽기
EKS 환경에서 Pod 장애 발생 시 요청을 이어받아 처리하는 방법
1. 개요 EKS 환경에서 Spring Boot 애플리케이션이 여러 개의 Pod에서 실행되고 있을 때,특정 Pod가 요청을 처리하는 중 장애로 종료되면, 다른 Pod에서 동일 요청을 이어서 처리할 수 있는가? 이 문서에서는 일반적인 CRUD 요청과 파일 업로드 요청 모두에 대해Pod 장애 발생 시에도 중단 없이 이어서 처리할 수 있는 방법을 설명합니다. 2. 첫 더 읽기
AWS Aurora Failover 대비 Spring Boot 트랜잭션 유지 및 커넥션 폐기 대응 방법
AWS Aurora를 사용하는 Spring Boot 애플리케이션에서 Writer 장애(Failover) 발생 시 트랜잭션을 유지하면서 서비스 중단을 최소화하려면 어떻게 해야 할까?Aurora 클러스터에 연결된 상태에서 Writer 장애 발생 시 기존 커넥션이 유지되지 않으며, 트랜잭션 처리 방식은 autocommit 설정에 따라 다르게 동작한다. 이 글에서는 Aurora 장애 발생 시 트랜잭션이 어떻게 동작하는지와 애플리케이션에서 최적의 대응 방법을 더 읽기