대세는 쿠버네티스 섹션1

 

1. Why Kubernetes?

 

-쿠버네티스의 가상화 기술을 사용하지 않을 경우 총 9대의 서버가 필요하지만, 쿠버네트스 가상화 기술을 사용하면 오토 스케일링 기능에 따라 자동으로 트래픽양에 따라 서비스의 자원양을 조절해 줌 (총 4대의 서버로 운영 가능)

-또한 기존 시스템의 경우 서버 장애 상황에 대응하기 위해 각 서비스별로 백업 서버를 두어야 하므로 총 3대의 서버가 더 필요함 하지만 쿠버네티스가 적용된 시스템은 장애가 난 서버 위에 있는 시스템들이 다른 서버로 자동으로 옮겨주는 오토 힐링 서비스를 제공,  여분의 서버 한대만 있으면 알아서 서버 유지 가능 

-서비스의 버전 업데이트가 필요한 경우, 서비스 중단이 허용된다면 모든 서버를 내렸다가 업데이트 작업 후 다 올리고, 무중단 서비스의 경우 한 서비스씩 내렸다가 업데이트 작업 후에 서버를 올림

쿠버네티스의 경우 Deployment 기능을 통해 업데이트에 대해 자동적으로 처리하도록 지원 중 

 

-쿠버네티스는 여러 기능에 대해 고정 자동화를 지원 중 → 운영환경의 편리함과 서비스 효율 증가O

+) 서비스 효율 증가로 인한 서버 사용 개수 감소 → 유지보수 비용 ↓

 

2. VM vs Container

Virtual Machine

Container

-공통적으로 HOST OS를 가짐  -HOST OS위에 VM 가상화를 위한 여러 하이퍼 바이저들이 존재 -하이퍼 바이저를 이용해서 원하는 운영체제로 게스트 OS를 올려서 여러 VM 생성 가능 *게스트 OS 역시 호스트 OS와 마찬가지로 하나의 OS를 독립적으로 가지고 있는 것처럼 사용 가능  -여러 어플리케이션 설치 및 서비스를 만들 수 있음 - 각 OS를 만들어야 함  -새로운 게스트 OS를 설치하므로 다양한 OS 사용이 가능  -한 게스트 OS가 뚫리더라도 다른 OS와는 완벽하게 분리되므로 각각의 VM에게 피해가 없음 -같은 언어로 제작하므로 특정 모듈에 부하 가 많이 걸리게 될 경우 다른 VM을 생성하여 띄움

-공통적으로 HOST OS를 가짐  -OS위에 컨테이너 가상화를 위한 여러 소프트웨어(대표: 도커) -도커가 컨테이너를 생성  *컨테이너: 리눅스마다 버전이 존재, 버전에 따라 기본적으로 설치되는 라이브러리가 다름 따라서 환경이 다를 경우, 버전 차이에 따른 문제가 발생할 수 O → 도커를 통해 컨테이너 이미지를 생성, 해당 이미지에는 한 서비스와 서비스를 운영하기 위한 라이브러리들이 함께 존재 => 버전이 다르더라도, 도커만 설치되어 있으면 이미지를 가져와서 사용했을 때, 안정적으로 시스템 구동 가능  - 여러 컨테이너간 호스트 자원을 분리해서 사용할 수 있게 함  : namespace(커널 영역 분리(와 cgroups(자원 영역 분리)를 사용해서 구현 -한 OS를 공유 (VM보다 빠른 이유) -컨테이너는 윈도우 컨테이너/리눅스 컨테이너 만을 사용해야 함  - 한 컨테이너가 뚫려서 OS영역에 접근하게 될 경우, 다른 컨테이너도 위험해질 수 있음 -한 서비스를 만들 때 모듈별로 쪼개서 컨테이너에 담음, 모듈에 맞는 최적화된 언어를 사용할 수 O

 

-도커와 같은 컨테이너 가상화 솔루션은 OS에서 제공하는 자원 격리 기술을 이용해서 컨테이너라는 단위로 서비스를 분리할 수 있게 함 → 이걸 사용할 경우 컨테이너 가상화가 깔려있는 OS에서는 개발 환경에 대한 걱정 없이 배포가 가능해짐 

 

-쿠버네티스는 여러 컨테이너들을 한 파드라는 개념에 묶고, 한 컨테이너만 파드에 담을 수 있음 → 한 파드가 배포 단위, 내가 필요한 파드만 확장이 가능 

 

4. Kubernetes Overview

 

-Master: 쿠버네티스의 전반적인 기능들을 컨트롤하는 역할

-Node: 자원을 제공하는 역할, 클러스터 전체 자원을 늘리고 싶다면 노드들을 계속 추가하면 됨

-Namespace: 쿠버네티스 오브젝트를 독립된 공간으로 분리되게 만듬

-Pod: 쿠버네티스 최소 배포 단위

-service: 파드에게 외부로부터 연결이 가능하도록 IP를 할당해주는 역할

*단 서로 다른 namespace에 있는 pod들 과는 연결할 수 없음 

-container: 하나의 APP이 동작, 컨테이너는 파드 안에 있기 때문에 파드에는 여러 앱이 동작할 수 있음 

-Volume: 파드에 문제가 발생하여 재생성될 경우, 그 안에 있는 데이터들이 날라가게 되는 것을 막기 위해 pod에 연결, 데이터를 저장 

-ResourceQuota/LimitRange: 한 namespace에서 사용할 수 있는 자원의 양을 한정시키는 역할

ex) pod 개수 제한, CPU/메모리 제한 등 

-ConfigMap/Secret: 컨테이너 안에 환경변수 값을 넣거나 하드 마운팅을 할 수 있도록 도와줌

-Controller: 파드를 관리하는 역할, 각각 사용용도가 다름 

 

1) Replication Controller, ReplicaSet

-가장 기본적인 컨트롤러, 파드가 죽으면 감지하여 다시 살려주거나 파드의 개수를 늘렸다가 줄이는 등의 역할을 함

 

2) Deployment

-배포 후에 파드를 새 버전으로 업그레이드 해줌, 업그레이드 중에 문제가 발생하면 롤백을 쉽게할 수 있도록 도움 

 

3) DemonSet

-한 노드에 파드가 하나씩만 유지되도록 함

 

4) Job

-특정 작업만하고 종료시키는 일을 할 때, 파드가 그렇게 동작하도록 해줌 

-이런 job을 주기적으로 실행해야 할 경우, CronJob을 사용