Kubernetes의 기본 구조와 애플리케이션 배포

Kubernetes를 처음 살펴보며 정리했던 개념입니다. 컨테이너를 여러 장비에 배포하고 유지할 때, 애플리케이션을 실행하는 단위와 그 상태를 관리하는 역할을 나눠 이해하는 것이 먼저였습니다.

당시 소개 메모는 컨테이너 배포를 자동화하는 플랫폼이라는 설명과 관련 자료를 모은 내용이었습니다. 여기서는 기본 구조를 정리하고 Pod·Deployment·Service가 어떻게 연결되는지 예시로 살펴봅니다.

원하는 상태와 실제 상태

애플리케이션을 두 개 실행하고 싶다면 복제본 수를 선언합니다. Kubernetes의 컨트롤러는 이 선언과 현재 상태를 비교하며 필요한 작업을 진행합니다.

이 과정이 배포와 복구의 모든 판단을 대신하는 것은 아닙니다. 애플리케이션의 준비 상태와 자원, 저장소, 접근 권한은 별도로 구성해야 합니다.

클러스터 구성 요소

Service의 통신 경로는 kube-proxy나 이를 대신하는 네트워크 구현이 처리할 수 있습니다. kube-proxy를 모든 Pod 간 통신을 담당하는 구성 요소로만 설명하면 역할을 혼동하기 쉽습니다.

Pod와 Deployment

Pod는 하나 이상의 컨테이너를 함께 실행하는 단위입니다. 같은 Pod의 컨테이너는 네트워크 공간을 공유해 localhost로 통신할 수 있고, 공유할 볼륨도 지정할 수 있습니다. 각 컨테이너의 파일시스템이 자동으로 모두 공유되는 것은 아닙니다.

Deployment는 Pod 템플릿과 복제본 수를 관리합니다. 아래는 Nginx 컨테이너 두 개를 실행하는 설명용 예시입니다. 실제 배포에서는 사용할 이미지 버전과 필요한 자원·상태 확인 설정을 프로젝트에 맞춰야 합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-web
  template:
    metadata:
      labels:
        app: example-web
    spec:
      containers:
        - name: web
          image: nginx:stable
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80

Deployment의 selector와 Pod 레이블이 맞아야 관리 대상이 연결됩니다. readinessProbe는 요청을 받을 준비가 됐는지 확인하는 설정입니다. livenessProbe의 실패는 컨테이너 재시작으로 이어질 수 있지만 Deployment의 이전 버전으로 자동 롤백하는 기능은 아닙니다.

Service로 접근 경로 연결

Pod를 새로 만들면 주소가 바뀔 수 있습니다. Service를 두면 레이블로 대상 Pod를 선택하고 일정한 접근 경로를 제공할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
  name: example-web
spec:
  selector:
    app: example-web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

여기서 ClusterIP는 클러스터 내부 접근을 위한 설정입니다. 외부 접속은 별도로 구성해야 하며 LoadBalancer를 지정한다고 모든 환경에서 같은 클라우드 로드 밸런서가 생기는 것은 아닙니다.

kubectl apply -f web.yaml
kubectl apply -f web-service.yaml
kubectl rollout status deployment/example-web
kubectl port-forward service/example-web 8080:80

포트 포워딩이 실행 중이면 로컬의 http://localhost:8080에서 확인할 수 있습니다. 이는 확인용 연결이며 운영용 외부 노출 구성을 대신하지는 않습니다.

설정과 저장소 분리

ConfigMap은 일반 설정, Secret은 비밀번호 같은 민감한 설정을 다룰 때 사용합니다. Secret의 Base64 표현은 암호화가 아니므로 접근 권한과 저장 시 암호화 설정을 별도로 확인해야 합니다.

지속할 데이터는 컨테이너의 임시 파일과 구분해 볼륨에 저장합니다. PVC는 스토리지를 요청하는 리소스이고 PV는 제공되는 볼륨을 나타냅니다. Pod가 사라진 뒤의 데이터 보관은 볼륨 수명과 reclaim policy에 따라 달라집니다.

이 관계를 이해한 다음 kubectl 조회와 운영 명령, Pod 배치 규칙을 보면 개별 설정이 어느 단계에 적용되는지 따라가기 쉽습니다.

참고 자료

• Kubernetes 구성 요소 
• Pod의 네트워크와 저장소 
• Deployment 
• Service 
• Secret 관리