AWS를 통해 컨테이너를 배포하기 위해 ECS를 사용했었는데, 이러한 방식은 좋기는 하지만 다른 벤더(ex Azure, GCP)에서는 동일한 방식으로 사용할 수가 없습니다. 이는 특정 벤더에 종속되는 방식으로 사용해야 하기 때문입니다~!
물론 계속 AWS만 사용하면서 ECS에 적응한다면, 그것만으로도 좋은 방식이기는 합니다.
다만, Kubernetes를 사용하게 된다면 이러한 문제를 해결할 수 있게 됩니다.
1. Kubernetes 란?
우선 공식 홈페이지에는 다음과 같이 설명되어 있습니다.
open-source system for automating deployment, scaling, and management of containerized applications.
Kubernetes로 배포하는 방식, 컨테이너를 scale up, down 하는 방법, 컨테이너가 실패할 경우 모니터링하는 방법과 교체하는 방법을 정의할 수 있기 때문입니다.
즉, Kubernetes는 컨테이너를 오케스트레이션 하기 위한 사실상 표준의 방식입니다.
자동 배포, 스케일링, 로드 밸런싱, 관리와 같은 태스크를 수행하는데 도움이 됩니다.
Kubernetes config 파일을 통해서 배포할 컨테이너, 인스턴스의 수, 스케일을 확장해야 하는지, 교체해야 하는지 등 목표로 하는 상태를 설정하게 됩니다. 예를 들면 다음과 같이 말이죠!
apiVersion: apps/v1
kind: Deployment
metadata:
name: users-deployment
spec:
replicas: 2
selector:
matchLabels:
app: users
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: users
image: my-repo/users-application
그다음으로 어떤 클라우드 벤더를 선택해도, 동일하게 우리의 Remote에 전달할 수가 있습니다.
Kubernetes 방식에 맞게 작성한 설정 파일을 해석하고 이해할 수만 있다면, 어떤 Cloud Provider를 사용해도 상관이 없습니다.
또한 특정 Cloud Provider에 특화된 옵션도 구성 파일에 추가할 수가 있습니다.
즉, 특정 Cloud Provider에 추가 구성이 필요한 경우에는 해당 구성 파일을 만들어 메인 파일에 추가하기만 하면 됩니다.
Kubernetes는 마치 여러 머신들을 위한 Docker-compose라고 생각할 수도 있습니다.
2. Kubernetes 개념
Kubernetes 세계에서 컨테이너는 이름바 Pod이라는 것에 의해서 관리됩니다.
Kubernetes 세게의 가장 작은 단위라고 할 수 있습니다.
내부에 컨테이너가 있는 Pod는 worker 노드에서 자신을 실행합니다.
worker노드는 일종의 가상 머신이라 생각할 수 있습니다. AWS에서 우리가 관리하는 리모트 머신인 EC2 인스턴스는 워커 노드가 됩니다.
worker노드는 특정 양의 CPU와 메모리가 있는 머신입니다.
따라서 해당 worker노드에서 하나 이상의 Pod를 실행할 수 있습니다.
Proxy는 Kubernetes가 워커 노드에서 포드의 네트워크 트래픽을 관리하는 도구입니다.
즉, Proxy는 기본적으로 Pod가 인터넷에 연결될 수 있는지의 여부와, 포드 및 그 내부에서 실행되는 컨테이너를 외부에서 어떻게 접근할 수 있는지를 제어합니다.
Pod에서 웹 애플리케이션이 실행 중일 경우, Proxy를 통해 외부 트래픽이 해당 컨테이너에 전달될 수 있도록 구성해야 합니다.
또한 서버를 scale up 할 때는 여러 worker노드를 만들어 서로 다르면서 동일한 컨테이너를 실행하여 트래픽을 고르게 분배할 수 있습니다.
그럼 누가 이러한 컨테이너와 Pod를 만들고 시작할까요?
누가 더 이상 필요하지 않은 경우 종료하거나, 교체할까요?
바로 Master Node입니다!
기본적으로 Master Node는 Worker노드와 상호작용하여 제어하는 컨트롤센터입니다.
단순히 다른 리모트 머신이라 할 수 있습니다.
일반적으로 Kubernetes를 통해 작업할 때는 Worker Node 또는 Pod와 직접 상호작용 하지는 않지만, Kubernetes와 해당 컨트롤 플레인이 처리하도록 합니다.
마스터 노드는 마스터 노드에서 실행 중인 컨트롤 플레인을 가지고 있으며, 워커노드와 워커노드 상에서 실행중인 포드와 상호작용하는 책임을 가집니다.
더 큰 배포의 경우에는 고가용성을 보장하기 위해, 자체적으로 여러 머신에 분할될 수 있는 마스터 노드가 있습니다.
이 모든 것들은 Cluster를 형성합니다.
마스터 및 worker 노드의 클러스터를 형성하고, 하나의 연결된 네트워크를 형성하게 됩니다.
Master Node가 Cloud Provider에게 API 요청을 보내서 특정 리소스를 생성하고, 최종 상태를 Provider에 생성하게 됩니다.
개발자로서 우리가 해야 할 일은
1) Cluster와 Worker Node, Master Node를 설정해야 한다는 점입니다.
2) 모든 Node에 Kubernetes에서 필요로 하는 소프트웨어, API server, kubelet 등을 설치해야 합니다
3) Cloud Provier에 따른 추가적인 리소스 설정. 예를 들면 로드밸런서나 파일 시스템과 같은.
Kubernetes는 클러스터를 생성하지 않습니다. 그저 사용할 뿐입니다.
2 - 1) Worker Node
Worker Node는 단순히 어딘가에서 실행 중인 하나의 EC2 인스턴스입니다. 마스터 노드에서 관리하죠!
이러한 Worker Node에는 하나 이상의 Pod가 있습니다.
Pod에는 하나 이상의 애플리케이션 컨테이너와 해당 컨테이너에 속한 모든 리소스를 호스팅 합니다.
Pod 자체도 Master Node에 의해서 관리됩니다.
Kubernetes에서는 Pod를 생성하거나 삭제할 수 있습니다.
일반적으로 하나의 Pod에 하나의 컨테이너가 있지만, 밀접하게 동작하는 여러 개의 컨테이너를 가질 수도 있습니다.
또한 Volume과 같은 추가적인 리소스가 필요할 수 있습니다.
추가적으로 당연히 Docker도 설치되어 있어야 하며, Woker와 Master의 통신 장치인 kubelet이 필요합니다.
Kube-proxy라는 들어오고 나가는 트래픽을 처리하는 소프트웨어 또한 필요합니다.
가장 좋은 점은 Kubernetes를 통해 원하는 최종 상태를 정의하기만 하면 됩니다.
2 - 2) Master Node
"Control Plane"의 주인입니다. 예를 들어 배포된 자원들을 관리하는 중앙 관제실 같은 것 이죠!
▶ API Server
Master Node에서 가장 중요한 것은 API 서버입니다. 이는 WorkerNode의 Kubelet과 소통하는 서비스입니다.
즉, Worker와 Master 노드 간의 통신을 위한 소프트웨어입니다.
▶ Kubelet
Master Node의 API 서버의 반대편에 해당됩니다. 즉 WorkerNode에 존재합니다.
▶ Scheduler
기본적으로 Pod를 관찰하고, 새 Pod가 생성되어야 하는 Worker Node를 선택하는 일을 담당합니다.
▶ Kube Controller Manager
워커 노드 전체를 감시하고 제어하며, 알맞은 수의 Pod를 가동하고 있는지 확인합니다.
따라서 Scheduler와 API 서버와 긴밀하게 소통합니다.
▶ Cloud Controller Manager
이는 AWS, Azure와 같은 Provider에게 무엇을 해야 하는지를 알려줍니다.
사용 중인 Cloud Provider가 무엇이든 명령들을 알맞게 전달합니다.
마지막으로 중요한점이 하나 있는데,
쿠버네티스는 어떠한 머신이나 가상 인스턴스를 생성하지 않으며, 소프트웨어를 설치하지도 않습니다.
단지 Pod와 컨테이너를 모니터링 하는데만 관심이 있으며, 스케일링, 접근에만 관심이 있습니다.
즉, 애플리케이션의 구동과 실행을 유지하는 도구 입니다.
애플리케이션에서 필요한 리소스를 생성하려면 우리가 직접 생성하거나, Kubermatic, AWS EKS 와 같은 관리형 서비스를 이용해야만 합니다.
사용자가 직접 사용하려면, 직접 Master, Worker Node를 만들고 Cluster를 설정해줘 하고, API 서버, 스케쥴러, kubelet, 도커, 마스터 노드와 통신하기 위한 소프트웨어 등 모두 설치해야만 합니다.
'DevOps > Kubernetes' 카테고리의 다른 글
| [Kubernetes] 쿠버네티스 핵심 개념 (1) | 2022.10.13 |
|---|
댓글