2021.10.22

컨테이너 탐험가를 위한 ‘쿠버네티스’ 안내서

Serdar Yegulalp | InfoWorld
쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션에 사용되는 오픈소스 플랫폼이다. 다시 말해, 다수의 독립적인(Self-contained) 런타임들인 컨테이너로 만든 애플리케이션을 관리해주는 플랫폼이다. 

컨테이너는 2013년 도커(Docker) 컨테이너화 프로젝트가 런칭된 이후 인기가 높아졌다. 그러나 크고 분산된 컨테이너화 애플리케이션들은 조율이 점차 어려워질 수 있는 문제를 갖고 있다. 컨테이너화 된 애플리케이션을 대규모로 용이하게 관리할 수 있는 쿠버네티스가 컨테이너 혁신의 핵심으로 부상한 이유다.
 
StockSnap (CC0)


컨테이너 오케스트레이션이란?
컨테이너는 VM과 유사한 분리 기능을 제공하면서도 비용이 훨씬 낮고, 유연성은 훨씬 더 크다. 그 결과, 컨테이너는 사람들이 소프트웨어 개발, 배포, 유지관리에 대한 사고방식을 바꿔 놓았다.

컨테이너화된 아키텍처의 경우, 하나의 애플리케이션을 구성하는 여러 서비스가 별개의 컨테이너로 묶여, 물리적 장치나 가상 머신의 클러스터에 배포된다. 그러나 이로 인해 컨테이너 오케스트레이션이 요구된다. 즉 컨테이너 기반 애플리케이션의 배포, 관리, 축소 및 확장, 네트워크 연결, 가용성을 자동화하는 도구가 필요해졌다.

쿠버네티스란?
쿠버네티스는 컨테이너 오케스트레이션 도구들 중 특히 인기를 끄는 오픈소스 프로젝트다. 다중 컨테이너 애플리케이션을 대규모로 배포해 관리할 수 있도록 도와준다. 쿠버네티스는 인기있는 컨테이너화 플랫폼인 도커와 함께 이용되는 경우가 많지만, 컨테이너 이미지 형식과 런타임에 대한 OCI 표준을 준수하는 다른 모든 컨테이너화 시스템도 지원한다. 

쿠버네티스는 활용 방식에 대한 제한이 적은 오픈소스이기 때문에 컨테이너를 운영하기 원하는 사람은 누구나 자유롭게, 그리고 온프레미스, 퍼블릭 클라우드, 두 곳 모두 등 장소에 구애 받지 않고 사용할 수 있다.
 


구글과 쿠버네티스
쿠버네티스는 구글 내부의 프로젝트로 시작됐다. 구글이 내부에서 이용한 초기 컨테이너 관리 도구인 구글 보그(Borg)의 후계자(직접적이지는 않지만)이다. 2014년에 구글이 쿠버네스를 오픈소스로 공개했다. 

공개 이유 중 하나는 쿠버네티스가 도움을 주는 분산형 마이크로서비스 아키텍처가 클라우드에서 애플리케이션을 쉽게 실행할 수 있도록 해주기 때문이었다. 구글은 컨테이너, 마이크로서비스, 쿠버네티스 도입이 고객들을 클라우드 서비스로 유도할 잠재력을 갖고 있다고 판단했다(그렇지만 쿠버네티스는 애저와 AWS도 지원한다). 

쿠버네티스는 현재 리눅스재단 산하인 클라우드 네이티브 컴퓨팅 재단이 관리하고 있다.

쿠버네티스와 다른 프로젝트
쿠버네티스가 가장 많이 사용되고, 광범위하게 지원되는 도구가 되었지만, 유일한 대규모 컨테이너 관리 도구는 아니다. 고려할 가치가 있는 다른 선택지들도 존재한다.

- 쿠버네티스 Vs. 도커 및 도커 스웜 모드
쿠버네티스는 도커를 대체하지 않는다. 이를 보완한다. 그러나 도커와 관련된 고수준 기술들 가운데 일부를 대체한다.

이런 기술 중 하나가 ‘스웜(Swarm)’으로 불리는 도커 엔진(Docker Engine) 클러스터를 관리하는 시스템인 도커 스웜 모드(Docker swarm mode)이다. 이는 본질적으로 작은 오케스트레이션 시스템이다. 쿠버네티스 대신 도커 스웜 모드를 사용할 수 있지만, 도커(Docker Inc.)는 향후 도커를 핵심 요소로 지원하기로 결정했다.

쿠버네티스는 도커 스웜 모드보다 훨씬 더 복잡하고, 배포 과정에 많은 작업이 필요하다. 그러나 이런 작업은 장기적으로 큰 보상을 준다. 관리가 더 용이하고 탄력적인 애플리케이션 인프라일 수 있기 때문이다. 단 개발 작업과 더 작은 컨테이너 클러스트 환경에서는 도커 스웜 모드가 더 단순한 선택지일 수 있다.

- 쿠버네티스 Vs. 메소스
쿠버네티스와 경쟁하는 또 다른 프로젝트는 메소스(Mesos)이다. 메소스는 아파치 프로젝트로 트위터 개발자들이 최초 개발했다. 구글 보그 프로젝트의 ‘대항마’였었다.

메소스는 컨테이너 오케스트레이션 서비스를 제공하지만, 그 이상을 추구한다. 컨테이너화 요소와 그렇지 않은 요소를 모두 조율할 수 있는 클라우드 운영 체제를 지향한다는 의미이다. 따라서 여러 다양한 플랫폼을 메소스 내부에서 실행할 수 있으며, 여기에 쿠버네티스도 포함된다.

쿠버네티스 아키텍처: 작동 방식
쿠버네티스 아키텍처는 다양한 개념과 추상화를 이용한다. 기존의 친숙한 개념에서 변형된 것들도 있지만, 쿠버네티스에만 특정적인 것들도 있다.

- 클러스터
가장 높은 수준의 쿠버네티스 추상화인 클러스터는 쿠버네티스와 쿠버네티스가 관리하는 컨테이너를 실행하는 머신 그룹을 일컫는다. 쿠버네티스 클러스터에는 클러스터의 다른 모든 쿠버네티스 머신을 명령 및 제어하는 시스템인 마스터를 갖고 있어야 한다. 가용성 높은 쿠버네티스 클러스터는 여러 머신에서 마스터의 기능을 복제한다. 그러나 한 번에 한 개의 마스터만 작업 스케줄러와 컨트롤러 관리자를 실행한다.

- 노드와 팟
각 클러스터에는 쿠버네티스 노드(Nodes)들이 있다. 노드는 물리적 장치일 수도, VM일 수도 있다. 다시 강조하지만, 추상화 개념이 중요하다. 어떤 애플리케이션이 실행되든 쿠버네티스는 해당 기판(Substrate)에서 배포를 처리한다. 심지어 쿠버네티스를 이용, 특정 컨테이너가 VM이나 베어 메탈에서만 실행되도록 만들 수 있다.

노드는 생성하거나 관리할 수 있는 가장 기본적인 쿠버네티스 개체는 팟(Pod)이다. 각 팟은 쿠버네티스의 애플리케이션의 단일 인스턴스나 실행 프로세스이며, 하나 이상의 컨테이너로 구성된다. 쿠버네티스는 팟의 모든 컨테이너를 그룹으로 시작, 중지, 복제한다. 팟은 사용자가 컨테이너 자체가 아닌 애플리케이션에 집중할 수 있도록 해준다. 팟 상태부터 쿠버네티스를 구성하는 방법에 대한 자세한 정보는 분산 키 값 저장소인 Etcd에 저장된다.

팟은 사용자가 팟 정의로 명시한 상태에 부합하도록 필요에 따라 노드에서 생성되고 파괴된다. 쿠버네티스는 팟 스핀업, 배치, 스핀다운 방법을 다루는 컨트롤러라는 추상화를 제공한다. 컨트롤러는 관리될 애플리케이션의 종류에 따라 달라진다. 예를 들어, 스테이트풀세트(StatefulSet) 컨트롤러는 영구적 상태가 필요한 애플리케이션 처리에 이용된다. 디플로이먼트 컨트롤러는 앱의 축소나 확장, 새 버전으로 업데이터, 문제가 있을 때 알려진 정상 버전으로 롤백에 이용된다.

- 쿠버네티스 서비스
팟은 필요에 따라 만들어지고 없어지기 때문에 애플리케이션 생애주기를 다룰 또 다른 추상화가 필요하다. 애플리케이션을 구성하는 컨테이너를 실행하는 팟이 영구적이지 않은 경우에도 애플리케이션은 영구적이어야 한다. 이에 쿠버네티스는 서비스라는 추상화를 제공한다.

쿠버네티스의 서비스는 특정 팟 그룹(또는 다른 쿠버네티스 개체)를 네트워크를 통해 액세스 할 수 있는 방법을 설명한다. 쿠버네티스 자료에 따르면, 애플리케이션의 백엔드를 구성하는 팟이 변경될 수 있지만, 프론트엔드는 이를 알거나 추적해서는 안 된다. 서비스가 이를 가능하게 만든다.

쿠버네티스 내부에는 중요한 요소들이 몇개 더 있다. 스케줄러는 리소스 간 균형이 유지되고, 배포가 애플리케이션 정의의 요건을 충족하도록 워크로드를 노드에 분산시킨다. 컨트롤러 관리자는 애플리케이션, 워크로드 등 시스템 상태가 Etcd의 구성 설정에서 정의한 상태와 일치하도록 만든다.

도커 자체와 같이 컨테이너가 이용하는 저수준 메커니즘이 쿠버네티스로 대체되지는 않는다는 점을 기억하는 것이 중요하다. 쿠버네티스는 앱을 대규모로 계속 실행하기 위해 이런 메커니즘을 사용할 수 있도록 도움을 주는 추상화 기능들을 제공할 뿐이다.

- 정책
쿠버네티스의 정책은 팟이 특정 동작 기준을 준수하는지 확인한다. 예를 들어, 정책을 통해 팟이 CPU와 메모리, 프로세스 ID, 디스크 공간을 과도하게 사용하지 못하도록 막는다. 이런 ‘제한 범위’는 CPU는 상대적(예, 하드웨어 스레드의 50%), 메모리는 절대적(예, 200MB)이다. 이런 제한과 함께  리소스 할당 방법을 이용, (애플리케이션이 아닌)여러 쿠버네티스 사용자 팀이 동등하게 리소스에 액세스를 할 수 있도록 만든다.

- 인그레스
쿠버네티스 서비스는 클러스터 내부에서 실행된다. 그러나 외부에서 이런 서비스에 액세스 하기 원할 수도 있다. 쿠버네티스는 각기 다른 단순성과 견고성으로 이러한 니즈를 채워주는 몇몇 구성 요소들을 갖고 있다. 노드포트(NodePort)와 로드밸런서(LoadBalance)를 예로 들 수 있다. 그러나 가장 유연한 구성 요소는 인그레스(Ingress)이다. 인그레스는 통상 HTTP를 통한 클러스터 서비스에 대한 외부 액세스를 관리하는 API이다.

인그레스를 제대로 설정하려면 약간의 구성이 요구된다. 쿠버네티스 개발과 관련된 책을 쓴 매튜 파머는 자신의 웹사이트에 단계적 과정들을 소개하고 있다.

- 대시보드
이들 구성 요소를 모두 파악하는 데 도움을 주는 쿠버네티스의 구성 요소는 앱 배포 및 문제해결, 클러스터 리소스 관리에 이용할 수 있는 웹 기반 UI인 대시보드이다. 대시보드는 기본으로 설치되어 있지 않지만, 추가해도 큰 문제는 없다.

쿠버네티스의 강점
쿠버네티스에는 새로운 추상화와 개념들이 도입되어 있고, 학습 곡선이 가파르기 때문에 이를 사용했을 때 장기적인 이점을 묻는 것은 당연한 일이다. 다음은 쿠버네티스 내부에서 앱을 더욱 쉽게 실행하도록 해주는 구체적인 몇몇 방법이다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2021.10.22

컨테이너 탐험가를 위한 ‘쿠버네티스’ 안내서

Serdar Yegulalp | InfoWorld
쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션에 사용되는 오픈소스 플랫폼이다. 다시 말해, 다수의 독립적인(Self-contained) 런타임들인 컨테이너로 만든 애플리케이션을 관리해주는 플랫폼이다. 

컨테이너는 2013년 도커(Docker) 컨테이너화 프로젝트가 런칭된 이후 인기가 높아졌다. 그러나 크고 분산된 컨테이너화 애플리케이션들은 조율이 점차 어려워질 수 있는 문제를 갖고 있다. 컨테이너화 된 애플리케이션을 대규모로 용이하게 관리할 수 있는 쿠버네티스가 컨테이너 혁신의 핵심으로 부상한 이유다.
 
StockSnap (CC0)


컨테이너 오케스트레이션이란?
컨테이너는 VM과 유사한 분리 기능을 제공하면서도 비용이 훨씬 낮고, 유연성은 훨씬 더 크다. 그 결과, 컨테이너는 사람들이 소프트웨어 개발, 배포, 유지관리에 대한 사고방식을 바꿔 놓았다.

컨테이너화된 아키텍처의 경우, 하나의 애플리케이션을 구성하는 여러 서비스가 별개의 컨테이너로 묶여, 물리적 장치나 가상 머신의 클러스터에 배포된다. 그러나 이로 인해 컨테이너 오케스트레이션이 요구된다. 즉 컨테이너 기반 애플리케이션의 배포, 관리, 축소 및 확장, 네트워크 연결, 가용성을 자동화하는 도구가 필요해졌다.

쿠버네티스란?
쿠버네티스는 컨테이너 오케스트레이션 도구들 중 특히 인기를 끄는 오픈소스 프로젝트다. 다중 컨테이너 애플리케이션을 대규모로 배포해 관리할 수 있도록 도와준다. 쿠버네티스는 인기있는 컨테이너화 플랫폼인 도커와 함께 이용되는 경우가 많지만, 컨테이너 이미지 형식과 런타임에 대한 OCI 표준을 준수하는 다른 모든 컨테이너화 시스템도 지원한다. 

쿠버네티스는 활용 방식에 대한 제한이 적은 오픈소스이기 때문에 컨테이너를 운영하기 원하는 사람은 누구나 자유롭게, 그리고 온프레미스, 퍼블릭 클라우드, 두 곳 모두 등 장소에 구애 받지 않고 사용할 수 있다.
 


구글과 쿠버네티스
쿠버네티스는 구글 내부의 프로젝트로 시작됐다. 구글이 내부에서 이용한 초기 컨테이너 관리 도구인 구글 보그(Borg)의 후계자(직접적이지는 않지만)이다. 2014년에 구글이 쿠버네스를 오픈소스로 공개했다. 

공개 이유 중 하나는 쿠버네티스가 도움을 주는 분산형 마이크로서비스 아키텍처가 클라우드에서 애플리케이션을 쉽게 실행할 수 있도록 해주기 때문이었다. 구글은 컨테이너, 마이크로서비스, 쿠버네티스 도입이 고객들을 클라우드 서비스로 유도할 잠재력을 갖고 있다고 판단했다(그렇지만 쿠버네티스는 애저와 AWS도 지원한다). 

쿠버네티스는 현재 리눅스재단 산하인 클라우드 네이티브 컴퓨팅 재단이 관리하고 있다.

쿠버네티스와 다른 프로젝트
쿠버네티스가 가장 많이 사용되고, 광범위하게 지원되는 도구가 되었지만, 유일한 대규모 컨테이너 관리 도구는 아니다. 고려할 가치가 있는 다른 선택지들도 존재한다.

- 쿠버네티스 Vs. 도커 및 도커 스웜 모드
쿠버네티스는 도커를 대체하지 않는다. 이를 보완한다. 그러나 도커와 관련된 고수준 기술들 가운데 일부를 대체한다.

이런 기술 중 하나가 ‘스웜(Swarm)’으로 불리는 도커 엔진(Docker Engine) 클러스터를 관리하는 시스템인 도커 스웜 모드(Docker swarm mode)이다. 이는 본질적으로 작은 오케스트레이션 시스템이다. 쿠버네티스 대신 도커 스웜 모드를 사용할 수 있지만, 도커(Docker Inc.)는 향후 도커를 핵심 요소로 지원하기로 결정했다.

쿠버네티스는 도커 스웜 모드보다 훨씬 더 복잡하고, 배포 과정에 많은 작업이 필요하다. 그러나 이런 작업은 장기적으로 큰 보상을 준다. 관리가 더 용이하고 탄력적인 애플리케이션 인프라일 수 있기 때문이다. 단 개발 작업과 더 작은 컨테이너 클러스트 환경에서는 도커 스웜 모드가 더 단순한 선택지일 수 있다.

- 쿠버네티스 Vs. 메소스
쿠버네티스와 경쟁하는 또 다른 프로젝트는 메소스(Mesos)이다. 메소스는 아파치 프로젝트로 트위터 개발자들이 최초 개발했다. 구글 보그 프로젝트의 ‘대항마’였었다.

메소스는 컨테이너 오케스트레이션 서비스를 제공하지만, 그 이상을 추구한다. 컨테이너화 요소와 그렇지 않은 요소를 모두 조율할 수 있는 클라우드 운영 체제를 지향한다는 의미이다. 따라서 여러 다양한 플랫폼을 메소스 내부에서 실행할 수 있으며, 여기에 쿠버네티스도 포함된다.

쿠버네티스 아키텍처: 작동 방식
쿠버네티스 아키텍처는 다양한 개념과 추상화를 이용한다. 기존의 친숙한 개념에서 변형된 것들도 있지만, 쿠버네티스에만 특정적인 것들도 있다.

- 클러스터
가장 높은 수준의 쿠버네티스 추상화인 클러스터는 쿠버네티스와 쿠버네티스가 관리하는 컨테이너를 실행하는 머신 그룹을 일컫는다. 쿠버네티스 클러스터에는 클러스터의 다른 모든 쿠버네티스 머신을 명령 및 제어하는 시스템인 마스터를 갖고 있어야 한다. 가용성 높은 쿠버네티스 클러스터는 여러 머신에서 마스터의 기능을 복제한다. 그러나 한 번에 한 개의 마스터만 작업 스케줄러와 컨트롤러 관리자를 실행한다.

- 노드와 팟
각 클러스터에는 쿠버네티스 노드(Nodes)들이 있다. 노드는 물리적 장치일 수도, VM일 수도 있다. 다시 강조하지만, 추상화 개념이 중요하다. 어떤 애플리케이션이 실행되든 쿠버네티스는 해당 기판(Substrate)에서 배포를 처리한다. 심지어 쿠버네티스를 이용, 특정 컨테이너가 VM이나 베어 메탈에서만 실행되도록 만들 수 있다.

노드는 생성하거나 관리할 수 있는 가장 기본적인 쿠버네티스 개체는 팟(Pod)이다. 각 팟은 쿠버네티스의 애플리케이션의 단일 인스턴스나 실행 프로세스이며, 하나 이상의 컨테이너로 구성된다. 쿠버네티스는 팟의 모든 컨테이너를 그룹으로 시작, 중지, 복제한다. 팟은 사용자가 컨테이너 자체가 아닌 애플리케이션에 집중할 수 있도록 해준다. 팟 상태부터 쿠버네티스를 구성하는 방법에 대한 자세한 정보는 분산 키 값 저장소인 Etcd에 저장된다.

팟은 사용자가 팟 정의로 명시한 상태에 부합하도록 필요에 따라 노드에서 생성되고 파괴된다. 쿠버네티스는 팟 스핀업, 배치, 스핀다운 방법을 다루는 컨트롤러라는 추상화를 제공한다. 컨트롤러는 관리될 애플리케이션의 종류에 따라 달라진다. 예를 들어, 스테이트풀세트(StatefulSet) 컨트롤러는 영구적 상태가 필요한 애플리케이션 처리에 이용된다. 디플로이먼트 컨트롤러는 앱의 축소나 확장, 새 버전으로 업데이터, 문제가 있을 때 알려진 정상 버전으로 롤백에 이용된다.

- 쿠버네티스 서비스
팟은 필요에 따라 만들어지고 없어지기 때문에 애플리케이션 생애주기를 다룰 또 다른 추상화가 필요하다. 애플리케이션을 구성하는 컨테이너를 실행하는 팟이 영구적이지 않은 경우에도 애플리케이션은 영구적이어야 한다. 이에 쿠버네티스는 서비스라는 추상화를 제공한다.

쿠버네티스의 서비스는 특정 팟 그룹(또는 다른 쿠버네티스 개체)를 네트워크를 통해 액세스 할 수 있는 방법을 설명한다. 쿠버네티스 자료에 따르면, 애플리케이션의 백엔드를 구성하는 팟이 변경될 수 있지만, 프론트엔드는 이를 알거나 추적해서는 안 된다. 서비스가 이를 가능하게 만든다.

쿠버네티스 내부에는 중요한 요소들이 몇개 더 있다. 스케줄러는 리소스 간 균형이 유지되고, 배포가 애플리케이션 정의의 요건을 충족하도록 워크로드를 노드에 분산시킨다. 컨트롤러 관리자는 애플리케이션, 워크로드 등 시스템 상태가 Etcd의 구성 설정에서 정의한 상태와 일치하도록 만든다.

도커 자체와 같이 컨테이너가 이용하는 저수준 메커니즘이 쿠버네티스로 대체되지는 않는다는 점을 기억하는 것이 중요하다. 쿠버네티스는 앱을 대규모로 계속 실행하기 위해 이런 메커니즘을 사용할 수 있도록 도움을 주는 추상화 기능들을 제공할 뿐이다.

- 정책
쿠버네티스의 정책은 팟이 특정 동작 기준을 준수하는지 확인한다. 예를 들어, 정책을 통해 팟이 CPU와 메모리, 프로세스 ID, 디스크 공간을 과도하게 사용하지 못하도록 막는다. 이런 ‘제한 범위’는 CPU는 상대적(예, 하드웨어 스레드의 50%), 메모리는 절대적(예, 200MB)이다. 이런 제한과 함께  리소스 할당 방법을 이용, (애플리케이션이 아닌)여러 쿠버네티스 사용자 팀이 동등하게 리소스에 액세스를 할 수 있도록 만든다.

- 인그레스
쿠버네티스 서비스는 클러스터 내부에서 실행된다. 그러나 외부에서 이런 서비스에 액세스 하기 원할 수도 있다. 쿠버네티스는 각기 다른 단순성과 견고성으로 이러한 니즈를 채워주는 몇몇 구성 요소들을 갖고 있다. 노드포트(NodePort)와 로드밸런서(LoadBalance)를 예로 들 수 있다. 그러나 가장 유연한 구성 요소는 인그레스(Ingress)이다. 인그레스는 통상 HTTP를 통한 클러스터 서비스에 대한 외부 액세스를 관리하는 API이다.

인그레스를 제대로 설정하려면 약간의 구성이 요구된다. 쿠버네티스 개발과 관련된 책을 쓴 매튜 파머는 자신의 웹사이트에 단계적 과정들을 소개하고 있다.

- 대시보드
이들 구성 요소를 모두 파악하는 데 도움을 주는 쿠버네티스의 구성 요소는 앱 배포 및 문제해결, 클러스터 리소스 관리에 이용할 수 있는 웹 기반 UI인 대시보드이다. 대시보드는 기본으로 설치되어 있지 않지만, 추가해도 큰 문제는 없다.

쿠버네티스의 강점
쿠버네티스에는 새로운 추상화와 개념들이 도입되어 있고, 학습 곡선이 가파르기 때문에 이를 사용했을 때 장기적인 이점을 묻는 것은 당연한 일이다. 다음은 쿠버네티스 내부에서 앱을 더욱 쉽게 실행하도록 해주는 구체적인 몇몇 방법이다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X