큰 기업들은 대규모의 서비스를 운영하고 있기 때문에 최대한 자원을 효율적으로 써야 비용적으로 유리해짐
서버 자원을 효율적으로 쓰기 위해 가상화 기술에 대해 관심이 필요
1.
가상화의 발전
a.
Linux 의 자원 격리 기술 : 1991년
i.
Chroot
ii.
namespace
iii.
cgroup
b.
VM 가상화 기술 : 자동화
i.
VMware, KVM, Xen..
ii.
OpenStack : rackspace + NASA, 2010년 7월
iii.
자동화는 되는거 같은데, 생각보다 시스템 효율이 부족
iv.
VM 가상화를 위해 무거운 OS를 띄어야 한다
1.
가벼운 서비스를 띄우기 위해 더 큰 OS를 띄어야 하는 경우도 있다.
c.
Container 가상화 기술 : 2014년 6월
i.
dotcloud라는 회사가 내장 Linux의 자원격리 기술을 컨테이너라는 이름으로 누구나 쉽게 쓸수 있게 만듬
ii.
도커라는 회사로 사명 변경 → 기술을 오픈소스로 공개
iii.
서비스간 자원 격리를 하는데 OS를 안 띄어도 됨 → OS 기동시간이 없기 때문에 자동화시 엄청 빠르고, 자원 효율도 매우 높음
iv.
단 도커는 하나의 서비스를 컨테이너로 가상화시켜 배포하는 거지, 엄청 많은 서비스를 운영할 때 일일이 배포하고 운영하는 역할을 해주진 않음
v.
컨테이너 오케스트레이터라는 개념이 필요 → 여러 컨테이너들을 관리해주는 솔루션
d.
오케스트레이터
i.
많은 회사에서 저마다의 오케스트레이터 개발
ii.
docker swarm, suse rancher, amazon ecs, hashicorp,
iii.
kubernetes 2015년 7월 발표 → 많은 생태예 참여로 타오케스트레이터에 비해 많은 인기
1.
Google이 주도
2.
red hat, ms, ibm, docker, coreOS 등 참여
iv.
IT에서는 누가 정한것보다 가장 많이 사용하는게 표준이 됨
e.
쿠버네티스
i.
많은 클라우드 기업에서 K8s 환경의 인프라를 서비스로 제공
ii.
직접 설치해서 자신의 운영 환경에서 사용 가능
2.
Kubernetes 코스
a.
운영자(user) : k8s 기능들을 활용해서 자신의 서비스를 배포
i.
처음부터 아키텍처나 모듈들이 어떻게 되어 있고, 내부 네트워크 부터 접근하면 k8s 왜이렇게 어려워할수 있어
b.
관리자(admin) : k8s 서비스 클러스터를 운영
i.
관리에 대한 부분은 향후 운영편에서 별로
3.
why k8s
a.
한시스템에 한서비스
i.
AS-IS : 다수의 서비스를 운영 → 시간대별로 접속 량이 다름 → 최대량 기준+예비서버으로 서버 준비→운영시 서버 중단 후 서비스 전환
ii.
To-Be : Auto-Scaling + Auto-healing + Deployment 통해 자동 업데이트 → 다양한 운영자동화 제공 → 서비스 효율 증가 → 적은 서버 → 유지보수 비용 절감
4.
VM과 컨테이너의 차이
a.
시스템 공통 구조 : 하나의 서버 위에 Host OS가 있음
b.
VM
i.
하나의 Host OS 위에 하이퍼바이저
ii.
하이퍼바이저 위에 게스트 OS : 하나의 OS 처럼 독립적 OS 사용하고 개별 APP 설치 가능
iii.
VM별로 각각의 OS를 보유
iv.
장점
1.
리눅스를 써도 다른 VM에는 윈도우즈 사용
2.
하나의 OS가 뚤려도 다른 OS에 영향이 없음
v.
서비스 개발 사상
1.
서비스를 만들때 하나의 언어로 여러 모듈들이 한 서비스로 동작
2.
여러 모듈 중 하나의 모듈에만 사용량이 많더라도 하나의 VM을 추가
3.
OS 및 자원 사용량이 두배로 필요
4.
안해도 되는 모듈도 확장
c.
컨테이너 가상화 해주는 도커가 있음
i.
OS 내 자원 격리 기술을 활용하여 컨테이너라는 단위로 서비스를 분리
ii.
하나의 Host OS 위에 컨테이너 가상화 솔루션 : docker, rkt, lxc등
iii.
도커가 컨테이너를 만들어줌
1.
리눅스 별로 라이브러리가 다르다 → OS가 다른 버전에 쓰러면 버전차이 발생
2.
도커로 컨테이너 이미지 생성시 : 서비스 + 라이브러리 존재
3.
자신의 이미지 내 라이브러리 사용으로 OS 달라도 버전 문제 미발생
iv.
컨테이너 간에 Host 자원 공유 : 컨테이너 단위로 서비스 관리
1.
리눅스 고유 기능(자원격리 기술) 활용
2.
namespace ; 커널 부분 격리
3.
cgroup : 자원에 대한 격리
v.
컨테이너 : 하나의 host OS를 공유 → 별도 OS가 없어 빠르다
vi.
단점
1.
리눅스 컨테이너 시스템 위에 윈도우즈 컨테이너 구동 못한다
2.
한 컨테이너가 뚤려서 Host OS에 접근하면 다른 컨테이너도 접근 가능
vii.
시스템 개발 사상 : 마이크로서비스
1.
한 서비스를 만들때 모듈별로 쪼개서 개발 → 모듈별 최적화 언어 사용 권장
2.
K8s는 pod가 배포단위 : 필요한 pod만 확장
3.
시스템을 모듈별로 쪼개 개발해야 효율적
3.
K8s 실습
a.
다수의 YAML 파일로
i.
pod : deployment, por가 배포되도록
ii.
Service : 외부에서 접근하도록
4.
k8s overview
a.
클러스터
i.
Master : K8s의 전반적 기능 컨트롤
ii.
Node : 여러 노드를 통해 자원 제공
b.
오브젝트
i.
namespace : k8s 내 프로젝트를 독립된 공간으로 제공
1.
pod : k8s 최소 배포단위
a.
pod 안에는 여러 container 존재
b.
container별로 하나의 app이 동작 → pod에는 여러 app이 동시 제공
c.
pod 에 문제가 생겨 재생성이 되면, 데이터가 날라감
i.
외부 볼륨을 만들어서 pod의 데이터를 저장
2.
service : pod가 외부로부터 연결이 가능하도록 IP를 할당
a.
서로 다른 pod에는 연결 불가
ii.
Resource Quota, LimitRange
1.
한 namespace에서 사용할 수 있는 자원의 양을 한정
a.
pod의 갯수 제한, CPU/MEM 등
iii.
Configmap/secret
1.
pod 생성시 환경 변수 추가하거나, 파일 마운트 등 제공
c.
컨트롤러 : 서비스들을 관리
i.
Replication Controller, ReplicaSet
1.
pod 가 죽으면 방지해서 다시 살려줌
2.
pod의 갯수를 늘렸다가 줄였다가 scale-in/out
ii.
Deployment
1.
배포 후 pod를 업그레이드, 롤백
iii.
DaemonSet
1.
한 노드에 pod가 하나씩만 유지
iv.
CronJob : Job을 주기적으로 동작
1.
Job : 특정 작업만 하고 종료