일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
Tags
- 티스토리챌린지
- PCA
- LLM
- Classification
- 회귀
- 머신러닝
- LG Aimers
- LG Aimers 4th
- 오블완
- supervised learning
- 해커톤
- LG
- Machine Learning
- deep learning
- OpenAI
- 지도학습
- GPT-4
- gpt
- 딥러닝
- ChatGPT
- regression
- AI
- 분류
Archives
- Today
- Total
SYDev
[Docker & Kubernetes] 4주차 정리 (1) - Chapter 7. 쿠버네티스의 기본 구조 본문
7.1. 쿠버네티스의 개념
7.1.1. 쿠버네티스
- Kubernetes: 컨테이너화된 application의 자동 배포, 확장 및 관리를 해주는 open source 플랫폼
- kubernetes -> 고대 그리스어로, 배의 조타수(Helmsman)
- Kubernetes -> K8S
- Helm: 쿠버네티스 패키지 관리 프로그램
7.1.2. 쿠버네티스의 역할
- 수많은 컨테이너를 관리하는 시스템 -> 서버를 다수 운영할 경우, 서로 다른 서버에서 작동하는 수많은 컨테이너를 한꺼번에 관리
7.2. 쿠버네티스의 구조
쿠버네티스의 구성 요소 - 쿠버네티스 클러스터, 컨트롤 플레인, 노드, 워크로드, 네트워크, 스토리지
7.2.1. 쿠버네티스 클러스터
- 쿠버네티스는 다수의 노드로 구성된 경우가 많음
- 클러스터 -> mater node와 worker node로 구분
- 개발자는 주로 마스터 노드와 통신, 사용자는 인터넷을 통해 워커 노드와 통신
CNI(Container Network Interfaces)
- CNI: 쿠버네티스 클러스터에 존재하는 컨테이너 간의 통신을 위해 필요한 인터페이스
- 대표적인 플러그인: Flannel, calico
7.2.2. 컨트롤 플레인
- Control Plane: 쿠버네티스 클러스터 전반의 작업을 관리하는 역할
- 컨트롤 플레인 구성 요소 - API server, etcd, Scheduler, Control Manager
API server
- kubectl 명령어 -> kube-apiserver에 api request 전송
- 컨트롤 플레인에서의 forntend 역할
etcd
- 쿠버네티스 클러스터에 존재하는 모든 데이터를 저장하는 key-value 저장소
Scheduler
- 쿠버네티스에서는 pod라는 object를 통해 application을 실행
- pod는 쿠버네티스 클러스터 구성 노드 중 하나에 실행 -> 이때 새롭게 생성되는 pod를 어느 node에 실행시킬지 정하는 역할
Controller Manager
- 쿠버네티스 resource를 관리하고 제어하는 역할
- 컨트롤러는 master node에서 실행
- 클러스터 상태를 monitoring
- Deployment Controller, Service Controller, Replicaset Controller, ... -> 각 컨트롤러는 특정 리소스 타입 관리
7.2.3. 노드
Kubelet
- 쿠버네티스 클러스터를 구성하는 각 node에 실행 -> pod 내부의 container 실행 담당
- pod의 상태 monitoring -> 상태 이상이 있다면 pod 재배포
Kube-Proxy
- node에서 network 역할을 수행
- 존재하는 pod들이 쿠버네티스 내/외부 네트워크와 통신을 가능하게 하는 역할
Container Runtime
- 컨테이너의 생명 주기를 담당하는 역할
- Container Runtime과 Kubelet이 통신 -> 이를 위해 Container Interface 필요
- containerd, CRI-O <- 쿠버네티스가 사용하는 컨테이너 런타임
pod
- Docker -> Container 단독 실행, Kubernetes -> Pod 내부에서 실행
- pod: 컨테이너를 실행하기 위한 오브젝트
- 각 파드는 한 개 이상의 컨테이너를 담을 수 있음 -> pod는 container를 그룹화한 것
- docker의 최소 실행 단위 - container, kubernetes의 최소 실행 단위 - pod
- 하나의 pod에 속하는 containers -> 모두 같은 node에서 실행
- 서로 다른 pod는 서로 다른 노드에서 실행 가능, but 하나의 pod가 분할되어 여러 노드에 실행은 X -> 하나의 pod는 하나의 node에서 실행
- 하나의 pod에 속한 containers -> 하나의 목적을 위해 구성
- pod는 container처럼 일시적인 존재
- 실행할 때마다 IP address 배정 -> 실행할 때마다 변경
7.2.4. 워크로드
- Workload: 쿠버네티스에서 실행되는 application
- 워크로드의 종류 5가지
ReplicaSet
- pod의 복제를 관리 -> client가 요구하는 복제본 개수만큼 pod를 복제, 모니터링, 관리
Deployment
- application의 배포와 스케일링을 관리하는 역할 담당
StatefulSet
- pod 사이에서 순서와 고유성이 보장되어야 하는 경우 사용
DaemonSet
- 쿠버네티스를 구성하는 모든 node -> pod의 복사본을 실행하도록 함
- 쿠버네티스 클러스터에 new node 추가 -> pod 역시 추가
- logging, monitoring, storage 등과 같은 시스템 수준의 서비스를 실행하는 데 사용
Job & Cronjob
- Task가 정상적으로 완료/종료되는 것을 담당하는 역할
- pod가 정상 종료 X -> 재실행
- Job -> 작업이 한 번 종료되는 것을 담당
- Cronjob -> 동일한 작업 스케줄에 따라 여러 번 수행하는 것 담당, Linux의 Crontab과 유사
7.2.5. 네트워크
Service
- pod를 여러 개 묶어서 클러스터 외부로 노출
- 이미 실행 중인 pod를 외부로 노출시키기 위해 pod 내부를 수정할 필요가 없음
- 서비스 사용 -> 수정 없이 client와 통신 가능
Ingress
- kubernetes 내부에 존재하는 service를 클러스터 외부로 노출시키는 역할을 하는 resource
7.2.6. 스토리지
- 컨테이너에 이런저런 문제가 생기거나, 컨테이너가 삭제되거나 재실행되면 해당 컨테이너 내부에 존재하는 파일 모두 삭제 ->컨테이너 내부에 존재하는 파일들은 수명이 짧음
- kubernetes storage를 활용 -> pod의 상태와 상관없이 파일 보관 가능
참고자료
- "한 권으로 배우는 도커 & 쿠버네티스", 장철원, 한빛미디어, 2024.04.29
'KHUDA 6th > Study' 카테고리의 다른 글
[핸즈온 AWS] Chapter 6. AWS 데이터베이스 서비스 (1) | 2024.08.14 |
---|---|
[Docker & Kubernetes] 4주차 정리 (2) - Chapter 8. 쿠버네티스 실습 환경 구축 (0) | 2024.08.13 |
[핸즈온 AWS] Chapter 5. AWS 스토리지 서비스 (0) | 2024.08.07 |
[핸즈온 AWS] Chapter 4. AWS 부하분산 서비스 (0) | 2024.08.07 |
[Docker & Kubernetes] Port Forwarding이란? (1) | 2024.08.06 |