[Kubernetes][CKA] Core Concepts - Cluster Architecture 개요 및 Docker vs ContainerD

Cluster Architecture

개요

목적 : 자동화된 방식으로 app 을 컨테이너 형태로 호스팅

→ Why ? 응용 프로그램의 많은 인스턴스를 쉽게 배포하고, 응용프로그램 내 다양한 서비스 간의 통신이 가능 

 

• 쿠버네티스 클러스트는 노드의 집합이다.
• 노드는 on-premise 또는 클라우드, 컨테이너 일 수 있다. 
• 노드의 종류에는 워커노드와 마스터 노드가 있다.
  • 관계
    • 마스터 노드는 클러스터의 전반적인 관리와 조정을 담당하며, 워커 노드는 실제 컨테이너를 실행하는 역할
    • 마스터 노드의 컴포넌트들은 워커 노드에 있는 애플리케이션의 배포, 관리 및 스케줄링을 조정
    • kubelet은 워커 노드에서 실행되며, kube-apiserver를 통해 마스터 노드와 통신
    • kube-apiserver는 kubelet의 요청을 받고, 적절한 명령을 내려 워커 노드에서의 컨테이너 관리를 조정
    • ETCD는 클러스터의 중요한 데이터를 저장하며, 클러스터의 상태와 구성을 관리하는 중심적인 역할
      • 데이터는 클러스터를 운영하는 데 필수적이며, 마스터 노드의 다양한 컴포넌트들이 이 정보를 사용하여 클러스터를 조정
  • Worker Nodes : Host Application as Containers ( 쿠버네티스 클러스터에서 실제로 애플리케이션을 호스트하는 노드 )
    • kubelet
      • 각 워커 노드에서 실행되며, 마스터 노드로부터 받은 명령(파드 생성, 삭제 등)을 수행
      • 컨테이너가 정의된 대로 실행되고 유지되는 것을 관리
    • kube-proxy
      • 네트워크 프록시로서 작동하여, 워커 노드 내의 컨테이너 간, 또는 외부 네트워크와의 네트워크 통신을 관리
    • Contoller Runtime Engine
      • 실제로 컨테이너를 실행하는 소프트웨어입니다. Docker가 가장 일반적인 예시지만 다른 엔진도 지원
  • Master : Manage, Plan, Schedule, Monitor Nodes ( 클러스터의 관리 및 조정을 담당 )
    
    • ETCD Cluster : Key-Value Database
      • 키-값 저장소로, 클러스터의 모든 설정과 상태 정보를 저장
    • kube-scheduler 
      • 파드를 어떤 워커 노드에 배치할지 결정
      • . 리소스 요구사항, 하드웨어/소프트웨어/정책적 제약 등을 고려하여 스케줄링
    • Controller-Manager : Node-Controller, Replication-Controller
      
      • 다양한 컨트롤러를 실행
      • 노드 컨트롤러(Node-Controller)는 노드의 상태를 관찰
      • 복제 컨트롤러(Replication-Controller)는 파드의 복제 수를 관리
    • kube-apiserver
      
      • 클러스터와의 모든 통신의 진입점
      • 사용자, 외부 시스템, 워커 노드의 kubelet과의 모든 API 호출을 처리

 

 

쿠버네티스가 새로운 기술 트렌드라고 해서 어디에나 적합한 것은 아니다.

실제로 컨테이너 형태의 배포 조차 적합하지 않은 프로그램이 있고(게임 회사 다니면서 배웠다 ㅋㅋㅋ), 컨테이너의 수가 적다면 쿠버네티스 클러스터를 구축하고 관리하는 것이 오버헤드가 될 수도 있다.

쿠버네티스 시대의 도래는 마이크로서비스 시대로인해 시작된게 아닐까 생각이 든다. 지금은 쿠버네티스가 대세지만, 요즘들어 Back to the basic 의 일종으로 모놀리식 애플리케이션으로 돌아가는 모습도 많이 보이니 앞으로 어떻게 될 지는 모르는 일이다.

 

* 마이크로서비스 : 독립적으로 배포 및 확장할 수 있는 작은 서비스 단위로 애플리케이션을 분해하는 접근 방식

→ 쿠버네티스로 인해 마이크로서비스의 배포, 관리, 확장 등이 용이하게 됨

 

[ 쿠버네티스의 사용이 적합하지 않은 케이스 ] 

1. 컨테이너 환경의 배포가 적합하지 않은 애플리케이션

- 깊은 시스템 수준의 통합이 필요한 경우

- 매우 높은 성능이 필요한 경우

2. 작은 규모의 배포

- 관리가 복잡하고, 일정 규모 이상의 인프라와 애플리케이션의 운영할 때 그 가치가 있다

- 소규모 배포의 경우 쿠버네티스 관리가 더 부담스러울 수 있다

3. 오버헤드

- 위와 동일하게 쿠버네티스 클러스터 구축 및 유지는 어렵다. 인프라, 보안, 네트워킹, 스토리지 등 다양한 작업이 필요하다.

 

 

Docker vs ContainerD

Docker(Dominant), rkt  => Kubernetes Ochestrates Docker

 

= User needs more than Docker =>

 

Kubernetes CRI ( Container Runtime Interface ) - OCI 준수하는 Container Runtime 은사용 가능 

( Docker 는 OCI 준수 X => dockershim ) 

 

---

 

Docker : CLI , API, BUILD, VOLUMES, AUTH, SECURITY, containerd

=> containerd compatible with CRI

 

containerd => can work directivly with kubernetes like other CRI

 

=> docker support removed ( docker follows Image OCI so still works and can works with containerd, but no CRI )

 

---

containerd used to part of docker but now seperate project

 

containerd's cli : ctr

- only for debugging containerd

- limited options

- not user-friendly

 

=>

 

nerdctl

 

similar to docker cli and supports most of options

 

=>

 

crictl

 

interact with CRI  ( CLI for CRI compatible container runtimes )

used to inspect and debug container runtimes

not to create containers idelaly

works across differenct runtimes

사용자의 필요성과 쿠버네티스의 CRI:

• 사용자들은 단순한 도커를 넘어서 추가적인 기능을 필요로 함.
• 이에 쿠버네티스는 CRI(Container Runtime Interface)를 도입.
• OCI(Open Container Initiative) 표준을 준수하는 모든 컨테이너 런타임은 쿠버네티스와 호환될 수 있음.
• 도커는 OCI를 준수하지 않아서 'dockershim'이라는 어댑터를 사용했었음.

 

도커의 구성요소:

• 도커는 CLI(Command Line Interface), API, 빌드, 볼륨 관리, 인증, 보안 기능 등을 포함함.
• 여기서 중요한 점은 도커의 핵심 구성요소인 'containerd'가 CRI와 호환된다는 것.

 

=> 쿠버네티스 버전 업그레이드와 도커 지원 제거

 

containerd와 쿠버네티스:

• containerd는 쿠버네티스와 같은 다른 CRI와 직접 작동할 수 있음
• 도커 지원이 제거되었음에도 불구하고, 도커는 OCI 이미지 표준을 따르기 때문에 여전히 동작함
• containerd를 통해 쿠버네티스와 함께 사용될 수 있음

containerd와 ctr CLI:

containerd는 과거 도커의 일부였지만, 이제는 별도의 프로젝트로 운영

containerd의 CLI 도구인 'ctr'는 주로 디버깅용이며 사용자 친화적이지 않고 옵션이 제한적

 

nerdctl과 crictl 도구:

• nerdctl:
  • 도커 CLI와 유사하며 대부분의 옵션을 지원
  • 사용자 친화적인 대안으로 제공됨
• crictl:
  • CRI 호환 컨테이너 런타임과 상호작용하는 CLI 도구
  • 주로 컨테이너 런타임을 검사하고 디버깅하는 데 사용
  • 컨테이너를 생성하기 위한 주요 도구는 아니며, 다양한 런타임에서 작동