AWS EKS(Elastic Kubernetes Service) 환경에서 Python 기반 서비스가 S3, DynamoDB와 같은 AWS 리소스에 접근하기 위해 boto3.client를 사용할 경우, aws_access_key_id 및 aws_secret_access_key를 코드나 설정 파일에 명시적으로 설정할 필요가 있는지에 대해 많은 분들이 궁금해하십니다.결론적으로, AWS의 고급 보안 기능을 활용하시면 해당 자격 증명을 직접 설정할 필요가 없습니다.이는 AWS EKS가 제공하는 핵심 기능 중 하나인 IRSA(IAM Roles for Service Accounts) 덕분입니다.1. Access Key를 설정하지 않아도 되는 근본적인 이유일반적으로 AWS 환경 외부에서 boto3 라이브러리를 사용할 ..

Kubernetes를 공부하거나 실제로 운영 환경에 적용하다 보면 "컨테이너"와 "파드"라는 용어가 자주 등장합니다. 두 개념은 비슷해 보이지만, Kubernetes에서는 엄연히 다른 역할을 가지고 있습니다. 이 글에서는 컨테이너와 파드의 개념을 비교하며, 어떤 차이가 있는지 정리해보겠습니다.컨테이너란?컨테이너(Container)는 애플리케이션과 그 실행 환경을 하나로 패키징한 단위입니다. 운영체제 수준의 가상화를 통해, 어떤 환경에서도 동일하게 애플리케이션을 실행할 수 있도록 만들어줍니다. 대표적으로 Docker 컨테이너가 많이 사용됩니다.컨테이너는 다음과 같은 특징을 가집니다.애플리케이션, 라이브러리, 설정 파일 등을 포함격리된 환경에서 실행되며, 가볍고 빠르게 구동됨단독 실행도 가능 (docker ..

문제 상황내부에서 운영 중인 두 개의 API Pod A와 B가 있습니다. Pod A는 Pod B의 특정 API를 호출하여 인증 등의 기능을 위임하고 있으며, 이들은 Kubernetes 클러스터 내에서 서비스 이름을 기반으로 통신하고 있습니다.문제는 간헐적으로 다음과 같은 예외가 발생한다는 점이었습니다.java.net.SocketException: Connection reset특정 시점에서 API 호출이 실패하고, 호출하는 쪽에서 위와 같은 오류가 발생했습니다. Pod B를 재시작하면 문제가 일시적으로 해결되었지만, 원인을 명확히 파악하지 못해 대응이 어려운 상황이었습니다.원인 분석에러 메시지와 인프라 구조를 바탕으로 다음과 같은 가능성을 검토하였습니다.1. 애플리케이션이 응답하지 않는 상태Pod 내부에서..

Spring Boot 기반 애플리케이션을 Kubernetes 환경에 배포하면서, 로그 수집 방식에서 다음과 같은 문제가 발생했다. 동일한 로그 경로에 여러 Pod가 동시에 접근하면서 로그가 덮어씌워지거나 뒤섞이는 문제가 생긴 것이다. 이를 해결하기 위해 Pod별로 로그를 분리하고, 날짜 기준으로 Rolling 되도록 설정한 경험을 정리해본다.1. 로그 파일이 충돌하는 문제 발생애플리케이션 로그는 app.log라는 고정된 파일명으로 기록되고 있었고, 이는 여러 Pod가 동일한 볼륨을 공유할 경우 로그 충돌을 일으켰다. 특히 상태 비저장(Stateless)한 구조에서 동시성이 높은 상황에서는 로그 유실이나 파일 잠금 문제가 발생할 수 있었다. 따라서 Pod마다 고유한 로그 파일을 생성하는 방식이 필요했다.2..

Kubernetes(쿠버네티스, 이하 K8s)는 컨테이너 오케스트레이션을 위한 오픈소스 플랫폼으로, 여러 대의 서버를 클러스터로 묶고 그 위에서 애플리케이션을 안정적으로 운영할 수 있도록 돕는 도구입니다. K8s를 실무에서 활용하다 보면 클러스터의 구조와 상태를 확인해야 할 일이 자주 생기는데요, 이번 글에서는 kubectl 명령어와 시각화 도구를 이용해 K8s 클러스터 구조를 파악하는 방법을 정리해 보겠습니다.클러스터 구조를 확인해야 하는 이유클러스터의 상태를 모니터링하고 문제를 빠르게 인지하기 위해파드나 서비스가 어느 노드에서 구동 중인지 파악하기 위해리소스의 할당 상태, 스케줄링 현황, 이벤트 로그 등을 분석하기 위해실습 환경 또는 운영 환경의 구조를 시각화해 문서화하거나 공유하기 위해1. 클러스터..