인프런 '초보를 위한 쿠버네티스 안내서' 강의를 들으며 정리한 내용입니다.
1. 용어 및 발음 정리
- master : 마스터
- node : 노드
- k8s : 쿠버네티스
- kubectl : 큐브 컨트롤
- etcd : 엣지디
- pod : 팟
- istio : 이스티오
- helm : 헬름
- knative : 케이 네이티브
2. 쿠버네티스 소개
컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리
컨테이너를 쉽게 관리하고 연결하기 위해 논리적인 단위로 그룹화
kubernetes = k8s
k와 s 사이에 알파벳이 총 8개 있어서 k8s라고 줄여서 표기하기도 한다.
Cloud Native Computing Foundation = CNCF
클라우드 네이티브란?
클라우드 이전에는 리소스를 한 땀 한 땀 직접 관리
(웹서버, 디비서버 모두 서버별로 나눠서...)
클라우드 이후에는 수많은 리소스를 자유롭게 사용하고 추상적으로 관리
클라우드 환경에서 어떻게 애플리케이션을 배포하는게 좋을까?
ex. 컨테이너, 서비스메시, MSA, API, DevOps -> Cloud Native 하다~
쿠버네티스는 클라우드에 어울리는 배포시스템이다.
3. 쿠버네티스 아키텍처
요청을 보내는 부분 | Master (체크, 실행하는 영역) | Node (실제로 컨테이너 실행 부분)
중간에서 교통 정리 해주는 사람 == API Server
상태를 저장하고 조회하는 데이터베이스 == etcd (엣지디)
Master 상세
1) etcd
- 모든 상태와 데이터를 저장
- 분산 시스템으로 구성하여 안전성을 높임 (고가용성)
- 가볍고 빠르고 정확하게 설계 (일관성)
- Key(directory) - Value 형태로 데이터 저장
- TTL (time to live), watch같은 부가 기능 제공
- 백업 필수!
2) API Server
- 상태를 바꾸거나 조회
- etcd와 유일하게 통신하는 모듈 (다른 컴포넌트가 엣지디 정보를 API Server에게 물어봄)
- REST API 형태로 제공
- 권한 체크하여 권한이 없을 경우 요청 차단
- 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
- 수평으로 확장되도록 디자인
3) Scheduler
- 새로 생성된 Pod을 감지하고 실행할 노드를 선택
- 노드의 현재 상태와 Pod의 요구사항을 체크
4) Controller
- 논리적으로 다양한 컨트롤러 존재 (복제 컨트롤러, 엔드포인트 컨트롤러, ...)
- 끊임없이 상태를 체크하고 원하는 상태를 유지
- 복잡성을 낮추기 위해 하나의 프로세스로 실행 (단일 프로세스)
5) 조회 흐름
1. [Controller -> API Server] 정보 조회 요청
2. [API Server] Controller의 정보 조회 권한 체크
3. [API Server -> etcd] 권한이 있으면, etcd에 정보 조회 요청
6) 기본 흐름
1. [etcd -> API Server] 원하는 상태 변경 되었음을 전달
2. [API Server -> Controller] 원하는 상태 변경 알림
3. [Controller] 현재 상태와 원하는 상태가 달라졌기 때문에 원하는 상태로 리소스 변경
4. [Contoller -> API Server] 변경사항 전달
5. [API Server] Controller 정보 갱신 권한 체크
6. [API Server -> etcd] 권한이 있으면 etcd에 정보 갱신
NODE 상세
Kubelet 큐블릿
- Pod을 실행하고 중지하고 상태를 체크하기 때문에 각 노드에 떠서 동작해야 함.
- CRI (Container Runtime Interface)
: docker, Containerd, CRI-O, ...
Proxy 프록시
- 네트워크 프록시와 부하 분산 역할
- 성능상의 이유로 별도의 프록시 프로그램 대신 iptables 또는 IPVS를 사용 (설정만 관리)
쿠버네티스 흐름
1. [관리자 -> API Server] 관리자가 Pod 요청
2. [API Server -> etcd] Pod 요청 etcd에 적어두기
3. [Controller -> API Server] 새로 생긴 Pod이 있는지 계속 확인
4. [Controller -> API Server] 새 요청 확인 후 API Server에 Pod 할당 요청
5. [API Server -> etcd] API Server는 Pod 할당 요청하도록 etcd 상태 수정
6. [Scheduler -> API Server] 할당 요청이 들어온 Pod이 있는지 계속 확인
7. [Scheduler] 특정 노드에 Pod 할당
8. [Scheduler -> API Server] 특정 노드 Pod 할당 정보 받기
9. [API Server -> etcd] 이 Pod을 특정 노드에 할당하는데, 상태는 아직 실행되기 전 상태임을 etcd에 업데이트
10. [Kubelet] 내 노드에 할당된 팟 중에서 아직 실행되지 않은 팟이 있는지 확인
11. [Kubelet] 있는 경우, Pod 생성
12. [API Server -> etcd] Pod이 생성되었으므로 Pod이 노드 할당 되고, 실행중임을 etcd에 업데이트
4. 쿠버네티스 오브젝트
1) Pod
- 가장 작은 배포 단위
- 각 Pod마다 고유한 IP를 할당
- 여러개의 컨테이너가 하나의 Pod에 속할 수 있음
2) ReplicaSet
- 여러개의 Pod을 관리
- 새로운 Pod은 Template을 참고하여 생성
- 신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 수(Replicas)를 유지
3) Deployment
- 배포 버전을 관리
- 내부적으로 ReplicaSet을 이용
4) Service - CluserIP
- 클러스터 내부에서 사용하는 프록시
- Pod을 로드밸런스 하는 별도의 서비스
- Pod은 동적이지만 서비스는 고유 IP를 가짐
- 클러스터 내부에서 서비스 연결은 DNS를 이용
내부에서만 사용 가능함. 외부 브라우저로는 접근 불가.
5) Service - NodePort
- 노드(host)에 노출되어 외부에서 접근 가능한 서비스
- 모든 노드에 동일한 포트로 생성
- 노드가 여러개여도 아무 노드에나 보내더라도 내부적으로 ClusterIP를 찾아감
연결한 노드가 죽는 경우, 다른 노드로 붙어야 하는데 순간적으로 접속이 되지 않음. 이를 방지하기 위해 로드밸런스를 앞에 둠.
6) LoadBalancer
- 하나의 IP 주소를 외부에 노출
- 사용자는 로드 밸런서로 요청을 보내고, 그 요청이 노드 포트로 가고, 그 요청이 다시 클러스터 아이피로 가고, 다시 팟으로 감.
7) Ingress
- 도메인 또는 경로별 라우팅
- Nginx, HAProxy, ALB 등을 쿠버네티스에 맞게 포장해서 사용
Deployment를 띄우고
Deployment가 ReplicaSet을 자동으로 생성하고
ReplicaSet이 Pod을 자동으로 생성하는 구조.
외부에 노출해야 하므로 Service(ClusterIP)를 붙이고
Ingress를 붙임. Ingress를 붙이면 LoadBalancer와 NodePort가 자동으로 따라옴.
클라이언트는 도메인으로 접속하면
로드 밸런서를 거쳐서 노드 포트를 거쳐서 클러스터 아이피를 거쳐서 팟으로 연결됨.
5. API 호출
Object Spec
- YAML 으로 명세 작성
- apiVersion : apps/v1, v1, batch/v1, networking.k8s.io/v1, ...
- kind : Pod, Deployment, Service, Ingress, ...
- metadata : name, label, namespace, ...
- spec : 각종 설정
- status (read-only) : 시스템에서 관리하는 최신 상태
API 호출
: 원하는 상태(desired state)를 다양한 오브젝트(object)로 정의(spec)하고 API 서버에 yaml 형식으로 전달
'STUDY > 쿠버네티스' 카테고리의 다른 글
| [초보를 위한 쿠버네티스 안내서] 컨테이너 오케스트레이션 (1) | 2022.09.12 |
|---|
