쿠버네티스란?

쿠버네티스란?

macOs m1 환경에서 Kubernetes 시작하기(feat. Docker)

macOs m1 환경에서 Kubernetes 시작하기(feat. Docker)

태초의 개념인 컨테이너부터 시작해보자.

• 가상화와 컨테이너
• 애플리케이션을 컨테이너로 패키징
• 컨테이너화된 애플리케이션을 클러스터에서 관리

 

가상화와 컨테이너

• 가상화를 사용하지 않은 물리 서버 : 애플리케이션의 리소스 경계를 정의할 수 없어 애플리케이션의 성능 저하 문제 발생
• 호스트 OS 혹은 하이퍼바이저 가상화 : 애플리케이션 실행을 위한 OS를 기준으로 CPU, 파일시스템, 네트워크 등의 리소스 할당
• 컨테이너 가상화 : OS는 공유하고, 독립적인 애플리케이션 실행을 위한 파일 시스템이나 CPU, 메모리, 프로세스 공간 등의 리소스 할당

 

왜 컨테이너 가상화가 대중화되었는가?

• 저렴한 이미지 생성 비용으로 애플리케이션의 신속한 변화에 대응 가능
• 개발환경과 배포환경 통합
• 클라우드 및 OS 배포 이동성
• MSA 구조에 적합
• >> 도커 << 가 나와서

 

애플리케이션을 컨테이너로 패키징하는 도커

 

개발자가 애플리케이션을 컨테이너로 패키징해서 개발하고 배포할 수 있는 서비스를 제공한다. 도커는 개발자가 컨테이너 가상화의 장점을 누릴 수 있도록 컨테이너 실행 및 관리 기능을 API로 제공한다.

 

도커는 클라이언트 - 도커 호스트(서버) - 레지스트리 구조를 가진다. 도커 호스트는 컨테이너 런타임을 사용해 이미지를 다운받고 컨테이너 실행, 배포하는 작업을 한다. 참고로 도커 호스트 안에는 컨테이너와 일대일로 대응되는 프로세스인 runC와 runC 컨테이너를 관리하는 컨테이너 런타임인 containerd, containerd와 엔드 유저를 이어주는 도커 엔진으로 구성된다. 클라이언트는 도커 명령어나 도커 데스크탑으로 도커 엔진에게 컨테이너 관리를 요청할 수 있다. 레지스트리에는 이미지나 플러그인, 확장 프로그램을 저장해두고 도커 데몬의 요청에 따라 이미지를 제공한다.

 

컨테이너화된 애플리케이션을 클러스터에서 관리하는 쿠버네티스

일반적인 n-tier 아키텍처 환경에서는 워크로드를 효율적으로 분산 배치하기 어렵다. 컨테이너를 알맞은 위치에 배포하고, 확장하며, 업데이트, 모니터링 할 수 있는 컨테이너 오케스트레이션 툴이 필요하다. 쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 시스템, 즉 컨테이너 오케스트레이션 도구이다. 참고로 컨테이너 오케스트레이션 도구로 쿠버네티스 외에 도커 스웜, Mesos 등이 있다.

 

정리하자면 애플리케이션을 프로세스 단위로 가상화하는 기술이 컨테이너이고, 애플리케이션을 컨테이너 단위로 패키징하고 실행할 수 있도록 API를 제공하는 기술이 도커, 도커를 통해 컨테이너화된 애플리케이션을 클러스터에 배치하고 관리하는 기술이 쿠버네티스이다. (’도커를 통해’라는 말은 다음 단락에서 부정된다) 크게 세 단계를 거쳐서 도약했다. 😁

 

 

🤔 쿠버네티스의 도커 지원 중단

Don't Panic: Kubernetes and Docker

Introducing Container Runtime Interface (CRI) in Kubernetes

• 컨테이너 런타임
• 처음 쿠버네티스 나왔을땐 도커를 연결했음
• 1.5 버전에 컨테이너 런타임 인터페이스 도입
  • 도커는 컨테이너 런타임을 구현하는 containerd를 사용하는 통합된 기술인데
  • 인터페이스 맞추려고 어댑터를 끼웠는데, 오버헤드도 생기고 유지보수 어려움

kublelt은 클러스터 노드에서 실행되는 에이전트. 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

 

 

쿠버네티스나 도커를 비롯한 컨테이너 플랫폼들은 이미지 다운로드, 컨테이너를 삭제와 실행을 담당하는 컨테이너 런타임을 사용한다. 쿠버네티스는 여러 컨테이너 런타임과 통신할 수 있는 컨테이너 런타임 표준 인터페이스(CRI)를 사용한다. 반면 도커는 도커 엔진을 사용해 컨테이너를 실행한다.

 

쿠버네티스는 CRI 표준을 지키는 모든 컨테이너 런타임을 사용할 수 있다. 하지만 도커는 컨테이너 런타임이 아니라, CRI 표준을 지키는 containerd를 사용하는 독립적인 소프트웨어이다. 그래서 쿠버네티스에서 도커를 사용해 컨테이너를 관리하려면 Dockershim이라는 인터페이스 어댑터를 사용했다.

 

도커 어댑터를 사용하는 방식은 컨테이너 런타임을 직접 사용하는 것보다 오버헤드가 크고, 도커심의 유지 보수 비용이 크다는 단점이 있다. 쿠버네티스가 개발될 당시에는 범용적으로 사용되던 컨테이너 관리 기술이 도커와의 연동을 목표로 했기 때문에 효율성이 떨어지더라도 연동을 선택한 것으로 보인다. 하지만 쿠버네티스가 쿠버네티스 1.5 버전(2016년)에서 CRI를 도입하여 장기적인 관점에서 컨테이너 런타임만을 사용하는 방식을 선택했으므로, 도커 지원 중단은 예정된 수순이었던 듯!

 

🤔 쿠버네티스 vs 도커 스웜

왜 도커 스웜보다는 쿠버네티스를 사용하는가?

쿠버네티스와 도커 스웜은 모두 컨테이너 오케스트레이션 툴로, 여러 대의 호스트에서 컨테이너를 배포하고 관리한다. 그럼에도 운영 환경에서 쿠버네티스를 사용하는 이유는 쿠버네티스가 대규모 클러스터의 컨테이너 오케스트레이션을 위해 설계된 툴이기 때문이다.

• 컨테이너 런타임 : CRI vs 도커 엔진
• 확장성 : 쿠버네티스는 높은 확장성을 제공합니다. 여러 대의 호스트에서 컨테이너를 실행하고 관리하는 것 외에도, 수천 대 이상의 노드에서 작동하는 클러스터를 만들 수 있습니다. 이는 쿠버네티스의 스케일링 기능이 우수하기 때문이며, 클러스터에 새로운 노드를 추가하거나 제거할 때도 자동으로 컨테이너를 재배치하여 안정적으로 운영할 수 있습니다.
• 다양한 기능 : 쿠버네티스는 다양한 기능을 제공하여 클러스터를 보다 효율적으로 관리할 수 있습니다. 라벨링, 선언적 구성, 롤링 업데이트, 로깅, 모니터링 등 다양한 기능을 지원하여 개발자나 시스템 관리자가 컨테이너 환경을 효과적으로 관리할 수 있습니다.
• 벤더 독립성 : 쿠버네티스는 벤더 독립적인 툴이기 때문에, 다양한 벤더에서 지원하는 다양한 인프라와 클라우드 플랫폼에서 사용할 수 있습니다. 따라서 기존에 사용하던 인프라와 원하는 클라우드 플랫폼에서도 쉽게 배포할 수 있습니다.