기존의 웹 3계층 시스템에서 프론트 서버, 업무 서버, DB 서버 등 기능별로 다른 서버에서 처리를 하는 것이 일반적이었습니다. 때문에 애플리케이션을 어디에 배치할지를 미리 정해 두고 거기에 플로이하여 각 기능을 상호 호출하는 아키텍처로 되어있었습니다. 따라서 애플리케이션 개발자와 인프라 관리자는 둘 다 '어디에서 어떤 애플리케이션이 움직이는지'를 알고 있었습니다.
하지만 쿠버네티스에서는 애플리케이션이 디플로이되는 위치가 쿠버네티스에 의해 정해집니다. 한 애플리케이션이 디플로이되면 쿠버네티스가 클러스터 상태에서 비어 있는 위치를 찾아내서 자동으로 배치합니다. 즉 지금까지 사람이 해 왔떤 작업을 쿠버네티스가 해 준다는 것입니다. 그래서 '애플리케이션을 적절한 곳에 디플로이 하고', '디플로이된 애플리케이션이 어디에 있는지를 찾아내는' 장치가 있습니다.
스케줄링
애플리케이션을 적절한 곳에 디플로이하는 장치를 스케줄링(scheduling)이라고 합니다. 여러 대의 서버로 구성되는 클러스터에서는 가능한 한 컴퓨팅 리소스를 낭비하지 않고 효율적으로 사용할 수 있도록 만드는 편이 경제적입니다. 또 애플리케이션에 따라 '많은 CPU를 사용해야한다.', '우선 순위가 낮다' 등 개별적인 요건이 있는데, 쿠버네티스에서는 이러한 요구를 매니페스트 파일로 정의하여 이를 바탕으로 클러스터 안의 적절한 위치에 애플리케이션을 자동으로 배치해 갑니다.
서비스 디스커버리
일반적인 웹 애플리케이션의 경우 리퀘스트를 받은 프론트엔드 애플리케이션이 사용자의 트랜잭션을 처리하기 위해 백엔드 서비스를 호출합니다. 이 때 디플로이된 애플리케이션이 어디에 있는지를 찾아내는 장치를 서비스 디스커버리라고 합니다. 쿠버네티스에서는 클러스터 안에 구성 레지스트리를 갖고 있어서 이를 바탕으로 서비스 디스커버리를 동적으로 수행합니다. 마이크로 서비스형 애플리케이션의 경우 작은 기능을 제공하는 수많은 서비스를 조합하여 하나의 시스템을 만듭니다. 이 때 서비스 간의 호출은 서비스 디스커버리가 수행합니다.
일반적인 서비스 디스커버리는 다음과 같은 것이 있습니다.
| 종류 | 기능 | 설명 |
| 고정 IP 주소 | 서비스의 고정 IP 주소를 결정 | 서버의 IP 주소를 자동으로 설정하는 경우에는 이용할 수 없다. 또 변경이 어려워 유연성이 떨어진다. |
| 호스트 파일의 엔트리 | 파일을 사용하여 서버명과 IP 주소를 매핑 | 서비스가 변경되었을 때 호스트 파일의 변경이 필요하다. |
| DNS | 서버를 사용하여 도메인명과 IP 주소를 매핑 | 널리 이용되고 있지만 실시간으로 변경하는 것은 힘들다. |
| 구성 레지스트리 | 인프라스트럭처와 서비스를 연결하여 일원 관리 | 동적으로 구성을 생성하여 인프라스트럭처 안의 리소스에 관한 상세한 정보를 제공한다. |
참고
https://book.naver.com/bookdb/book_detail.nhn?bid=15476569
완벽한 IT 인프라 구축의 자동화를 위한 Kubernetes
AZURE를 사용한 쿠버네티스의 개념 파악과 실전 응용이 책은 쿠버네티스를 처음 사용하는 업무 애플리케이션 개발자 및 도커에 대한 기초 지식이 있는 분을 대상으로 컨테이너 오케스트레이션
book.naver.com
'About > Kubernetes' 카테고리의 다른 글
| [k8s] 매니페스트 파일 작성 방법 (0) | 2022.01.04 |
|---|---|
| [k8s] 애플리케이션 설정 정보 관리(ConfigMap/Secrets) (0) | 2022.01.04 |
| [k8s] Service - (ClusterIP, NodePort, LoadBalancer) (0) | 2022.01.04 |
| [k8s] Pod의 특징 (Container, Label, NodeSelector) (0) | 2022.01.04 |
| [k8s] 쿠버네티스의 서버 구성(마스터와 노드) (1) | 2021.12.30 |
