Docker + GitHub Actions 배포 vs 쿠버네티스 배포 비교

쿠버네티스를 이용한 배포 방식으로 변경하면 기존 Docker + GitHub Actions 기반 배포와 비교해서 차이가 많습니다.

특히, 온프레미스(개발 서버 직접 운영) 환경이라면, 쿠버네티스를 적용하는 방식이 다소 달라질 수 있습니다.

 

배포 방식기존 Docker + GitHub Actions쿠버네티스 (K8s)

 

배포 대상	EC2 또는 직접 구축한 서버에서 실행	쿠버네티스 클러스터 (온프레미스 or 클라우드)
실행 방식	서버에서 Docker 컨테이너 직접 실행	K8s의 Pod 단위로 컨테이너 관리
배포 방식	GitHub Actions에서 docker build → docker run	GitHub Actions에서 kubectl apply
확장 방식	서버의 스펙을 높이거나, 새로운 서버 추가 후 수동 배포	HPA(Pod 자동 확장), Node 추가 가능
장애 대응	컨테이너가 죽으면 수동으로 재시작 필요	쿠버네티스가 자동으로 복구 (Self-healing)
네트워크 관리	Docker 컨테이너별 포트 설정	K8s Service & Ingress 컨트롤 가능
로드 밸런싱	Nginx 또는 AWS ELB 사용	쿠버네티스 자체 로드 밸런싱 지원

👉 결론: 기존 Docker 배포보다 확장성, 장애 대응, 자동 복구, 트래픽 관리 측면에서 쿠버네티스가 훨씬 유리함. 하지만 운영이 더 복잡할 수 있음.

 

 

기존 Docker + GitHub Actions 배포 방식

🔹 기존 배포 과정 (Docker 방식)

1️⃣ GitHub Actions 실행 → 서버에서 Docker 이미지 빌드

- name: Build Docker Image
  run: docker build -t my-app .

 

2️⃣ Docker Hub or ECR에 푸시

- name: Push to Docker Hub
  run: docker push my-app

 

3️⃣ 서버에 SSH 접속 후 실행

- name: Deploy to Server
  run: |
    ssh user@server "docker stop my-app && docker rm my-app"
    ssh user@server "docker run -d -p 8080:8080 my-app"

✔️ 문제점:

• 서버에 직접 Docker 컨테이너를 실행하는 방식이라 서버 장애 발생 시 자동 복구 안됨
• 스케일링(트래픽 증가 시 확장)이 어렵고, 컨테이너 개수를 늘리면 수동으로 관리해야 함

---

🚀 쿠버네티스 기반 배포 방식

쿠버네티스로 전환하면 기존 Docker 배포보다 더 유연하고 자동화된 방식으로 운영 가능.

🔹 쿠버네티스 배포 과정 (K8s 방식)

1️⃣ GitHub Actions 실행 → Docker 이미지 빌드

- name: Build Docker Image
  run: docker build -t my-app .

 

2️⃣ 이미지를 컨테이너 레지스트리(Docker Hub, ECR, Private Registry)에 푸시

- name: Push to Docker Hub
  run: docker push my-app

 

3️⃣ 서버의 쿠버네티스 클러스터에 kubectl apply

- name: Deploy to Kubernetes
  run: kubectl apply -f deployment.yaml

 

✔️ 차이점:

• GitHub Actions에서 docker run으로 직접 실행하는 것이 아니라, 쿠버네티스 클러스터에 배포
• 서버 장애 발생 시 쿠버네티스가 자동 복구
• HPA (Horizontal Pod Autoscaler)로 트래픽 증가 시 자동 확장 가능

---

🚀 쿠버네티스 배포 시 필요한 구성 요소

쿠버네티스로 배포하려면 기존과 다른 몇 가지 추가 설정이 필요.

✅ 1) Deployment 설정 (deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        ports:
        - containerPort: 8080

✔️ Pod 개수(replica)를 설정하여 스케일링 가능

---

✅ 2) Service 설정 (service.yaml)

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

✔️ 쿠버네티스 내부에서 Pod 간 트래픽을 관리
✔️ LoadBalancer 타입을 사용하여 외부에서 접근 가능

---

✅ 3) Ingress 설정 (ingress.yaml, 선택)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

✔️ 도메인을 통해 접근하도록 설정 (Nginx Ingress 사용 가능)

---

🚀 쿠버네티스로 바뀌면 무엇이 편리해질까?

기능기존 Docker 배포쿠버네티스 배포

자동 복구	컨테이너 죽으면 직접 재시작 필요	Pod가 죽으면 K8s가 자동으로 재시작
트래픽 증가 대응	서버 수동 추가 필요	HPA(Pod 자동 확장) 사용 가능
로드 밸런싱	Nginx 등 직접 설정	K8s Service & Ingress로 자동 관리
Zero-Downtime 배포	기존 컨테이너 중지 후 배포	Rolling Update로 무중단 배포 가능
다중 서버 관리	수동으로 서버 추가	K8s 노드 추가로 자동 확장

---

🚀 쿠버네티스로 전환하면 이런 점이 좋아짐

1️⃣ 트래픽 증가 시, 자동으로 Pod 개수를 늘릴 수 있음 (HPA 사용)
2️⃣ 서버 장애 발생 시, 자동으로 복구됨 (Self-Healing)
3️⃣ CI/CD 연동하여 무중단 배포(Rolling Update) 가능
4️⃣ 서비스 간 통신(Networking)이 자동 관리됨 (Service & Ingress 활용)
5️⃣ 운영이 안정적이고, 확장성이 좋아짐 (스케일아웃이 유리함)

---

🚀 결론: 쿠버네티스로 전환하는 게 좋은 경우

✅ 개발 서버가 여러 개 있고, 트래픽 증가 시 자동 확장이 필요할 때
✅ 서버 장애가 나도 자동 복구되도록 운영하고 싶을 때
✅ Zero-Downtime 배포(무중단 배포)를 적용하고 싶을 때
✅ CI/CD 파이프라인을 K8s 기반으로 개선하고 싶을 때