[Basic] 쿠버네티스 클러스터 아키텍처

쿠버네티스 클러스터 아키텍처

쿠버네티스 아키텍처

쿠버네티스 클러스터 아키텍처

마스터와 노드

• 쿠버네티스는 크게 마스터(Master)와 노드(Node) 두 개의 컴포넌트로 분리되어 있다.
• 마스터(Master)
  • 마스터는 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할을 한다.
  • etcd, kube-apiserver, kube-scheduler, kube-controller-manager
• 노드(Node)
  • 노드는 Pod나 컨테이너처럼 쿠버네티스 위에서 동작하는 워크로드를 호스팅하는 역할을 한다.
  • 노드에는 kubelet, kube-proxy, docker 등이 실행된다.
  • 실제 사용자가 사용하는 컨테이너들은 대부분 노드에서 실행된다.

---

마스터 컴포넌트

마스터 컴포넌트 개념

• 클러스터 전체를 관리하는 컨트롤러를 의미한다.
• 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다.
• 마스터 컴포넌트는 클러스터에 관한 전반적인 결정(예: 스케줄링)을 수행하고 클러스터 이벤트(예: 디플로이먼트의 Replicas 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
• 마스터 컴포넌트는 클러스터 내 어떠한 머신에서도 동작이 가능하다.
• API Server, Controller Manager, Scheduler, etcd로 구성된다.
• 관리자는 Master의 API Server를 통해 K8S를 관리하며 모든 컴포넌트들은 API Server를 통해 서로 통신한다.

kube-scheduler

• 노드가 배정되지 않은 새로 생성된 파드를 감지하고 파드가 구동될 노드를 선택하는 마스터 상의 컴포넌트다.
• 새로운 파드들이 만들어질 때 현재 클로스터내에서 자원할당이 가능한 노드들 중에서 알맞은 노드를 선택해서 그곳에 파드를 생성하는 역할을 한다.
• 파드는 처음 실행될 때 여러 가지 조건을 지정해서 실행하는데, kube-scheduler가 그 조건에 맞는 노드를 찾아주는 역할을 한다.
• 스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약/어피니티(affinity)/안티-어피티니(anti-affinity) 명세, 데이터 지역성, 워크로드간 간섭, 데드라인을 포함한다.

kube-controller-manager

• 컨트롤러를 구동하는 마스터 상의 컴포넌트
• 논리적으로 각 컨트롤러는 개별 프로세스지만, 복잡성을 낮추기 위해 모드 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
• cloud-controller-manager는 바탕을 이루는 클라우드 제공사업자와 상호작용하는 컨트롤러를 작동한다.
• cloud-controller-manager는 클라우드 벤더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다.

kube-apiserver

• 쿠버네티스는 MSA(Microservice Architecture) 구조로 구성된다.
• 여러 개의 분리된 프로세스로 구성된다.
• 쿠버네티스 API를 노출하는 마스터 상의 컴포넌트, 쿠버네티스 컨트롤러 플레인에 대한 프론트엔드다.
• 클러스터로 요청이 왔을 때 그 요청이 유효한지 검증하는 역할을 한다.
• 쿠버네티스로의 모든 요청은 kube-apiserver를 통해서 다른 곳으로 전달한다.
• kube-apiserver는 수평적으로 확장이 가능하게 설계가 되어 있어서 여러 대의 장비에 여러 개를 띄워놓고 사용할 수 있다.

etcd

• etcd는 고가용성을 제공하는 분산 키-밸류(key-value) 저장소다.
• 쿠버네티스에서 필요한 모든 데이터를 저장하는 실질적인 데이터베이스다.
• etcd는 프로세스 1개만 띄워서 사용할 수도 있지만 데이터의 안정성을 위해서는 여러 개의 장비에 분산해서 etcd 자체를 클러스터링을 구성해서 실행하는 것이 일반적인 방법이다.
• etcd가 안정적이기는 하지만 보다 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업할 필요가 있다.
• curl 등 HTTP 클라이언트/라이브러리로 작업이 가능하다.

---

노드 컴포넌트

노드 컴포넌트 개념

• 노드 컴포넌트는 동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며 모든 노드 상에서 동작한다.
• 노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있다. 여러 개의 파드는 하나의 노드 위에서 동작할 수 있다.

kubelet

• kbelet은 클러스터내의 모든 모드에서 실행되는 에이전트다.
• 쿠버네티스 마스터와 통신한다.
• 파드들과 노드의 상태를 클러스터에 보고한다.
• 파드 내의 컨테이너들이 실행되는 것을 직접적으로 관리하는 역할을 한다.
• 다양한 메커니즘으로 제공된 PodSpec 설정 집합을 가지며 PodSpec에 기술된 컨테이너들이 정상적으로 실행되고 있는지 상태 체크를 진행한다.
• 노드 안에 있는 컨테이너라고 하더라도 쿠버네티스에 의해 생성되지 않은 컨테이너들은 관리하지 않는다.

kube-proxy

• 클러스터 내 각 노드에서 실행되는 네트워크 프록시다.
• 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시다.
• 쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리한다.
• kube-proxy는 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스다.
• 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로써 쿠버네티스 서비스 추상화가 가능하도록 해준다.

Container Runtime

• 컨테이너 런타임은 실제로 컨테이너를 실행시키는 역할을 한다.
• 가장 많이 알려진 런타임으로는 도커가 있고, rkt, runc와 같은 서비스도 런타임을 지원한다.
• 컨테이너에 관한 표준을 제정하는 역할을 하는 OCI(Open Container Initiative)의 런타임 규격(runtime-spec)을 구현하고 있는 컨테이너 런타임이라면 쿠버네티스에서 사용 가능하다.

---

애드온

애드온 개념

• 애드온은 쿠버네티스 리소스(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 기능을 구현한다.
• 클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 kube-system 네임스페이스에 속한다.

DNS

• 절대적으로 요구되지 않지만 필요로 하기 때문에 모든 쿠버네티스 클러스터는 cluster DNS를 갖추어야만 한다.
• 클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS서버다.

웹 UI (대시보드)

• 대시보드는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다.
• 사용자로 하여금 클러스터 자체 뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리 및 장애를 처리한다.

컨테이너 리소스 모니터링

• 컨테이너 리소스 모니터링은 중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공한다.

클러스터-레벨 로깅

• 클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장한다.