1. 리눅스 생태계와 배포판 이해

1.1 리눅스의 역사적 배경

Unix의 한계와 리눅스의 등장

• Unix의 특징

  • 1970년대 개발된 멀티태스킹, 멀티유저 운영체제

  • 강력한 보안과 안정성을 제공하지만 유료 라이선스

  • 기업용 서버에서 여전히 사용되지만 높은 비용으로 인해 접근성 제한

• 리눅스의 혁신

  • 1991년 리누스 토르발스가 개발한 Unix-like 운영체제

  • GPL(General Public License) 하에 배포되는 완전한 오픈소스

  • 커뮤니티 기반 개발로 빠른 발전과 다양한 배포판 생성

     

1.2 주요 리눅스 배포판 계열

Debian 계열

• Debian Linux

  • 커뮤니티 주도의 완전 무료 배포판

  • 패키지 관리자: APT(Advanced Package Tool)

  • 안정성을 중시하는 보수적인 릴리스 정책

  • 데스크톱과 서버 환경 모두 지원

• Ubuntu

  • Canonical에서 개발한 Debian 기반 배포판

  • 사용자 친화적인 GUI와 편의 기능 제공

  • 6개월마다 정기 릴리스, LTS(Long Term Support) 버전은 5년 지원

  • 클라우드 환경에서 가장 널리 사용되는 배포판

Red Hat 계열

• 개발 및 릴리스 프로세스

  Fedora -> CentOS Stream -> Red Hat Enterprise Linux(RHEL)
     ↓           ↓                    ↓
   실험적        테스트              상용 안정화
   무료         무료                유료

• Fedora

  • Red Hat이 후원하는 커뮤니티 프로젝트

  • 최신 기술과 패키지를 빠르게 도입

  • 6개월마다 새 버전 릴리스

  • RHEL의 기술 검증 플랫폼 역할

• Red Hat Enterprise Linux(RHEL)

  • 기업용 상용 리눅스 배포판

  • 장기 지원 및 기술 지원 서비스 제공

  • 패키지 관리자: YUM/DNF

  • 높은 안정성과 보안성으로 기업 환경에서 선호

• CentOS 변화와 대안

  • 기존 CentOS: RHEL의 무료 클론, 소스코드 재컴파일 버전

  • CentOS Stream: RHEL의 업스트림 개발 버전으로 전환

  • 종료 일정: CentOS 8(2021년), CentOS 7(2024년)

  • 대안책들:

    • Rocky Linux: CentOS 창립자가 새로 시작한 프로젝트

    • AlmaLinux: CloudLinux에서 후원하는 RHEL 클론

    • Oracle Linux: Oracle에서 제공하는 RHEL 호환 배포판

1.3 기업 환경에서의 선택 기준

비용 구조 분석

• 무료 배포판의 숨겨진 비용

  • 자체 기술 지원팀 필요

  • 보안 패치 및 업데이트 관리

  • 장애 발생 시 자체 해결 능력 요구

• 상용 배포판의 가치

  • 24/7 기술 지원 서비스

  • 정기적인 보안 패치 제공

  • 법적 책임과 보장

  • 장기 지원 정책(10년 이상)

2. 컨테이너 기술의 기반 이해

2.1 리눅스 커널의 가상화 기술

핵심 기술 요소들

• chroot(Change Root)

  • 프로세스의 루트 디렉터리를 변경하여 파일시스템 격리

  • 1979년 Unix V7에서 처음 도입

  • 컨테이너 파일시스템 격리의 기초 기술

• cgroups(Control Groups)

  • 프로세스 그룹에 대한 리소스 제한 및 모니터링

  • CPU, 메모리, 디스크 I/O, 네트워크 대역폭 제어

  • 컨테이너별 리소스 할당의 핵심 메커니즘

• namespaces

  • 시스템 리소스를 격리하여 독립적인 환경 제공

  • 주요 네임스페이스 유형:

    • PID: 프로세스 ID 격리

    • Network: 네트워크 인터페이스 격리

    • Mount: 파일시스템 마운트 격리

    • User: 사용자 및 그룹 ID 격리

    • UTS: 호스트명과 도메인명 격리

    • IPC: 프로세스 간 통신 격리

2.2 컨테이너 기술의 진화

LXC(Linux Containers)

• 컨테이너의 어머니, 최초의 컨테이너

  • 리눅스 커널의 격리 기술(chroot, cgroup, namespace)을 집약하여 정리

  • 운영체제 수준의 가상화 제공

  • 기존에는 평범한 개발자가 사용하기 어려운 로우레벨 기술

• 사용 목적의 차이

  • LXC: 운영체제를 컨테이너 가상화로 나누기 위한 목적

  • 내 리눅스 OS에 CentOS나 Ubuntu를 게스트 OS로 띄울 수 있음

  • 기존 VM 기술을 컨테이너 기술로 구현하는 개념

Docker의 혁신적 변화

• 사용자 친화성의 혁명

  • LXC 기반으로 누구나 쓰기 쉬운 형태로 만듦

  • 잘 정리된 블로그 몇 개만 봐도 컨테이너를 띄울 수 있는 수준

  • 2013년 첫 발표 시 가상화 환경에서 빠른 "Hello World" 시연으로 큰 반향

• 목적의 차이

  • Docker: 앱들을 독립적인 환경에서 띄우려는 목적

  • LXC와는 다른 사용 패턴과 철학

3. 컨테이너 오케스트레이션의 필요성

3.1 단일 컨테이너 vs 오케스트레이션

전통적인 배포 프로세스의 한계

• 수동 프로세스의 문제점

  • 컨테이너 생성 -> 상태 확인 -> 네트워크 설정 -> 기존 컨테이너 제거

  • 각 단계별 수동 개입 필요

  • 실패 시 롤백 과정의 복잡성

  • 스케일링 시 반복 작업의 비효율성

오케스트레이션의 자동화 가치

• 선언적 배포 모델

  • 원하는 최종 상태를 선언

  • 시스템이 현재 상태와 비교하여 자동으로 조정

  • 상태 지속적 모니터링 및 자동 복구

• 고급 운영 기능

  • 자동 스케일링(Horizontal/Vertical)

  • 셀프 힐링(자동 장애 복구)

  • 롤링 업데이트 및 롤백

  • 로드 밸런싱 및 서비스 디스커버리

3.2 Kubernetes의 기술적 우위

구글의 운영 경험 기반

• Borg 시스템의 교훈

  • 구글 내부에서 10년 이상 사용된 컨테이너 오케스트레이션

  • 대규모 분산 시스템 운영 노하우 축적

  • 장애 처리 및 리소스 최적화 경험

산업 표준으로서의 지위

• CNCF(Cloud Native Computing Foundation) 졸업 프로젝트

  • 기술 성숙도 및 안정성 검증 완료

  • 벤더 중립적 거버넌스 구조

  • 광범위한 기업 및 커뮤니티 지원

4. 컨테이너 런타임 생태계

4.1 런타임 계층 구조

High-Level vs Low-Level Runtime

Application Layer
    ↓
High-Level Runtime(Docker, Podman)
    ↓
Low-Level Runtime(runc, crun)
    ↓
Kernel Layer(namespaces, cgroups)

• High-Level Runtime 특징

  • 사용자 친화적 인터페이스 제공

  • 이미지 관리 및 네트워크 설정

  • 로그 수집 및 모니터링 기능

  • 플러그인 아키텍처 지원

• Low-Level Runtime 특징

  • OCI(Open Container Initiative) 표준 준수

  • 실제 컨테이너 생성 및 실행 담당

  • 커널 기능에 직접 접근

  • 경량화 및 성능 최적화 중심

4.2 주요 컨테이너 런타임 비교

rkt(Rocket)의 등장과 특징

• 보안 공략 전략

  • Docker의 보안 취약점을 공략하여 등장

  • Docker보다 더 안정적이고 성능이 좋다고 주장

  • Docker의 루트 권한 실행 문제를 해결하려 함

• CoreOS와의 관계

  • CoreOS(현재 Fedora CoreOS)라는 컨테이너 전용 리눅스의 대표 런타임

  • Red Hat 인수 후 입지 축소

  • Red Hat이 CRI-O를 밀면서 rkt의 영향력 감소

• 현재 상황

  • 로우레벨 런타임 특성상 사용하기 어려움

  • 강의에서도 비교 대상으로만 언급될 정도로 실사용 감소

containerd의 등장 배경

• Docker에서 분리된 컨테이너 생성 기능

  • Docker 엔진에서 컨테이너를 만들어주는 기능만 분리

  • CNCF에 기부되어 중립성 확보

  • 현재 Kubernetes 설치 시 가장 많이 사용

CRI-O의 차별화

• Red Hat에서 개발한 Kubernetes 전용 런타임

  • 태생부터 CRI 규격에 맞춰 개발

  • 2023년까지는 CNCF 인큐베이팅 프로젝트 단계

  • 곧 졸업 프로젝트가 될 예정

참고: CNCF 프로젝트 단계는 기술 성숙도를 나타내며, 졸업 프로젝트는 신뢰할 수 있는 수준의 기술을 의미한다.

4.3 Docker의 복잡한 구조와 Kubernetes의 고민

Docker 엔진의 다면적 특성

"Docker가 많은 기능들이 녹아진 엔진"이라고 표현한 이유:

• dockerd(Docker Daemon)

  • 실제 컨테이너 생성 기능

  • CLI 인터페이스 제공

  • 로그 관리 기능

  • 스토리지 드라이버 제공

  • 네트워크 생성 및 관리

• 사용자 편의성 vs Kubernetes 관점의 차이

  • 사용자: 모든 기능이 통합되어 편리함

  • Kubernetes: 컨테이너 생성 기능만 필요, 나머지는 과도함

Docker 내부 구조의 실제

Docker CLI 명령
    ↓
dockerd(Docker Daemon)
    ↓
containerd(실제 컨테이너 생성)
    ↓
libcontainer(과거) → runc(현재)
    ↓
Linux Kernel

• containerd의 역할: Docker 내부에서 실제 컨테이너를 만들어주는 핵심 기능

• libcontainer에서 runc로의 변화: OCI 표준을 맞추기 위한 진화

4.4 OCI 표준과 이미지 호환성

컨테이너 표준화의 배경

런타임이 점점 많아지면서 이미지 호환성 문제가 대두:

• "Docker에서 containerd로 바꾸면 기존 이미지를 다시 만들어야 할까?"

• 이런 의문에 대한 답이 바로 OCI 표준

OCI(Open Container Initiative)의 역할

• 컨테이너 런타임이 지켜야 할 표준 규약 관리

• 이 규약을 지키면 런타임들끼리 서로 이미지 공유 가능

실제 구현 변화

• Docker의 대응: OCI 규격에 맞추기 위해 runc 개발

  • 기존 libcontainer에서 runc로 변경

  • LXC를 이용하지 않고 직접 커널 레벨 가상화 기술 사용

• rkt의 표준 준수: 마찬가지로 OCI 표준을 따름

호환성의 실제 증명

"Docker로 만든 이미지를 rkt에서도 사용할 수 있다"고 확신할 수 있는 이유:

• 모든 런타임이 동일한 runc를 사용

• CRI-O도 runc를 사용

• 결국 모든 컨테이너는 같은 방식으로 생성됨

5. Kubernetes와 컨테이너 런타임의 복잡한 관계

5.1 Kubernetes의 컨테이너 런타임 사용 방식

Pod 중심의 컨테이너 관리

사용자 -> kube-apiserver -> kubelet -> 컨테이너 런타임 -> 컨테이너 생성

• Kubernetes의 특이점: 컨테이너 하나를 생성하는 명령이 없음

• Pod 단위 관리: Pod 안에 컨테이너를 하나 이상 명시

• 실제 동작 과정:

   

  • 사용자가 Pod 생성 명령을 kube-apiserver에 전달

     

  • kube-apiserver가 해당 API를 kubelet에게 전달

     

  • kubelet이 Pod 내용을 확인하여 컨테이너 개수 파악

     

  • 컨테이너 런타임에게 컨테이너 생성 요청(컨테이너 개수만큼 반복)

5.2 CRI(Container Runtime Interface) 도입 배경

초기 Kubernetes의 문제점(1.0 버전)

• 하드코딩된 런타임 지원

  • kubelet 소스에 케이스문으로 Docker인지 rkt인지 판단

  • Docker와 rkt 호출 API들을 따로 패키지로 관리

  • 런타임 추가 시마다 kubelet 소스 수정 필요

CRI의 혁신적 해결책(1.5 버전부터)

• 인터페이스 분리 패턴 적용

  • kubelet이 CRI 인터페이스만 호출

  • 각 런타임별 구현부를 따로 분리

  • 새로운 런타임 추가 시 kubelet 수정 불필요

• 오픈소스 기여 방식

  • 구현부는 Kubernetes 프로젝트에 포함

  • Docker, rkt 등 런타임 측에서 Kubernetes 프로젝트에 기여하는 형태

5.3 Docker 지원 변화의 복잡한 역사

dockershim의 등장과 역할(1.5~1.23 버전)

• CRI 도입 시점의 타협책

  • Docker는 CRI 이전부터 사용되던 런타임

  • CRI 규격에 맞지 않는 Docker를 위한 어댑터 역할

  • "Kubernetes에서 Docker 지원 중단" 첫 번째 소동의 원인

"Docker 지원 중단" 소동의 진실

• 1.20 버전 발표: dockershim 사용 중단 경고

   

  • 사람들의 오해: "Docker를 못 쓴다"

  • Kubernetes 답변: "CRI 규격 맞춘 Docker Shim 있으니 그대로 사용 가능"
    

• 1.24 버전 발표: dockershim 완전 제거 예고

  • 또 다른 오해: "이제 정말 Docker 못 쓴다"

  • 많은 사람들이 containerd로 전환 시작

dockershim 제거 배경

• 관리 부담과 품질 문제

  • 1.5부터 1.23까지 오랜 기간 유지되면서 관리가 소홀

  • 버그가 많이 발생

  • Docker 자체의 수익 모델 문제로 인한 관리 어려움

Mirantis의 구원투수 역할

• Docker 인수 후 적극적 대응

  • CRI-dockerd 어댑터 개발

  • 본질적으로는 dockershim을 외부로 분리한 것

  • 1.24 버전부터 Docker 지원 재개

  • 새로운 이름: Mirantis Container Runtime(MCR)

참고: Mirantis는 OpenStack 프로젝트를 주도하던 회사로, 가상화 분야에서 오랜 경험을 가지고 있다.

5.4 CRI 구조의 한계와 최신 발전

여전한 구조적 문제점

CRI 도입 후에도 Kubernetes가 아쉬워하는 부분:

• 개발 라이프사이클의 불일치

  • 컨테이너 런타임 기술 개발 ≠ Kubernetes 기능 개발

  • Docker에 새 기능 추가 → Kubernetes도 패치 필요

  • 런타임 변경 시 CRI 구현체도 수정 필요 → 결국 Kubernetes 패치

최종 해결책: Direct CRI 지원(1.27 버전)

기존: kubelet -> CRI 구현체 -> 컨테이너 런타임
최신: kubelet -> 컨테이너 런타임(CRI 플러그인 내장)

• containerd의 CRI 플러그인: 런타임 자체에서 CRI 인터페이스 제공

• CRI-O의 네이티브 지원: 태생부터 이 규격에 맞춰 개발

• Mirantis Container Runtime: cri-dockerd를 통해 이 구조 지원

현재 구조의 최종 모습(1.27 버전 기준)

• 기본 동작: kubelet이 런타임에 직접 CRI 호출

• 통신 방식: gRPC 프로토콜 사용

• 이 강의의 실습 환경: 1.27 버전 Kubernetes 사용

5.5 런타임 계층 구조의 최종 정리

High-Level vs Low-Level 구분

개발 언어와 유사한 분류:

• High-Level Runtime(사용자 친화적)

  • Docker, Podman 등

  • 다양한 편의 기능 제공

  • 사용하기 쉽지만 상대적으로 무거움

• Low-Level Runtime(기계 친화적)

  • LXC, rkt 등

  • 기본 기능에 충실

  • 가볍고 빠르지만 사용하기 어려움

최종 기술 스택

Kubernetes(kubelet)
    ↓ CRI gRPC
containerd / CRI-O / MCR
    ↓
runc(공통 OCI Runtime)
    ↓
Linux Kernel(cgroups, namespaces)

• 공통점: 모든 런타임이 최종적으로 runc 사용

• 차이점: 사용자 인터페이스와 부가 기능

• 호환성: OCI 표준으로 이미지 호환성 보장

6. Docker Desktop 유료화의 정확한 이해

6.1 유료화 정책의 실제 범위

• Docker Desktop만 유료화

  • Windows/Mac용 개발 환경 도구

  • GUI 기반 Docker 관리 도구

  • 기업 규모에 따른 유료화(직원 250명 이상 등)

• 서버용 Docker Engine은 여전히 무료

  • Linux 서버에서 사용하는 Docker

  • 프로덕션 환경에서는 전혀 영향 없음

  • 컨테이너 런타임으로서의 Docker는 계속 무료

7. 기업의 CentOS 대응 전략과 교훈

7.1 CentOS 종료가 주는 시사점

IBM 인수 후 전략 변화

• Red Hat의 새로운 수익 모델

  • CentOS 사용자를 RHEL로 유도

  • 무료 제품을 통한 시장 확산 -> 유료 전환 전략

  • 기업용 소프트웨어의 일반적인 비즈니스 모델

오픈소스 선택 시 고려사항

• 커뮤니티 vs 기업 주도 프로젝트

  • 기업 주도 프로젝트의 정책 변경 리스크

  • 벤더 록인 위험성

  • 장기적 지속가능성 평가 필요

7.2 기술 선택의 객관적 지표 활용

구글 트렌드 분석의 중요성

• Rocky Linux vs AlmaLinux 비교 예시

  • 검색 빈도: Rocky Linux가 압도적 우세

  • GitHub 스타수: 20배 차이

  • 포크수: 5배 차이

  • 커뮤니티 활성도가 기술의 생존에 직결

오픈소스 선택 시 체크리스트

1. 커뮤니티 규모: GitHub Stars, Forks, Contributors

2. 개발 활동: 최근 커밋 빈도, 이슈 처리 속도

3. 기업 후원: 안정적인 후원사 존재 여부

4. 생태계: 관련 도구 및 플러그인 풍부함

5. 문서화: 설치/운영 가이드 완성도

8. 기업 관리형 Kubernetes의 현실적 가치

8.1 운영 복잡성의 현실

Kubernetes 학습 곡선의 실제

• 빙산 모델: 보이는 부분은 일부, 실제 운영에 필요한 지식은 방대

• 운영 영역의 확장

  • 모니터링 시스템 구축 필요

  • 로깅 시스템 통합 구성

  • 보안 정책 설정 및 관리

  • 스토리지 및 네트워킹 설정

  • 장애 대응 및 복구 프로세스

중소기업의 현실적 제약

• 인력 부족 문제

  • 1-2명의 운영자가 전체 인프라 관리

  • Kubernetes 전문가 채용의 어려움

  • 장애 발생 시 해결 능력의 한계

8.2 기업 관리형 Kubernetes의 실제 가치

통합 패키지의 편의성

• Kubernetes + 운영 도구 일괄 설치

  • 모니터링 도구 자동 설치

  • 로깅 시스템 통합 구성

  • 배포 도구까지 포함된 완전한 패키지

  • 개별 도구 호환성 문제 해결

운영 부담 경감

• 단순화된 운영 프로세스

  • 관리 화면의 빨간불 모니터링만으로 충분

  • 복잡한 Kubernetes 명령어 숙지 불필요

  • 문제 발생 시 기술 지원팀의 전문적 도움

배포 환경별 선택

• 프라이빗 환경: 자체 서버실에서 관리형 Kubernetes 운영

• 퍼블릭 클라우드: 각 클라우드 회사의 Kubernetes 서비스 이용

참고: 구체적인 제품명을 언급하지 않았지만, 실무에서는 AWS, GCP, Azure 등 주요 클라우드 제공업체들이 각각 관리형 Kubernetes 서비스를 제공하고 있다.

9. 실무에서 흔한 오해와 정확한 이해

9.1 강의 시작 퀴즈 해답 분석

첫 번째 오해: "도커 유료화로 런타임 사용 불가"

• 잘못된 인식: Docker 전체가 유료화되어 사용할 수 없다

• 정확한 사실: Docker Desktop만 특정 기업에 유료, 서버용 Docker Engine은 무료

• 실무 영향: 프로덕션 환경에서는 전혀 영향 없음

두 번째 오해: "containerd가 새로운 더 좋은 기술"

• 잘못된 인식: containerd가 Docker를 대체하는 새로운 기술

• 정확한 사실: Docker 내부에서 사용하던 기능을 분리한 것

• 기술적 관계: Docker -> containerd -> runc 구조에서 중간 계층

세 번째 오해: "기존 Docker 이미지 재작성 필요"

• 잘못된 인식: 런타임 변경 시 이미지를 다시 만들어야 함

• 정확한 사실: OCI 표준 준수로 모든 런타임에서 동일 이미지 사용 가능

• 실제 상황: Docker -> containerd 전환 시 이미지 재작성 불필요

9.2 기술 학습과 정리의 중요성

지식의 휘발성 문제

• 1년 후 기억률: 강의 내용의 대부분을 망각

• 재학습 비용: 같은 내용을 반복해서 공부하는 비효율

• 실무 적용 시: 학습했던 내용을 찾지 못해 잘못된 판단

개인 정리의 가치

• 나만의 관점으로 재구성: 이해한 방식으로 정리하여 기억력 향상

• 빠른 검색 가능: 필요한 순간에 즉시 참고할 수 있는 자료

• 지속적 업데이트: 새로운 경험과 지식을 축적하여 내용 보강

10년차 엔지니어의 차이

• 깊이 있는 이해: 여러 기술을 넓게 아는 것보다 핵심 기술의 깊은 이해

• 경험 기반 판단: 비슷한 상황에서의 경험을 바탕으로 한 신속한 의사결정

• 체계적 지식 관리: 학습한 내용을 체계적으로 정리하고 활용하는 능력

10. 현재와 미래의 기술 전망

10.1 컨테이너 생태계의 현재 상황

Kubernetes의 사실상 표준화

• 시장 지배력: 컨테이너 오케스트레이션 분야에서 압도적 점유율

• 기업 도입: 대부분의 클라우드 네이티브 전략의 핵심

• 학습 필요성: 현대 인프라 엔지니어의 필수 기술로 인식

런타임 다양성의 의미

• 선택의 자유: 요구사항에 맞는 런타임 선택 가능

• 벤더 락인 방지: 특정 기술에 종속되지 않는 아키텍처

• 지속적 혁신: 경쟁을 통한 기술 발전 촉진

10.2 학습자를 위한 실용적 조언

기술 선택 시 판단 기준

1. 커뮤니티 활성도: GitHub 스타, 포크, 이슈 활동

2. 기업 후원: 안정적인 개발 지원 여부

3. 생태계 완성도: 주변 도구 및 플러그인 풍부함

4. 학습 자료: 문서화 수준 및 예제 풍부함

5. 실제 사용 사례: 프로덕션 환경에서의 검증된 사용

효과적인 학습 전략

• 개념 이해 우선: 세부 설정보다 전체적인 흐름과 원리 파악

• 실습과 이론 병행: 실제 환경에서의 경험과 이론적 배경 연결

• 지속적 정리: 학습한 내용을 자신만의 방식으로 문서화

• 커뮤니티 참여: 실무자들과의 소통을 통한 실제 경험 공유