redis education kubernetes k8s_intro_1

쿠버네티스(Kubernetes) 환경에서 Redis 구축 가이드 ①

쿠버네티스(Kubernetes) 소개

2014년도 부터 Redis 전용 서버(Bare-Metal, VM) 및 Docker 환경에서 Redis 설치/운영 노하우를 공유해 온 레디스게이트(redisGate)입니다.
최근 엔터프라이즈 프로젝트 현장에서 애플리케이션뿐만 아니라 Redis와 같은 In-Memory 데이터베이스도 쿠버네티스(Kubernetes) 파드(Pod)로 구성해 달라는 요구사항이 빠르게 늘고 있습니다.   기존 레디스 엔지니어나 DBA 관점에서는 "Stateful한 데이터베이스를 변동성이 심한 쿠버네티스 파드에 올려도 안전한가?"라는 의문이 먼저 들 수 있습니다.
본 가이드는 이러한 고민을 해결하기 위해 Rocky Linux 9.5 (폐쇄망) 환경에서 K3s 및 최신 Redis 8.8.2을 활용하여 Redis-Cluster, Redis-Sentinel을 직접 구축하고 장애 조치(Failover)까지 완벽하게 검증한 실전 기록입니다.     (📝 쿠버네티스-레디스 설치/테스트: 2026년 7~9월)

☸️ 운용 환경 변화

위 이미지가 deployment 환경이 일률적(一律的)으로 변한다는 뜻은 아닙니다.   파드(pod)의 특징 중에 하나가 ephemeral(수명이 짧은, 일회성)입니다.   하지만 여기서 다루는 DB는 수명이 짧지도 않고 일회성도 아닙니다.   MySQL, PostgreSQL 같은 Disk-Base DB는 permanent(영구적인, 불변의)합니다.   Redis 또한 상태가 변하면 변경사항을 conf 파일에 기록합니다.   그리고 데이터도 거의 실시간으로 AOF 파일에 기록합니다.   따라서 In-Memory DB 인 Redis도 역시 'permanent'합니다.

쿠버네티스에서도 'permanent'한 소프트웨어를 지원하기 위해 'statefulset'을 지원합니다.   그리고 프로젝트를 기획할 때 배포(deployment) 아키텍처를 쿠버네티스로 하는 것을 기본으로 하는 경우가 많아지고 있습니다.   레디스에서도 redis-sentinel은 2021년 2월 발표된 Redis-6.2.0부터, redis-cluster는 2022년 4월 발표된 Redis-7.0.0부터 쿠버네티스 파드를 지원합니다.

저희 레디스게이트 경험으로 보면 10%는 물리서버, 80%는 VM, 10%는 도커/쿠버네티스에서 구축합니다. 이제 레디스도 쿠버네티스 환경에서 구축해야 될 때가 되었습니다.

☸️ 쿠버네티스(*Kubernetes) 란? (간략 설명)

쿠버네티스(Kubernetes, *K8s)는 컨테이너화된 애플리케이션의 자동 배포, 스케일링, 관리를 조율하는 오픈소스 컨테이너 *오케스트레이션(Orchestration) 플랫폼입니다.
전통적인 서버 환경에서는 Redis가 죽으면 엔지니어가 수동으로 프로세스를 살려야 했지만, 쿠버네티스는 '바라는 상태(Desired State)'를 설정 파일(YAML)에 선언해 두면 프로세스 이상(down) 감지 시 자동으로 재기동(Self-healing)하고 가용성을 유지해 줍니다.

구글은 2003년경부터 내부적으로 'Borg'라는 대규모 클러스터 관리 시스템을 운영하며, Google 검색, Gmail, YouTube 등의 인프라를 관리해왔습니다.   일주일에 *20억 개 이상의 컨테이너 배포를 처리하며 축적된 경험을 바탕으로, 2014년 6월 쿠버네티스를 오픈소스로 공개했습니다. 이듬해인 2015년 7월 v1.0이 출시되었고, 현재는 *CNCF(Cloud Native Computing Foundation)에 의해 관리되고 있습니다.

핵심 기능

• 자동 복구(Self-healing): 프로그램이 들어 있는 컨테이너가 갑자기 멈추면(down) 스스로 원래 상태로 다시 살려내거나 새로운 것으로 바꿔줍니다.
• 자동 확장(Auto-scaling): 사용자가 갑자기 몰려오면 프로그램 개수를 자동으로 늘려주고, 사람이 줄어들면 다시 줄여줍니다. ➡ 레디스 특성 상 자동 확장 기능은 사용하지 않을 것입니다.
• 부하 분산(Load Balancing): 한쪽으로 일감이 몰리지 않도록 여러 곳으로 골고루 나누어 전달해 줍니다. ➡ 레디스 특성 상 레디스 자체 부하 분산 기능을 사용할 것입니다.

☸️ 파드(Pod)란 무엇인가?

쿠버네티스에서 생성하고 관리할 수 있는 최소 배포 단위가 바로 파드(Pod)입니다.

파드의 핵심 특징 4가지

• 자원 공유 (네트워크 & 스토리지)
  • ① IP 주소 공유: 파드는 고유한 단일 IP 주소를 부여받습니다. 파드 안의 모든 컨테이너는 이 IP를 공유하며, 서로 'localhost'를 통해 매우 빠르게 통신할 수 있습니다.
  • 볼륨 공유: 파드에 할당된 스토리지(볼륨)를 내부 컨테이너들이 함께 읽고 쓸 수 있습니다.
• ② 동일 노드 스케줄링: 한 파드 안에 속한 컨테이너들은 항상 쿠버네티스 클러스터 내의 동일한 워커 노드(Worker Node)에 함께 배포되고 함께 실행됩니다.
• ③ 휘발성(Ephemeral) 생명주기와 고유성:
  • 파드는 영구적이지 않습니다. 오류가 발생하거나 노드가 다운되면 파드는 삭제되고 새로 생성됩니다. 이때 파드의 IP 주소도 변경됩니다.
  • 레디스 구성 시 파드의 고유 식별명을 유지해 주는 'StatefulSet'과 'Headless Service' 조합이 필수적입니다.   레디스는 7.0부터 파드 IP가 변경되어도 운용할 수 있도록 지원합니다.
  • Ephemeral(이페머럴)은 '수명이 짧은', '단명하는', '덧없는'이라는 뜻. 어떤 현상이나 물체가 아주 잠깐 동안만 존재하고 순식간에 사라질 때 주로 씁니다.
  • Permanent: 영구적인, 불변의
• ④ 1 파드 = 1 컨테이너가 기본
  • 일반적으로는 1개의 파드에 1개의 애플리케이션 컨테이너를 실행하는 구성을 가장 많이 사용합니다.
  • 하지만 목적에 따라 부속 컨테이너(사이드카)를 함께 묶어 배포할 수 있습니다.
    

쿠버네티스 Pod로 레디스 구성 시 주의할 점

쿠버네티스는 기본적으로 휘발성(Stateless) 특성을 가지지만, 레디스는 상태 유지(Stateful) 애플리케이션입니다. 따라서 Pod로 운영할 때 다음 5가지를 반드시 주의해야 합니다.

• ① 워크로드 객체 선택 (StatefulSet 필수)
  • Deployment 대신 반드시 📍'StatefulSet'을 사용해야 합니다.
  • 레디스 클러스터나 센티널은 각 노드가 고정된 네트워크 식별자(Pod 이름 및 DNS)를 가져야 장애 조치 및 재연결이 정상 동작합니다.
• ② AOF 영속성을 위한 Storage(PV) 및 IOPS(Input/Output Operations Per Second) 관리
  • AOF가 활성화되어 있으므로 Pod가 재시작되어도 데이터가 유지되도록 📍PersistentVolumeClaim(PVC)을 마운트해야 합니다.
  • AOF 쓰기 작업(fsync)이 빈번하게 일어나므로, 디스크 I/O 병목이 발생하면 레디스 전체 성능(메모리 처리)이 저하됩니다. 속도가 빠른 NVMe/SSD 기반 StorageClass를 할당하는 것을 권장합니다.
• ③ Pod 안티-아피니티(Pod Anti-Affinity) 설정
  • Master와 Replica Pod가 쿠버네티스의 동일한 물리 워커 노드(Node)에 배치되면, 해당 노드 장애 시 Master와 Replica가 동시에 죽어 고가용성이 깨집니다.
  • 'podAntiAffinity' 구성을 통해 Master/Replica Pod들이 서로 다른 Node에 분산 배치되도록 강제해야 합니다.
• ④ 메모리 설정 (Memory Limit & maxmemory)
  • 쿠버네티스 resource limit 메모리와 레디스의 maxmemory 설정 간 유격이 필요합니다.
  • 레디스 'maxmemory'를 Pod 메모리 Limit과 동일하게 잡으면, AOF 자식 프로세스 생성(fork)이나 메모리 파편화로 인해 쿠버네티스 OOMKilled(Out Of Memory Killer)에 의해 Pod가 즉시 강제 종료됩니다.
  • 권장: 레디스 'maxmemory'는 Pod 메모리 Limit의 📍50%~90% 수준으로 설정하세요.
    • 메모리 사용량이 10GB 이상이고 입력/수정/삭제가 많을 경우: 50%~60%
    • 메모리 사용량이 10GB 이상이지만 거의 조회일 경우 경우: 70%~80%
    • 메모리 사용량이 1GB 이하이고 입력/수정/삭제가 적을 경우: 80%~90%
    • 가장 안전하게 운영하려면 maxmemory 1GB 일 경우 Pod 메모리는 2GB로 설정한다.
        (maxmemory의 2배)
• ⑤ 커널 파라미터 및 호스트 환경 설정
  • 레디스가 AOF rewrite나 BGSAVE를 실행할 때 'fork()' 시스템 콜을 사용합니다.
  • 이때 호스트 노드의 'vm.overcommit_memory' 값이 '1'로 설정되어 있지 않으면 백그라운드 저장 작업이 실패할 수 있습니다.
  • 📍호스트 노드(OS) 레벨에서 사전에 커널 파라미터를 설정해 두어야 합니다.
  • m.overcommit_memory = 1, net.core.somaxconn=8192, Transparent Huge Pages(THP) Disable 등 설정

📦 왜 컨테이너를 직접 실행하지 않고 '파드'로 감쌀까요?

단일 컨테이너만으로 해결하기 어려운 밀접하게 결합된 협업 구조를 다루기 위해서입니다. 예를 들어, 메인 웹 서버 컨테이너 옆에 로그 수집기나 보안 프록시 컨테이너를 붙여야 할 때가 있습니다. 이를 사이드카(Sidecar) 패턴이라고 부릅니다.

이 두 컨테이너는 로컬 파일 시스템이나 'localhost' 네트워크를 공유해야만 정상 동작합니다. 쿠버네티스는 이를 '파드'라는 단위로 묶어 두 컨테이너가 항상 같은 노드에서 생사를 함께하도록 관리해 줍니다.
레디스 구축 시 'Redis + Sentinel'을 한 파드로 구성하는 사이드카 패턴은 그다지 권장하지 않습니다.   'Sentinel'은 독립된 인스턴스(객체)입니다. 따라서 별로 파드에 구축하는 것이 맞습니다.
🔗 자세한 내용은 "Kubernetes Redis-Sentinel Sidecar" 페이지를 보세요.

파드를 직접 생성하기보다 컨트롤러를 사용하는 이유

실무에서는 파드를 개별적으로 직접 생성하는 일이 드뭅니다. 파드는 쉽게 지워지고 재생성되는 특성이 있기 때문에, 보통 디플로이먼트(Deployment), 스테이트풀셋(StatefulSet) 같은 컨트롤러 객체를 사용해 파드의 개수 유지, 롤링 업데이트, 복구 등을 자동화합니다.

☸️ 'Deployment' 와 'StatefulSet'의 차이점은?

쿠버네티스에서 디플로이먼트(Deployment)와 스테이트풀셋(StatefulSet)은 모두 파드(Pod)를 여러 개 묶어서 관리하고 개수를 유지해 주는 워크로드 컨트롤러입니다. 두 개념의 가장 결정적인 차이는 "파드에 상태(State)와 고유한 식별자(이름/IP/디바이스)가 필요한가?"입니다.

• 1. 디플로이먼트(Deployment)
  디플로이먼트는 상태유지가 필요없는 애플리케이션(Stateless)을 관리하기 위한 표준 컨트롤러입니다.
  
  • 특징: 파드들이 완전히 동일하며, 대체 가능합니다.
  • 파드 이름: 뒤에 무작위 해시값이 붙습니다. (예: `my-web-58997b6b96-abc12`)
  • 생성/삭제 순서: 순서 없이 여러 파드가 동시에 생성되거나 삭제됩니다.
  • 주요 용도: 웹 서버, API 서버, 프론트엔드 등 파드 하나가 죽고 다른 파드가 새로 생겨도 아무 문제가 없는 애플리케이션.
• 2. 스테이트풀셋 (StatefulSet)
  스테이트풀셋은 상태 유지가 필요한 애플리케이션(Stateful)을 관리하기 위한 전용 컨트롤러입니다.
  📍레디스는 StatefulSet를 사용합니다.
  • 특징: 각 파드가 고유하고 지속적인 식별자(이름, 네트워크, 스토리지)를 갖습니다.
  • 파드 이름: 0부터 시작하는 순차적인 고정 인덱스가 붙습니다. (예: `redis-0`, `redis-1`, `redis-2`)
    - 파드가 죽어서 재시작되어도 이름(`redis-0`)과 고정 DNS 주소는 절대 바뀌지 않고 유지됩니다.
  • 생성/삭제 순서: 지정된 순서대로 하나씩 생성되고(`0` -> `1` -> `2`), 삭제될 때는 역순으로 제거됩니다.
  • 독립적인 스토리지 (PVC Templating): 파드마다 전용 영구 디스크(PV)가 1:1로 매핑됩니다. 파드가 다른 노드로 이사를 가도 자기 디스크를 찾아가서 다시 마운트합니다.
  • 주요 용도: 레디스(Redis), 데이터베이스(MySQL, PostgreSQL), 카프카(Kafka) 등 노드 간의 순서나 고정된 식별자가 필수적인 분산 시스템.

한눈에 보는 비교 (Deployment vs StatefulSet)

☸️ PersistentVolumeClaim(PVC)는 무엇인가요?

쿠버네티스에서 PVC (PersistentVolumeClaim, 영구 볼륨 요청)는 사용자(파드)가 쿠버네티스에게 "이 정도 스펙의 저장 공간(디스크)을 나에게 주세요"라고 요청하는 신청서/티켓입니다. 이 개념을 이해하려면 레디스 데이터가 저장되는 실제 디스크(PV)와 PVC의 관계를 함께 보면 가장 쉽습니다.

• 1. PV와 PVC의 비유 (부동산 계약)
  쿠버네티스는 인프라(디스크) 관리와 개발자(파드) 요청을 깔끔하게 분리하기 위해 PV와 PVC라는 개념을 나누어 놓았습니다.
  • PV (PersistentVolume - 영구 볼륨):
  
  • 인프라 관리자가 클러스터에 미리 마련해 둔 실제 디스크 자원 (예: AWS EBS 100GB, NVMe SSD 500GB, SAN 스토리지 등)입니다.
  • 비유: 부동산 시장에 올라와 있는 "실제 건물/방"
  • PVC (PersistentVolumeClaim - 영구 볼륨 요청):
  • 개발자나 파드가 "나 용량 20GB 필요하고, 읽기/쓰기가 빠르고 영구적으로 보존되는 디스크 하나 줘"라고 제출하는 요청서입니다.
  • 비유: 세입자가 제출하는 "방 구함 조건표 (원룸, 용량 20GB, 입주 요청)
  쿠버네티스는 파드가 제출한 PVC(신청서)의 조건에 맞는 PV(실제 디스크)를 찾아 둘을 임대/연결(Binding)해 줍니다.
  
• 2. 왜 레디스 같은 상태 유지 앱에 PVC가 필수일까요?
  앞서 설명해 드렸듯, 쿠버네티스 파드(Pod) 내부의 파일 시스템은 휘발성입니다. 파드가 재시작되거나 다른 노드로 이사를 가면 내부 데이터(redis.conf, AOF 파일)는 전부 사라집니다.
  ① 데이터 영속성 확보: AOF 파일을 파드 내부가 아니라 PVC를 통해 연결된 외부 PV(디스크)에 씁니다.
  ② 파드 재시작/이동 시 복구: 노드 장애로 `redis-0` 파드가 죽어서 다른 노드로 새로 켜지더라도, 기존에 연결되어 있던 PVC(디스크)를 새 파드에 그대로 다시 마운트합니다. 덕분에 AOF 데이터 유실 없이 레디스가 그대로 복원됩니다.
• 3. StatefulSet과 PVC의 환상적인 조합 (VolumeClaimTemplate)
  일반 디플로이먼트는 모든 파드가 하나의 디스크를 바라보려고 해서 충돌이 납니다.
  반면 레디스에 쓰이는 스테이트풀셋(StatefulSet)은 'volumeClaimTemplates'라는 기능을 제공합니다.
  이 기능을 쓰면 파드가 생성될 때마다 전용 PVC가 1:1로 자동 발행됩니다.
  o 'redis-0' 생성 → 'data-redis-0'이라는 PVC(디스크) 자동 할당 및 연결
  o 'redis-1' 생성 → 'data-redis-1'이라는 PVC(디스크) 자동 할당 및 연결
  o 'redis-2' 생성 → 'data-redis-2'라는 PVC(디스크) 자동 할당 및 연결

결과적으로 각 레디스 노드가 자신만의 독자적인 conf 파일, AOF/RDB 저장소를 안전하게 챙기게 됩니다.