먼저 사용할 어플리케이션이 도커 이미지로 변환이 되었고 docker hub에 올라가 있어 k8s 가 pull 해 다운받을 수 있다고
가정해봅시다.
도커를 사용하는 이유는 편리성 때문이며 최종목표는 서버에서 컨테이너를 제대로 동작시키는것입니다.
k8s 는 노드에 직접 컨테이너를 배포하지 않습니다. k8s의 구성요소중 하나인 pod에 감싸서 배포합니다.
pod는 하나의 인스턴스이고 k8s에서 만들 수 있는 가장 작은 오브젝트입니다.
가장 간단한 예시를 한번 살펴보겠습니다.
cluster에 하나의 node, node 안에 하나의 pod, pod 안에 하나의 docker container 가 동작하고 있고 한명의 사용자가 이 시스템에 접근하고 있습니다. 지금 상태에선 문제되는게 없습니다. 하지만 만약 사용자가 늘어난다면 요청에 응대하기 위해 application이 추가적으로 실행되어야 할 것입니다. 어떻게 추가할까요?
k8s에서는 하나의 pod에 두개이상의 container를 잘 동작시키지 않습니다. 때문에 추가적으로 container를 실행하기 위해선 pod가 늘어나야 합니다. 그래서 전체적으로 볼때 아래와 같은 모습이 완성됩니다.
만약 유저기반이 더 증가해서 현재 노드가 충분한 용량을 갖추지 못한다면 어떻게 될까요? 노드를 증설하면 됩니다.
원래는 pod 하나에 하나의 container가 들어가는게 일반적이지만 예외의 경우도 있습니다. 동작하는 application을 보조하는 역할의 프로그램을 실행시키는 것과 같은 경우죠 메인 app에서 생성된 결과를 바탕으로 바로 분석하는 app등과 같은 것들이 있습니다. 이런 경우 하나의 pod에 2개이상의 container가 실행되기도 합니다.
이 두개의 컨테이너는 서로 직접적으로 통신할 수 있고 같은 스토리지 볼륨을 공유할 수도 있습니다.
그렇다면 왜 k8s를 사용하는 걸까요, container 그 자체로 서버에서 혼자 동작이 가능하지만 굳이 pod로 감싸서
배포하는 걸까요? 실제로 server에서
docker run python -app 명령어만 친다면 container를 실행 시킬 수 있습니다. 여러 번 명령어를 수행시킨다면
하나의 서버에서 여러개의 container가 실행되겠죠 아직까진 문제가 없습니다. 하지만 사용자가 늘어나고 트래픽이
증가하면서 실행해야 할 application이 늘어나고 이를 서포트 해야 할 container또한 배포해야 하는 상황이 온다면
문제가 생깁니다. 먼저 하나의 app container에 help container 를 각각 매칭시켜 주어야 하고 이들을 서로 통신 가능하도록 만들어야하며 도중에 중단된다면 재실행 또한 시켜주어야 합니다.
단순히 docker run python -app 명령어를 통해 container를 실행 시킨 경우 방금 말한 그 어떤 것도 보장되지 않습니다.
단순히 실행명령이 떨어졌을 뿐입니다. 이런 문제들을 해결하기 위해서 k8s와 같은 오케스트레이션 툴들이 등장했습니다. 이들은 자동으로 container를 모니터링하고, 재배포하고, 네트워크를 설정해 통신 가능하도록 만들며, 공유 스토리지 볼륨을 지정합니다. 또한 이런 작업들을 가능하도록 하기 위해 pod로 container를 감싸서 배포합니다. 즉 pod라는 것은 그냥 k8s의 운영정책이라고 이해하면 됩니다.
k8s에서 pod를 어떻게 배포하고 모니터링 할 수 있을까요?
배포 : docker hub or 개인 repository 에서 image를 다운받아 kubectl run nginx --image nginx 를 통해 pod 생성 가능 합니다.
모니터링 : kubectl get pods → NAME , READY , STATUS ,RESTART ,AGE 등의 정보를 얻을 수 있습니다.