카테고리 없음

컨테이너 한방 정리 (쿠버네티스 어나더 클래스 지상편)

종종이94 2024. 3. 4. 13:57

쿠버네티스는 '컨테이너', '가상화', '데브옵스' 속으로 녹아져있어, 이 세가지 개념을 알아야 쿠버네티스를 이해하는데 도움이 되어, 이번 섹션은 **'컨테이너'**를 중심으로 쿠버네티스를 이해하는 강의였다.

 

 

강의주요 내용

Linux OS, Container 의 흐름 (어떤 OS 에 쿠버네티스를 설치해야하는지, 컨테이너-쿠버네티스 연관 관계)

Linux OS 의 역사

 

 

 

최초의 OS 인 Unix 는 유료 인 반면 Linux 는 무료. 무료 짱짱! 배포판도 엄청 많이 만들어졌음

주요 배포판 두개! 'Debian', 'Redhat' 계열이 있으며 OS 설치의 주류로 무료는 Debian(커뮤니티용), 유료는 Redhat(Redhat 기업에서 만듦)이 있다. 쿠버네티스 설치도 크게 이 두가지 계열 모두 지원한다!

 

 

 

Debian 계열

'Ubuntu' 가 전 세계적으로 많이 쓰이고, Debian을 기반으로 만듦. 사용자 편의(예. UI) 추가

 

 

 

Redhat 계열

'배포판이 만들어 지는 순서가 있는데,

개발버전(fedora, 무료) → 안정화 버전(RHEL, 유료) →복제 버전(CentOS, 무료) 순이다.

시장 점유율이 적어 CentOS 가 종료된다고 한다.

그리고 Redhat 이 IBM에 인수되며 배포판 순서가 달라졌고,

개발버전(fedora, 무료) → 테스트버전(CentOs Stream, 바이너리 호환 문제) → 안정화버전(RHEL, 유료) 순이다.

또, 추가로 이 RHEL 을 복사하여 만든 무료 배포판인 Rocky Linux(CentOS 설립자 중 한명이 만듦), AlmaLinux 가 있다.

 

 

Container 의 역사

 

리눅스 OS의 핵심 기술 중 하나인 격리 기술은 사용자, 파일, 네트워크, 자원(CPU/메모리), 프로세 분리를 가능하게 합니다.

 

chroot : 유저 격리, 파일 격리, 네트워크 격리

cgroup : 자원 격리로, 각 앱마다 cpu, memory 를 할당할 수 있게 되었다.

namespace : 프로세스 격리로, 독립적인 환경에서 앱을 실행할 수 있게 되었다.

 

위 기술 기반으로, Container 가 만들어집니다.

 

LXC : (LinuX Container) 최초 컨테이너

docker : 현재 rootless 모드가 생겨 보안이 강화되었다. (과거 root 권한으로 설치/실행 했었어야 했다), 그리고 mirantis 라는 회사에 인수되어 쿠버네티스 인터페이스를 잘 맞추려는 노력 중!

rkt : 로켓이라는 컨테이너로 당시 docker 의 보안의 안 좋은 점을 공략해서 나왔다고 한다.

cri-o : Redhat 에서 인수하여 밀고 있는 컨테이너 (rkt 입지 감소)

 

더 뒤의 역사는 쿠버네티스랑 함께 이야기해야하는데,

쿠버네티스가 표준화가 되고 있는 반면, 쿠버네티스의 인터페이스와 잘 맞지 않는 docker...

 

 

쿠버네티스 호환성과 잘 맞는 containerd, cri-o 가 나왔다.

containerd : docker 에서 컨테이너를 만들어지는 기능이 분리되어 나옴, CNCF 에 기부(Graduated Project 상태로, 믿고 써도 된다)

cri-o 도 CNCF 에 기부됨

현재는, 쿠버네티스가 컨테이너 런타임을 알아서 조작해주게 되면서, 직접 컨테이너를 다룰 일이 줄어들게 되었고, 쿠버네티스 인터페이스와 잘 맞는 컨테이너를 선택하는게 중요해졌다.

 

 

Container 사용하는 이유

1. 동일한 OS 커널을 공유하기 때문에 애플리케이션 실행에 필요한 컴퓨팅 자원 경량화 달성

2. 컨테이너는 각각 독립적으로 실행되기 때문에 하나의 컨테이너가 문제가 다른 컨테이너 영향을 미치지 않는다.

3. 컨테이너가 모든 종속 항목을 함께 전달하기 때문에 한번 만든 컨테이너 이미지느 어느 컴퓨팅화경에서 재구성 필요없이 사용 가능  

 

 

 

Container Orchestration 란

  • 앱을 컨테이너에 담아서 배포
  • 시스템 운영 노하우를 가짐 (예. Auto-Scale, Self-Healing 등)
  • 쿠버네티스가 여러 Container Orchestration 중 대표!!! (넘사벽, CNCF 인정...)

 

 

 

Container Orchestration 의역사

 

 

kubernetes : CNCF 에 기부, CNCF 1기 졸업생

openshift, rancher, vmware tanzu : kubernetes 를 가지고 기업들이 만든 것, 기업관리형으로 제공됨(쿠버네티스 + 모니터링 + 로깅 등), 기업의 자체 서버실에 프라이빗하게 쿠버네티스를 쓰고 싶을 때 사용됨

퍼블릭으로 가장 많이 쓰이는 건 AWS, GCP, NCP 등의 클라우드 회사에서 제공중인 서비스

 

 

 

 

 

 

 

  • 사용자 친화적인건 고급어이고, 기계에 친화적 일수록 저급어로 나뉩니다.
  • 최조의 컨테이너는 LXC는 커널레벨의 기술을 가지고 만든 로우레벨 런타임 → Docker가 LXC 기반으로 libcontainer라는 Low Level 컨테이너 런타임 만듬
  • LXC는 운영체제를 컨테이너 가상화로 나누기 위한 목적으로 사용 / 도커는 APP을 컨테이너화 해서 가상화로 나누기 위한 목적으로 사용
  • 런타임에는 RKT가 있다. 도커 보다 보안은 좋지만 로우레벨 런타임이라 꺼려하는 분위기임

 

 

 

 

Container 생성 과정

 

 

 

 

kube-apiserver : 쿠버네티스 내에서 여러 기능들과 커뮤니케이션을 관장

kubelet : 컨테이너 생성 과정을 중계

 

위 그림으로, Container Runtime 과 Container 를 명확히 구별할 수 있다.

Container Runtime : 컨테이너를 만들고 실행하는 기술

Container : 컨테이너 런타임으로 생성된 생성물 (예. Docker)

 

 

ex)  컨테이너 2개를 한 Pod에 만들라는 명령을 보내면 kube-api server는 kubelet한테 전달 → kubelet은 Pod안에 컨테이너가 2개인걸 확인하고 → 컨테이너 런타임한테 컨테이너 생성명령을 날린다.

 

Container Runtime

  • LXC : Kernel 레벨의 기술을 가지고 만든 Low Level 컨테이너 런타임
  • libcontainer : docker 가 LXC 를 기반으로 만든 Low Level 컨테이너 런타임
  • docker : libcontainer 를 이용하여 사용자 친화적으로 만든 High Level 컨테이너, 기능 집약적!

 

 

  • rkt : 보안에는 좋으나 Low Level 로 점유율 낮아짐

목적이 다른데, LXC 는 운영체제를 컨테이너 가상화로 나누기 위함(나의 linux 에 CentOS 나 Ubuntu를 게스트 OS 로 띄움), docker 는 app 을 독립적인 환경에 띄움

 

 

 

Kubelet 의 역사

kubelet 은 Container Runtime 이 받을 수 있게 API 호출을 한다. 버전별 흐름은 아래와 같다.

v1.0 ~ v1.20

 

kubelet 소스에 케이스 문으로, Docker 인지 rkt 인지 판단하는 로직이 있고, Docker 와 rkt 에 호출하는 API를 모아놓은 패키지들도 있어서 맞춤형 API를 Container Runtime 으로 호출한다.

 

 

v1.5 ~ v1.23

 

 

 

 

 

Container Runtime 이 점점 늘어남에 따른 변화를 수용하는 버전으로 인터페이스를 추가한다.

kublet 의 인터페이스 규격을 정하고, 이 규격에 맞는 구현부를 만들었다.

이 구현부를 CRI 라고 컨테이너 런타임 인터페이스라고 부르며 각각의 컨테이너 런타임을 호출한다.

CRI 는 쿠버네티스 프로젝트에 있으며, Container Runtime 측에서 소스를 contribution 하는 형태이다.

참고. dockershim 관리가 이루어지지 않아 버그도 많았고, 그래서 kubernetes 에서 dockershim 을 빼겠다고 이야기 하기도 했다고 한다. (docker 를 더이상 지원하지 않는 다는 썰로 착각 NO!)

한편, CRI 가 많아지며 표준 규약을 관리하는 OCI 등장!! 해당 규약을 지키면 CRI 끼리 공유가 가능!!

참고로, docker 에서 containerd 로 변경 시 기존 이미지를 변경하지 않아도 되는게 containerd 는 docker 내부에 있었음. 즉 docker 도 containerd 로 컨테이너를 생성함.

docker 는 OCI 규격을 지키고자, Low Level 의 runC 를 만들었고 containerd 에서도 runC 를 쓸 수 있게 변경했다. runC 가 libcontainer 와 다른 점은 LXC 를 사용하지 않고 커널레벨의 가상화 기술을 쓴다.

rkt 도 OCI 규격을 따르며, docker 에서 돌던 이미지를 rkt 에서도 사용할 수 있게 된다.

 

 

 

 

 

 

v1.24 ~

 

 

 

 

 

kubelet 에서 CRI 로 바로 호출하는 구조로 변경한다. (이전 버전은, Container Runtime 이 패치 혹은 변경 등의 변화로 CRI 패치가 되는 경우 Kubernetes 도 패치되어야 하는 구조)

  • containerd 에서는 CRI-Plugin 기능 추가
  • cri-o : Redhat 에서 태생부터 이 규격을 맞춰 만듦
  • cri-dockered : mirantis 회사가 docker 를 인수하고나서, 규격을 맞추기 위해 만듦. dockershim 을 밖으로 빼낸 거라고 보면 된다. 이렇게 되면서 docker 를 다시 지원할 수 있게 되었고 이름은 '미란티스 컨테이너 런타임'이라고 부름

 

 

 

 

강의 속 퀴즈(?)

강의를 듣고난 후, 초반부에 소개해주신 아래 대화에 오류 세가지에 대해 짚을 수 있었다.

 

 

오류1. Docker 유료화

Container Runtime 의 Docker 를 유료화하는 것이 아니라 윈도우 설치용 Docker Desktop 유료화.

 

오류2. ContainerD 라고 더 좋은게 나왔다

ContainerD 는 기존 Docker 엔진에서 사용하던 기술이다.

 

오류3. Docker 로 만들었던 이미지를 다시 만든다

OCI 표준이라 만들지 않아도 된다.

쿠버네티스는 '컨테이너', '가상화', '데브옵스' 속으로 녹아져있어, 이 세가지 개념을 알아야 쿠버네티스를 이해하는데 도움이 되어, 이번 섹션은 **'컨테이너'**를 중심으로 쿠버네티스를 이해하는 강의였다.