컨테이너 오케스트레이션의 등장
쿠버네티스에 대해서 알아보기 전, 왜 쿠버네티스가 등장했는지 부터 알아보자!
- 전통적인 환경에서의 배포(On-premise)
- 초기의 개발 환경은 물리적 서버에서 애플리케이션을 실행했다. 이 방법은 물리적 서버에 애플리케이션의 변경 사항을 쉽게 적용할 수 없고, 물리적 서버를 유지 관리하는데도 비용이 많이 생겼다.
- 한 물리 서버에 여러 애플리케이션이 구동되면, 다른 애플리케이션 성능이 저하될 수 있어 리소스 할당 문제가 발생했다.
- 때문에 여러 물리 서버를 나누어 애플리케이션을 실행했지만, 많은 비용이 듦과 비효율적인 구조를 구축하게 됐다.
- 가상 환경에서의 배포(VM)
- 물리적 환경에 대한 솔루션으로 가상화가 도입되었다. 단일한 물리적 서버의 CPU에서 여러 대의 가상머신을 실행할 수 있게 되었다. 이러한 가상화를 사용하게 되면 애플리케이션 간에 격리를 할 수 있고, 상호 간의 보안 환경 유지할 수 있다.
- 하나의 OS 위에 여러 OS를 실행시킨다는 것은 리소스를 많이 잡아 먹기 때문에 다소 무겁다는 단점이 존재했다.
- 컨테이너로의 배포(Container)
- 컨테이너는 위의 가상머신과 유사하지만 컨테이너에는 자체 파일 시스템, CPU 공유, 메모리, 프로세스 공간 등이 있다. 기본 인프라에서 분리되기 때문에 클라우드 및 OS 배포 전반에 걸쳐 이식이 가능하다. VM보다 더 경량화된 것이다.
- 호스트 OS 위에 컨테이너 엔진을 설치하고, 애플리케이션 작동에 필요한 바이너리, 라이브러리 등을 하나로 모아 각자의 별도의 서버인 것처럼 사용하는 환경이다.
이렇듯 컨테이너는 프로세스 단위의 격리 환경을 조성하여 상호 간의 의존도를 낮추어 준다. 또한 VM에 비해 리소스도 적어 배포가 빠르고 성능 손실이 거의 없다. 다양한 컨테이너 런타임 기술이 존재하지만, 단연 그중에 도커가 사실상 표준이 되었다.
오케스트레이션이란?
컨테이너화된 애플리케이션도 관리를 해야한다. 온프레미스 방식과 VM보다 용이하지만 컨테이너의 스케일 아웃 장점때문에 관리해야 하는 컨테이너 수가 많아지게 되면 관리가 어려워진다.
컨테이너 오케스트레이션(Container Orchestration): 컨테이너들을 지휘하는 메인 컨트롤러가 있고 그 지휘에 맞춰 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 것을 말한다. 컨테이너를 사용하는 어떤 환경에서든 사용할 수 있다.
복잡한 단계를 버리고 유기적인 관계를 미리 정의해 손쉽게 사용하도록 서비스를 제공하는 것. 다수의 컨테이너를 유기적으로 연결, 실행, 종료할 뿐만 아니라 상태를 추적하고 보존하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어주는 것이 컨테이너 오케스트레이션이다.
쿠버네티스(Kubernetes) 란?
쿠버네티스(k8s): 컨테이너 관리 도구, 컨테이너 오케스트레이션을 위한 솔루션으로, 여러 대의 컨테이너화된 애플리케이션을 효율적으로 배포, 확장 및 관리하는 오픈소스 플랫폼이다.
Google에서 개발한 오픈 소스 프로젝트로 시작되었으며, 현재는 CNCF에 의해 관리되고 있다. 쿠버네티스는 컨테이너화 된 애플리케이션을 쉽게 배포하고 관리하기 위한 풍부한 기능을 제공한다.
왜 쿠버네티스일까?
컨테이너 오케스트레이션을 제공하는 대표적인 솔루션은 다음과 같다.
- 도커 스웜(Docker Swarm): 간단하게 설치할 수 있고, 사용하기도 용이하다. 그러나 그만큼 기능이 다양하지 않아 대규모 환경에 적용하려면 사용자 환경을 변경해야 할 수 있다. 따라서 소규모 환경에 용이하다.
- 메소스(Mesos): 아파치의 오픈소스 프로젝트. 대규모 서버 환경에서 자원을 유연하게 공유하며 하나의 자원처럼 관리할 수 있는 도구이다. 하지만 기능을 활용하기 위해선 분산 관리 시스템과 연동해야 한다.
- 노메드(Nomad): 간단한 구성으로 컨테이너 오케스트레이션 환경을 제공한다. 하지만 기능이 부족하므로 복잡하게 여러 기능을 사용하는 환경이 아닌 가볍고 간단한 기능만 필요한 환경에서 사용하기를 권장한다.
- 쿠버네티스(k8s): 다양한 형태의 쿠버네티스가 지속적으로 계속 발전되고 있어 IT 인프라 자체를 컨테이너화하고, 컨테이너화 된 인프라 제품군을 쿠버네티스 위에서 동작할 수 있게 만든다. 즉 거의 모든 벤더와 오픈 소스 진영 모두 쿠버네티스를 지원하고, 그에 맞게 통합 개발하고 있다. 때문에 사실상의 표준으로 자리매김되었다.
쿠버네티스 구성
쿠버네티스는 다음과 같은 기능을 제공한다.
- 서비스 디스커버리와 로드 밸런싱
- 쿠버네티스는 DNS 이름을 사용하거나 자체 IP주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
- 스토로지 오케스트레이션
- 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다.
- 자동화된 롤아웃과 롤백
- 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며, 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
- 자동화된 빈 패킹
- 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
- 자동화된 복구
- 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
- 시크릿과 구성관리
- 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. 컨테이너 이미지를 재구성하지 않고, 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.
주요 구성 요소
클러스터
컨트롤 플레인 및 하나 이상의 컴퓨팅 머신 또는 노드로 구성된 클러스터는 최소 하나 이상의 제어판(Control Plane) 컴포넌트와, 이것과 연결된 몇 개의 워커노드로 구성되어 있다.
컨트롤 플레인(제어판)
쿠버네티스 노드를 제어하는 프로세스들이 모여있는 곳이다. 여기에서 모든 태스크 할당이 시작되고 제어판 컴포넌트는 클러스터가 잘 작동할 수 있게 돕는다.
- etcd
- 쿠버네티스 클러스터의 모든 데이터를 담고 있는 key-value 저장소이다.
- 인프라를 원하는 상태로 만들기 위해 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터를 저장한다.
- kube-api-server
- 쿠버네티스 클러스터의 허브로서 클라이언트와 etcd에 저장된 데이터 사이의 상호작용을 중개한다.
- 사용자(운영자), 클러스터 내 구성요소, 그리고 외부 컴포넌트가 서로 통신 할 수 있도록 HTTP API를 제공한다.
- kube-api-server 작동원리
- kube-scheduler
- 새로운 Pod를 감지하여 어떤 워커노드에 실행시킬지 선택하는 역할을 한다.
- 노드의 현재 상태와 Pod의 요구사항을 체크한다. 노드에 라벨을 부여한다.
- kube-controller-manager
- API 서버를 통해 클러스터의 다양한 컴포넌트들의 상태를 감지하고, 원하는 상태로 만드는 역할을 한다. 다양한 컨트롤러가 하나로 패키징되어 단일 프로세스 내에서 실행되게 한다.
워커노드
kubelet이라는 프로세스가 돌아가고 있는데, 이 kubelet은 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 한다. 한 개 이상의 컨테이너가 자리 잡고 있으며, 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳이라고 할 수 있다.
kubelet
- 각 노드에서 실행되는 기본 노드 에이전트이다. 일종의 데몬이라고 생각하면 된다.
- 컨테이너를 생성, 삭제하고 상태를 모니터링하며 마스터 노드와 통신을 담당 역할을 한다.
- 큐베렛이 작동하는 원리는 PodSpec 측면에서 작동한다. 파일로 명시된 PodSpec 부분에 그 코드에 설명된 컨테이너가 실행되고 정상적으로 작동하는 지를 확인한다.
- 큐베렛은 쿠버네티스에서 생성되지 않은 컨테이너는 관리하지 않는다.
kube-proxy
- 모든 워커노드마다 실행되는 네트워크 프록시이다.
- 다른 Pod간의 네트워크 통신과 클러스터 바깥에서 Pod로 네트워크 통신을 할 수 있게 해준다.
- 성능 상의 이유로 별도의 프록시 프로그램 대신 iptable 또는 IPVS를 사용한다. 즉 설정만 관리한다는 뜻이다.
pod
단일 노드에 하나 이상의 컨테이너 그룹이다. 포드에 있는 모든 컨테이너는 IP주소, IPC, 호스트이름, 기타 리소스를 공유한다.
'DevOps' 카테고리의 다른 글
[MSA] Spring Boot 프로젝트에서 MSA 실습하기(Kafka) - 2 (2) | 2023.11.26 |
---|---|
[MSA] Spring Boot 프로젝트에서 MSA 실습하기(Spring Cloud) - 1 (4) | 2023.11.25 |
[아키텍처] 모놀리식 아키텍처 VS 마이크로 서비스 아키텍처(MSA) (0) | 2023.11.15 |
[GitActions] Error: Gradle script '/home/runner/work/' is not executable. (0) | 2023.06.01 |
netlify sass error (0) | 2022.04.18 |