비즈니스 애플리케이션을 위한 쿠버네티스 기초

비즈니스 팀을 위한 군더더기 없는 실용적인 쿠버네티스 입문서: 핵심 객체가 하는 역할, 복사해서 바로 쓸 수 있는 실제 배포 예제, 그리고 PDPL 데이터 거주 요건을 충족하기 위해 사우디 국내 Skyline Cloud 인프라에서 실행하는 방법을 다룹니다.

SKYLINE Engineering @skyline

게시일 2026년 6월 8일 | 읽는 시간 6분

비즈니스 애플리케이션을 위한 쿠버네티스 기초

쿠버네티스(흔히 "K8s"로 줄여 부릅니다)는 컨테이너화된 애플리케이션을 프로덕션 환경에서 실행하기 위한 표준입니다. 비즈니스 관점에서 그 가치는 구체적입니다. 서버에 장애가 발생해도 앱을 계속 구동하고, 부하가 몰릴 때 확장하며, 다운타임 없이 새 버전을 배포하고, 청구 API부터 고객 포털에 이르기까지 모든 것을 운영하는 일관된 방식을 팀에 제공합니다.

이 튜토리얼은 핵심 구성 요소를 설명하고, 복사해서 바로 쓸 수 있는 실제 배포 과정을 안내하며, 데이터가 사우디 PDPL, NCA, SDAIA 요건의 적용을 받도록 사우디 국내 인프라에서 실행하는 방법을 보여 줍니다.

비즈니스가 쿠버네티스를 사용하는 이유

작은 단일 웹사이트 하나에는 쿠버네티스가 필요하지 않습니다. 여러 개의 서비스, 여러 환경, 또는 가동 시간(업타임) 의무가 생기기 시작할 때 비로소 필요해집니다. 실질적인 이점은 다음과 같습니다.

• 자가 복구(Self-healing): 충돌한 컨테이너는 자동으로 재시작되며, 비정상 상태의 노드는 비웁니다(드레인).
• 수평 확장(Horizontal scaling): 레플리카를 추가해 트래픽 급증을 흡수하고, 이후 다시 축소합니다.
• 무중단 릴리스(Zero-downtime releases): 롤링 업데이트가 기존 파드를 점진적으로 교체하며, 실패 시 롤백합니다.
• 이식성(Portability): 동일한 매니페스트가 노트북, 테스트 클러스터, 프로덕션에서 모두 실행됩니다.

핵심 객체, 쉬운 말로 설명하면

쿠버네티스의 모든 것은 YAML로 기술하는 선언적 객체입니다. 클러스터는 여러분이 선언한 내용과 실제 상태가 일치하도록 끊임없이 작동합니다.

파드를 직접 생성하는 경우는 드뭅니다. Deployment를 생성하면 그것이 파드를 대신 관리해 줍니다.

동작하는 예제

다음은 서비스 뒤에 배치된 무상태(stateless) 웹 앱의 완전하면서도 최소한의 배포 예제입니다. app.yaml로 저장하세요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

여기서 이해해 둘 만한 점이 두 가지 있습니다. selector 필드는 Deployment와 Service가 자신의 파드를 찾는 방식입니다. 이들은 이름이 아니라 app: web이라는 레이블로 일치시킵니다. 그리고 readinessProbe는 파드가 실제로 80번 포트에서 응답하기 전까지 쿠버네티스가 해당 파드로 트래픽을 보내지 않도록 지시합니다. 바로 이것이 롤링 업데이트를 안전하게 만들어 주는 요소입니다.

이를 적용하고 수렴하는 과정을 지켜보세요.

kubectl apply -f app.yaml
kubectl get pods -l app=web
kubectl rollout status deployment/web

세 개의 파드가 Running 상태에 도달하는 것을 볼 수 있습니다. 하나를 종료시켜 자가 복구가 작동하는 모습을 확인해 보세요.

kubectl delete pod -l app=web --field-selector=status.phase=Running --grace-period=0 | head -1
kubectl get pods -l app=web   # 이미 대체 파드가 생성되고 있습니다

확장과 안전한 릴리스

확장은 명령어 한 줄이면 되며, 이는 나중에 자동화할 때 쓰는 명령어와 동일합니다.

kubectl scale deployment/web --replicas=6

새 버전을 배포하려면 이미지를 변경하면 됩니다. 그러면 쿠버네티스가 롤링 업데이트를 수행하여, 새 파드를 띄우고 새 파드가 레디니스 프로브를 통과할 때에만 기존 파드를 제거합니다.

kubectl set image deployment/web web=nginx:1.27.1
kubectl rollout status deployment/web
# 문제가 있는 경우:
kubectl rollout undo deployment/web

프로덕션 트래픽 패턴을 위해서는 HorizontalPodAutoscaler를 추가하여 클러스터가 CPU를 기준으로 레플리카를 자동으로 추가하도록 하세요.

kubectl autoscale deployment/web --min=3 --max=10 --cpu-percent=70

설정과 시크릿

설정은 이미지 밖에 두세요. 실행 시점에 주입하면 됩니다.

kubectl create configmap web-config --from-literal=APP_ENV=production
kubectl create secret generic web-secret --from-literal=DB_PASSWORD='change-me'

그런 다음 파드 사양에서 envFrom으로 이를 참조합니다. 이렇게 하면 동일한 이미지를 스테이징과 프로덕션에서 변경 없이 실행할 수 있으며, 자격 증명은 별도로 관리되어 빌드에 절대 포함되지 않습니다.

사우디 왕국 내에서 실행하기

사우디 및 GCC 비즈니스에게는 클러스터가 어디서 실행되는지가 어떻게 실행되는지만큼 중요합니다. PDPL에 따라 사우디 거주자의 개인 데이터는 일반적으로 정보 주체의 기대와 적용 가능한 이전 규칙을 고려하여 처리되어야 하며, NCA/SDAIA 프레임워크는 규제 대상 워크로드를 국내 호스팅 쪽으로 유도합니다. 노드, 영구 볼륨, 백업을 사우디 데이터 센터 내부에서 실행하면 해당 데이터가 현지에 거주하도록 유지되고 감사가 간소화됩니다.

Skyline Cloud는 사우디 국내 사업자이므로, 사우디 왕국 내의 클라우드 서버 및 VPS에서 쿠버네티스 워커 노드를 실행하고, 영구 볼륨과 백업을 위한 국내 블록 및 오브젝트 스토리지를 연결하며, 새벽 2시에 무언가 고장 났을 때 아랍어를 구사하는 현지 팀에 연락할 수 있습니다. 애플리케이션이 고객 알림이나 영수증도 발송한다면, 이를 동일한 국내 인프라 상의 비즈니스 이메일 호스팅과 함께 사용함으로써 해당 데이터 역시 현지에 거주하도록 유지할 수 있습니다. 관리형 클러스터와 운영 모델에 대한 더 자세한 내용은 사우디아라비아의 관리형 쿠버네티스 허브를 참고하세요.

대부분의 비즈니스에 합리적인 첫 클러스터는 작은 워커 노드 세 개입니다. 과도한 지출 없이 노드 장애를 견디고 롤링 업데이트를 현실적으로 테스트하기에 충분한 규모입니다.

실용적인 시작 체크리스트

1. 먼저 무상태 서비스 하나를 컨테이너화하고, 데이터베이스는 처음에는 관리형 스토리지에 남겨 두세요.
2. 위 예제처럼 Deployment + Service를 작성하고 깔끔한 rollout status를 확인하세요.
3. 레디니스 프로브와 리소스 요청/제한(requests/limits)을 추가하세요. 클러스터가 제대로 동작하게 만드는 핵심 요소입니다.
4. 설정을 ConfigMap과 Secret으로 옮기세요.
5. 기본 사항이 안정되면 오토스케일러와 Ingress를 추가하세요.

Skyline Cloud에서 시작하기

워커 노드를 띄우고, 국내 스토리지를 연결하며, 데이터를 사우디 관할권 아래에 두는 일을 단 몇 분 만에 할 수 있습니다. Skyline Cloud 계정을 생성하고, 현지 지원을 든든한 뒷받침으로 삼아 첫 클러스터를 배포하세요.