새로운 사내 프로젝트로 IaaS, PaaS, SaaS를 통합 관리하는 플랫폼을 개발하게 되었다. 이 프로젝트를 하려면 쿠버네티스에 대한 개요라도 아는 게 필요하다고 생각해서 공부한 내용을 정리해 볼 겸 글을 쓴다.
쿠버네티스란?
컨테이너(화된 애플리케이션)의 자동화된 배포, 스케일링 등을 관리하는 확장 가능한 오픈소스 플랫폼
Pod대부분의 Pod는 1개의 컨테이너로 온전한 애플리케이션 역할을 수행한다.
한 개 이상의 컨테이너 그룹을 Pod라고 한다. 쿠버네티스는 컨테이너 단위가 아닌 Pod 단위로 클러스터를 관리한다.
쿠버네티스 플랫폼의 가장 작은 단위이며, 하나의 Pod는 온전한 하나의 애플리케이션이 된다.
Pod 내의 컨테이너들은 공유 스토리지(Volumn), 네트워크(Cluster IP), 실행 정보 (container Image version, ports, …) 를 공유한다.
Node위와 같은 노드들이 모여 쿠버네티스 클러스터를 구성한다.
쿠버네티스의 워커 머신이다. (가상, 물리 모두 가능) → “워커노드”
각 워커노드는 마스터노드에 의해 관리되며, 이런 워커노드들과 마스터노드가 쿠버네티스 클러스터를 구성한다.
모든 Pod는 노드 위에서 동작하고, 하나의 노드는 여러 개의 Pod를 가질 수 있다.
쿠버네티스 클러스터 구성요소
Control plane
클러스터에 관한 전반적인 결정을 수행하는 역할(스케줄링 등)을 수행하고, 클러스터 이벤트(디플로이먼트의 replicas
필드에 대한 요구 조건이 충족되지 않을 경우 새로운 Pod를 구동시키는 것)를 감지하고 반응한다.
kube-api server → 마스터 노드
쿠버네티스 컨트롤 플레인의 프론트 엔드의 역할을 수행한다. 즉, 클러스터의 내부 및 외부 요청을 처리한다. REST 호출
이나 kubectl
커맨드라인 인터페이스 또는 kubeadm
과 같은 기타 CLI(command-line interface)를 통해 API에 액세스할 수 있다.
kube-scheduler
노드가 배정되지 않은 새로 생성된 Pod를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트
kube-controller-manager
쿠버네티스의 다양한 컨트롤러를 관리하는 역할 (아래와 같은)
✅ 컨트롤러?
시스템 안에서 다양한 컴포넌트들의 상태를 지속적으로 모니터링하는 프로세스
Compute machines
kubelet
클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 Pod에서 컨테이너가 확실하게 동작하도록 관리한다.
kube-proxy
클러스터의 각 노드에서 실행되는 네트워크 프록시로, 운영 체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리한다.
Container runtime
컨테이너 실행을 담당하는 소프트웨어이며, Pod가 노드에서 실행될 수 있도록 클러스터의 각 노드에 컨테이너 런타임(확인 해보면 좋을 내용)을 설치해야 한다.
쿠버네티스는 containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스)구현체를 지원한다.
etcd
설정 데이터와 클러스터의 상태에 관한 모든 정보를 담는 쿠버네티스 뒷단의 저장소 역할을 수행한다. 키-값 형태의 데이터를 저장하는 데이터베이스 저장소이다.
Persistant storage
클러스터의 리소스로, 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다.
Container registry
쿠버네티스가 의존하는 컨테이너 이미지는 컨테이너 레지스트리에 저장된다.