[kubernetes] #2 - 기본 이해 (1/4)

Cloud/kubernetes

[kubernetes] #2 - 기본 이해 (1/4) - 아키텍처

근육곰돌이 2022. 2. 24. 19:31

이번 장에는 쿠버네티스의 기본 구성요소 (구조)에 대해 알아보겠습니다.

1. 아키텍처

쿠버네티스의 아키텍처는 생각외로 간단합니다. 쿠버네티스는 앞장에서 말씀드렸듯이 클러스터라고 보시면 됩니다.
이 k8s 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커머신의 집합(Worker Node)과 워커 머신들을 관리하는 마스터 노드(Master Node)로 구성되어 있습니다.

- 구성 노드 : 클러스터를 구성에는 두가지로 구분된 노드가 있습니다.
"Master Node" : 클러스터관리를 담당하는 마스터노드
"Worker Node" : 컨테이너가 실제 배포되는 곳이며, 모든 명령은 Master Node의 API Server와의 통신하여 애플리케이션 실행에 필요한 작업등을 수행 합니다.

각 노드간의 구성과 세부내용은 아래에 추가 설명하겠습니다.

2. 아키텍처와 컴포넌트

출처: https://kubernetes.io/ko/docs/concepts/overview/components/

1절에서 쿠버네티스는 간단하게 마스터와 워커노드로 구성된다고 말씀드렸습니다.
각 노드별로 컴포넌트들이 존재하며, 이 컴포넌트들이 서로 API를 주고 받으며 각자의 역할을 수행하여, 클러스터를 이루게 됩니다.

각각의 기능과 역할은 아래와 같습니다.

구분	구성 요소	설명
Master	kubectl	k8s를 조작하기 위한 도구로 커맨드라인 인터페이스입니다. kubectl의 명령을 API Server가 모든 명령을 수신합니다.
	kube-apiserver	kubectl등의 모든 API 클라이언트로부터 오는 REST 요청을 검증하고, API 오브젝트를 구성하고 상태를 보고합니다. 명령 수신 후 etcd에 저장한 후 다시 다른 WorkerNode들에게 명령을 전달합니다.
	kube-scheduler	k8s의 기본 스케줄이며, 새로 생성된 모든 Pod에 대해 실행할 최적의 노드를 찾아 선택합니다. 스케줄러는 Pod가 실행 가능한 노드를 찾은 다음 점수를 계산하여 가장 높은 점수의 노드를 선택한다. 만약 적합한 노드가 없다면 Pod배치 할 수 있을때까지 할당하지 않습니다.
	kube-controller-manager	컨트롤러를 구동하는 마스터상의 컴포넌트입니다. Desired-state를 미리 정의한 뒤 Current-state가 Desired-state가 되도록 하는 Control Loop 시스템입니다. 예를 들어, 에어컨과 같이 희망온도를 설정하면 에어컨이 그에 맞게 온도를 유지하려고 하는 것과 같습니다. 실제 컴포넌트로는 실행할 Pod의 개수를 관리하는 Replication Controller와 클러스터 내 전체 노드에 특정 Pod를 실행하도록 하는 Daemon Set Controller 등이 있습니다. 이들은 복잡성을 낮추기 위해 각각 단일 바이너리로 컴파일되어 단일 프로세스로서 실행됩니다.
	cloud-controller-manager	컨트롤러(Replica controller, Service controller, Volume Controller, Node controller 등)를 생성하고 이를 각 노드에 배포하며 이를 관리하는 역할을 합니다.
	etcd	k8s의 모든 관리 데이터는 etcd에 저장됩니다. etcd는 CoreOS가 개발한 분산 키/값 저장소로 신뢰성이 요구되는 핵심 데이터의 저장 및 접근을 위해 설계되었습니다. - 참고: https://github.com/etcd-io/etcd
Worker	kubelet	노드에 배포되는 에이전트로 마스터의 API서버와 통신하면서, 노드가 수행해야 할 명령을 받아서 수행하고, 반대로 노드의 상태등을 마스터로 전달하는 역할을 합니다. - 역할 정리 . Pod와 컨테이너의 실행 . Pod와 노드의 상태를 API Server에 보고 . 컨테이너의 동작을 확인하는 프로브 실행 . 내장된 cAdvisor를 통해 메트릭 수집 및 공개
	cAdvisor (Pod 아님)	각 노드에서 기동되는 모니터링 에이전트로 컨테이너들의 상태와 성능의 정보를 수집하여, 마스터 서버의 API서버로 전달한다.
	kube-proxy	kube-proxy는 각 노드로 들어오는 트래픽을 라우팅, 로드벨런싱, 프록시역할을 수행하며, 노드와 마스터간의 통신을 관리합니다. - 역할 정리 . 서비스와 Pod의 변경을 감지하여 최신 상태로 유지 . iptables 규칙을 관리 . 서비스명과 ClusterIP를 내부 DNS에 등록
ALL	kube-flannel	모든 노드에서 실행되며 여러 노드 사이에서 IPv4 네트워크를 제공한다. 이에 따라 컨테이너(Pod)는 클러스터 내부에서 사용되는 IP주소를 바탕으로 다른 노드에 있는 Pod와 통신 할수있다.
ALL	kube-calico	flannel과 동일한 역할을 하는 네트워크 기능 Pod이며, flannel과 다르게 통신, 라우팅말고도 네트워크 접근 관리 기능을 추가로 제공합니다.
Configmap	coredns	Pod가 서비스 이름으로부터 IP주소를 얻기위해 사용합니다. Pod나 서비스는 IP를 동적으로 생성되는 리소스형태이기 때문에, IP주소가 생성될때마다 변경되기 때문에 정확한 위치정보를 얻어야합니다. 이러한 관리를 위한 패턴을 Service Discovery라고하며 k8s는 내부 DNS를 구성하여 이를 관리합니다. 버전 1.11부터 kube-dns -> coredns가 사용되었고, 프로젝트는 CNCF에서 관리합니다. - 참고: https://kubernetes.io/ko/docs/tasks/administer-cluster/coredns/

- 런타임: Container runtime
: Pod를 통해서 배포된 컨테이너를 실행하는 컨테이너 런타임이다. 컨테이너 런타임은 보통 도커 컨테이너를 생각하기 쉬운데, 도커 이외에도 rkt (보안이 강화된 컨테이너), Hyper container 등 다양한 런타임이 있다.

3. 역할 분담

쿠버네티스의 역할별로 한번 나누어서 정리해보려고 합니다.
k8s를 조작을 할때 아래와 같이 역할별로 기능을 수행하게 되니 한번쯤 읽어보시면 좋을거 같습니다.

- 클라이언트의 역할
: kubectl이나 API를 통한 생성/변경/삭제 이벤트 발생
: 상태 조회

↓

- 마스터 노트의 역할
: k8s 클러스터 관리
: Pod 관리
: 클라이언트로부터 온 API를 수용하여 컨트롤러 역할 수행

↓

- 워커 노드의 역할
: 컨테이너 실행
: 애플리케이션 Pod 상태보고

↓

- 컨테이너
: 애플리케이션
: 미들웨어, 실행 환경 런타임

이번 장은 쿠버네티스의 구성요소와 아키텍처에 대해 살펴보았습니다.
보시다가 궁금한점이 있으면 댓글 부탁드립니다.

참고

https://inkkim.github.io/kubernetes/Kubernetes-%EA%B8%B0%EB%B3%B8%EC%9A%A9%EC%96%B4-%EC%A0%95%EB%A6%AC/
https://bcho.tistory.com/1258?category=731548
https://kubernetes.io/ko/docs/concepts/overview/components/

저작자표시 비영리 변경금지