Introduction to Kubernetes

아래 영상을 보고 정리하였다.

쿠버네티스는 컨테이너를 관리하기 위한 툴이다.

도커를 이용해 Node.js 혹은 장고 웹사이트를 배포하려고 한다면, 그리고 그걸 도커 컨테이너 안에 넣어서 AWS로 보내고 싶다면 이 프로세스에서는 쿠버네티스를 알아야할 이유가 없다. 도커를 업로드하고, 배포하는 것이 전부이기 때문이다.

Monitoring Containers

도커는 여러개의 컨테이너를 갖고 있을 때 쓰인다.

만약 micro-service archtechture를 갖고 있다면, 그래서 어떤 컨테이너는 유저 업로드만 다루고 어떤 컨테이너는 인증만 다루고 어떤 건 결제만 다루고 있다면 이 모든 컨테이너들은 동시에 업로드가 되어야 한다.

배포를 할 땐 그렇게 하면 되긴 하는데, 많은 컨테이너들을 갖고 있다면 문제가 생길 수 있다.

예시로, 컨테이너 하나가 죽으면 재빠르게 해당 컨테이너를 재시작해야한다. 서비스의 핵심 파트일 수 있으므로.

이때 쿠버네티스가 등장한다. 수동으로 컨테이너들을 바라보며 문제가 있는지 없는지 체크해 죽으면 재빠르게 재시작하고 이러는게 아니라, 쿠버네티스로 하여금 (예를 들어) 최소 n개의 컨테이너들이 작동하게끔 할 수 있다. 그리고 그 중 하나라도 죽으면 쿠버네티스가 바로 재시작할 것이다. 즉, 컨테이너들을 모니터링한다. 컨테이너가 많은 경우, 쿠버네티스는 매우 유용할 것이다.

Load Balancing

만약 1만 명의 유저가 접속하였지만 웹/앱은 준비가 되지 않았을 경우 쿠버네티스는 자동으로 새로운 컨테이너들을 만들 수 있다. 해당 웹사이트의 니즈를 수용할 수 있게 말이다.

쿠버네티스가 알아서 해당 웹 니즈에 맞춰서 컨테이너들을 준비하고 사람들이 떠나고 니즈가 줄어들면 컨테이너를 지정해둔 최소 숫자로 자동으로 조정한다. 이전에는 수동으로 해야하는 작업이었지만 쿠버네티스가 도와주는 것이다.

Rolling Update

클라우드에 5개의 컨테이너가 있다고 해보자. 코드의 버그를 고치고 싶거나, 버전을 업데이트 하고 싶은 경우 쿠버네티스 없이 수동으로 해야한다면 컨데이너들을 끄고 새로운 버전을 올린 후 다시 컨테이너들을 켜야할 것이다. 이는 웹사이트가 잠시 다운되어야 한다는 의미이다.

쿠버네티스를 이용하면 쿠버네티스가 컨테이너의 신규 버전을 차례로 업데이트 해줄 것이다. 웹사이트가 다운되는 경우 없이 말이다.

Conclusion

컨테이너로 작업 할 때 자동화해야할 것들이 많다. 새로운 버전을 배포하거나, 컨테이너 사이즈를 조정하거나, 혹은 컨테이너가 죽었을 때 빠르게 재시작한다거나 등.

많은 컨테이너가 필요한 웹/앱 서비스를 운영한다면 컨테이너를 업데이트하고, 재시작하고, 사이즈를 조정하는 등등의 경우 쿠버네티스가 필요할 것이다.