※ 본 내용은 「한 권으로 배우는 도커&쿠버네티스 - 한빛미디어」를 참고하여 작성하였습니다.
Kubernetes(쿠버네티스, k8s)의 구조와 기본 용어 (feat. 한 권으로 배우는 도커&쿠버네티스, 한빛미디어)
쿠버네티스를 익히면서
처음 시작할 때 용어가 너무 많고 생소해서
시작하는데 어려움이 많았습니다.
그래서 한 번은 정리하고 가는게 좋을 것 같더라구요.
쿠버네티스는 Site에 정리가 매우 잘 되어있는 편입니다.
아래 링크는 쿠버네티스 공식 docs로, 한글로 설명이 되어있습니다.
물론 용어들도 확인이 가능합니다.
하지만 쿠버네티스를 처음 접하시는 분들이 사이트를 보고 익히기에는 너무 방대하고 힘듭니다.
이 분야에 늦게 접한 저에게는 특히 설명이 잘 되어있는 자료가 중요했습니다.
그래서 주로 정리가 잘 되어있는 책을 통해 내용을 익히는데요.
최근 접했던 「한 권으로 배우는 도커&쿠버네티스 - 한빛미디어」 책은
시작하기 좋은 실습들과 다양한 그림으로 잘 정리되어있어서 초보자에게 좋은 것 같더라구요.
(강추!, 광고 아니구요 정말 제가 느꼈던 점 입니다😊)
1. 쿠버네티스의 구조
2. 용어의 정리
※ 참고 : 「한 권으로 배우는 도커&쿠버네티스 - 한빛미디어」, 쿠버네티스 - 용어집
1) 컨트롤 플레인(Control Plane) : 쿠버네티스 클러스터 전반의 작업을 관리 (또는 마스터 노드)
- kubectl :
쿠버네티스 클러스터에 명령을 내리는 역할. 다른 구성요소들과 다르게 바로 실행되는 명령형태인 바이너리(binary)로 배포되기 때문에 마스터 노드에 있을 필요는 없으나 통상적으로 API 서버와 주로 통신.
- API 서버 :
API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.
최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공한다.
또, 쿠버네티스의 API 오브젝트(예: 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
대부분의 작업은 kubectl 커맨드 라인 인터페이스 또는 API를 사용하는 kubeadm과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.
- etcd :
모든 클러스터 데이터(상태값 등)를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 Key-Value 저장소.
→ 긴급 장애 상황에서도 etcd를 통해 복구 가능. 가용성 확보.
- 스케줄러(kube-scheduler) :
노드가 배정되지 않은 새로 생성된 파드를 감지하고, 노드의 상태, 자원, 레이블, 요구조건 등을 고려해 어떤 워커노드에 생성할 것인지 결정하고 할당하는는 컨트롤 플레인 컴포넌트.
- 컨트롤러 매니저 :
쿠버네티스 리소스 관리 및 제어 역할을 한다. 컨트롤러는 마스터 노드에서 실행되며 클러스터 오브젝트 상태를 관리, 모니터링한다. 예를들어 워커 노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어진다.
컨트롤러에는 디플로이먼트(Deployment) 컨트롤러, 서비스(Service) 컨트롤러, 레플리카셋(Replicaset) 컨트롤러 등의 여러 종류가 있으며 각 컨트롤러는 특정 리소스 타입을 관리한다.
2) 노드(Node) (또는 워커노드)
- Kubelet :
쿠버네티스의 클러스터를 구성하는 각 노드에 실행되며 파드 내부의 컨테이너 실행을 담당한다. 파트의 상태를 모니터링하고, 상태이상시 해당 파트를 다시 배포하는 역할도 한다.
- Kube-Proxy :
노드에 존재하는 파드들이 쿠버네티스 내/외부와 네트워크 통신을 가능하게 한다. 이때 실제 통신은 br_netfilter와 iptables로 관리한다.
- 컨테이너 런타임 :
파드 안에서 컨테이너가 문제 없이 작동(컨테이너 생명주기를 담당)하게 만드는 표준 인터페이스이며, Kubelet과 런타임 인터페이스를 통해 통신한다. 쿠버네티스가 사용하는 런타임에는 containerd, CRI-O 등이 있다.
- 파드(Pod) :
쿠버네티스의 최소 실행단위이자 컨테이너를 실행하기 위한 오브젝트로, 컨테이너를 담을 수 있다. 쿠버네티스에서는 컨테이너가 단독으로 실행되지 않고 파드 내에서 실행된다. 파드들은 워커 노드에 분산되어 실행되는데, 하나의 파드에 속하는 컨테이너들은 모두 같은 노드에서 실행된다. 즉, 하나의 파드가 분할되어 여러 노드에서 실행되지는 않는다.
하나의 파드에 속한 컨테이너들은 같은 목적을 가진다.
파드는 컨테이너처럼 일시적인 존재로, 실행할 때마다 IP주소를 배정받으므로 IP주소가 파드를 실행할 때마다 변경된다.
3) 워크로드(Workload) : 쿠버네티스에서 실행되는 애플리케이션
- 레플리카셋(ReplicaSet) :
파드의 복제를 주로 관리하며, 클라이언트가 요구하는 복제본 개수만큼 파드를 복제하고 관리한다.
- 디플로이먼트(Deployment) :
애플리케이션의 배포와 스케일링을 관리
- 스테이트풀셋(StatefulSet) :
파드 사이에서 순서와 고유성이 보장되어야 하는 경우 사용
- 데몬셋(DaemonSet) :
쿠버네티스를 구성하는 모든 노드가 파드의 복사본을 실행하도록 한다. 쿠버네티스 클러스터에 새로운 노드가 추가되면 파드 역시 추가된다. 주로 로깅, 모니터링, 스토리지 등과 같은 시스템 수준의 서비스를 실행하는 데 사용된다.
- 잡(Job)과 크론잡(Cronjob) :
작업의 정상적인 완료/종료를 담당한다. 파드의 비정상 종료시 재실행시키며, 잡은 작업이 한 번 종료되는 것을 담당하고 크론잡은 동일한 작업이 스케줄에 따라 여러 번 수행하는 것을 담당한다.
4) 네트워크(Network)
- 서비스(Service) :
쿠버네티스의 서비스는 실행중인 파드의 수정없이도 파드를 여러 개 묶어 클러스터 외부로 노출이 가능하여, 클라이언트와 통신할 수 있게 한다.
- 인그레스(ingress) :
쿠버네티스 내부에 존재하는 서비스의 HTTP/HTTPS 루트를 클러스터 외부로 라우팅하는 역할을 한다.
- 네트워크 플러그인 :
쿠버네티스 클러스터의 통신을 위해 네트워크 플러그인을 선택하고 구성해야 함.
일반적으로 CNI로 구성하는데, 주로 캘리코(Calico), 플래널(Flannel), 실리움(Cillium) 등이 있다.
* CNI(Container Network Interface, 컨테이너 네트워크 인터페이스)
클라우드 네이티브 컴퓨팅 재단의 프로젝트로, 컨테이너의 네트워크 안정성과 확장성을 보장하기 위해 개발됨. 구성방식과 지원기능/성능이 다르므로 사용목적에 맞게 선택하여 사용한다. (ex. Calico - L3로 컨테이너 네트워크 구성 // Flannel - L2로 컨테이너 네트워크 구성)
5) 스토리지
컨테이너에 문제가 생기가너 삭제/재실행되면 컨테이너 내부에 존재하는 파일은 삭제/손상되기 쉽다. 따라서 쿠버네티스 스토리지를 활용하면 파드의 상태와 상관없이 파일 보관이 가능하다.
6) CoreDNS
클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트로, 빠르고 유연한 DNS 서버이며, 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는데 사용한다.
'Data Engineering > docker, kubernetes(k8s)' 카테고리의 다른 글
Kubernetes 서비스의 개념과 인그레스 (0) | 2024.12.19 |
---|---|
Kubernetes 노드/파드 운영을 위한 명령어(생성, 변경, 삭제, replica, cordon, drain) (1) | 2024.12.18 |
Kubernetes 설치 및 설정 Code 분석, Pod 생명주기, 기본 명령어 (1) | 2024.12.17 |
도커 네트워크 종류(bridge, host, container, none)와 통신상태 확인 (port, ping) 방법 (0) | 2024.12.15 |
도커 네트워크와 컨테이너 포트 포워딩 기본 개념 (1) | 2024.12.15 |
댓글