[Kubernetes] 컨테이너 한방 정리

 

◎ Linux OS의 역사

 

linux

1) 최초 OS UNIX 탄생

2) UNIX 기반의 LINUX 탄생

3) Linux는 지속적 업데이트를 통해 아래 두 계열로 구분됨

• 무료판 Debian 계열
• 유료판 Redhat 계열

4) 데비안을 기반으로 만든 배포판 Ubuntu 탄생

5) Redhat 계열은 linux 배포판이 만들어지는 순서가 있음.

• 새로운 기능을 개발하는 버전인 fedora
• fedora가 안정화되면 RedHat Enterprise Linux로 이름을 바꿔 release(RHEL)
• RHEL을 복제한 CentOS

6) CentOS7 - 2024 지원 종료, CentOS8 - 2021 지원 종료.

7) IBM이 Redhat을 인수하며 Redhat 배포판을 만드는 순서 변경

• fedora를 통해 초기 개발
• CentOS Stream으로 기능 테스트(바이너리 호환성 보장이 안될 수 있음)
• 안정화 후 Redhat Linux(RHEL) 배포

8) RHEL을 복제해서 무표 배포판을 만든 프로젝트

• Rocky Linux - 시장점유율 압도적 => 이번 학습에 사용될 OS
• Alma Linux

◎ Container

1) 격리 기술

• chroot - 유저격리, 파일격리, 네트워크 격리
• cgroup - 자원 격리(cpu, memory). 각각의 App마다 cpu나 메모리 할당
• namespace - 프로세스 격리

=> 위 기술들을 집약해서 정리한 Linux Container(LXC) 탄생

 

2) Docker

• LXC 기반으로 Docker 탄생(사용자 친화적으로 사용하기 매우 편함)
• 등장 당시 root 권한으로만 설치가 가능해 보안 취약문제 제기(현재는 rootless로 해결)
• docker 첫 시연 영상 ->  https://www.youtube.com/watch?v=9xciauwbsuo  

 

3) rkt(Rocket) 탄생

• 도커에 비해 안정적인 컨테이너 강조
• 리눅스 배포판 중 컨테이너 전용 OS인 CoreOS가 있고, 이 OS에 대한 대표 런타임
• Redhat이 CoreOS를 인수하며 fedora CoreOS로 변경
• Redhat은 cri-o라는 컨테이너를 밀고 있어 rkt는 점점 입지가 줄어듦

◎ Container Orchestration

 => Container Orchestration에는 여러 종류가 있지만 Kubernetes가 시장점유율이 압도적. 

 

1) 컨테이너와 컨테이너 오케스트레이션의 차이

 

• 컨테이너만 런타임 사용

1. 사용자가 docker에 App 생성 명령
2. docker가 container 생성
3. 만들어진 container가 App V1이 됨
4. 해당 App을 버전2로 업그레이드
5. 정상 기동 될 때까지 기동확인 과정 필요
6. V1으로 흘러가던 트래픽을 V2로 전환(docker에서 네트워크 수정 명령)
7. App V1삭제

• 컨테이너 오케스트레이션 사용 시

1. 사용자가 쿠버네티스에게 App 생성 명령
2. 쿠버네티스가 컨테이너 런타임(docker)에게 명령 전달
3. 런타임에서 컨테이너 생성
4. 해당 App을 버전2로 업그레이드
5. 쿠버네티스가 AppV2를 모니터링 후 기동이 완료되면 네트워크 수정, 트래픽 전환, App V1 삭제

★ Container Orchestration의 특징

 1. App을 컨테이너에 담아서 배포한다.

 2. 시스템 운영 노하우를 많이 가지고 있다.

 

◎ Container Orchestration(쿠버네티스)과 컨테이너들 간의 흐름

1) Kernel 레벨 기술 - chroot, namespace, cgroup(깊은 레벨의 기술)

2) Container runtime

• High Level - 사용자 친화

       1. libcontainer를 기반으로 사용자 친화적으로 만든 docker 탄생

docker

• Low Level - 기계에 친화

       1. LXC(Kernel level의 기술로 만든 컨테이너 런타임) 

       2. docker가 LXC를 기반으로 libcontainer라는 컨테이너 런타임 만듦

 

3) 쿠버네티스 흐름

  1. pod 생성(컨테이너 갯수 명시 가능)

  2. kube-apiserver가 쿠버네티스로 보내지는 모든 api 받음

  3. 현재 받은 api를 kublet에 전달

  4. kublet이 pod 확인 후 컨테이너 갯수 확인]

  5. 컨테이너 런타임에 컨테이너 생성 명령(컨테이너 갯수만큼)

  6. 요청받은 만큼의 컨테이너를 생성 

 

* 컨테이너를 생성해주는 역할을 하는 것이 컨테이너 런타임

 

CRI(Container Runtime Interface)란 ?

 - 처음 docker, rkt 두 개의 런타임 존재(v1.0)

 - containerd, cri-o같은 런타임이 계속 생기면서 런타임이 추가될 때마다 kubelet 소스코드를 수정해줘야 하는 문제 발생

 - v1.5부터 인터페이스 규격을 kubelet에 정하고 이를 구현하는 구현부를 따로 만듦

   -> OCI 탄생

OCI(Open Container Initiative)란?

 - 컨테이너를 만들 때 지켜야 하는 표준 규약을 관리하는 단체.

 - 런타임들끼리 컨테이너 공유 가능

 - 즉, docker에서 돌던 컨테이너를 rkt에서도 사용 가능

 

출처 : https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%96%B4%EB%82%98%EB%8D%94-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%A7%80%EC%83%81%ED%8E%B8-sprint1