kubernetes_object
Last updated
Last updated
https://kubernetes.io/it/docs/concepts/overview/components/
마스터와 노드
쿠버네티스는 크게 마스터와 노드 두개의 컴포넌트로 분리
쿠버네티스 마스터
전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행합니다. 즉 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할입니다.
etcd, kube-apiserver, kube-scheduler, kube-controller-manager
쿠베네티스 노드
실제 배포되는 컨테이너 애플리케이션을 실행합니다.실제 사용자가 사용하는 컨테이너들은 대부분 노드에서 실행합니다.
노드나 파드나 컨테이너처럼 쿠버네티스 위에서 동작하는 워크로드를 호스팅 하는 역할
노드에서 kubelet, kube-proxy, docker등이 실행합니다.
마스터 컴포넌트
마스터 컴포넌트
클러스터 전체를 관리하는 컨트롤러로 클러스터의 컨트롤 플레인을 제공합니다.
클러스터에 관한 전반적인 결정(ex-스케줄링)을 수행하고 클러스터 이벤트(ex-디플로이먼트와 replicas 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응합니다.
클러스터 내 어떠한 머신에서도 동작 가능하며 API Server, Controller Manager, Scheduler, etcd로 구성되어 있습니다.
관리자는 Master API Server를 통해 K8s를 관리하며 모든 컴포넌트들을 API Server를 통해 서로 통신합니다.
kube-scheduler
애플리케이션의 배포를 담당합니다.(애플리케이션의 배포 가능한 각 구성 요소를 워크 노드에 할당)
노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의 컴포넌트
새로운 파드를 만들어질 때 현재 클러스터내에서 자원할당이 가능한 노드들 중에서 알맞은 노드를 선택해서 그곳에 포드를 띄우는역할
파드는 처음 실행될 때 여러 가지 조건을 지정해서 실행하는데, kube-scheduler가 그 조건에 맞는 노드를 찾아주는 역할
스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함힙니다.
Kube-controler-manager
컨트롤러를 구동하는 마스터 상의 컴포넌트
구성 요소 복제본, 워커 노드 추적, 노드 장애 처리 등과 같은 클러스터단의 기능을 수행하며 쿠버네티스 클러스터의 상태를 항상 감시하는 백엔드 컴포넌트입니다.
각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일 되고 단일 프로세스내에서 실행합니다.
cloud-controller-manager
바탕을 이루는 클라우드 제공사업자와 상호작용하는 컨트롤러를 작동
클라우드 밴더 코드와 쿠버네티스 코드가 서로 독립적으로 발전 나갈 수 있도록 해줍니다.
kube-apiserver
사용자, 컨트롤 플레인 구성 요소와 통신합니다.
쿠버네티스 API를 노출하는 마스터 상의 컴포넌트, 쿠버네티스 컨트롤 플레인에 대한 프론트엔드
클러스터로 요청이 왔을때 그 요청이 유효한지 검증하는 역할
쿠버네티스로의 모든 요청은 kube-apiserver를 통해서 다른 곳으로 전달
kube-apiserver는 수평적으로 확장이 가능하게 설계가 되어 있어서, 여러 대의 장비에 여러 개를 띄워놓고 사용합니다.
쿠버네티스는 MSA(마이크로서비스아키텍처) 구조로 여러 개의 분리된 프로세스로 구성되어 있습니다.
ETCD
https://github.com/mjs1995/Certified-Kubernetes-Administrator/blob/main/docs/02_Core%20Concepts.md
고가용성을 제공하는 분산 키-밸류(key value)스토어(저장소)로 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소입니다.
쿠버네티스에서 필요한 모든 데이터를 저장하는 실질적인 데이터베이스
프로세스 1개만 띄워서 사용할 수도 있지만 데이터의 안전성을 위해서는 여러 개의 장비에 분산해서 etcd 자체를 클러스터링을 구성해서 실행하는 게 일반적인 방법
etcd가 안정적이기는 하지만 보다 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업 필요
curl 등 HTTP 클라이언트/라이브러리로 작업 가능합니다.
노드 컴포넌트
동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작합니다.
노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있습니다. 여러 개의 파드는 하나의 노드 위에서 동작할 수 있습니다.
kubelet
클러스터내의 모든 모드에서 실행되는 에이전트
쿠버네티스 마스터와 통신하며 Pod들과 Node의 상태를 클러스터에 보고합니다.
파드내의 컨테이너들이 실행되는걸 직접적으로 관리하는 역할
다양한 메커니즘으로 제공된 PodSpec 설정 집합을 가지며, PodSpec에 기술된 컨테이너들이 정상적으로 실행되고 있는지 상태 체크를 진행
노드안에 있는 컨테이너라고 하더라도 쿠버네티스에 의해 생성되지 않은 컨테이너들은 관리하지 않습니다.
Docker 컨테이너를 실행하거나 스토리지를 마운트하는 기능을 갖으며 클러스터의 구성 정보를 YAML 또는 .JSON 형식의 정의 파일로 관리합니다.(매니페스트-manifest파일)
kube-proxy
클러스터 내 각 노드에서 실행되는 네트워크 프록시
각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시
쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리하며 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스입니다.
호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로써 쿠버네티스 서비스 추상화가 가능하도록 해줍니다.
컨테이너 런타임
실제로 컨테이너를 실행시키는 역할
가장 많이 알려진 런타임으로는 도커(Docker)가 있고, 그외 rkt, runc 같은 런타임도 지원합니다.
컨테이너에 관한 표준을 제정하는 역할을 하는 OCI(Open Container Initiative)의 런타임 규격을 구현하고 있는 컨테이너 런타임이라면 쿠버네티스에서 사용 가능합니다.
https://www.oreilly.com/library/view/kubernetes-in-action/9781617293726/
https://www.oreilly.com/library/view/cloud-native-devops/9781492040750/
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/
