"그게 뭔데..? 알려줘.."
"그.. 그런게 있어... 짜샤!! 난 뭔지 앎 암튼 넌 바보임.."
모르는 것 = 이해하지 못한 것
난 쿠버네티스를 모르는게 맞았다.
그리고 감히 말해보건대, 실제 MSA 기반의 어플리케이션을 개발하고 유지 보수한 경험이 없는자들 또한
쿠버네티스를 모르고 있는게 맞다. 나만 모르는게 괘씸하니 일단은 이렇게 생각하자
그래서 아는 척이라도 하기 위해 쿠버네티스에 관한 정보를 구글링했다.
스읍.. 공식 문서는 언제나 그렇듯 재미 없고 설명을 참 못한다.
피부에 와닿는. 그런 근본 강좌가 없을까 없을까 하며 계속해서 검색을 해나갔는데
"어라, 나 이해해버린걸지도?"
계속해서 찾아보다 보니, 다른 출처의 글의 내용이 예상이 가면서 이해 비스무리한 삘링이 왔다
역시 우리 한국인들에겐 아몰라 반복학습과 다짜고짜 암기해버리기st 공부법이 최고인 것이다
그럼 이제 설명을 함 해볼까?
Docker? Container
우리 집 컴퓨터는 똥컴이라 안깔리는 거 같아 ㅜ
하나의 어플리케이션이 완성 되어 서비스 오픈을 위해 이를 서버에 배포를 한다 했을 때,
기존의 가상머신(VM) 서버에 어플리케이션을 배포하는 방식은 이래저래 귀찮은게 많았다.
윈도우와 리눅스 서버의 deploy(배포) 방법이 달랐고, 각 운영체제도 버전에 따라 권장되는 배포 파이프라인이 달라 배워야할게 한두가지가 아니었다고 해야되나..
A 앱을 윈도우 서버에 올리고.. B 앱이 완성 되어 추가로 올릴라 하는데 이번엔 우분투 서버에? 대체 왜 그래야 하는데? 뭐 어쩔 수 없지. 요구사항이 그런데 ㅜ ㅎ 일단 함 해보겠음..
컨테이너를 이용해 배포하면 이러한 시행착오를 겪지 않아도 된다고!!?
- VM 서버에 앱을 배포하는 방식은 각 VM 마다 OS 를 띄우기 때문에, 무겁고 속도가 비교적 느린 반면에
- Container 서버에 앱을 배포하는 방식은, 앱마다 OS를 고를 필요 없이 편리하게 컨테이너에 담고, 이 컨테이너들은 모두 하나의 Host OS를 공유하기 때문에 구성이 가벼워 속도가 훨씬 빠르다(고한다).
Container 방식을 사용하면 새로운 서비스를 만들 때 신규 서버 구성과 번거로운 설정을 해줄 필요가 없다. 설정 미리 하면 됨
그럼 그걸 누가 하는데?
뿌우우우우우 도커가 해준다구!!
- 우리 도커가 컨테이너(Container) 에 숨결을 불어 넣어준다..
- 도커가 없는 컨테이너는 깡통 그 이상도 이하도 아니다..
- 도커는 엔진 그 자체다. (진짜로 Docker Engine 이라고 함 위에 올린 비교 사진 보셈)
- 도커가 있어야 컨테이너들이 작동한다 (VM처럼 ㅋ)
- 새로운 컨테이너 생성, 관리, 환경 설정도 도커를 통해 한다.
이 모든걸 어떻게 하는지는 나중에 도커 써볼 때나 경험할래....
도커 끝 ㅋ 쉽네
이제 쿠버네티스 함 뿌셔볼까 ㅋㅋㅋ
Kubernetes
- Container Orchestraition Tool.
컨테이너 오...오케스트라? 오케스트라는 그 그 지휘 그거 아닌가?
맞다. 저 지휘자가 쿠버네티스, 나머지 연주자들이 컨테이너라고 보면 된다.
우리 지휘자 쿠버네티스는 각 컨테이너들이 할 일을 잘 해낼 수 있게 도와준다.
이렇게 많은 수의 컨테이너 (세어 봤는데 27개임 ㅋㅋ)가 있을 땐 그만큼 관리와 운영에 있어 어려움이 따르겠지?
그냥 무작정 굴려대다가 컨테이너 하나 터지면 어떡함 ㅋㅋ 무작정 싣다가 배 가라앉으면 어떡함 ㅜ
이런 걱정들을 쿠버네티스가 덜어준다. 쿠버네티스가 그럼 정확히 뭘 해주는지는 내용을 복붙해서 보여주겠다.
(당연히 컨테이너들에 좋은 것들을 많이 많이 해주겠지..)
쿠버네티스 특징
- 자동화된 복구(self-healing)
컨테이너들을 모니터링하며, 컨테이너 중 하나라도 죽으면 쿠버네티스는 그것을 빠르게 재시작 시킵니다.
- 로드 밸런싱(Load balancing)
만약 1만명의 유저가 접속하지만, 당신의 웹/앱은 준비가 되지 않았을 경우
쿠버네티스는 해당 웹사이트의 니즈를 수용할 수 있도록
자동으로 새로운 컨테이너들을 만들 수 있습니다.
또한, 니즈가 줄어들면 컨테이너의 숫자를, 지정해둔 최소 숫자로 자동으로 조절합니다.
이전에는 수동으로 했던 작업들을 쿠버네티스가 자동으로 도와주는 것입니다.
- 무중단(Fault tolerance-FT) 서비스
기업에서는, 서버 업데이트를 위해서 사용자들이 잠든 새벽 시간을 활용하거나, 긴급 점검의 형태로 서비스를 일시 중단해왔습니다.
하지만, 쿠버네티스는 점진적 업데이트를 제공하기 때문에, 서비스를 중단하지 않고도 애플리케이션을 업데이트할 수 있습니다.
- 호환성(Vendor Lock In 해결)
고객이 A사의 클라우드를 사용하다가 I사의 클라우드로 환경을 이전하고 싶을 때,
서로 다른 업체(Vendor)의 클라우드 제품 간에 호환 문제가 발생하여 이전하기 어려운 상황을 Vendor Lock In 이라고 합니다.
쿠버네티스는 도커 컨테이너를 기반으로 하는 오픈소스이기 때문에, 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경들을 이전할 수 있습니다.
또한, 한 번 쿠버네티스를 익히면 provider 회사에 상관없이 공통된 마이크로서비스 아키텍쳐 개발이 가능합니다.
출처 : https://wooono.tistory.com/109
짜잔! 쿠버네티스는 컨테이너를 효율적으로 관리하기 위해 이러한 기능들을 제공한다고 한다.
쿠버네티스 비스무리한 Orchestraion Tool 들로는 (다른 지휘자들)
'도커 스웜', 'ECS', 'Nomad' 등이 있다고 한다.
.
.
.
.
.
.
ok
그럼.. 음.. 컨테이너 몇개부터 쿠버네티스 쓰면 될까?
나도 모르지 ㅋ
일단 확실한건 한 개의 컨테이너만 사용한다면 쿠버네티스는 필요 없다는 것이다. (돈 아깝자너)
그럼 컨테이너 3개는..?
쓸 수는 있겠지 근데 굳이? 트래픽이 좀 많은 편이라면 좋을 것 같기도 하다.
개발 / 서버 환경과 사용량, 확장 가능성 등 고려해볼게 많다.
여러 서비스 아키텍쳐들을 살펴보니까 컨테이너 두개 밖에 없는데 쓰는데도 있더라.
막 10개인데 안쓰는 곳도 있을거야 ㅋㅋ
우선 일단 안쓰고 컨테이너들 굴리다가 ㅋㅋ 문제 생기거나 터지면 그때가서 쓰면 된다 아님? ㅋㅋ
끝!
