[ TERMS 05 ] 쿠버네티스
1. 쿠버네티스(Kubernetes)의 정의
쿠버네티스는 구글에서 개발한 오픈 소스 기반의 컨테이너 오케스트레이션(Container Orchestration)이다. 'Kubernetes'는 그리스어로 '키잡이''를 뜻한다. 쿠버네티스는 현재 가장 널리 사용되고 있는 오케스트레이션 툴로서, '쿠베르네티스, K8s, 쿠베, 쿠버, 큐브' 등 여러 이름으로 불리고 있다.
2. 쿠버네티스는 어디에서 접하게 될까?
모놀리식(Monolithic)을 마이크로서비스로 나누거나 마이크로서비스 기반 시스템을 처음부터 구축할 때 수많은 서비스만큼 수많은 컨테이너가 생성된다. 이런 분산 시스템에서 정신없이 많은 컨테이넏릉르 능숙하게 관리하는 쿠버네티스를 만날 수 있다.
3. 쿠버네티스 알아보기
> 등장배경
관리해야 하는 컨테이너 이미지가 점점 많아지면서 컨테이너만으로 구성된 인프라의 문제점이 생기기 시작했다. 컨테이너가 수백 개에 이르게 되면서 각 서버 인스턴스의 상태 체크, 배포, 죽은 컨테이너를 살리는 업무, 갑작스러운 사용자 증가/감소에 따른 호스트 서버의 성능 스케일업/스케일아웃 업무 등을 자동으로 처리해 줄 툴이 필요해졌다. 그래서 등장한 것이 컨테이너 오케스트레이션 툴이다.
> 역사
구글은 2014년 중순에 자사 내부 컨테이너 클러스터 관리 서비스인 보그(Borg)를 오픈 소스 버전으로 공개했고, 2015년 7월 21일에는 쿠버네티스 v1.0을 출시했다. 이때 구글은 리눅스 재단(Linux Foundation)과 파트너십을 맺고 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)을 설립했다. 이후로 CNCF가 쿠버네티스를 관리하고 있다.
현재는 구글, 아마존, 애저 등 주요 클라우드 벤더와 IBM, 오라클 같은 소프트웨어 벤더들이 각자의 브랜드로 쿠버네티스 배포판을 제공하고 있으며, 컨테이너 오케스트레이션의 사실상의 표준으로 자리 잡았다.
> 개념
쿠버네티스의 개념은 크게 두 가지로 나누어 설명할 수 있다. 첫째 선언적 구성과 컨트롤러이다. 사용자가 '원하는 상태(Desired State)'를 선언해 두면 쿠버네티스가 능동적으로 조치한다. 해당 선언은 YAML 형태로 이루어진다.
컨트롤러 선언문(YAML)이 원하는 상태를 확인하고 현재 상태를 관찰한 후 불일치할 경우 자동으로 조치를 취한다. 그 결과 현재의 상태는 원하는 상태와 일치하게 된다. 쿠버네티스는 수많은 컨트롤러로 구성되어 있으며 각 컨트롤러는 자체적인 컨트롤 루프를 수행한다.
둘째 암시적/동적 그룹화이다. 쿠버네티스의 암시적/동적 그룹화는 레이블(Label)과 레이블 셀렉터(Label Selector)로 수행된다.
> 특징
- 지원하는 앱의 유형을 제약하지 않는다. 쿠버네티스는 다양한 워크로드를 지원하기 때문에 컨테이너에서 구동된다면, 쿠버네티스에서도 잘 동작할 것이다.
- 소스코드를 배포하지 않으며 앱을 빌드하지 않는다. 지속적인 통합과 배포(CI/CD) 워크플로는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정되는 부분이기 때문이다.
- 앱 레벨의 서비스를 제공하지 않는다. 앱 레벨의 서비스에는 미들웨어, 데이터 처리 프레임워크, 데이터베이스, 캐시 또는 클러스터 스토리지 시스템등이 있다. 이런 컴포넌트는 쿠버네티스상에서 구동되고 쿠버네티스상에서 구동 중인 앱이 Open Service Broker와 같은 이식 가능한 매커니즘을 통해 접근할 수 있다.
- 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
- 기본 설정 언어/시스템을 제공하거나 요구하지 않는다. 선언적 명제의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
- 포괄적인 머신 설정, 유지 보수,관리,자동 복구 시스템을 제공하거나 채택하지 않는다.
쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 쿠버네티스는 오케스트레이션의 필요성을 없애 준다. 오케스트레이션의 기술적인 정의는 A이후 B이후 C를 하는 것과 같이 정의된 워크 플로를 수행하는 것이다. 그러나 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 원하는 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요하지 않다. 이로써 시스템이 사용하기 쉬워지고, 강력해지고, 견고해지고, 회복력을 갖추게 되며, 확장 가능해진다.
> 장점
- 서비스 디스커버리와 로드 밸런싱이다. 쿠버네티스는 DNS이름이나 자체 IP주소로 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드 밸런싱하여 배포가 안정적으로 이루어지게 한다.
- 스토리지 오케스트레이션이다. 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다. 따라서 하이브리드 클라우드 운영이 가능하다.
- 자동화된 롤아웃과 롤백이다. 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다.
- 자동적인 빈 패킹(bin packing)이다. 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시하면, 쿠버네티스는 컨테이너를 노드에 맞춰서 리소스를 효율적으로 관리한다.
- 자가 치유(self-healing)이다. 쿠버네티스는 컨테이너에 문제가 발생해 죽더라도 시스템에서 현재 상태와 원하는 상태를 비교하여 실패한 컨테이너를 스스로 다시 시작한다.
- 시크릿과 구성 관리이다. 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 앱 구성을 배포 및 업데이트할 수 있다.
> 단점
쿠버네티스의 가장 큰 단점은 학습의 난이도가 높다는 것이다. 지금도 빠르게 변화하며 새로운 API와 개년들이 추가 및 삭제되고 있으며 다양한 기술들이 혼재되어 있어 불안정한 모습도 보인다는 지적이 있다. 이는 쿠버네티스의 학습 난이도가 높다는 것이기도 하지만 동시에 오픈 소스의 역동성을 보여주는 것이다.
4. 쿠버네티스를 사용하는 이유
클라우드 시대로 넘어오면서 빠르고 유연하게 자원을 사용할 수 있게 되었지만, 클라우드 회사마다 자원을 사용하는 방법이 달라 클라우드 플랫폼별로 설정을 다르게 해야 했다. 하지만 쿠버네티스 클러스터를 설치하면 클라우드 플랫폼에 상관없이 동일한 설정을 이용해서 앱을 구축할 수 있다.
요즘 대부분의 사용자들은 무중단 웹 서비스를 기대한다. 개발자들 역시 새 버전을 하루에도 몇 번씩 배포하는 것을 기대한다. 이러한 목표는 컨테이너와 쿠버네티스를 통해 실현할 수 있다.
5. 쿠버네티스 사용하기
> 쿠버네티스 클러스터
쿠버네티스 클러스터는 컨트롤 플레인(Control Plane)과 노드(Node) 두 개의 컴포넌트로 분리된다. 위 이미지에서 컨트롤 플레인은 쿠버네티스 전체를 컨트롤 하는 시스템이다. 컨트롤 플레인은 API 서버, 스케줄러, 컨트롤 매니저(Controller manager), 클라우드 컨트롤 매니저(Cloud Controller manager), etcd로 구성되어 있다.
쿠버네티스는 REST API로 통신하는데, API 서버가 중심이 된다. 스케줄러는 파드(Pod)를 적절한 노드에 할당하는 역할을 한다. 컨트롤러 매니저는 컨트롤러를 생성해서 각 노드에 배포하고 관리하는 역할을 한다. 클라운드 컨트롤러 매니저는 클라우드 플랫폼에 특화된 리소스를 제어하는 역할을 한다. etcd는 설정값이나 클러스터의 상태를 저장하는 서버이다.
노드는 컨트롤 플레인 명령을 받고 실제 워크로드를 생성 및 서비스한다. 노드는 Kubelet, Kube-proxy, Container runtime으로 구성 되어 있다. Kubelet은 API 서버와 통신하면서 노드에 할당된 파드와 컨테이너의 생명 주기를 관리한다. Kube-proxy는 컨테이너의 네트워킹을 담당하며 서비스마다 개별 IP를 가지게 하고 클러스터 내/외부의 트래픽을 파드로 전달하도록 패킷을 라우팅한다.
> 쿠버네티스 사용을 돕는 도구
- 헬름(Helm) : 쿠버네티스의 패키지 매니저이다. 쿠버네티스의 각종 설정을 담고 있는 YAML 파일들을 차트라는 패키지로 쉽게 관리하는 도구이다.
- Weave Scope : 시각화 및 모니터링을 위한 도구이며, 컨테이너로 설치할 수 있다. Weaveworks사에서 만든 제품으로 오픈 소스이며, 플러그인을 개발해서 사용할 수 있다. Weave Scope는 프로세스, 컨테이너, 호스트를 자동으로 감지한다. 컨테이너가 분산화되어 발생하는 소프트웨어 문제(네트워크 병목 현상, 마이크로서비스 아키텍처에서의 메모리 누수 등)를 감지하고 해결한다.
- 랜처(RANCHER) ： 컨테이너 워크로드의 관리를 돕는 오픈 소스 형태의 멀티 클러스터 관리 플랫폼이다. 랜처 2.x 버전부터는 쿠버네티스만 지원하고 있으며, 쿠버네티스 클러스터를 ‘멀티 클라우드’로 운영할 수 있게 해준다.
6. 쿠버네티스 사용하기
> 미니큐브 (Minikube)
미니큐브는 쿠버네티스의 라이트 버전이다. 간단하게 쿠버네티스 클러스터를 생성할 수 있다. 쿠버네티스를 처음 사용해 보는 개발자가 간단히 테스트할 때 유용하다. 미니큐브는 마스터 노드의 일부 기능과 하나의 노드만 제공합니다.
> 컨테이너 오케스트레이션 툴의 종류
쿠버네티스를 제외하고 도커스웜, 메소스 등이 있지만, 쿠버네티스가 컨테이너 오케스트레이션의 표준으로 인정받으면서 각 회사의 제품들은 쿠버네티스를 지원한다.
- 구글의 GKE (Google Kubemetes Engine)
- 도커의 Docker Swarm
- 레드햇의 OpenShift
- 마이크로소프트의 ACS (Azure Container Service)
- 아마존의 Amazon ECS(Elastic Container Service)
- 아파치의 Mesos
- 클라우드 네이티브 재단의 쿠버네티스
- 클라우드 파운드리 재단의 Diego
- 하시코프의 Nomad
- CoreOS의 Fleet
- Rancher의 Cattle
> 함께 알아 두면 좋은 용어
- 클라우드
- 데브옵스
- DevSecOps
- 마이크로서비스 아키텍처
- 온프레미스
> 혼동하기 쉬운 용어
- 도커
- PaaS
'IT 도서 리뷰 > 개발자가 되기 위해 꼭 알아야 하는 IT 용어' 카테고리의 다른 글
| [PART4] 클라우드/데브옵스 - TERMS 07 (0) | 2025.05.02 |
|---|---|
| [PART4] 클라우드/데브옵스 - TERMS 06 (0) | 2025.04.28 |
| [PART4] 클라우드/데브옵스 - TERMS 04 (0) | 2025.04.10 |
| [PART4] 클라우드/데브옵스 - TERMS 03 (0) | 2025.04.05 |
| [PART4] 클라우드/데브옵스 - TERMS 02 (0) | 2025.03.29 |