이 글은 일프로 선생님의 쿠버네티스 어나더 클래스 지상편을 수강하고
복습 메뉴얼을 가이드에 따라 작성한 포스팅입니다
위 대화에는 몇 가지 오류가 있다고 한다
여러분도 한 번 찾아보길 바란다 :)
아래는 컨테이너의 개요이다
정의 내용이 만만치 않다 (하지만 이 글을 작성하는 지금의 나는 저 내용이 아주 멀게 느껴지진 않는다)
쉽게 얘기하면,
OS의 커널 기능을 이용해서 호스트 OS의 자원을 격리하고
커널을 제외한 경량화한 OS를 설치후 필요한 애플리케이션을 기동한다
이렇게 되면 호스트 OS가 윈도우, 우분투, 레드햇 종류 없이 동일한 동작을 보장한다
혹시나 어렵게 느껴지면 미안하다 ...
리눅스 OS 역사
유료 CLI OS인 Unix가 있었지만, 유료라 오래가지는 못하고 유저층은 리눅스에게 넘어간다
이 리눅스는 무료(데비안)과 유료(레드햇)로 나뉘게 된다
레드햇의 배포과정은
개발(Fedora) -> 정식 릴리즈 (유료) (RHEL) -> 무료 (CentOS)
-로 진행된다
CentOS의 경우 무료이나 유지보수 지원이 안된다
그리고 ver 7이 24년에 종료를 한다
그리고 배포 과정이 아래처럼 바뀌게 된다
페도라 OS 이후에
테스트 베드인 CentOS Stream이 나오고 RHEL이 나온다
즉, 안정화 버전이 없어졌다
그리고 복사본인 Rocky Linux(무료)가 생겼다 (이곳엔 Cent OS 창립자가 있다)
컨테이너 기술 역사
커널 기술인 chroot, cgroup, namesapce 이 최초에 있었고
이 기술을 바탕으로 LXC(Linux Container)가 탄생한다
그리고 이 기술을 기반으로 도커가 생긴다
도커의 컨테이너 생성 기술만 별도로 분리하여 container D가 생긴다
도커의 재정상황이 약해지면서 유저풀이 조금씩 빠져나갈때 미란티스가 도커를 인수한다
그리고 구글 트렌드에 의하면 도커는 아직 건재하다 !
CNCF(Cloud Native Computing Foundation)에 containerD, CRI-O가 기부되고
containerD는 Graduated가 된다 (성숙한 기술, 졸업생과 같다. 믿고 쓰면 된다고 한다)
가장 빨리 졸업한 1기 졸업생은 쿠버네티스 (2015) 다
컨테이너 기술 의존 관계도
용어 정리
컨테이너 런타임: 도커와 같이 컨테이너를 만들고 실행하는 기술
컨테이너: 컨테이너 런타임으로 생성된 생성물
태초에 리눅스 커널 가상화 기술이 있다 (#1)
#1을 토대로 저수준 컨테이너 런타임인 LXC가 만들어진다 (#2)
#2를 사용하는 libcontainer가 생긴다 (아직 저수준이다) (#3)
그리고 #3을 기반으로 사용자 친화적인 (고수준) 도커가 나온다
도커엔진의 기술 의존 관계는
dockerd -> container d -> libcontainer -> LXC -> kernel 기능 순서로 의존한다
예를 들어, 사용자가 `
kubectl apply -f create-pods.yml` 라고 입력하면 아래처럼 호출된다
kube-apiserver는 쿠버네티스 내에서 여러 기능들과 커뮤니케이션을 관장하는 곳이다
kubelet은 컨테이너 생성 과정을 중계한다
(컨테이너 생성 자체는 컨테이너 런타임이 한다)
버전별 kubelet 구조 변화
1.0 ~ 1.20 Deprecated
kubelet에서 분기문에 의해 docker, rkt 로 나뉘어 처리한다
그러나 container d 등 컨테이너 런타임이 많아지면서 kubelet 소스코드가 계속 변경이 되어야만 했다
1.5 ~ 1.23 Deprecated
그래서 쿠버네티스는 인터페이스(CRI)를 두고 구현체를 분리하기로 한다
CRI(Container Runtime Interface)의 구현체로 dockershim, CRI-Containerd, rktshim 가 있다
kubelet과 CRI는 서로 gRPC로 통신한다
이때 도커는 OCI(컨테이너 표준) 규약을 지키기 위해 runC를 개발했다
OCI를 규약(규격)을 지켜서 만든 컨테이너는 서로 호환이 된다
따라서 이 runC를 통해서 도커와 container d, rkt는 이미지가 서로 호환이 된다
그리고 runC가 생기면서 이제 containerD는 libcontainer를 거치지 않고 바로 kernel 레벨의 가상화 기술을 사용한다
그러나 아직 문제가 있다,
컨테이너 런타임에 업데이트가 될때 이제 kubelet 소스는 변경되지 않지만
저 CRI 구현체가 변경이 된다. 그리고 이 CRI 구현체는 쿠버네티스 영역이다
(각 컨테이너 런타임이 CRI 구현체로 contribution을 하는 구조이다)
1.24 ~
인터페이스와 구현체를 제거하고
구현체의 역할은 이제 각 컨테이너 런타임이 담당한다
container d의 경우 CRI-Plugin을 두었고
cri-o는 태생부터 redhat 이 규격을 맞춰서 만들었다
도커(미란티스 컨테이너 런타임)도 이를 위해 cri-dockerd 를 만들었다
쿠버네티스 공감짤
'Infra, DevOps > 인프런 k8s 복습인증' 카테고리의 다른 글
[일프로님 k8s 복습인증] 5. App기능으로 이해 Probe (2) | 2024.02.05 |
---|---|
[일프로님 k8s 복습인증] 4. Object 그려보며 이해하기 (0) | 2024.01.24 |
[일프로님 k8s 복습인증] 3. 실무에서 느껴본 쿠버네티스가 정말 편한 이유 (1) | 2024.01.24 |
[일프로님 k8s 복습인증] 2. 쿠버네티스 무게감 있게 설치하기 (0) | 2024.01.23 |
hi hello... World >< 가장 아름다운 하나의 해답이 존재한다
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!