Multi Node/Architecture Cluster
쿠버네티스 클러스터
쿠버네티스는 다중 아키텍처 플랫폼으로, 하나의 클러스터 안에 여러 아키텍처 노드, 여러 운영체제로 구동되는 노드가 포함될 수 있다.
컨트롤플레인 구조
쿠버네티스의 노드들 중 클러스터 관리 기능을 담당하는 노드를 컨트롤플레인이라고 부르며, 그 외 노드는 클러스터가 수행하는 작업을 실제 담당하게 된다.
컨트롤플레인에서는 API 서버 외에 DNS 서버 및 코어 시스템 컨트롤러가 동작한다.
API 서버 : 클러스터 관리를 위한 서버로, kubectl, kubernetes API에서 사용된다. HTTPS 기반의 REST API 엔드포인트로 구현된다. kube-apiserver 파드에서 실행되며 필요에 따라 스케일링된다.
스케줄러 : 파드 생성 요청이 들어오면 파드를 실행할 노드를 선택한다. kube-scheduler 파드에서 실행되며, 플러그인 컴포넌트이기 때문에 커스텀 스케줄러를 사용할 수 있다.
컨트롤러 매니저 : 외부에 드러나지 않는 코어 컨트롤러를 구동한다. kube-controller-manager 파드에서 실행되며 노드 상태를 감시하고 서비스 엔드포인트를 관리한다.
etcd : 쿠버네티스의 데이터 저장소로 클러스터와 관련된 데이터가 저장된다. 분산 key-value 데이터베이스이므로 클러스터 내에 여러 복제본이 존재한다.
AKS 와 같은 클라우드 매니지드 쿠버네티스 환경에서는 컨트롤플레인을 직접 관리하지 않아도 된다.
컨트롤플레인을 여러 대 둘 수 있으며 일부 노드가 다운되면 나머지 컨트롤플레인 노드끼리 투표해 새로운 컨트롤플레인 노드를 뽑는다.
노드의 구조
노드는 파드를 생성하고 파드 컨테이너를 유지하며 파드를 쿠버네티스 네트워크에 연결시킨다.
노드에서는 다음과 같은 구성 요소가 존재한다.
kubelet은 호스트의 백그라운드 프로세스로 구동되어 파드 생성 요청을 전달받고 파드의 생애 주기를 관리한다. 노드의 상태를 컨트롤플레인 API 서버에 전달하기도 한다.
kube-proxy는 노드 내 파드끼리 통신 혹은 다른 노드끼리 통신할 때 트래픽 라우팅을 담당한다. 파드 하나를 가진 데몬셋 형태로 구동되어 각 노드마다 트래픽을 관리한다.
컨테이너 런타임은 kubelet의 지시를 받아 파드 컨테이너를 관리한다. 도커, containerd, CRI-O가 사용된다.
클러스터 구축
쿠버네티스 클러스터 구축은 대부분 kubeadm을 통해 처리한다.
다음 명령을 통해 장비를 컨트롤플레인 노드로 만들 수 있다.
컨트롤플레인 노드에는 DNS, 컨트롤러 관리자, API 서버가 동작한다.
파드 네트워크는 플러그인 모델이기 때문에
kubectl apply명령으로 직접 배치해주어야 한다.kubeadm join명령과 함께 컨트롤플레인의 IP 주소, 토큰, 인증서 해시 등을 입력해 현재 장비를 클러스터 노드로 등록할 수 있다.노드에는 kubelet이 쿠버네티스와 별개로 백그라운드 프로세스로 동작하며, 네트워크 프록시와 네트워크 플러그인이 파드 형태로 동작한다.
하이브리드 애플리케이션
컨테이너에 띄워질 이미지가 윈도우용 이미지라면 컨테이너가 실행중인 호스트 컴퓨터의 아키텍쳐도 윈도우여야 한다.
컨테이너는 자신을 실행중인 호스트 컴퓨터의 커널을 사용하기 때문이다.
쿠버네티스 클러스터에서 서로 다른 아키텍처의 애플리케이션을 실행하려면 각 아키텍처에 맞는 노드가 있어야한다.
다음과 같은 클러스터처럼 ARM CPU 리눅스, AMD CPU 리눅스, 윈도우 노드들을 갖도록 구성할 수 있다.
컨트롤플레인은 리눅스 전용이지만 kubelet, kube-proxy는 크로스 플랫폼을 지원한다.
Last updated
