[EKS] Spring 모놀리식 서버의 EKS 기반 클라우드 네이티브 배포 아키텍처 및 자동화 정리

0. 들어가며

현대적인 백엔드 아키텍처의 지향점은 단순히 코드를 잘 짜는 것을 넘어, 작성한 애플리케이션을 얼마나 안정적이고, 유연하며, 관측 가능한 형태로 배포하고 운영하느냐에 달려 있다. 단일 소스 기반의 Spring 모놀리식 애플리케이션이라 할지라도 쿠버네티스(Kubernetes) 생태계와 결합하면 고가용성, 무중단 배포, 탄력적 오토스케일링 등의 클라우드 네이티브 이점을 극대화할 수 있다.

[EKS] 쿠버네티스 핵심 컴포넌(Pod, Service, Deployment) 동작 원리 파악

 

이 글에서는 AWS EKS를 기반으로 Spring Boot 서버를 다중 인스턴스로 분산 배포하고, RDS/Redis 인프라 연동, GitHub Actions를 통한 CI/CD 파이프라인, cert-manager 기반 HTTPS 암호화, Pod/Node 이중 오토스케일링, 그리고 ArgoCD 및 Prometheus/Grafana를 이용한 모니터링까지 아우르는 엔터프라이즈급 실무 배포 파이프라인을 완전히 해부해 본다.

 

 

1. 전체 배포 아키텍처 및 트래픽 흐름

우리가 도달해야 할 최종 인프라 아키텍처의 모습을 먼저 정의하고 출발하자. 전체 트래픽은 외부 인터넷 망에서 AWS Route53과 Application Load Balancer(ALB Ingress)를 거쳐 EKS 클러스터 내부로 인입된다.

 

 

2. 인프라 자원 사전 생성 및 수동 부트스트랩

자동화된 파이프라인이 정상적으로 돌기 위해서는 데이터베이스, 보안 그룹, 이미지 저장소 등의 뼈대가 미리 생성되어 있어야 한다. 초기 인프라 프로비저닝 단계를 밟아보자.

2.1 RDS MySQL 생성 및 네트워크 장벽 제거

AWS 콘솔 또는 CLI를 사용하여 RDS MySQL을 생성한다. Spring Boot가 상용 서버 환경에서 안전하게 커넥션을 맺을 수 있도록 네트워크 구성을 세팅한다.

1. RDS MySQL 데이터베이스 생성: 스펙에 맞는 인스턴스(예: db.t3.medium)와 엔진 버전(예: MySQL 8.0)을 선택한다.
2. 보안 그룹(Security Group) 규칙 설정: RDS의 보안 그룹에 인바운드 규칙을 추가한다. EKS의 워커 노드가 사용하는 보안 그룹 대역 또는 특정 서브넷 IP 대역으로부터 TCP 3306 포트의 인입을 허용한다.
3. 퍼블릭 액세스 허용(테스트 목적): 실무에서는 엄격히 private 서브넷 배치를 지향하지만, 초기 마이그레이션 및 간편한 로컬 DDL 실행을 위해 퍼블릭 액세스를 일시 허용할 경우 외부 IP 주소 바인딩을 정확히 확인해야 한다.
4. 스키마 생성: 외부 DB 툴(DBeaver, IntelliJ Database 등)로 RDS에 접속하여 Spring 시스템의 근간이 되는 초기 데이터베이스 스키마(예: ordersystem)를 구성한다.

 

2.2 Redis Pod 및 서비스 적용

Spring 컨테이너들이 세션 저장 및 임시 캐싱 용도로 사용할 인메모리 DB를 K8s 내부 서비스로 미리 배포한다.

# redis-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-deployment
  namespace: my-namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7.0-alpine
        ports:
        - containerPort: 6379
---
# redis-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: redis-service
  namespace: my-namespace
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis

 

2.3 ECR 레포지토리 및 수동 도커 이미지 부트스트랩

GitHub Actions가 컨테이너 이미지를 밀어 넣을 저장소인 AWS ECR(Elastic Container Registry)을 생성하고, 최초의 이미지를 개발자 로컬 머신에서 수동으로 빌드하여 업로드해 본다.

1. ECR 레포지토리 생성: AWS Console에서 ordersystem-backend라는 이름의 프라이빗 레포지토리를 생성한다.
2. Spring Boot 설정: 로컬의 application.yml 파일의 프로필 설정을 운영(prod)으로 매핑한다.
3. 로컬 환경에서의 인증 및 이미지 Push: 터미널에서 아래의 명령을 차례대로 수행한다. (자신의 AWS 계정 ID 148761635844 기준)

# 1. AWS CLI를 통한 ECR 로그인 토큰 획득 및 도커 클라이언트 로그인
aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin 148761635844.dkr.ecr.ap-northeast-2.amazonaws.com

# 2. 로컬에서 Dockerfile을 기준으로 컨테이너 이미지 빌드
# 멀티 스테이지 빌드가 적용된 4.ordersystem 디렉토리 경로 기준
docker build -t [148761635844.dkr.ecr.ap-northeast-2.amazonaws.com/ordersystem-backend:latest](https://148761635844.dkr.ecr.ap-northeast-2.amazonaws.com/ordersystem-backend:latest) -f ./4.ordersystem/Dockerfile ./4.ordersystem

# 3. 중앙 저장소로 빌드된 도커 이미지 업로드
docker push [148761635844.dkr.ecr.ap-northeast-2.amazonaws.com/ordersystem-backend:latest](https://148761635844.dkr.ecr.ap-northeast-2.amazonaws.com/ordersystem-backend:latest)

 

 

3. 쿠버네티스 핵심 리소스 설계 (Secret, Deployment, Service, Ingress)

컨테이너가 EKS에 올라갔을 때 안정적으로 외부 연결 정보를 바인딩하고 가동될 수 있도록 선언적 오브젝트 설정을 설계한다. 민감 정보는 별도의 보안 리소스인 Secret을 통해 캡슐화한다.

 

3.1 K8s Secret 생성 및 관리

보안 관련 민감 정보를 관리하는 명령들이다.

# 중요 변수들을 주입하여 Secret 리소스 생성
kubectl create secret generic my-app-secrets \
  --from-literal=REDIS_HOST=redis-service.my-namespace.svc.cluster.local \
  --from-literal=DB_HOST=your-rds-endpoint.ap-northeast-2.rds.amazonaws.com \
  --from-literal=DB_USERNAME=admin \
  --from-literal=DB_PW=securepassword \
  -n my-namespace

# Secret 디버깅 및 명세 조회 (Base64 인코딩 결과 반환)
kubectl get secret my-app-secrets -n my-namespace -o yaml

# Secret 삭제 명령어
kubectl delete secret my-app-secrets -n my-namespace

 

3.2 Spring Boot application.yml (prod 환경)

컨테이너의 런타임 환경 변수를 Spring의 바인딩 시스템과 결합하여 보안 위협을 격리한다.

# application-prod.yml
spring:
  datasource:
    url: jdbc:mysql://${DB_HOST}:3306/ordersystem?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
    username: ${DB_USERNAME}
    password: ${DB_PW}
    driver-class-name: com.mysql.cj.jdbc.Driver
  redis:
    host: ${REDIS_HOST}
    port: 6379

 

3.3 Spring Boot Deployment & Service 통합 매니페스트

고가용성을 위해 다중 인스턴스(Replicas: 3) 구조를 취하고, 리소스 한계를 제한(Resource Limits)하여 파드 간의 간섭을 차단한다.

# spring-app-manifest.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: brad-order-backend
  namespace: my-namespace
  labels:
    app: brad-order-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: brad-order-backend
  template:
    metadata:
      labels:
        app: brad-order-backend
    spec:
      containers:
      - name: app-container
        image: [148761635844.dkr.ecr.ap-northeast-2.amazonaws.com/ordersystem-backend:latest](https://148761635844.dkr.ecr.ap-northeast-2.amazonaws.com/ordersystem-backend:latest)
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "200m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi"
        env:
        - name: SPRING_PROFILES_ACTIVE
          value: "prod"
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: my-app-secrets
              key: DB_HOST
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: my-app-secrets
              key: DB_USERNAME
        - name: DB_PW
          valueFrom:
            secretKeyRef:
              name: my-app-secrets
              key: DB_PW
        - name: REDIS_HOST
          valueFrom:
            secretKeyRef:
              name: my-app-secrets
              key: REDIS_HOST
---
apiVersion: v1
kind: Service
metadata:
  name: brad-order-backend-service
  namespace: my-namespace
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: brad-order-backend

 

 

4. 인증서 자동 관리와 HTTPS 통신 (Cert-Manager)

보안 통신인 HTTPS(TLS/SSL)를 인입 단계에서 처리하기 위해, 자가 서명 및 갱신이 가능한 오픈소스 컨트롤러인 cert-manager를 K8s에 이식하고 자동으로 인증서 서명 요청서(CSR)를 발급받는 메커니즘을 적용한다.

4.1 인증서 발급 아키텍처 및 원리

전통적인 인증서 발급 프로세스는 아래와 같이 쿠버네티스 컨트롤러 내부에서 자동 조율 루프로 승화된다.

 

4.2 Cert-Manager 컨트롤러 설치 및 구축

K8s API의 데이터 구조(CRDs)를 확장하고, cert-manager 전용 서비스와 기동 컴포넌트를 이식한다.

# 1. 독립적인 격리 네임스페이스 생성
kubectl create namespace cert-manager

# 2. cert-manager가 인지할 Custom Resource Definition (Issuer, Certificate 등) 반영
kubectl apply -f [https://github.com/cert-manager/cert-manager/releases/download/v1.5.0/cert-manager.crds.yaml](https://github.com/cert-manager/cert-manager/releases/download/v1.5.0/cert-manager.crds.yaml)

# 3. 핵심 컨트롤러 구성 요소 배포
kubectl apply -f [https://github.com/cert-manager/cert-manager/releases/download/v1.5.0/cert-manager.yaml](https://github.com/cert-manager/cert-manager/releases/download/v1.5.0/cert-manager.yaml)

 

4.3 ClusterIssuer 및 Certificate 발급 선언

실제 CA(인증기관)와 도메인 자격 증명을 획득할 정보를 K8s에 등록한다.

# cluster-issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # Let's Encrypt 디렉토리 엔드포인트
    server: [https://acme-v02.api.letsencrypt.org/directory](https://acme-v02.api.letsencrypt.org/directory)
    email: admin@bradkim198.shop
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx
---
# certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: order-api-tls
  namespace: my-namespace
spec:
  secretName: brad-order-backend-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - brad-order-backend.shop

위 자원이 생성되면 cert-manager가 외부 Let's Encrypt와 통신하여 챌린지를 마친 후 자동으로 brad-order-backend-tls라는 K8s Secret에 유효한 공개키와 비밀키를 기입해 준다.

# 발급 성공 여부 확인 (Status가 True로 명시되는지 관찰)
kubectl describe certificate order-api-tls -n my-namespace

 

4.4 Ingress 리소스를 통한 HTTPS 자동 연동

생성된 TLS Secret을 Ingress에 연계하여 외부로부터 들어오는 HTTPS 통신을 터미네이션한다.

# app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - brad-order-backend.shop
    secretName: brad-order-backend-tls
  rules:
  - host: brad-order-backend.shop
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: brad-order-backend-service
            port:
              number: 80

 

 

5. GitHub Actions를 이용한 CI/CD 자동화 파이프라인

소스 코드 저장소인 GitHub의 갱신 주기와 클라우드 호스팅 인프라를 연결한다. GitHub Actions는 이벤트(Push, PR 등)에 반응하여 가상 컴퓨팅 환경(Runner)을 열고, 빌드, 이미지 압축, AWS 인증, 그리고 배포 트리거까지의 과정을 자율 조율한다.

5.1 CI/CD 전체 프로세스 단계

GitHub Actions 워크플로우는 다음과 같이 설계되어 돌아간다.

 

5.2 GitHub Repository Secrets 구성

빌드에 필요한 AWS 보안 키셋 및 핵심 전역 변수들을 GitHub 저장소 Settings -> Secrets and variables -> Actions 에 수동 등록해 둔다.

• AWS_ACCESS_KEY_ID: IAM 사용자의 엑세스 키
• AWS_SECRET_ACCESS_KEY: IAM 사용자의 비밀 엑세스 키
• AWS_REGION: ap-northeast-2

 

5.3 GitHub Actions Workflow YAML 정의

이벤트 감지 및 가상 머신 구동 지침을 수립한 코드 파일이다.

# .github/workflows/deploy.yml
name: CI/CD Pipeline to AWS EKS

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    
    steps:
    # 1. 소스 코드 소유권 복제
    - name: Checkout code
      uses: actions/checkout@v3

    # 2. JVM 기동을 위한 JDK 설치
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'

    # 3. 빌드 권한 부여 및 빌드 진행
    - name: Grant execute permission for gradlew
      run: chmod +x ./4.ordersystem/gradlew

    - name: Build with Gradle
      run: ./4.ordersystem/gradlew build -x test --project-dir ./4.ordersystem

    # 4. AWS 로그인 자격 인증 설정
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ secrets.AWS_REGION }}

    # 5. AWS ECR 토큰 발급 및 로그인
    - name: Log in to AWS ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    # 6. 도커 빌드, 고유 커밋 태그 생성 및 저장소 배포
    - name: Build, tag, and push image to Amazon ECR
      env:
        ECR_REGISTRY: 148761635844.dkr.ecr.ap-northeast-2.amazonaws.com
        ECR_REPOSITORY: ordersystem-backend
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG -t $ECR_REGISTRY/$ECR_REPOSITORY:latest -f ./4.ordersystem/Dockerfile ./4.ordersystem
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:latest

 

 

6. 이중 오토스케일링 전략 (Pod HPA & EC2 CA)

대규모 트래픽 유입이나 예기치 못한 시스템 자원 고갈 상황이 발생하더라도 스스로 인프라 자원을 불리고 줄일 수 있는 이중 방어막을 구축한다. K8s의 오토스케일링은 파드 수준의 오토스케일러(HPA)와 물리 서버 수준의 오토스케일러(CA)가 맞물려 연쇄 회로처럼 작동한다.

6.1 수평 파드 오토스케일링 (Horizontal Pod Autoscaler - HPA)

파드의 자원 현황을 모니터링하여 개수를 동적으로 증감시키는 HPA를 구성한다.

1. 메트릭 서버 설치: HPA가 각 파드의 물리적 CPU, 메모리 자원 상황을 관측할 수 있도록 메트릭 수집 에이전트를 먼저 설치한다.

kubectl apply -f [https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.3/components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.3/components.yaml)

1. HPA 매니페스트 배포:

# hpa-config.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: brad-order-backend-hpa
  namespace: my-namespace
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: brad-order-backend
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50 # CPU 사용량이 50%를 상회할 시 스케일 아웃

1. HPA 실시간 모니터링 모드 가동:

# 실시간 모니터링을 통한 추적
kubectl get hpa brad-order-backend-hpa -n my-namespace -w

1. 부하 테스트 및 파드 증감 검증: 특정 파드의 쉘 콘솔로 진입하여 인위적으로 고성능 요청 트래픽 루프를 유발시켜 본다.

# 특정 구동 중인 파드로 내부 진입
kubectl exec -it <brad-order-backend-pod-name> -n my-namespace -- /bin/sh

# 내부 curl 툴 다운로드 (alpine 이미지 기준)
apk add --no-cache curl

# 무한 루프 요청을 통해 파드 CPU에 부하 유발
while true; do curl -s http://brad-order-backend-service/product/list; done

• 결과: CPU 부하가 폭발함과 동시에 HPA의 타겟 수치가 50%를 초과하게 되며, 순식간에 Replicas가 최소 3개에서 최대 10개까지 늘어나는 모습을 확인할 수 있다. 부하를 강제로 중단하면 약 5분 가량의 대기 시간(Cool-down)을 거쳐 파드가 점진적으로 원복된다.

 

6.2 물리 노드 오토스케일링 (Cluster Autoscaler - CA)

컨테이너들이 증식하여 물리 서버(EC2 Node)의 CPU나 메모리 자원 여유 공간이 완전히 소실되면 새로운 파드들이 Pending 상태에 갇히게 된다. 이때 Cluster Autoscaler는 자원 부족을 감지하고 AWS의 EC2 Auto Scaling Group(ASG)에 새로운 물리 컴퓨터 노드를 붙여달라고 자동 긴급 신호를 요청한다.

1단계: ASG 태그 주입 및 OIDC 연동

• AWS EC2 서비스 콘솔 -> 오토스케일링 그룹(ASG) 세팅으로 이동하여 해당 EKS 노드 그룹이 지닌 ASG에 자율 관제 태그를 강제 등록한다.
  • k8s.io/cluster-autoscaler/enabled -> true
  • k8s.io/cluster-autoscaler/<EKS_클러스터_이름> -> owned
• IAM의 ID 제공업체(OpenID Connect) 목록에 EKS 클러스터의 OIDC 공급자 URL을 삽입하여 STS 임시 서명 토큰 발급 주체로 등록한다. (대상에는 sts.amazonaws.com 입력)

 

2단계: IAM 역할 및 신뢰 관계 정책 수립

AWS 리소스를 제어하기 위해 CA 파드가 사용할 IAM Role을 정의하고, 특정 서비스 어카운트에 바인딩을 신뢰하도록 설정한다.

// IAM Trust Relationship Policy
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::148761635844:oidc-provider/[oidc.eks.ap-northeast-2.amazonaws.com/id/YOUR_EKS_OIDC_HASH](https://oidc.eks.ap-northeast-2.amazonaws.com/id/YOUR_EKS_OIDC_HASH)"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "[oidc.eks.ap-northeast-2.amazonaws.com/id/YOUR_EKS_OIDC_HASH:sub](https://oidc.eks.ap-northeast-2.amazonaws.com/id/YOUR_EKS_OIDC_HASH:sub)": "system:serviceaccount:kube-system:cluster-autoscaler"
        }
      }
    }
  ]
}

• 위 역할에 다음 AWS 관리형 정책을 바인딩한다: AmazonEKSClusterPolicy, AutoScalingFullAccess, AmazonEC2FullAccess

 

3단계: Cluster Autoscaler 리소스 배포 및 SA 매핑

CA 컨트롤러의 뼈대 야믈 파일을 다운로드하여 튜닝한다.

curl -o cluster-autoscaler-autodiscover.yaml [https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml](https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml)

이 다운로드한 명세 파일 중 서비스 어카운트(ServiceAccount) 및 커맨드 설정 부분을 핵심 수정사항에 맞춰 아래와 같이 가공한다.

# cluster-autoscaler-autodiscover.yaml 수정 발췌본
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-addon: cluster-autoscaler.addons.k8s.io
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
  namespace: kube-system
  annotations:
    # 2단계에서 미리 만들어둔 IAM Role의 ARN을 매핑한다.
    [eks.amazonaws.com/role-arn](https://eks.amazonaws.com/role-arn): arn:aws:iam::148761635844:role/autoscale-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
  labels:
    app: cluster-autoscaler
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cluster-autoscaler
  template:
    metadata:
      labels:
        app: cluster-autoscaler
    spec:
      serviceAccountName: cluster-autoscaler
      containers:
        # 자신의 쿠버네티스 마이너 버전과 매치되는 CA 이미지 버전 설정
      - image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.29.0
        name: cluster-autoscaler
        command:
          - ./cluster-autoscaler
          - --v=4
          - --stderrthreshold=info
          - --cloud-provider=aws
          - --skip-nodes-with-local-storage=false
          - --expander=least-waste
          - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
        env:
        - name: AWS_REGION
          value: "ap-northeast-2"

위 수정본을 클러스터에 배포한다.

kubectl apply -f cluster-autoscaler-autodiscover.yaml

 

 

7. GitOps CD와 관측 가능성 인프라 (ArgoCD, Prometheus, Grafana)

배포 자동화의 정수이자 현대 개발 문화의 기준인 GitOps 엔진 ArgoCD를 기동하고, 가동 인프라의 하드웨어 리소스 상황을 가시화해 보여주는 Prometheus & Grafana 모니터링 환경을 정초한다.

7.1 ArgoCD 구축 및 Sync 선언

ArgoCD는 Git 저장소의 K8s 매니페스트 파일 변화를 실시간으로 감시하여 클러스터와 완전히 동일한 상태로 싱크로나이즈하는 상태 일치 메커니즘을 제공한다.

# 1. ArgoCD 관리 독립 네임스페이스 수립
kubectl create namespace argocd

# 2. ArgoCD 코어 컨트롤러 및 서비스 설치
kubectl apply -n argocd -f [https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml)

실제 ArgoCD가 바라볼 Git 타겟 저장소 및 브랜치 정보를 알려주기 위해 아래 Application 명세를 작성하여 배포한다.

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ordersystem-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: '[https://github.com/your-username/ordersystem-gitops.git](https://github.com/your-username/ordersystem-gitops.git)'
    targetRevision: HEAD
    path: k8s-manifests
  destination:
    server: '[https://kubernetes.default.svc](https://kubernetes.default.svc)'
    namespace: my-namespace
  syncPolicy:
    automated:
      prune: true       # Git에서 삭제된 자원은 클러스터에서도 자동 추방
      selfHeal: true    # 수동 변조 발생 시 Git 스펙으로 자가 복구 강제 실행

로컬 대시보드 및 퍼블릭 SSL 우회 튜닝

로컬에서 임시 대시보드 포트를 열어 확인할 때는 다음을 사용한다.

kubectl port-forward svc/argocd-server -n argocd 8080:443

만약 퍼블릭 도메인(https://argo.bradkim198.shop)을 연동하여 웹 접속 통로를 열어두려면, 외부 로드밸런서 계층에서 복호화된 http가 argocd 내부 SSL 프로토콜과 마찰을 빚지 않도록 서버 설정을 강제로 평문화해야 한다.

# ArgoCD 서버 디플로이먼트 수정 모드 진입
kubectl edit deployment argocd-server -n argocd

열린 설정 파일 내부에서 argocd-server 실행 파라미터 컨테이너 아규먼트(args) 줄을 찾아 --insecure 옵션을 단독 추가한다.

# Deployment args 수정부 예시
      containers:
      - args:
        - /usr/local/bin/argocd-server
        - --insecure  # 이 라인을 추가하여 내부 HTTPS 의존 제거

• 수정 후 저장하고 닫으면 자동으로 argocd-server 롤아웃이 실행되어 무중단 적용된다.

초기 로그인 정보 추출 방법

• 계정: admin
• 비밀번호: 암호화된 초기 패스워드를 획득하여 디코딩한다.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 --decode

 

7.2 프로메테우스 및 그라파나 모니터링 시스템 이식

시스템의 건전성을 정량적 수치 데이터로 축적하고 이를 시각적 인포그래픽으로 감시할 환경을 마련한다.

1. 격리 네임스페이스 수립:

kubectl create namespace monitoring

1. 프로메테우스, Node Exporter, 그라파나 패키지 설치: 대규모 자원 매니페스트 수집 모음 파일을 쿠버네티스 클러스터에 즉시 전파한다.

# 통합 prometheus-grafana 올인원 스택 설치
kubectl apply -f [https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests-all--in-one.yaml](https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests-all--in-one.yaml) -n monitoring

1. 로컬 웹 브라우저 포트 포워딩 연결:

kubectl port-forward svc/grafana -n monitoring 3000:3000

• 웹 브라우저로 http://localhost:3000 접속 (초기 ID/PW: admin / admin)

1. 그라파나 - 프로메테우스 연결 및 대시보드 임포트:
   • Connections -> Data Sources로 접속하여 Add data source를 누른다.
   • Prometheus 타입을 선택한다.
   • 내부 URL 칸에 프로메테우스 서비스 네임 주소인 http://prometheus-service.monitoring.svc.cluster.local:9090 (혹은 단축형 http://prometheus-service:9090)을 입력하고 Save & Test를 확인한다.
   • Dashboards -> Import 메뉴를 선택한다.
   • Grafana.com 공식 템플릿 검색 ID 란에 쿠버네티스 노드 통합 모니터링 대시보드 표준 식별 번호인 1860을 입력하고 Load를 실행한다.

 

 

8. 실무 운영자용 체크리스트 및 트러블슈팅

성공적인 배포 완료 이후, 시스템 안정성을 유지하기 위한 실무 가이드라인을 공유한다.

체크 포인트	발생 상황	디버깅 및 점검 행동 지침
Pending 상태의 파드	스케일 아웃 도중 파드가 안 뜸	kubectl describe pod <pod-name> 명령으로 이벤트 원인 조회. 리소스 한도(Resource Limits) 과다 산정 여부 확인 및 노드 용량(CA 작동 여부) 점검.
CrashLoopBackOff 에러	컨테이너가 뜬 후 즉시 사망	kubectl logs <pod-name> -n my-namespace 명령으로 Spring Boot 부팅 예외 로그 검색. 주로 외부 Secret(DB/Redis 호스트, 암호) 주입 누락이나 DB 스키마 생성 누락이 원인.
Secret 데이터 갱신	DB 비밀번호 변경 필요 시	Secret 리소스를 재생성(kubectl delete secret -> kubectl create secret)한 후, Spring Boot Deployment를 무중단 재배포(kubectl rollout restart deployment brad-order-backend)하여 캐시 갱신.
ArgoCD Out of Sync	Git 상태와 클러스터 불일치	ArgoCD 대시보드에서 Sync 실패 유발 원인 컴포넌트 추적. 대개 수동으로 클러스터의 레이블이나 포트를 임의 변경하여 YAML 제약 사항에 위배된 경우로, 대시보드의 Sync -> Force 혹은 Prune 처리로 수습.

 

 

9. 요약 및 결론

EKS 기반의 클라우드 네이티브 아키텍처는 가파르게 전개되는 트래픽 변화 속에서도 비즈니스 아이디어를 빠르고 유연하게 가동하기 위한 최적의 엔지니어링 패러다임이다.

우리는 데이터베이스 및 인메모리 캐시 연동 등의 물리 환경을 사전에 프로비저닝한 후, Secret 리소스를 통해 암호 데이터를 은닉화하였다. 이어서 cert-manager 기반의 Let's Encrypt 자동 갱신 체계를 마련하여 네트워크 입구를 강력히 보호하고, GitHub Actions라는 자동화 수단과 ArgoCD라는 자율 조율 루프를 연결해 완벽한 GitOps 선순환 배포 체계를 확립하였다.

나아가 트래픽 폭증 상황에 유연히 적응할 수 있는 이중 오토스케일링(HPA/CA) 메커니즘을 설계하여 시스템 안전 마진을 사수하였으며, Prometheus와 Grafana를 통한 전방위 시각 자료 모니터링을 완성하여 24시간 중단 없는 신뢰성 있는 인프라의 주춧돌을 세우게 되었다. 본 가이드가 여러분의 마이그레이션과 클라우드 아키텍처 구축 여정에 든든한 밑거름이 되기를 소망한다.

 

 

 

 

 

 

# 본 이미지들은 AI를 이용하여 생성하였습니다.