[Container Management] Kubernetes 개요

이번 포스팅에서는 Kubernetes란 무엇인가에 대해 알아보겠습니다.

지난해 포스팅을 진행했었으나, 미진한 부분도 있었고 해서 리부트 차원에서 다시금 살펴보고자 합니다.

(곧.. 프로젝트도 있고해서..)

쿠버네티스(Kubernetes)는 컨테이너 애플리케이션을 배포하는 오픈소스 오케스트레이터(Open Source Orchestrator)입니다. 구글은 지난 10여 년간 애플리케이션 지향 API를 사용해 컨테이너에서 신뢰성(Reliable)과 확장성(Scaleable)을 갖춘 시스템을 배포한 경험에서 영감을 받아 쿠버네티스를 개발하였습니다. 이를 바탕으로 분산 시스템을 성공적으로 개발하고 배포할 수 있게 도와주는 역할을 합니다. 
먼저 쿠버네티스란 무엇이며, 왜 필요한지에 대해 하나씩 살펴보겠습니다. 

쿠버네티스의 필요성

쿠버네티스를 알아보기 전에 위에서 이야기한 신뢰성과 확장성을 갖춘 분산 시스템에 대해 먼저 이해해야 합니다.
분산 시스템은 신뢰성 높게 한 부분이 고장이 나거나 동작이 중지되어도 전체 시스템은 계속 운영이 되어야 하며, 소프트웨어 롤아웃의 경우나 그 밖의 유지 관리 작업 중에도 해당 시스템은 가용성을 지녀야 하는 시스템의 경우 적용하게됩니다. 또한 점점 더 많은 비즈니스가 온라인으로 진입하고 이런 서비스를 이용하므로 이를 수행하는 분산 시스템은 지속적으로 증가하는 사용량을 재설계 없이 수용할 수 있도록 높은 확장성을 갖추어야 합니다. 
바로 쿠버네티스는 속도와 확장성, 인프라 추상화 그리고 효율성 측면에서 이점이 있어 사용한다 볼수 있습니다. 

쿠버네티스의 장점

1) 먼저 속도는 오늘날 모든 소프트웨어 개발에서 핵심 요소입니다. 
고객들은 변화하는 기술의 흐름에 따라 새로운 기술을 반영하기를 원하지만, 이와 병행으로 안정성과 속도의 향상을 함께 원합니다. 
속도는 높은 가용성으로 서비스를 유지하며 제공할 수 있는 항목의 수로 측정하게 됩니다. 이런 점에서 컨테이너와 쿠버네티스는 가용성을 확보한 상태에서 작업을 빨리 할 수 있는 도구를 제공합니다. 
이를 가능하게 하는 핵심 개념은 불변성, 선언형 설정, 온라인 자가 치유 시스템이라 할 수 있습니다. 
이런 개념은 서로 연관되어 소프트웨어의 안정성을 유지하며 배포 속도를 획기적으로 향상 시킵니다. 

 

2) 컨테이너와 쿠버네티스는 개발자들이 불변형 인프라 원칙을 준수하며 분산 시스템을 구축하도록 돕는 역할을 합니다. 
불변형 인프라에서는 시스템에 결함이 발생하더라도 사용자의 수정을 통해 변경되지 않습니다. 
이는 다르게 말하면 업데이트 개념에서 벗어난 완전하고 새로운 이미지가 생성되고 단 한번의 실행으로 이 이미지를 새로운 버전의 이미지로 교체할 수 있습니다. 
이를 기반으로 컨테이너 환경에서 소프트웨어를 업그레이드 하는 방법으로 두가지를 생각해 볼 수 있습니다. 
먼저 컨테이너에 로그인하여 새로운 소프트웨어 버전을 다운로드하는 명령을 입력합니다. 그리고 기존 서버를 중지하고 새로운 서버를 시작하는 방식입니다. 
두번째로 새로운 컨테이너 이미지를 만들고 컨테이너 레지스트리로 주입을 합니다. 그리고 기존 컨테이너를 중지하고 새로운 컨테이너를 시작하는 방식입니다.
위 두가지 방식의 중요한 차이점은 새로운 컨테이너를 어떠한 방식으로 기록하는지의 차이라 볼 수 있습니다. 기존 이미지를 수정하는 것보다 새로운 이미지를 만들면 기존 이미지를 유지할 수 있기 때문에 오류 발생 시 즉시 되돌릴 수 있다는 장점이 있습니다.
변경 불가능한 이미지는 앞으로 쿠버네티스에서 다룰 모든 개념의 핵심이 됩니다. 
불변성을 통해 클러스터에서 동작 중인 컨테이너를 쿠버네티스에 애플리케이션을 기술하는 방식으로 확장 할 수 있습니다. 
쿠버네티스에 포함된 구성요소는 요구하는 시스템 상태를 나타내는 선언형 설정 객체입니다. 
실제 상태와 요구하는 상태를 일치시켜주는 것이 쿠버네티스의 역할이라 할 수 있습니다. 

쿠버네티스는 온라인 자가 치유 시스템을 지원합니다. 
요구하는 상태 설정을 받으면 한번에 현재 상태를 요구된 상태와 일치시키려고 하지 않고, 오히려 현재 상태를 요구된 상태로 일치시키려고 끊임없이 확인하는 과정을 수행합니다. 즉 쿠버네티스는 초기화하기도 하지만 불안정한 시스템 상태와 신뢰성에 영향을 미치는 오류나 변화로부터 시스템을 보호하기도 합니다. 이는 운영자가 직접 장애를 복구하기 위해 시도해야 하는 일련의 과정을 생략할 수 있기에 부담을 줄여주며, 안정적으로 더 빨리 복구할 수 있으므로 시스템 전체의 신뢰성이 향상됩니다. 
예를 들어보자면, 쿠버네티스에 요구된 상태로 5개의 복제본을 지정하게 되면, 단순히 5개의 복제본을 만들고 끊나는 것이 아니라, 강제로 6개의 복제본을 만들었을 경우 5개로 줄여주고, 문제로 인해 또는 직접 복제본을 3개로 줄였을 경우 5개로 다시 유지해 줍니다. 이는 운영 측면에 소모되는 요소를 줄여주고 신뢰성을 확장해 준다고 볼 수 있습니다. 

3) 다음으로 쿠버네티스는 분리된 아키텍처를 지향해 확장성을 확보합니다. 
분리된 아키텍처에서 각 컴포넌트는 정의된 API와 서비스 로드밸런서를 통해 다른 컴포넌트와 분리됩니다. 로드밸런서를 통해 컴포넌트를 분리하면, 프로그램 크기와 처리 용량을 증가시켜도 서비스의 다른 계층에서 조정이나 재설정이 필요하지 않습니다. 따라서 서비스를 구성하는 프로그램을 쉽게 확장할 수 있습니다. 
쿠버네티스는 불변적인 선언적 속성으로 서비스를 쉽게 확장 할 수 있습니다. 
컨테이너를 변경할 수 없고 복제본의 수가 단순히 선언형 설정에 포함되어 있으므로 서비스 확장을 하려면 간단히 설정 파일에서 이 숫자만 변경하면 됩니다. 앞서 설명한 온라인 자가 치유 시스템과 동일한 형태로 동작하게 됩니다.  

4) 다음으로 쿠버네티스는 분리된 마이크로서비스 아키텍처를 좀 더 쉽게 만들 수 있는 다양한 추상화와 API를 제공합니다. 
먼저 Pod나 컨테이너 그룹은 여러 팀이 개발한 컨테이너 이미지를 단일 배포 단위로 그룹화 할 수 있습니다. 
쿠버네티스 서비스는 마이크로서비스별 격리를 위해 로드밸런싱, 네이밍, 검색등을 제공합니다. 
또한 네임스페이스는 격리와 접근제어를 제공해 각각의 마이크로서비스가 다른 서비스와 상호작용하는 정도를 제어할 수 있습니다. 
Ingress Object는 마이크로서비스를 단일 외부와 API 영역으로 그룹화할 수 있도록 쉬운 프론트엔드를 제공합니다. 

5) 마지막으로 쿠버네티스는 같은 애플리케이션 지향 컨테이너 API로의 전환에는 두 가지 확실한 장점을 가지고 있습니다. 
먼저 앞서 설명한 내용과 같이 특정 머신에서  개발자를 분리할 수 있다는 것 입니다. 이것은 클러스터 확장 시 머신을 간단히 추가해 역할을 쉽게 만들수 있으며, 클라우드 개발자는 특정 클라우드 인프라 API로 구현되는 고수준 API를 사용하므로 높은 수준의 이식 가능성을 제공합니다. 

 

또한 명확한 경제적 이점을 가지고 있습니다. 
효율성은 머신이나 프로세스가 수행한 유용한 작업량과 작업에 소비한 총 비용으로 측정할 수 있습니다. 애플리케이션을 배포하고 관리하는 경우 많은 도구와 프로세스가 비효율적으로 사용됩니다. 
효율성을 논의할 때는 보통 서버를 운영하는 비용과 그 서버를 관리하는 인건비를 함께 고려하는 것이 좋습니다. 
서버 운영 시 전력 사용량, 냉각 요구사항, 데이터 센터 공간, 기본 컴퓨팅 전원을 기준으로 비용이 발생합니다. 
쿠버네티스는 기존 도구 보다 고수준의 사용률을 보장하고, 자동으로 애플리케이션을 클러스터 내 머신으로 배분하는 도구를 제공합니다. 
각 배포 비용을 여러 대의 가상 머신이 아닌 소수의 컨테이너로 측정할 경우 비용은 급격히 줄어듭니다. 쿠버네티스의 원래 가치로 돌아가서 생각해 보자면, 이렇게 문제가 발생한 지점을 명확히 파악하기 위해 세부사항과 코드 안정성에 대한 강력한 신뢰를 확보하므로 결국 속도 향상으로 이어집니다. 

지금까지 쿠버네티스에 대해 알아 보았습니다. 
요약해 보자면, 쿠버네티스는 클라우드에서 애플리케이션을 구축하고 배포하는 방식을 변경하기 위해 만들어 졌습니다. 
기본적으로 개발자에게 더 효율적인 속도, 확장성, 추상화 효율성을 안겨주도록 설계되었습니다. 

다음 포스팅에서는 실제 Kubernetest Master Node를 설치해 보도록 하겠습니다.