[에스넷시스템 부트캠프] TIL Day 29 - Podman Volume, Compose, 쿠버네티스

1. Podman Volume

컨테이너에서 볼륨은 데이터를 저장하기 위한 용도로 사용한다.

• Podman Image: 읽기 전용 (Read-Only)
• Podman Container: 읽기/쓰기 가능 (Read-Write)
• 컨테이너의 파일 시스템은 휘발성이므로, 데이터 유지에는 볼륨이 필수

 

 

1) 마운트 방식

유형	설명
Bind Mount	호스트 PC의 특정 디렉토리를 컨테이너 내부에 마운트
Named Volume (익명/이름있는 볼륨)	Docker가 관리하는 영역에 자동 생성됨
Shared Volume	컨테이너 간 볼륨 공유, 하지만 보통 1:1 사용이 일반적

 

 

2. Podman Network 

1) 타입

네트워크 타입	설명
bridge	기본값. NAT 기반 브릿지 네트워크. 외부와 통신 가능
host	컨테이너가 호스트의 네트워크 스택을 직접 사용 (격리 X)
overlay	여러 노드 간 네트워크 구성. Docker Swarm에서 사용
ipvlan	VLAN을 기반으로 한 Layer 2/3 통신 가능
macvlan	컨테이너에 고유한 MAC 주소 부여, 물리 장치처럼 동작
none	네트워크 기능 비활성화 (완전 격리)
plugin	외부 네트워크 플러그인(CNI 기반) 사용 가능

 

일반적인 단일 머신 개발 환경에서는 bridge 또는 host 모드를 가장 많이 사용한다. 

 

 

3. Podman Compose

Podman Compose는 여러 개의 컨테이너를 하나의 애플리케이션처럼 묶어서 관리할 수 있도록 해주는 도구이다. 
Docker Compose의 사용 방식과 매우 유사하다. 

 

1) 특징

• 여러 서비스를 YAML 파일 하나로 정의
• podman-compose up -d로 전체 서비스 구동
• depends_on, volumes, networks, restart 등의 설정 지원

 

 

2) 유의 사항

• 첫 줄에는 version 반드시 명시
• 콜론 뒤에는 반드시 공백 1칸
• 들여쓰기는 스페이스로 (탭 사용 금지)
• 문자열은 '작은따옴표' 또는 "큰따옴표" 사용
• 주석은 #로 작성
• --rm 옵션은 Compose에서는 사용 불가

 

3) restart 옵션

• no : 기본값. 컨테이너가 중지되었을 때 자동으로 재시작하지 않음
• always : 컨테이너가 중지되면 항상 재시작. 사용자가 수동으로 중지해도 재시작
• on-failure : 리턴 코드가 0이 아닌 경우에만 재시작
• on-failure:N : N= 숫자, N번의 횟수만큼 재시작을 시도
• unless-stopped : 시스템이 재부팅되거나 서브시가 실패하더라도 재시작. 사용자가 stop으로 멈추기 전까지는 계속 재시도

compose에는 --rm 명령어 자체가 없음

 

4) [실습] WordPress + MariaDB 구성

version: "3.8"

services:

  wordpressdb:
    container_name: wordpressdb
    image: localhost/ldb:latest
    networks:
      - wordpress-net
    environment:
      MARIADB_ROOT_PASSWORD: pw
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wp_user
      MARIADB_PASSWORD: wp_pass
    volumes:
      - wordpressdb:/var/lib/mysql
    restart: unless-stopped

  wordpress:
    container_name: wordpress
    image: localhost/lwp:latest
    depends_on:
      - wordpressdb
    networks:
      - wordpress-net
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: wordpressdb:3306
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: wp_pass
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - /home/consvc/data/wp_data:/var/www/html:Z
    restart: unless-stopped

volumes:
  wordpressdb:
    external: true
    name: wordpressdb

networks:
  wordpress-net:

 

• WordPress와 DB가 독립된 컨테이너로 실행됨
• wordpress-net이라는 가상 네트워크를 통해 통신
• /home/consvc/data/wp_data를 통해 WordPress 콘텐츠가 호스트와 공유
• localhost:8080으로 WordPress 웹 UI 접속 가능

 

 

4. 쿠버네티스 

1) 쿠버네티스란?

Kubernetes(K8s)는 컨테이너 오케스트레이션 플랫폼으로, 여러 개의 컨테이너를 자동으로 배포, 확장, 관리, 복구하는 인프라 플랫폼이다. 

 

2) 쿠버네티스 구성 요소

• Pod (기본 단위)
  • 쿠버네티스에서 컨테이너를 실행하는 가장 작은 단위
  • 하나의 Pod에는 1개 이상의 컨테이너가 포함될 수 있음
• Static Pod
  • kubelet이 직접 관리하는 Pod
  • 마스터 노드 자체에서 실행되며 API 서버에 의해 생성되지 않음

 

3) Control plane 구성요소

Control plane은 쿠버네티스 클러스터의 중심 뇌로, 클러스터의 상태를 지속적으로 감시하고 필요한 조치를 자동으로 수행한다.

• kube-apiserver
  • API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트
• API 서버
  • 쿠버네티스 컨트롤 플레인의 프론트엔드
  • 수평 확장이 가능하도록 설계되어 있음
• etcd 
  • 모든 클러스터 데이터를 담는 쿠버네티스 내부 저장소
  • etcd를 사용할 경우 데이터 백업 필수
  • 일관성 고가용성 키-값 저장소
• kube-scheduler
  • 노드가 배정되지 않은 새로 생성된 파드를 감지하고 실행할 노드 선택
• kube-controller-manager
  • 컨트롤러 프로세스 실행
• kube-controller-manager (cloud-controller-manager)
  • 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결
  • 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터만 상호작용하는 컴포넌트를 구분
• node
  • 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며 모든 노드 상에서 동작
  • 종류 :
    • kubelet : 클러스터의 각 노드에서 실행되는 에이전트로 파드에서 컨테이너가 확실하게 동작하도록 관리
    • kube-proxy : 클러스터의 각 노드에서 실행되는 네트워크 프록시
    • 컨테이너 런타임 : 컨테이너 실행을 담당하는 소프트웨어
• Addon
  • 쿠버네티스 리소스를 이용해 클러스터 기능 구현
  • 클러스터에 속하기 때문에 애드온에 대한 네임스페이스 리소스는 kube-system 네임스페이스에 소속
  • 종류 : DNS, 웹 UI, 컨테이너 리소스 모니터링, 클러스터-레벨 로깅

 

✍️ 하루 회고

오늘은 드디어 쿠버네티스(Kubernetes) 학습에 들어간 날이었다.
본격적인 오케스트레이션 개념을 접하다 보니 기대 반 걱정 반이었다.

설치는 생각보다 쉽지 않았다. 설치 과정을 문서로 남기면서 따라가려 했지만, 중간에 꼬이는 바람에 결국 기록은 하지 않기로 했다.