[K8S] Container 개념 정리

[K8S] 컨테이너 관련 개념 정리

Checkbox
Date	@2023년 2월 14일 오전 11:30

요약

• 컨테이너는 결국 프로세스

• Containerd는 Docker의 컨테이너 런타임 (애초에 Docker에서 만들었음)

• Docker 내부에 Containerd가 속해 있음

• 하지만 Dockerd를 통해 수행하는 Containerd와 별도로 수행되는 Containerd는 다름

내용

• 컨테이너의 작동 방식 (Docker 기준 위→아래)

  

  • Docker UI (Docker Desktop or CLI)
  • Docker (엔진 = dockerd)
    • Docker 자체는 컨테이너 생성, 작업 및 관리를 위한 개발자 도구
    • dockerd는 도커 엔진에서 실행하는 백그라운드 데몬(deamon) (결국 도커 엔진과 동일)
    • Network나 Volume, Namespace 관련한 처리를 수행함
  • containerd (도커 컨테이너 런타임 OCI 준수 ) ↔ CRI-O(쿠버네티스 진영에서 만든 컨테이너 런타임 OCI 준수)
    • Docker에서 개발한 컨테이너 런타임인 Containerd는 컨테이너를 탑재하고 운영 체제 커널과 함께 작동하여 컨테이너화 프로세스를 시작하고 지원하는 엔진의 구성 요소임
    • containerd 밑에 containerd-shim을 통해 runc를 호출 (shim은 틈새를 메꾸는 의미를 가짐)
    • container에 대한 기능만 가지고 있는 것이 containerd, 고수준 컨테이너 런타임에 해당
    • 이미지 관리, 압축 해제, 저수준 컨테이너 런타임으로 전달
    • 혼동이 발생하는 부분!!
      • containerd 또한 ctrcli라고 불리는 containerd 전용 CLI Client를 제공하면서, Docker 엔진과 마찬가지로 데몬 형태로 동작함 (홀로 동작이 가능함)
      • containerd 홀로 실행이 되면 자체 Namespace 기능을 제공하는 데, Docker를 통해 실행되는 Containerd는 moby라는 이름의 네임스페이스에 모든 컨테이너를 생성함
      • K8S에서 CRI를 통해 containerd를 제어하면 K8S의 네임스페이스 정책을 따라감
  • runc (저수준 컨테이너 런타임)
    • OCI를 준수, 이전 libcontainer로 부름 (여러 OS에서 생성할 수 있게 만든 라이브러리)
    • 실제 컨테이너를 생성하고 종료하는 런타임
    • 오로지 컨테이너를 실행하는 기능만 제공
  • Container (프로세스)
    • 이미지 - 어디서나 실행할 수 있도록 코드가 라이브러리 및 실행에 필요한 항목과 함께 패키징 되어 있다
    • 컨테이너 - 이 이미지를 실행 시켜 생성된 격리된 프로세스 (OS 커널만 공유)
    • Docker, CRI-O, RKT LXD와 같은 엔진들이 어플리케이션을 패키징, 배송 및 실행할 수 있도록 환경 제공

• K8S에서 발생한 문제 (출처 - 참고자료 이쿠님 블로그)

  

  • CRI 컨테이너 런타임 인터페이스
    • kubelet이 다양한 컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스
  • kubelet에서 명령을 실행할 시에 cri > docker-shim > dockerd를 통해 실행을 했었음
  • docker-shim 유지보수에 어려움이 많아짐, k8s 진영에서 docker에게 CRI를 따르라고 전달
  • Docker 진영에서 1년 넘게 CRI를 따르지 않음 > docker-shim 제거
  • 결국 Docker 엔진 하위에 동일한 Containerd를 실행한다고 하지만, dockerd에 지배를 받는 containerd와 홀로 실행되는 containerd는 namespace의 영역에서 차이가 발생함

배울 점

• containerd가 무엇인지 docker가 무엇인지 계속 혼동 되는 것이 많았는 데 정리가 될 수 있었음

• OSS간에 호환성과 서로의 영향이 발생하여서 단호하게 제거되는 면을 볼 수 있었음

 

추후 해야할 것

• containerd 사용해보기

---

참고자료

컨테이너란?  |  Google Cloud

컨테이너는 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 경량 소프트웨어 패키지입니다.

https://cloud.google.com/learn/what-are-containers?hl=ko

86. Kubernetes docker 지원 중단 관련 설명

kubernetes docker 지원 중단 관련 설명 목표 kubernetes 에서 2021년 하반기 1.23 version 부터 docker를 지원하지 않는다고 하는데 그 이유를 자세히 알고싶어서 리서치를 진행했던 과정을 정리해봄. 이유와 대처 방법을 알아봄. 2022-02 월 내용 추가 사항 현재 Docker는 Mirantis(미란티스)가 인수해서 cri-docker를 지원함. 그래서 k8s 1.23에서 Docker를 사용할 수 있음.

https://ikcoo.tistory.com/189

containerd vs. Docker: What’s the Difference?

This article explores the differences between containerd, a container runtime of Docker, and Docker, which is a container engine.

https://blog.purestorage.com/purely-informational/containerd-vs-docker-whats-the-difference/

containerd는 무엇이고 왜 중요할까?

2013년 Docker가 처음으로 세상에 나타난 이후 IT업계는 정말 크게 변했습니다. 어플리케이션의 배포단위는 이제 war, jar, zip 등이 아니라 Docker 이미지가 되었고 Docker를 사용할 수 있는 환경이기만 하면 어플리케이션은 Windows에서든, Ubuntu에서든 동일하게 동작하였습니다.

https://www.linkedin.com/pulse/containerd%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/?originalSubdomain=kr

흔들리는 도커[Docker]의 위상 - OCI와 CRI 중심으로 재편되는 컨테이너 생태계

컨테이너에 대한 관심이 급격히 증가하면서 대부분의 주요 IT 벤더와 클라우드 공급자들은 컨테이너 기반의 솔루션을 발표했고 관련 스타트업 또한 급증해 컨테이너의 생태계를 넓혀왔습니다. 하지만 포맷과 런타임에 대한 특정한 규격이 없다 보니 컨테이너의 미래는 불안했던 것이 사실입니다. 일례로 2013년 출시된 도커(Docker)가 사실상의 컨테이너 표준 역할을 했지만 코어OS(CoreOS)는 도커와는 다른 규격으로 표준화를 추진하려 했습니다. 이러한 문제를 해결하기 위해 2015년 6월 도커, 코어OS, AWS, 구글, 마이크로소프트, IBM 등 주요 플랫폼 벤더들은 애플리케이션의 이식성(Portability) 관점에서 컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 만들기 위해 OCI(Open Container Initiative)를 구성하였습니다. 이후 컨테이너 시장은 OCI의 런타임 명세와 이미지 명세를 준수하는 방향으로 성장하였고 그 과정에서 2016년 12월 쿠버네티스(Kubernetes)의 컨테이너 런타임을 만들기 위한 CRI(Container Runtime Interface)가 등장했습니다.

https://www.samsungsds.com/kr/insights/docker.html