🛹 전통적 배포 vs 가상화된 배포 vs 컨테이너 배포
Traditional Deployment
전통적인 방법에 의해서 어플리케이션을 배포한다는 것은 물리적인 하드웨어 위에 운영체제를 설치하고, 필요로 하는 어플리케이션을 설치해서 사용하는 방식이다.
하나의 물리적인 서버가 가지고 있는 리소스를 여러 가지 어플리케이션이 공유해서 사용한다.
따라서 특정한 어플리케이션에서 리소스를 많이 점유하고 사용하게 되면 다른 어플리케이션은 상대적으로 성능이 떨어질 수밖에 없다.
전통적인 배포 방식은 간단하고 직관적이지만, 확장성이 낮고 유연성이 부족할 수 있다.
Virtualized Deployment
두 번째, 전통적인 배포 방식에 대한 문제점을 해결해 서버 가상화라는 기술이 나왔다.
서버 가상화는 물리적인 하드웨어 위에 운영체제가 있고, 하이퍼바이저라는 기술을 통해서 각각의 VM의 개별적인 운영체제를 운영할 수가 있다.
개별적인 운영체제를 운영한다는 이야기는 CPU, 메모리, 프로세서 등 VM 간의 독립적으로 운영할 수 있기 때문에 이 안에 설치되는 어플리케이션 간에 어느 정도의 보안도 유지할 수 있다.
어쨌든 물리적인 하드웨어가 가지고 있는 리소스를 쪼개 서버 가상화에 있는 VM들이 사용하는 것이기 때문에 VM들이 점점 늘어날수록 서버 자체의 부담이 될 수밖에 없다.
Container Deployment
세 번째로 컨테이너 가상화라는 것은 일단 VM과 유사하지만 격리하는 부분에 대해서 좀 더 완화해서 어플리케이션 간의 운영체제를 서로 공유할 수 있도록 해주는 가상화 기술이다.
이렇게 운영체제에 필요한 리소스를 서비스 간에 서로 공유함으로써 컨테이너 가상화 기술은 서버 가상화 기술에 비해서 훨씬 가볍게 어플리케이션을 운영할 수 있게 되었고, 서버 가상화 기술과 마찬가지로 자체적인 파일 시스템이라든가 CPU에 대한 점유율, 메모리, 프로세서들도 사용할 수 있게 되었다.
그리고 기본 인프라의 종속성을 분리할 수 있었기 때문에 다양한 클라우드에 이식하여 운영할 수가 있다.
🚲 Kubuernetes란
-
오픈소스 기반의 컨테이너화 된 애플리케이션(워크로드와 서비스)의 자동 배포, 스케일링 등을 제공하는 관리 플랫폼
-
즉, 컨테이너 가상화 기술을 사용함에 있어 각각의 컨테이너를 관리해주고, 스케줄링하기 위한 편리한 도구
-
Kubernetes를 Docker와 같은 컨테이너 엔진 자체를 대신할 수는 없다.
장점
-
컨테이너화 된 애플리케이션 구동
-
서비스 검색과 로드 밸런싱
-
스토리지 오케스트레이션 (데이터 저장과 관련된 작업을 자동화하고 최적화하는 프로세스)
-
자동화된 롤아웃과 롤백
-
자동화된 빈 패킹(bin packing)
-
자동화된 복구(self-healing)
-
시크릿과 구성 관리
단점
-
소스 코드 배포 X, 빌드 X
-
애플리케이션 레벨 서비스 X
-
로깅, 모니터링 솔루션 X
-
포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공 X
🛫 Kubernetes Cluster
Kubernetes는 클러스터 전체를 관리하는 마스터 노드와 실제 컨테이너를 실행하고 관리하는 워커 노드로 구성된다.
마스터 노드는 클러스터의 상태를 감시하고 관리하며, 각 노드에 할당된 컨테이너를 관리하고 스케줄링한다.
워커 노드는 컨테이너를 실행하고 관리하며, 마스터 노드의 명령에 따라 작업을 수행한다.
이렇게 마스터와 워커 노드가 함께 동작하여 구성된 전체 시스템을 Kubernetes 클러스터라고 한다.
마스터 노드 안에는 설정 정보, 사용자의 스케줄 관리, API등을 처리할 수 있도록 구성이 되어 있다.
각각의 노드들(워커 노드)은 실제로 운영하고자 하는 컨테이너를 관리하기 위한 Pod라는 개념, 그리고 이 Pod를 운영하기 위한 Kubelet이라는 개념들이 포함되어 있다.
개발자 or 운영자가 UI를 가지고 있는 웹서비스 툴 또는 CLI를 통해서 어떤 명령어를 마스터의 API 서버에 전달한다.
API 서버는 자기가 가용할 수 있는 노드들한테 해당하는 명령어를 전달한다.
각 노드 안에서는 큐브 프록시에게 전달한다.
큐브 프록시는 클러스터의 각 노드에서 실행되고 있는 네트워크 프록시이다. (=쿠버네티스에서 서비스 개념)
-> 개발자 or 운영자가 요청했던 정보가 마스터를 통해 각각의 Kubernetes 노드에 전달이 되면 사용자들은 각각의 노드에 붙어 원했던 서비스를 사용할 수 있게 된다.
🚀 Kubernetes의 작업
마스터에서 각각 가용할 수 있는 노드에다가 어떤 명령을 전달하면 사용할 수 있는 컨테이너를 pod 형태로 묶어서 사용하는 게 일반적인 형태이다.
docker의 여러가지 컨테이너들이 묶여서 하나의 Pod를 구성한다.
Kubernetes에서는 사용할 수 있는 최소한의 단위를 pod라는 형태로 묶어서 배포를 하게 된다.
또한 각각의 노드들은 컨테이너를 운영하기 위해 컨테이너 엔진을 가지고 있어야 한다.
노드를 단일 노드로 구성할 수도 있지만 안정적인 서비스 스케줄링을 위해서는 멀티노드를 가지고 Kubernetes 클러스터를 구성하는게 일반적이다.
그래서 Pod, Service, Deployment란?
위 그림에서 노드 안에 포함되어 있는 서비스를 좀 확대하여 보면 SVC, POD가 있다.
이들은 Kubernetes가 사용할 수 있는 오브젝트 또는 리소스라고 불리는 개념이다.
-
Pod
Pod는 쿠버네티스에서 실제로 컨테이너를 실행하는 가장 작은 단위이다.하나의 Pod 안에는 여러 개의 컨테이너가 존재할 수 있다.
+---------------+ | Pod | | | | +----------+ | | |Container1| | | +----------+ | | | | +----------+ | | |Container2| | | +----------+ | +---------------+ -
Deployment
Deployment는 Pod를 관리하고 원하는 상태를 유지하도록 해주는 역할을 한다.
예를 들어, Pod의 개수를 3개로 유지하고 싶다면 Deployment를 통해 Pod의 개수를 3개로 유지하도록 설정하여 만들 수 있다.
Pod가 삭제된다 하더라도 Deployment가 새로운 Pod를 자동으로 생성해준다.
+---------------+ | Deployment | | | +-------+-------+ | +-------V-------+ | | | +----------+ | | | Pod | | | +----------+ | | | | +----------+ | | | Pod | | | +----------+ | | | | +----------+ | | | Pod | | | +----------+ | | | +---------------+ -
Service
Service는 Pod들에 대한 단일 진입점(entry point)을 제공한다.
사용자는 Service를 통해 Pod에 접근할 수 있으며, Pod의 IP 주소가 변경되더라도 Service IP를 통해 계속 접근할 수 있다.
Service는 내부적으로 로드 밸런싱을 수행한다.
+---------------+ | Service | | | +-------+-------+ | +-------V-------+ | | | +----------+ | | | Pod | | | +----------+ | | | | +----------+ | | | Pod | | | +----------+ | | | | +----------+ | | | Pod | | | +----------+ | | | +---------------+
CI-CD 파이프라인을 통해서 Kubernetes에 만든 결과물을 배포한다는 것은 컨테이너 형태로 배포하되 컨테이너는 Pod 형태로 감싸서 배포가 되고, Pod 형태로 감싸져 있는 결과물을 외부에서 사용할 수 있도록 Service라는 오브젝트가 붙어 사용할 수 있는 상태로 만들어 준다.
🛴 Kubernetes 클러스터 구축
Kubernetes 클러스터 구축은 리눅스에 설치를 하는 게 일반적이다.
그래서 리눅스 시스템을 여러 대 설치해 놓고 하는 게 가장 좋겠지만 현실적으로는 그럴 수 없기 때문에 VM을 이용해서 리눅스를 설치하고 그 위에다가 Kubernetes를 구축할 수 있다.
호스트 PC에 VAGRANT 또는 VirtualBox 또는 VMware와 같은 가상화 도구를 이용한다.
Kubernetes의 클러스터를 구성할 때 마스터 노드와 워커 노드들을 구성한다.
마스터 노드하고 워커 노드는 분리를 시켜 놓은 상태에서 마스터노드는 사용자가 요청했던 명령을 처리, 워커 노드는 실제로 컨테이너 작업을 진행한다.
스케줄링 작업 도중 문제가 생겼을 때 해당하는 리소스를 재가용하는 노드도 하나 이상 설치하는 게 좋다.
Kubernetes 클러스터 설치
VirtualBox로 Kubernetes 클러스터 설치하기
위 링크를 타고 들어가면 VirtualBox로 Kubernetes 클러스터를 설치하는 가이드를 상세히 기술하고 있다.
순서대로 진행하여 위와 같은 그림으로 구축한다.
MiniKube
미니큐브는 테스트 용도로 또는 개발 용도로 간단하게 사용할 수 있는 Kubernetes 버전이다.
Kubernetes 클러스터를 복잡하게 구성하는 것이 아니라 미니큐브를 이용하여 Docker 데스크탑이 있는 상태에서 싱글 클러스터를 구축하고 있는 Kubernetes를 사용할 수 있는 상태이다.
도커 데스크탑이 설치되어 있는 상태에서 환경 설정에 들어가면 제일 마지막 항목에 Kubernetes라는 항목이 있다.
Kubernetes를 작동할 수 있도록 Enable Kubernetes라는 체크 박스가 비활성화 되어 있는데 이걸 체크해 주시게 되면 Kubernetes에 관련된 내용이 설치가 된다.
설치 후 테스트
미니큐브까지 Kubernetes가 설치가 다 되었다고 하면 몇 가지 테스트 코드를 실행해 봐야 한다.
첫 번째는 어떤 노드가 있는지 확인하는 명령어이다.
kubectl get nodes
미니큐브를 사용했을 경우에는 싱글 노드를 쓴다고 위에서 말했다. 그 싱글 노드는 마스터 역할도 함과 동시에 워커노드 역할도 한다.
두 번째, 현재 사용할 수 있는 현재 서비스가 가동 중인 Pod의 목록을 확인하는 명령어이다.
kubectl get pods
그 외에 Kubernetes 클러스터 내의 모든 디플로이먼트를 조회하는 명령어는 다음과 같다.
** 디플로이먼트 : Kubernetes에서 애플리케이션을 실행하는 방법 중 하나이며, 애플리케이션의 배포, 업데이트 및 롤백을 관리하는 데 사용
kubectl get deployments
Kubernetes 클러스터 내의 모든 서비스를 조회하는 명령어는 다음과 같다.
kubectl get services
출처
