초보를 위한 쿠버네티스 안내서를 보고 학습한 내용을 정리했습니다.
설명 진짜 짱짱👍
# 쿠버네티스 구성/설계 (Architecture)
👉 발음정리
용어 | 발음 |
master | 마스터 |
node | 노드 |
k8s | 쿠버네티스, 케이에잇츠, 케이팔에스 |
kubectl | 큐브컨트롤, 큐브시티엘, 큐브커들 |
etcd | 엣지디, 엣시디, 이티시디 |
pod | 팟, 파드, 포드 |
istio | 이스티오 |
helm | 헬름, 핾(ㅋㅋ🤣), 햄 |
knacive | 케이네이티브 |
👉 쿠버네티스란? (Kubernetes = k8s = kube)
- 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리 -> 사람이 직접 하던 작업을 자동화 함
- 컨테이너를 쉽게 관리하고 연결하기 위해 논리적인 단위로 그룹화 -> Pod, Node, Replica set, Namespace, Deployment, Endpoint, Stateful set, Demon set, Volume, Service, job, Ingress ... 등
- google에서 15년간의 경험을 토대로 최상의 아이디어와 방법들을 결합 -> 구글뿐만 아니라 AWS, MS 등 최고의 기업들이 함께 기여하는중
- cncf 졸업한 프로젝트
👉쿠버네티스 아키텍쳐
# Master
1. Api server
상태를 바꾸거나 조회
Etcd와 유일하게 통신하는 모듈
Restapi 형태로 제공
권한을 체크하여 적절한 권한이 없을 경우 요청을 차단
관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
수평으로 확장되도록 디자인
2. Scheduler
새로 생성된 Pod를 감지(감시)하고 실행 할 노드를 선택
노드의 현재 상태와 pod의 요구사항을 체크
-노드에 라벨을 부여
-ex) 가용영역별 또는 인스턴스 타입(gpu) 구분
3. Contraller
논리적으로 다양한 컨트롤러가 존재
-복제컨트롤러
-노드 컨트롤러
-엔드포인트 컨트롤러…
끊임없이 상태를 체크하고 원하는 상태를 유지
복잡성을 낮추기 위해 하나의 프로세스로 실행 됨
4. etcd
모든 상태와 데이터를 저장
분산 시스템으로 구성하여 안전성을 높임 (고가용성)
가볍고 빠르면서 정확하게 설계(일관성)
Key (directory)-volue 형태로 데이터 저장
TTL, Watch 같은 부가기능 제공
백업 필수!
# Node
1.Proxy
네트워크 프록시와 부하분산 역할
성능상의 이유로 별도의 프로그램 대신
Iptables 또는 IPVS를 사용 (설정만 관리) --> 커널레벨에서 매우 빠른 iptables를 사용
2. Kubelet
각 노드에서 실행
Pod를 실행/중지하고 상태를 체크
CRI (Container Runtime Interface)
- docker
- containerd
- CRI-O
👉 쿠버네티스 흐름
1. Pod 요청 시 API 서버에서 요청을 받음
2. API 서버는 요청을 etcd에 정보를 저장 "Pod를 생성해라"
3. 컨트롤러가 새로운 Pod를 발견함(계속 확인하기때문)
4. 컨트롤러는 Pod 할당을 API 서버에 요청함
5. API 서버는 "컨트롤러가 Pod 할당을 요청했다" 정보를 etcd에 저장
6. Scheduler는 새로운 할당요청을 발견함 (계속 확인하기 때문)
7. Scheduler는 특정 노드에 Pod를 할당 한다고 API서버에 알려줌
8. API서버는 할당 정보를 etcd에 정보를 저장 "Pod가 어디에 할당되었으며, 실행되기 전이다"
9. kubelet은 내 노드에 실행되어야 할 정보를 발견 함 (계속 확인하기 때문)
10. kubelet은 Pod를 생성하고 그 정보를 API 서버에게 알려줌
11. API 서버는 "Pod가 특정노드에 생성됨" 정보를 etcd에 저장함
👉 Add Ons 컴포넌트
1. CNI (네트워크) / 필수
2. DNS (도메인, 서비스 디스커버리) /필수
3. 대시보드 (시각화)
# 쿠버네티스 오브젝트 (Object)
👉 Pod
가장 작은 배포 단위
각 pod마다 고유한 ip를 부여 받음
여러개의 컨테이너가 하나의 pod에 속할 수 있음 (ex, 앱컨테이너+로그수집컨테이너, 앱컨테이너+캐시컨테이너)
👉 Replica Set
여러개의 Pod를 관리
Template를 참고하여 신규 Pod을 생성하거나, 기존 Pod를 제거하여 원하는 수(Replicas)를 유지
👉 Deployment
배포버전을 관리 (무중단배포 사용 시)
Deployment는 내부적으로 ReplicaSet을 사용
👉 Demon Set
모든 노드에 꼭 하나씩만 떠있기를 원하는 Pod (로그, 모니터링)
👉 Stateful Set
파드를 순서대로 실행하고 싶거나, 같은 볼륨을 재활용 하고 싶을때 사용
👉 Job
한번 실행하고 종료
👉 Service - Cluster IP
클러스터 내부에서 사용하는 프록시 (로드밸런서)
Pod는 동적이지만 서비스는 고유한 IP를 가짐 (Pod의 IP는 언제나 바뀔 수 있기때문에)
클러스터 내부에서 서비스 연결끼리의 연결은 DNS를 이용
👉 Service - NodePort
노드(host)에 노출되어 외부에서 접근 가능한 서비스
모든 노드에 동일한 포트로 생성
👉 Service - LoadBalancer
하나의 IP주소를 외부에 노출 (노드 앞에 별도의 로드벨런서를 두는 방식)
👉 Ingress
도메인 또는 경로별 라우팅 (nginx, HAproxy, ALB ...)
👉 Volume
스토리지 (ebs, nfs..)
👉 NameSpace
논리적인 리소스 구분
👉 ConfigMap/Secure
설정
👉 ServiceAccount
권한계정
👉 Role/ClusterRole
권한 설정 (get, list, watch, create..)
# 쿠버네티스 API 호출
👉쿠버네티스는 yaml 파일을 사용한다!
원하는 상태를 다양한 오브젝트(object)로 정의(spec)해서 API서버에 yaml형식으로 전달하는것! (아래는 샘플)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
👉 Object Spec
apiVersion
- apps/v1, v1, batch/v1, networking.k8s.io/v1 ....
kind
- Pod, Deployment, Service, Ingress ...
metadata
- name, lable, namespace, ...
spec
- 각종 설정 (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18)
status(read-only)
- 시스템에서 관리하는 최신 상태
이제 실습하러 갑니다 GoGo!