서버 자원을 효율적으로 쓰기 위해서는 가상화기술에 대해 관심을 가질 수 밖에 없다.
고정적인 서버 -> VM -> 도커 -> 쿠버네티스 순서로 발전
컨테이너 가상화 기술은 서비스간에 자원 격리를 할 때 os를 별도로 띄울 필요가 없다.
그 중 도커를 많이 쓰지만 도커는 하나의 서비스를 컨테이너로 가상화시켜서 배포해주는 역할로, 엄청나게 많은 서비스를 운영할 때 일일이 배포하고 운영하는 역할은 아니다.
이런걸 해주는 것이 컨테이너 오케스트레이터(Container Orchestrator)이다. 그 중에서 가장 많이 쓰는 것이 쿠버네티스고, 그래서 쿠버네티스를 배워보려 한다.
쿠버네티스는 쿠버네티스 클러스터를 운영하는 운영자와, 자신의 서비스를 배포하는 사용자로 이루어져 있다.
Why Kubernetes?
기존 고정 서버와 비교
여러 가지 서비스를 운영한다고 가정했을 때
고정 서버는 시간대별로 트래픽의 차이가 있더라도 가장 트래픽이 많을 때를 고려하여 최대 서버를 계속 돌려야 한다.
그리고 서버에 장애가 발생했을 때를 대비해 각 서비스당 백업 서버까지 하나씩 더 두어야 안정적인 서비스를 운영할 수 있다.
서비스 업그레이드를 위해 배포할 때는 데이터를 백업하고 배포하기 위해서 여분의 서버가 더 필요하다.
반면 쿠버네티스 가상화 기술은 평균 트래픽을 계산해 컨테이너의 용량을 자동으로 조정해주는 Auto Scaling을 지원한다. 장애가 발생했을 때에도 자동으로 옮겨주는 Auto Healing을 지원해 효율적인 자원 배치가 가능하다.
업그레이드를 위해 배포할 때도
그만큼 유지보수 비용이 적어지며 운영의 규모가 커질 수록 효과가 커진다.
VM vs Container
VM은 Host OS를 설치하고, 그 위에 가상화를 위한 Hypervisor를 올리고, 그 위에 Guest OS를 올리는 방식이다.
Container는 Host OS 설치까지는 VM과 동일하지만, OS 위에 컨테이너를 가상화시켜주는 소프트웨어(ex.도커)를 올린다.
OS의 버전이 다르더라도 자원 격리 기술을 이용해서 컨테이너라는 단위로 자원을 분리하기 때문에 배포 및 실행이 가능하다. 즉, 개발환경에 대한 걱정 없이 배포가 가능하게 된다.
하지만 Container도 단점이 없는 것은 아니다. Container는 OS의 버전은 다를 수 있어도 OS가 아예 다르면 사용하지 못한다. 예를 들면 리눅스 os에서 윈도우용 컨테이너를 사용할 수 없다.
또한 vm은 모든 환경이 완전히 분리되어 있기 때문에 하나의 VM에 장애가 발생했다고 해도 다른 VM에 피해를 주지 않지만, 컨테이너는 한 컨테이너가 뚫릴 경우 모든 컨테이너가 피해를 입을 수 있다.
MSA와 Container
컨테이너는 한 서비스를 모듈별로 쪼개서 msa를 구현한다. 각 모듈마다 가장 효율적인 언어를 쓰는 것을 권장한다. 그래서 컨테이너를 사용하는 쿠버네티스에서는 파드로 쪼개서 모듈을 분리해 사용할 수 있기 때문에 효율적이라고 할 수 있다.
쿠버네티스 시작하기
.......
Kubernetes Overview
쿠버네티스의 전체적인 구조를 간략하게 살펴보려고 한다.
Kubernetes Cluster
쿠버네티스는 서버 한 대는 Master로 쓰고, 나머지 서버는 Node로 쓴다. 모든 서버들은 다 연결되어있고 이들을 합친 것을 쿠버네티스 클러스터라고 한다.
마스터는 쿠버네티스의 전반적인 기능을 컨트롤하는 역할이며 노드는 자원을 제공하는 역할이다. 쿠버네티스 클러스터의 자원을 늘리고 싶으면 노드를 추가하면 된다.
노드들을 독립된 공간으로 분리해주는 것이 바로 Namespace이다.
네임스페이스 안에는 Pod들이 있고, 파드들은 실제 서비스 환경을 설정해주는 Service와 연결되어있다.
이 때 서로 다른 네임스페이스에 있는 파드들은 연결할 수가 없다.
파드 안에는 Container들이 있고, 컨테이너 하나당 하나의 앱이 들어있다. 즉 파드 하나에 여러 앱이 돌아갈 수 있다.
만약 파드가 종료되거나 재생성되는 경우 안에 있는 데이터는 어떻게 될까?
이 때 사용할 수 있는 것이 바로 Volume으로, 볼륨을 만들어서 파드에 연결하면 데이터를 별도로 저장할 수 있으므로 파드가 재생성되더라도 데이터가 날아가지 않는다.
Pod Controller
파드들을 관리할 수 있는 컨트롤러가 존재한다. 컨트롤러는 종류가 많고 각각 사용 용도가 있다.
Relication Controller(RC), ReplicaSet
실행할 파드의 개수를 지정하고 지정한 개수만큼 파드가 유지되도록 관리한다. 개수를 늘리거나 줄일 수 있다.
Deployment
파드들을 새 버전으로 업그레이드하고, 롤백이 쉽게 해준다.
daemonSet
한 노드에 파드가 하나씩만 있도록 유지해준다. 전체 노드에 특정 파드를 실행할 때 사용한다.
CronJob, Job
job은 특정 작업만 하고 종료해야 할 때 파드가 그렇게 실행되도록 해준다. 이런 작업을 주기적으로 하고자 할 때 cronjob을 쓴다.
(참고: 나중에 수정)알아야 주의해야 할 점은 논리적으로는 구분되어 있지만 물리적으로는 구분되지 않는다는 점 입니다. ex) 다른 네임스페이스에서 생성된 두 포드가 같은 노드에 존재할 수 있습니다.
