유튜브 초보를 위한 쿠버네티스 안내서 영상 시리즈를 보고 정리한 포스팅입니다.
서버 관리의 진화
문서화를 잘 해보자 --> 실행하는 순서를 하나하나 설명하는 ppt 등으로 만들어서 보관
문서보다는 코드를 직접 받아와서 관리해보자 --> CHEF, puppet, ANSIBLE 등의 프로그램 사용 but 하나의 서버에서 여러 버전을 돌리기 힘들었음
그럼 가상머신을 통해서 하나의 프로그램만 실행해보자 --> Oracle VirtualBox 사용 but 하나의 프로그램만 실행 가능하다. 다른 클라우드를 사용하려면 어려움이 있음, 느림
그래서 도커 등장! --> 모든 실행환경을 컨테이너로 묶어서 어디서든 쉽게 실행시킬 수 있음
컨테이너의 특징
가상머신과 비교하여 컨테이너 생성이 쉽고 효율적
언어나 프레임워크에 상관없이 애플리케이션을 동일한 방식으로 관리
개발, 테스팅, 운영환경, 로컬, 클라우드까지 동일한 환경으로 실행 가능
코드 작성 --> 도커 이미지 생성 --> 도커 저장 --> 원하는 환경에서 도커 실행
그래서 도커 이미지 생성이 중요하다.
그런데 도커 컨테이너가 많아지면 이 역시 관리가 필요하다.
왜 쿠버네티스인가?
컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼
구글에서 컨테이너를 너무 많이 사용해서 본인들이 사용하기 위해서 만들었다.
1. 오픈소스이기 때문에 다양하고 활발한 활동이 이루어짐
2. 실제 운영에서 사용하고 있는 비율이 가장 높은 오픈소스임 (카카오, 라인 등에서도 사용)
3. 무한한 확장성이 있음
4. 사실상 컨테이너 오케스트레이션 플랫폼의 표준이 되었음
어떤걸 배워야 하는가?
도커를 모른다면 쿠버네티스를 완벽하게 이해할 수 없다.
도커와 컨테이너를 먼저 완벽하게 이해하고 쿠버네티스 배포 과정을 배우면 된다.
도커와 컨테이너를 어느정도 공부를 했을 때 쿠버네티스는 다음과 같이 공부할 수 있다.
1. 도커 컨테이너 실행
도커와 도커컴포즈를 이용한 멀티 컨테이너 관리
2. 쿠버네티스에 컨테이너 배포
실습환경 만들기 / kubectl 사용법 / pod, deployment, service 등 기본 리소스 학습
3. 외부 접속 설정
Cluster IP, NodePort, LoadBalancer, Ingress 서비스 타입 학습 / 서비스 디스커버리 학습
4. 스케일 아웃
부하에 따른 컨테이너 개수 조정 / 최소 리소스 요청 설정 / 오토스케일링
5. 그 외 고급기능
HELM 패키지 매니저 소개 등
용어 정리
| master | 마스터 |
| node | 노드 (구 minion 미니언) |
| k8s | 쿠버네티스 = 케이에잇츠 = 케이팔에스 |
| kubectl | 큐브컨트롤 = 큐브시티엘 = 큐브커들 |
| etcd | 엣지디 = 엣시디 = 이티시디 |
| pod | 팟 = 파드 = 포드 |
| istio | 이스티오 |
| helm | 헬름 = 핾 = 햄 |
| knative | 케이네이티브 |
공부 순서
1. 도커는 알아요 (컨테이너 오케스트레이션이 뭔지도 알아요) --> 도커 모르면 도커 공부부터 하고 오기
2. 쿠버네트스 배포 시연
3. 쿠버네티스 소개 및 아키텍쳐
4. Object 실습
5. 통합 배포 실습
6. 일반적인 쿠버네티스 사용 (입문자 졸업!)
Cloud Native
클라우드 환경에서 어떻게 애플리케이션을 배포하는게 좋은걸까?
컨테이너 / 서비스메시 / 마이크로 서비스 / API / 인프라 사용하고 삭제 / DevOps 등등의 방법들을 Cloudnative 라고 한다.
구성 / 설계 Architecture
쿠버네티스 - 원하는 상태 (Desired State)
상태 체크 Observe 를 통해 현재 상태 == 원하는 상태 가 되도록 계속해서 모니터링
현재 상태가 원하는 상태가 아니라면 조치를 취하는데 이 흐름을 무한반복한다.
상태 체크 --> 차이점 발견 --> 조치 이러한 상황을 관리하는 것을 controller라고 한다.
이러한 상황을 관리하는 controller는 서버, 모델, 데이터 등등에 따라 여러 controller를 둘 수 있다.
마스터 상세 - etcd
모든 상태와 데이터를 저장, 요청상태를 저장하는 곳
분산 시스템으로 구성하여 안전성을 높임(고가용성)
가볍고 빠르면서 정확하게 설계 (일고나성)
key-value 형태로 데이터 저장
TTL, watch 같은 부가 기능 제공
백업 필수!
마스터 상세 - API server
상태를 바꾸거나 조회
etcd와 유일하게 통신하는 모듈
REST API 형태로 제공
권한을 체크하여 적절한 권한이 없을 경우 요청을 차단
관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
수평으로 확장되도록 디자인
마스터 상세 - Scheduler
새로 생성된 Pod을 감지하고 실행할 노드 선택
노드의 현재 상태와 Pod의 요구사항 체크 (노드에 라벨 부여)
마스터 상세 - Controller
논리적으로 다양한 컨트롤러 존재 (복제 컨트롤러, 노드 컨트롤러, 엔드포인트 컨트롤러 등등)
끊임없이 상태를 체크하고 원하는 상태 유지
복잡성을 낮추기 위해 하나의 프로세스로 실행
마스터 상세 - 조회 흐름
1. 상태 조회 요청 (Controller --> API server)
2. 정보 조회 권한 체크 (API server)
3. 권한이 있는 경우 정보 조회 (API server --> etcd)
4. 원하는 상태 요청 (etcd --> API server)
5. 원하는 상태와 현재 상태가 맞지 않는 경우 원하는 상태로 변경 요청 (API server --> Controller)
6. 원하는 상태로 리소스 변경 (Controller)
7. 변경사항 전달 (Controller --> API server)
8. 정보 변경 권한 체크 (API server)
9. 정보 갱신 (API server --> etcd)
노드 상세 - kubelet
컨테이너 관리를 확실하게
각 노드에서 실행
Pod을 실행/중지하고 상태 체크
CRI (Container Runtime Interface) - docker, Containerd, CRI-O...
노드 상세 - proxy
네트워크 프록시와 부하 분산 역할
성능상의 이유로 별도의 프록시 프로그램 대신 iptables Ehsms IPVS를 사용 (설정만 관리)
쿠버네티스 흐름
오브젝트 Object
Pod
가장 작은 배포 단위
전체 클러스터에서 고유한 IP 할당
여러개의 컨테이너가 하나의 Pod에 존재할 수 있음
Replica Set
여러개의 Pod을 관리할 수 있음
새로운 Pod은 Template을 참고하여 생성
신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 Pod 개수 유지
Deployment
배포 버전 관리
기존 version = 1 을 version = 2 로 변경하면 Deployment 내부에 있는 replica set을 두개로 나눠서 version1 과 version2를 모두 가지게 된다. Pod은 기존 version1 replicaset에 있다가 순차적으로 version2 replicaset으로 이동한다.
다양한 Work Load
| DAEMON SET | 모든 노드에 pod이 하나씩만 떠있기 원할 때 (ex. 로그수집, 모니터링) |
| REPLICA SET | 일반적인 상황에서 사용 |
| STATEFUL SETS | 순서대로 pod을 실행하고 싶을 때 |
| JOB | 한 번 실행하고 죽는 pod을 만들 때 |
Service - Cluster IP
클러스터 내부에서 사용하는 프록시
Pod은 동적이지만 서비스는 고유 ip를 가지기 때문에 외부에서 어떤 요청을 할 때 서비스의 고유 ip를 통해서 원하는 pod에 요청을 보낼 수 있다.
Cluster IP로는 외부 웹브라우저에서 pod으로 전달할 수 없기 때문에 Node를 이용한다.
Service - Node Port
노드(host)에 노출되어 외부에서 접근 가능한 서비스
웹브라우저는 노드포트를 통해 클러스터 IP에게 요청사항을 전달, pod에 그 요청사항이 도달한다.
Service - Load Balancer
내가 1번 노드와 웹 브라우저를 연결해뒀는데 1번 노드가 삭제되는 경우, 순간적으로 접속이 안되고 수동적으로 2번 노드로 재연결을 시켜야한다. 이럴 때 자동으로 노드를 연결시켜줄 수 있도록 로드 밸런서를 이용한다.
Ingress
위와 같은 설명은 ip port로 접속을 하는 방법이라면, 도메인 또는 경로 별 라우팅을 통해 접속을 하고자 하면 ingress를 통하면 된다.
모든 도메인에 대해 전부 노드 포트를 만들거나 로드 밸런서를 만들면 자원이 낭비가 되기 때문에 ingress 내부적으로 service를 만들어 접근한다. 이 과정에서 ingress는 자동으로 Service (load balacer)를 생성한다.
API 호출
원하는 상태 (desired state)를 다양한 오브젝트로 정의(spec)하고 API 서버에 yaml 형식으로 전달
Object Spec - YAML
key-value 형식으로 표현
# object pod 띄우기
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: busybox
image: busybox:1.25위와 같이 코드를 작성하면 version1인 pod을 컨테이너 busybox1.25 이미지를 통해 만들겠다라고 하는 명세서라고 할 수 있다.
이 명세서를 작성하면 위에서 설명한 API Server가 확인해서 etcd에 명세서를 저장하고, 각 컨트롤러들이 저장된 정보를 보고 동작을 한다.
# replicas set 띄우기
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
app: frontend
template:
metadata:
labels:
app: frontend
spec:
containers:
- name: web
image: image:v1pod하고 비슷하게 사용하면 되는데 각종 설정에 따라 spec에 작성하는 내용이 달라진다.
'MLOps' 카테고리의 다른 글
| 6. 쿠버네티스 실습 환경 구축 (minikube, MacOS) (0) | 2022.01.12 |
|---|---|
| 5. 맥북에서 MLOps 환경 구축; 맥북에 도커 설치, 도커 실행 (0) | 2022.01.11 |
| 3. MLOps와 쿠버네티스(Kubernetes) (0) | 2022.01.05 |
| 2. MLOps 핵심 기능들 (0) | 2022.01.05 |
| 1. MLOps란? (0) | 2022.01.05 |
