inflearn logo
강의

강의
N
챌린지

챌린지
멘토링

멘토링
N
클립

클립
로드맵

로드맵
지식공유

[쿠버네티스] 컨테이너 한방 정리 #3

_hamtaro_o
2

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

1.1 리눅스의 역사적 배경

Unix의 한계와 리눅스의 등장

1.2 주요 리눅스 배포판 계열

Debian 계열

Red Hat 계열

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

비용 구조 분석

 

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

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

핵심 기술 요소들

2.2 컨테이너 기술의 진화

LXC(Linux Containers)

Docker의 혁신적 변화

 

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

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

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

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

3.2 Kubernetes의 기술적 우위

구글의 운영 경험 기반

산업 표준으로서의 지위

 

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)

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

rkt(Rocket)의 등장과 특징

containerd의 등장 배경

CRI-O의 차별화

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

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

Docker 엔진의 다면적 특성

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

Docker 내부 구조의 실제

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

4.4 OCI 표준과 이미지 호환성

컨테이너 표준화의 배경

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

OCI(Open Container Initiative)의 역할

실제 구현 변화

호환성의 실제 증명

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

 

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

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

Pod 중심의 컨테이너 관리

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

5.2 CRI(Container Runtime Interface) 도입 배경

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

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

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

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

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

dockershim 제거 배경

Mirantis의 구원투수 역할

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

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

여전한 구조적 문제점

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

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

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

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

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

High-Level vs Low-Level 구분

개발 언어와 유사한 분류:

최종 기술 스택

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

 

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

6.1 유료화 정책의 실제 범위

 

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

7.1 CentOS 종료가 주는 시사점

IBM 인수 후 전략 변화

오픈소스 선택 시 고려사항

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

구글 트렌드 분석의 중요성

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

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

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

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

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

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

 

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

8.1 운영 복잡성의 현실

Kubernetes 학습 곡선의 실제

중소기업의 현실적 제약

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

통합 패키지의 편의성

운영 부담 경감

배포 환경별 선택

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

 

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

9.1 강의 시작 퀴즈 해답 분석

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

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

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

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

지식의 휘발성 문제

개인 정리의 가치

10년차 엔지니어의 차이

 

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

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

Kubernetes의 사실상 표준화

런타임 다양성의 의미

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

기술 선택 시 판단 기준

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

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

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

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

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

효과적인 학습 전략

데브옵스 · 인프라 쿠버네티스 일프로

답변 0