44BITS (1)컨테이너 오케스트레이션이란?
옮
===
요약
서버관리 : 문서 -> 설정관리도구 -> 가상화 -> 도커(컨테이너) -> 쿠버네티스(컨테이너관리기술)
CLUSTER, STATE, SCHEDULING, ROLLOUT&ROLLBACK, SERVICE DISCOVERY, VOLUME
===
https://youtube.com/playlist?list=PLIUCBpK1dpsNf1m-2kiosmfn2nXfljQgb
초보를 위한 쿠버네티스 안내서
쿠버네티스가 뭔지 하나하나 알아봅시다~ #쿠버네티스 #kubernetes
www.youtube.com
===
: 시작하기와 알아보기만 있음, 충분
쿠버네티스는
컨테이너, 오케스트레이션 이 두개에 대한 설명이 필요
===
컨테이너 오케스트레이션이 등장한 배경
서버관리 = 서버상태를 관리 = 서버관리자가 서버가 문제없도록, 죽지 않도록 관리하는 것
이때의 고민은 갑자기 알수 없는 이유로 서버가 죽고, 밤에 연락이 오고, 인수인계 등이 어려운 점
어떻게 하면 쉽게 할 수 있을까?
첫번째 아이디어는 문서화를 잘해보자였겠지
프로그램 설치하는법을 캡쳐를 떠서 문서로 잘 만드는 것
문제가 있어, 문서를 아무리 잘 만들어도 업데이트가 안될수도, 환경이 좀 바뀌면(OS가 바뀌거나, 버전이 바뀌면) 따라해도 잘 안되는 케이스들이 생김
->문서화가 좋긴 하지만 여전히 관리가 어렵다
===
그래서 등장한게 서버를 관리하는 도구
CHEF, ANSIBLE, PUPPET : 사용자가 직접 서버에 접속해서 명령어를 날리는게 아니라 도구가 대신해서 명령어를 날려주고, 그럼 서버 관리자는 이 도구의 설정에 맞게끔 어떤 프로그램을 설치하고, 어떤게 없으면 어떤 설정으로 바꿔라 이런것들을 설정하는 것
설정관리도구가 좋긴한데, 설정관리 도구 자체를 배워야하고, 서버를 복잡하게 관리하다보면, 도구 자체의 사용법도 난이도가 높아짐 ex.자바 1.6과 1.8을 같이 써야하거나.. node버전 다른걸 한 서버에서 써야하면 프로그램 자체를 디렉토리를 다르게 설정해야.. 어떻게 하면 한 서버에서 여러개의 버전을 잘 돌릴 수 있을까 고민이 됨
===
그래서 나타난게 가상머신
가상머신 하나 띄우고, 거기다 프로그램 설치해놓으면, 문제가 생길 가능성이 적다. 그 가상머신엔 하나의 프로그램만 떠있기 때문에 충돌날 일도 없고, 필요하면 가상머신 자체를 묶어서 파일 하나로 저장해서 불러다 쓸 수도 있다
뭔가 좀 느리지만 관리도 완전 직관적이진 않지만 좋긴 좋다
근데 클라우드가 대세인데 클라우드 환경에 안맞는 부분이 있고, 특정 밴더에 속하게 된다. 디펜던시가 생겨
요즘 멀티클라우드 이런 얘기도 나오는데 그런데서 사용하긴 어렵다.
느린걸 감수하고 사용한다
===
이때 도커가 등장
모든 실행환경을 컨테이너로 바꾸게 됨
도커만 설치돼 있으면 어디서든 동작, 사용법도 쉽고, vmware, vitual machine처럼 느린것도 없고 굉장히 효율적으로 동작
기능이 하나 좋으면 단점이 있기 마련인데 컨테이너는 서버관리자들의 대부분의 복잡함을 해결해주는 좋은 기술
->CPU나 메모리 사용이 효율적
->동일방식관리 : 컨테이너를 실행하면 내부적으로 그 안의 내용이 자바든 노드든 상관없이 뜬다
->보통 배포가 어려운게, 로컬PC나 staging에선 잘 도는데, 운영에선 뭔가 잘 안될때가 있다
그런 부분이 서버 환경이나 설치에 따라 다를 수 있는데, 컨테이너로 하면 전체 서버 환경을 다 갖고 오기 때문에 문제가 생길 확률이 적다. 모두 거의 동일한 환경으로 돌아감
->컨테이너는 오픈소스이고, 특정 클라우드 밴더에 종속적이지 않다 = aws에서 쓰던걸 애저나 gcp로 옮기기도 간편
===
그래서 하다보면 모든걸 컨테이너를 사용하게됨
기존에 설치해서 쓰던걸 전부 컨테이너를 사용하게됨
한번 도커에 맛을 보면 모든걸 컨테이너로 관리하고 싶은 욕구가 생김
===
모든 프로그램의 개발의 과정이 이렇게 정형화가 됨
개발자가 코드 작성하면
->Build(도커 이미지를 만듦)
->Ship(만든 이미지를 도커허브나, 저장소에 저장)
->Run(도커 이미지를 컨테이너로 실행
그 전엔 어떤 언어를 쓰는지, 어떤 프레임워크를 쓰는지에 따라 방법이 달랐었다
근데 이제 도커를 도입하고 나서는, 일단 도커 이미지로 만들기만하면 그걸 저장하고 사용하는 방식자체가 표준화
=>서버 관리자 입장에서는 굉장히 편함, 도커이미지만 잘 만들어주시면 띄우는게 너무 쉽다, 관리하기도 쉽다
===
관리자가 편해졌나? 하는 생각이 들때쯤에
모든걸 다 컨테이너로 만들기 시작했는데
4개
부하가 늘어서 12개
사용량이 더 늘어서 몇천개가 될 수도
=>도커가 좋긴한데 많은걸 관리하려면 여전히 손은 간다
===
지금까지의 개발하고, 빌드하고, 복사하고, 실행하고 나서 다음 단계가 필요하다고 생각이 듦
===
1.(도커이후에)배포는 어떻게 할까?
컨테이너 기술이 좋은데, 컨테이너를 어떻게 배포하는게 좋을까? 생각을 해봤을 때
총 서버가 3대, 컨테이너 실행을 하려면,
1번 서버에 ssh접속, docker stop 하고 docker run 하면 새로운 앱이 뜸
2번 ...
3번 ...
하나하나를 일일이 IP로 관리해야되고, 실행할때도 하나하나 접속해서 실행해야
===
또
도커 많이 쓰다보면 빈공간이 생김
빈공간 : 서버가 여러개가 있는데, 컨테이너가 실행이 안돼있는 서버
새로운 컨테이너를 실행할때, 저 빈서버에 실행하는게 좋을 것
어떤 서버가 여유있는지 보려면, 하나하나 접속하면서 관리하거나 모니터링하는 도구를 따로 만들어야
===
또 컨테이너를 v1으로 많이 사용, 배포
일부를 v2로
이때도 하나하나 접속해서 업데이트...
전체를 v2로 했는데 문제가 생기면 v1로 롤백해야해
롤아웃/롤백 손이너무 많이 간다
중앙에서 모든 컨테이너를 버전업하고 싶다 하는 욕구가 생김
===
2.(도커이후에)서비스 검색은 어떻게 할까?
서비스 검색 : 프로그램이 프로그램을 바라볼 때, 192.168.0.100을 설정하는데, 부하가 많아져서 191.168.0.101 까지 두개가 되면?
단순하게는 중간에 로드 밸런서를 설치할 수 있다
로드밸런서로 요청이 들어온 애는 100번이나 101번으로 부하를 분산할 수 있어
기존의 PROXY는 100번을 바라봤던걸 로드밸런서를 바라보게 하면 돼
근데 이게 하다보면 굉장히 많아지고, 마이크로 서비스가 유행하면서 내부 서비스간 통신이 많아짐
그럴때마다 앞에 로드밸런서를 설치하고..IP가 바뀌면 바뀔때마다 업데이트하고.. 이게 서비스 검색
===
3.(도커이후에)내부에 있는 서비스를 외부로 노출은 어떻게 할까?
제일 쉬운 방법은 Public영역에 nginx같은 PROXY서버를 하나 두고 거기에 들어오는 호스트가 뭐냐에 따라 내부의 Private에 있는 컨테이너로 연결해줄 수가 있다
test.com이라는 호스트가 있으면 App1로 연결하고..
근데 하다보면 귀찮다
내부적으로 서버를 하나 띄우면 요청이 옴. 도메인하나 새로 등록했으니까, 저 컨테이너로 연결해주세요 라고 하면 nginx설정 바꾸면 되긴 하는데
서버관리자는 좀 편하게 일하고싶어 자동으로 할 수 있지 않을까? 생각을 함
===
4.(도커이후에)서비스에 이상이 생기거나, 부하 모니터링은 어떻게 해?
12개의 컨테이너를 관리하고 있는데 저렇게 저 5개의 컨테이너가 죽으면?
부랴부랴 접속을 해서 컨테이너 로그보고, 새로 띄우는 그런 방법으로 함
어쨌든 자동화되거나, 좀더 쉬운 방법이 필요
또 이렇게 서버가 죽은건 아닌데 부하를 많이 받기 시작해. 응답속도가 느려져서 개수를 늘려야 하는데
그것도 뭔가 자동화하는 방법이 필요해, 문제 생기면 새벽에 일어나서 조치를 해야해
===
컨테이너라는 기술 자체는 좋은데, 저 많은 컨테이너를 관리하기위한 기술이 필요하게되고, 그게 바로 컨테이너 오케스트레이션이라는 기술
결국 서버 관리자가 하는 일들을 대신해주는 프로그램을 만드는 것
===
컨테이너 오케스트레이션의 특징
(1)CLUSTER
(1)CLUSTER
NODE를 하나하나 관리하는게 아니라(1번 서버는 8기가.. 2번 서버는... 3번 서버엔 어떤 프로그램이 깔려있고...) 근데 이게 많아지게되면 하나로 합치고, cluster단위로 추상화해서 관리를 함
cluster 하나하나의 노드에 ssh로 다 접속해서 하기가 어렵기 때문에 master서버를 하나 두고, 관리자는 master서버에 명령어를 던지면, master서버가 알아서 노드에 명령어를 보내게 됨
또 클러스터 내의 node들 끼리는 네트워크 통신이 잘 돼야, 가상네트워크라든가 설정을 잘 연결해서 서버들끼리 통신을 하는데 문제가 없도록
또 중요한건 node의 개수가 수천개 수만개가 되더라도 잘 돌아야 한다, 처음 설계할 때 잘 설계하지 않으면 부하를 감당하지 못해, 컨테이너 오케스트레이션에선 그걸 고려해야함
===
(2)상태 관리
*replicas : 복제
2개로 설정한 replicas를 3로 바꾸면 자동으로 3개를 띄워줘 => 이게 상태, 3개를 띄우길 원하는 상태. 내가 직접 조치를 안하더라도 컨테이너 오케스트레이션이 자동으로 상태를 맞춰주길 원하는 것
컨테이너 하나 문제가 생기면 그걸 죽이고 또 하나를 띄움
===
(3)배포 관리
APP1은 좀 무거운, CPU와 메모리를 많이 사용하는
APP2는 좀 가벼운
이때 APP1을 하나 더 띄우려면, 서버 관리자 입장에서는 매번 관리를 해줘야해, 어떤 서버에 뭐가 떠 있는지 알아야하고, 어떤 서버가 여유있는지 봐야, 그걸 자동으로 체크해서 쏙 넣어줌 = 스케줄링
여기서 또 하나 더 띄우고싶으면 서버를 하나 더 띄우고 거기에 컨테이너를 띄우는것도 스케줄링 해줄 수 있다
===
(4)버전 관리
배포 버전을 관리하는게 필요한데,
v1 3개
v2로 올라갔다가 문제생기면
Rollback, 이걸 하나하나 관리하는게 아니라 중앙해서 관리하고 싶은 것
===
(5)서비스 등록 및 조회
WEB이 100번으로 뜨면, 저장소에 등록을 함
101번이 또 뜨면 또 등록을 함
이걸 사용하는 PROXY서버가 있을텐데, 얘는 저장소를 계속 관찰을 한다. 바뀌게될때마다 설정을 내부적으로 변경하고, 프로세스를 재시작한다
관리자가 하나하나 IP를 바꿀필요 없이 프로그램이 자동으로 재설정
===
(6)볼륨 스토리지
NODE 3개에 각각 필요한 볼륨을 MOUNT(*시작하다)해야될 수 있다
이런 스토리지를 연결해야될 수 있는데
당연히 손으로 일일이 할 수 있지만, 좀 더 추상적으로 설정으로 관리할 수 있으면 좋은 것. 그게 컨테이너 오케스트레이션의 역할
===
컨테이너 오케스트레이션은 개념, 개념을 어떻게 구현할지는 자유, 초반에 굉장히 많은 오케스트레이션 도구들이 생겨났었다.
도커 자체에서도 이런 기능이 안되니까 dock SWARM이라고 별도로 만들었음
별도로 만들었다가 도커로 합쳐지기도 함
잘 만들었지만
쿠버네티스가 인기가 더 많아짐
'컨테이너 관리도구'의 춘추전국시대가 열릴뻔하다가 학습자 입장에선 다행스럽게 쿠버네티스가 등장