2020. 10. 10. 21:13ㆍDevOps/Kubernetes
(필자가 공부한 내용을 토대로 작성되었기에 피드백, 오타등 제보바람)
쿠버네티스는 그리스어로 조타수의 의미로 컨테이너화된 애플리케이션의 자동 디플로이, 스케일링 등을 제공하는 관리 시스템으로, 오픈소스 기반이다. 구글에 의해 설계되었고 현재는 리눅스 재단에 의해 관리되고 있다. DevOps 세계에서는 컨테이너 오케스트레이션과 쿠버네티스를 거의 동일시한다. 모든 주요 클라우드 공급자는 관리형 쿠버네티스 솔루션을 제공하고 여러 기업 사이에서 흔히 볼 수 있으며 구글, 마소, 아마존, IBM, VMware와 같이 쿠버네티스를 협력하고 추진하는 매우 큰 참여 기업들이 있다.
이번 글에서는 Kubernetes 구조의 이해와 다양한 기능 및 장점을 소개하고 끝내겠다.
1. 모놀리스와 마이크로서비스의 이해
쿠버네티스를 알기 전에 모놀리스와 마이크로서비스에 대해 알 필요가 있다. (이 부분은 aws나 redhat 홈페이지에 교과서적인 설명이 되어있다. 자세한 내용은 두 군데 확인해보기 바란다.)
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식이다. 즉 마이크로서비스를 전통적인 모놀리식 접근 방식과 구별 짓는 기준은 애플리케이션의 핵심기능을 세분화하는 것이다. 즉 쇼핑몰을 예로들면 로그인 기능, 상품 구입 기능, 장바구니 기능, 등등 다양한 서비스들을 각각 컨테이너화로 배포 및 관리하는 것이다. 이렇게 개별 서비스가 다른 서비스에 부정적인 영향을 주지 않으면서 작동할 수 있음을 의미하고 장애 발생시 트리플슈팅이 수월하다는 것이다. 물론 큰 단점도 있다. 대표적으로 설계가 복잡하다.(즉 개발난이도가 급상승한다.) 당연히 코드 양도 증가하지만 서비스간의 통신을 해주어야된다. 물론 툴을 이용하면 어느정도 쉽게 해결할수 있다. 마이크로서비스에대한 대표적인 툴은 도커와 쿠버네티스이다.
Docker와 Kubernetes는 필자 입장에서 진리인거 같다. Docker의 경우 점유율이 압도적이지만 kubernetes는 다양한 오케스트레이션 툴이 존재하기 때문에 배움에 있어 고민할 수 있다. 하지만 요즘 회사에서 많이 추진하기 때문에 적극 추천하는 바이다.
2. Kubernetes란
kubernetes.io에서 정의한 내용은 "컨테이나화된 워크로드와 서비스를 관리하기 위해 이식할 수 있고 확장 가능한 오픈 소스 플랫폼으로 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있으며 서비스, 지원 그리고 도구들을 광범위하게 제공된다." 이렇다. 쿠버네티스는 대표적인 컨테이너 오케스트레이션 툴이다. 오케스트레이션이란 컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미한다. 여기서 자동화와 오케스트레이션은 다른 개념이지만 연관은 되어있다. radhat에서 정의된 내용을 보자 (일반적인 자동화란 단일 테스크의 자동화를 의미하지만 오케스트레이션은 여러 이기종 시스템 전반에서 다양한 단계를 수반하는 프로세스 또는 워크플로우를 자동화하는 방법을 뜻한다.)
이처럼 오케스트레이션은 여러 이기종, 다양한 단계의 프로세스, 워크플로우를 자동화 해줘야되기 때문에 많이 복잡하다. 그중에서도 쿠버네티스는 다른 오케스트레이션 툴보다 훨씬 다양한 지식이 필요하며 쿠버네티스 자체의 관리가 더욱 어려울 수도 있다. 즉 학습 비용이 크다는 것 그럼에도 불구하고 많은 회사들이 쿠버네티스를 실제 서비스 운영에 도입하는 이유는 무엇일까?
- 애플리케이션 배포 단순화
- 하드웨어 활용도 극대화
- 상태 확인 및 자가 치유
- 오토스케이링
- 애플리케이션 개발 단순화
이들은 엄청난 기능들이다. 또한 필자가 언급안한 기능들이 더 존재하고 이보다 더 많은 다양한 장점도 존재한다. 개발자 입장에서 보면 핵심 애플리케이션 기능에 집중할 수 있게 하고 운영자 입장에서 보면 효과적으로 리소스들을 활용할 수 있다. 즉 인프라의 추상화를 함으로 컨테이너 시스템에서 컨테이너 애플리케이션을 쉽게 배포, 관리하도록 돕고, 기본 인프라를 추상화해 개발 및 운영 팀의 개발, 배포, 관리를 단순화되고 모든 노드가 하나의 거대한 컴퓨터인 것처럼 수천개의 컴퓨터 노드에서 소프트웨어 애플리케이션을 실행할 수 있다.
쿠버네티스의 구조와 디자인은 그 성공의 큰 부분이다. 이 부분을 설명하기 전에 용어를 알아두어야 된다. ( kubernetes.io 용어 정리집 제공해주니 꼭 참고 하길바람)
- 컨트롤 플레인
- API Server (사용자, 컨트롤 플레인과 통신)
- Kube-scheduler (워커 노드에 파드의 스케줄을 조정)
- Controller-manager (구성 요소 복제, 워커 노드 추적, 노드 장애 처리 등 클러스터 수준 기능 을 실행)
- etcd (데이터 스토리지 : 클러스터 구성을 지속적으로 저장하는 안정적인 분산 데이터 저장소) <- 이분은 CoreOS가 개발한것임 (etcd.io)
etcd
A distributed, reliable key-value store for the most critical data of a distributed system
etcd.io
- 데이터 플레인
- kubelet (API 서버와 통신하고 노드에서 컨테이너를 관리)
- kube-proxy (애플리케이션 간에 네트워크 트래픽을 분산 및 연결)
- containar runtime (컨테이너를 실행하는 도커)
- 클러스터 아키텍쳐
- master node (전체 쿠브네티스 시스템을 관리하고 통제하는 쿠버네티스 컨트롤 플레인을 관장)
- worker node (실제 배포하고자 하는 애플리케이션의 실행을 담당)
용어를 알았으니 이제 부터 구조에 대해 설명하자면 각 클러스터에는 컨트롤 플레인과 데이터 플레인이 있다.
컨트롤 프레인은 API 서버와 클러스터 상태를 유지하기 위한 메타데이터 저장소와 데이터 플레인의 노드 관리와 사용자 엑세스 제공을 담당하는 다중 컨트롤러 등 여러 구성 요소로 나뉘어 있는데 운영 중인 컨트롤 플레인은 높은 가용성 및 견고성을 여러 머신에 분산 할 것이다.
데이터 플레인은 여러개의 노드 또는 워커로 구성되는데 컨트롤 플레인에서 이러한 노드에 파드(컨테이너 그룹)을 배치하고 실행한 다음 변경 사항을 확인하고 응답한다. 컨테이너형 워크로드를 파드로 실행하는 클러스터 내 노드의 모음이다.
데이터 플레인 및 컨트롤 플레인은 물리적 또는 가상머신을 공유할 수 있다. 물론 minikube와 같은 단일 노드 클러스터를 실행할 때 이러한 현상이 발생한다. 그러나 일반적으로 프로덕션 환경에서는 데이터 플레인 자체 노드가 있을 것이고 쿠버네티스는 통신, 감시, 스케줄링하기 위해 각 노드에 설치되는 데이터 플레인 구성요소들이 있다.
- 정리 ( 쿠버네티스와 마이크로서비스 - 완벽한 조합 )
쿠버네티스와 마이크로서비스는 아주 잘 정렬되어 있다. 네임스페이스, 파드, 디플로이먼트, 서비스와 같은 쿠버네티스의 구성 요소는 중요한 마이크로서비스 개념과 신속한 소프트웨어 개발 수명주기에 직접 매핑된다. 마이크로서비스 아키텍처를 사용할 때 수많은 마이크로서비스가 있을 것이다. 즉 수많은 컨테이너는 애플리케이션을 패키징하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 그 수많은 컨테이너를 일일히 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? 답은 쿠버네티스에 있다.
(출처: kubernetes.io, aws.amazon.com, redhat.com, cloud.google.com, boanproject.com)
(참고문헌: 시작하세요 도커/쿠버네티스, Hands On MICROSERVICES(with KUBERNETES))
'DevOps > Kubernetes' 카테고리의 다른 글
| Kubernetes Roadmap 3# (0) | 2020.10.15 |
|---|---|
| Kubernetes 설치 2# (0) | 2020.10.10 |