쿠버네티스

이영진·2025년 3월 17일

SKALA 클라우드

클라우드

목록 보기

2/6

클라우드 네이티브와 MSA, 컨테이너, 쿠버네티스: 상세 이해

1. 클라우드 네이티브와 MSA

클라우드 네이티브의 특성

클라우드 네이티브는 확장성, 탄력성, 내결함성, 민첩성을 특징으로 합니다. 이를 통해 애플리케이션은 클라우드 환경에서 최적화된 성능을 발휘할 수 있습니다.

주요 특성

확장성: 필요에 따라 자원을 동적으로 확장하거나 축소 가능.
탄력성: 장애 발생 시에도 시스템이 지속적으로 동작.
내결함성: 장애를 자동 복구하거나 대체.
민첩성: 빠른 개발 및 배포를 지원.

Refactoring과 Re-architecturing

Refactoring: 기존 시스템을 개선하는 과정.
Re-architecturing: 목적에 맞게 시스템을 새롭게 설계하는 것을 의미하며, 클라우드 네이티브 애플리케이션은 기술과 프로세스 측면에서 이를 고려해야 합니다.

MSA(Microservice Architecture)의 장점

MSA는 서로 다른 서비스를 분리하여 독립적으로 관리하고 변화할 수 있도록 지원합니다. 이를 통해 코드가 단순해지고, 각 기능별 라이프사이클을 독립적으로 관리할 수 있습니다.

Monolith vs Microservice

Monolith	Microservice
애플리케이션은 복잡하지만 구조는 단순	애플리케이션은 단순하지만 구조는 복잡
변경 사항 반영에 시간이 걸림	자동화를 통해 안정성과 민첩성을 확보

MSA의 구성 요소

Inner Architecture (내부 아키텍처): 업무 중심의 설계로 도메인 주도 설계(DDD)를 활용하여 마이크로 서비스를 분할.
Outer Architecture (외부 아키텍처): 기술 중심의 설계로 데이터베이스 연결 및 외부 서버와 통신을 관리.

Outer Architecture 핵심 요소

고가용성 구조
분산 데이터 구조
리스크 회피 및 검증 체계
PaaS 기반 지능화된 운영 방식

2. 컨테이너

컨테이너란?

컨테이너는 애플리케이션과 그 실행에 필요한 모든 의존성을 하나로 묶어 격리된 환경에서 실행하는 기술입니다.

컨테이너 이미지

컨테이너 이미지는 애플리케이션과 실행에 필요한 라이브러리, 파일 시스템 등을 포함하는 패키지입니다. 이를 통해 동일한 환경에서 애플리케이션을 실행할 수 있습니다.

컨테이너의 장점

빠른 시작과 종료.
자원의 효율적 사용.
애플리케이션 간 독립적인 환경 제공.
이식성이 뛰어나 다양한 환경에서 동일하게 동작.

컨테이너 vs 가상 머신(VM)

항목	가상 머신(VM)	컨테이너
가상화	하드웨어 가상화	OS 레벨 가상화
부팅 시간	수십 초~수 분	수 초~수십 초
자원 활용	물리 서버당 4~6 VM	물리 서버당 20~30 컨테이너
이식성	동일 하이퍼바이저 간 가능	이기종 환경(물리/가상/클라우드) 간 가능

컨테이너(Container)와 가상머신(VM)의 차이점

컨테이너와 가상머신은 각각의 특성과 장단점에 따라 사용 목적이 다릅니다. 아래 표는 두 기술의 주요 차이점을 정리한 것입니다.

특징	컨테이너(Container)	가상머신(VM)
OS 가상화 방식	OS 수준에서 가상화하며 Host OS 커널을 공유함	전체 OS를 가상화하며 Guest OS를 포함함
자원 효율성	경량화된 구조로 자원 사용량이 적음 (CPU, 메모리 절약 가능)	Guest OS로 인해 자원 사용량이 많음
시작 속도	빠른 시작 가능 (몇 초 내로 실행)	느린 시작 속도 (OS 부팅 시간이 필요)
격리 수준	프로세스 수준의 격리 (Host OS 커널 공유로 보안 취약 가능)	강력한 격리 (각 VM이 독립된 OS와 커널을 가짐)
운영체제 종속성	Host OS 커널에 종속적 (같은 OS 버전에서만 실행 가능)	Host OS와 독립적으로 다양한 운영체제 실행 가능
포트 및 네트워크	Host OS의 네트워크 설정을 공유하며 경량화된 네트워크 가상화 제공	독립적인 네트워크 어댑터를 사용하여 완전한 네트워크 격리 제공
보안	커널 공유로 인해 보안 위협 발생 가능 (커널 취약점 시 모든 컨테이너에 영향)	각 VM은 독립된 커널과 OS를 가지므로 보안성이 높음
휴대성 및 이동성	경량화된 구조로 환경 간 이동 및 배포가 용이함	VM 이미지 크기가 크고 이동 시 호환성 문제 발생 가능
사용 사례	마이크로서비스, CI/CD 파이프라인, 클라우드 네이티브 애플리케이션	멀티 OS 환경, 레거시 애플리케이션, 높은 보안 요구 사항

컨테이너의 특징

Host OS의 커널을 공유하여 애플리케이션과 의존성을 패키징한 경량화된 구조.
빠른 시작 속도와 높은 자원 효율성을 제공하지만, 보안 격리가 약할 수 있음.
마이크로서비스 아키텍처와 CI/CD 파이프라인에서 선호됨.

가상머신(VM)의 특징

하드웨어를 에뮬레이션하여 독립적인 Guest OS를 실행.
강력한 격리와 보안을 제공하며 다양한 운영체제 환경을 지원.
레거시 애플리케이션 및 높은 보안 요구 사항에 적합.

요약

컨테이너는 경량화와 빠른 배포에 적합하며, 가상머신은 강력한 격리와 멀티 OS 환경을 지원합니다. 두 기술은 목적에 따라 선택하거나 함께 사용할 수 있습니다.

컨테이너의 한계

개별 컨테이너 개수의 증가로 인한 관리 문제

서비스가 커지면 커질수록 관리해야 하는 컨테이너의 양이 급격히 증가
일반적인 물리 서버또는 가상화 서버 관리 서비스만으로는 관리 불가

→ 관리하는 Orchestrator 필요

→ 물리적인 서버를 논리적으로 하나의 시스템으로 통화해서 컨테이너가 운영되도록 지원

3. 쿠버네티스(Kubernetes)

쿠버네티스란?

쿠버네티스는 컨테이너 오케스트레이션 도구로, 여러 개의 컨테이너를 효율적으로 배포하고 관리할 수 있도록 지원합니다.

쿠버네티스 주요 리소스

Pod: 배포 가능한 가장 작은 단위로, 하나 이상의 컨테이너를 포함.
동일한 네트워크 네임스페이스와 스토리지를 공유합니다.

정확한 설명은 아니지만, 파드는 쿠버네티스가 컨테이너를 실행하는 수단 이라고 생각
Deployment: 애플리케이션 상태를 선언적으로 관리하며 롤링 업데이트와 롤백 지원.
ReplicaSet: 특정 개수의 Pod 복제본을 유지.
Volume: 데이터 저장 및 공유를 위한 리소스.
ConfigMap: 비민감한 구성 데이터를 Key-Value 형식으로 저장.
Secret: 민감한 데이터를 암호화하여 저장.

쿠버네티스 메니페스트 파일

쿠버네티스는 YAML 형식의 메니페스트 파일을 사용해 리소스를 정의합니다.

spec: 시스템에 요구하는 규격 정의.
status: 실제 시스템 상태를 나타냄.

4. DevOps와 CI/CD

DevOps란?

개발(Development)과 운영(Operation)의 협업을 통해 빠르고 지속적으로 가치를 제공하는 문화와 접근 방식입니다.

CI/CD (Continuous Integration & Continuous Deployment)

코드를 지속적으로 통합하고 테스트하여 자동으로 배포하는 프로세스를 의미합니다.

배포 전략 비교

배포 전략	설명	장점	단점
Rolling Update	새로운 버전을 하나씩 교체해 나감. 서비스 중단 없이 점진적으로 업데이트함.	서비스 중단 없이 점진적으로 업데이트할 수 있음. 호환성 문제 최소화 가능.	모든 서비스가 동일한 버전이 아닐 수 있어 호환성 문제 발생 가능.
Canary 배포	일부 사용자에게 새로운 버전을 먼저 배포하여 테스트함.	작은 규모로 테스트 가능하여 리스크를 줄일 수 있음.	사용자 경험의 불일치가 발생할 수 있음.
Blue/Green 배포	기존 서비스와 새로운 버전을 동시에 운영하며 트래픽을 점진적으로 전환함.	빠르게 롤백 가능하며, 서비스 중단 없이 전환할 수 있음.	두 버전의 서비스를 동시에 운영해야 하므로 자원 사용량이 증가함.

배포 전략 선택 기준

기준	Rolling Update	Canary 배포	Blue/Green 배포
서비스 중단 여부	서비스 중단 없이 점진적으로 업데이트함.	서비스 중단 없이 일부 사용자에게 배포.	서비스 중단 없이 트래픽을 점진적으로 전환함.
리스크 관리	호환성 문제 최소화 가능.	작은 규모로 테스트하여 리스크를 줄일 수 있음.	빠르게 롤백 가능하여 리스크를 줄일 수 있음.
자원 사용량	기존 자원 사용량에 미치는 영향이 적음.	일부 사용자에게만 배포하므로 자원 사용량이 상대적으로 낮음.	두 버전의 서비스를 동시에 운영해야 하므로 자원 사용량이 증가함.
적합한 상황	점진적인 업데이트가 필요한 경우.	테스트가 필요한 경우나 일부 사용자에게 먼저 배포할 때 적합.	빠른 롤백이 필요한 경우나 서비스 중단을 최소화해야 할 때 적합.