Multi Master & 컨테이너 런타임

최근 업데이트일 2024-11-17

따라하며 배우는 쿠버네티스: 멀티마스터 쿠버네티스 클러스터

쿠버네티스: Options for Highly Available Topology

고가용성을 위해 Master Node가 여러 개인 클러스터를 구성해보고, 각 Node가 Node가 되기 위해 가져야 하는 컨테이너 런타임에 대해서 알아보자.

Multi Master Kubernetes

• kubespray: Ansible 기반의 쿠버네티스 클러스터 자동 설치 툴
  • kubeadm을 내부적으로 호출하면서, 네트워크 구성, SSH 연결, OS 최적화, 다중 노드 설정, HA 로드밸런서 설정까지 모든 작업을 Ansible로 자동화하였다.
  • Ansible: 여러 서버에 자동으로 명령을 실행하고 설정을 관리할 수 있게 해주는 오픈소스 자동화 도구
    • 서버 여러 대에 동시에 ssh 접속해서, 서비스를 시작하는 것을 자동으로 해주는 도구
  • kubespray는 Ansible을 이용한 Kubernetes 클러스터 자동 배포 템플릿이다.

kubeadm을 이용해서 control plane을 여러 대(3,5,7) 중첩해서 구성하여 Highly Available(HA)한 cluster를 운영할 수도 있다.

• 클러스터 외부(또는 worker)에서 단일 API Server 주소를 바라보게 하고 작업을 분배하는 용도로 load balancer가 필요하다
• 모든 마스터 노드는 로컬 etcd를 가지며, 서로 클러스터링되어 데이터 일관성 유지해야 한다.

과정

Master node 3대 LB 1대 Worker node 2대로 구성한다.

1. container runtime(Docker or containerd or crio) install
2. kubeadm · kubelet · kubectl install
   • 방화벽 포트 개방 및 swap 비활성화
   • iptables에서 bridge listening
   • repo 등록 및 daemon 설정 (Kubernetes 프로젝트의 공식 저장소 URL을 등록하여 최신버전 패키지 설치)
3. LB 구성
   • nginx를 컨테이너로 실행하고 -p 6443:6443 포트포워딩 설정 가능
   • 포트 6443에 모든 master의 API server를 연결하도록 설정
4. HA Cluster 구성 후 Worker node 연결
   • Master1에서 kubeadm init --control-plane-endpoint "[lb-address]:6443" --upload-certs로 클러스터 생성 (API server 주소는 LB의 IP 사용)
   • Master2, Master3는 kubeadm join [lb-address] ~로 control plane으로 조인
   • 각 마스터에 kubectl 설정 (admin.conf) 후 CNI 설치
   • Worker Node 설치

컨테이너 런타임

쿠버네티스는 다양한 컨테이너 런타임을 지원하며, 컨테이너 런타임은 실제로 컨테이너를 실행하고 관리하는 소프트웨어이다.

• 쿠버네티스는 다양한 컨테이너 런타임을 통일된 방식으로 사용할 수 있게 해주는 인터페이스인 CRI(Container Runtime Interface)를 통해 컨테이너 런타임과 상호 작용한다.
  • 클러스터 컴포넌트를 다시 컴파일하지 않아도 kubelet이 다양한 컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스
    • 클러스터 컴포넌트는 kube-apiserver, kube-scheduler, kube-controller-manager, kube-proxy, kubelet 등을 의미한다.
  • 클러스터의 모든 노드에 동작 중인 컨테이너 런타임이 존재해야, kubelet이 Pod들과 컨테이너들을 구동할 수 있다.
  • kubelet은 CRI만 구현되어 있다면 어떤 런타임이든 통일된 방식으로 사용할 수 있다.
  • 클러스터 컴포넌트 kubelet과 container runtime 사이의 통신을 위한 주요 gRPC 프로토콜을 정의한다.

• 변화 과정
  1. 초기에는 쿠버네티스가 Docker에 의존하여 컨테이너를 실행하였다.
  2. Docker는 쿠버네티스가 직접 사용할 수 있는 CRI 표준을 따르지 않고, 자체적인 API와 런타임 구조를 가지고 있었다.
  3. 이를 dockershim이라는 중간 레이어를 도입해서 도커 API와 쿠버네티스의 CRI 사이에서 중개 역할을 했으나, 오버헤드와 관리 복잡성으로 인해 dockershim 사용이 중단되었다.
  4. 현재는 다른 CRI 호환 런타임(e.g. containerd, CRI-O) 등을 사용하는 것이 권장된다.
• Docker는 실제 컨테이너 실행을 위해 내부적으로 containerd를 런타임 엔진으로 사용하며, Docker 설치 시 containerd도 함께 설치된다.
• Kubernetes는 이 중개자(Docker)를 거치지 않고 containerd를 직접 사용하는 구조로 전환되었다.
  • 즉, k8s는 함께 설치된 containerd를 컨테이너 런타임으로 사용하는 것이다.