Kubernetes

Kubernetes

Kubernetes는 인기 있는 컨테이너 오케스트레이터(orchestrator)이다. 오케스트레이터는 컨테이너와 서버/노드 집합을 가져와서 컨테이너 워크로드를 노드 사이에 어떻게 실행할지 결정하는 역할을 수행한다. 간단하게 말하면, 여러 대의 서버를 하나처럼 동작하도록 만든다. 2014년 구글에서 공개된 여러 오케스트레이터 중 하나였으며 현재는 전 세계의 오픈 소스 커뮤니티에 의해 관리된다.

Kubernetes는 본질적으로 컨테이너 내의 애플리케이션에서 실행되는 일련의 API로 서버 집합을 관리하고 Docker에서 컨테이너를 실행한다. 기본적으로 Docker 위에서 실행된다. 따라서 컨테이너 런타임을 제거하지는 않으며 다중 노드 시스템을 관리하는 일련의 컨테이너가 컨테이너 런타임 위에 실행되는 것이다. 즉, Kubernetes는 컨테이너 내에서 실행되는 일련의 API로서 Docker 위에서 동작한다. Kubernetes는 API 집합과 명령 줄 도구를 제공하여 Swarm과 유사한 서버 인프라를 배포하고 유지 관리할 수 있게 해준다. 주로 사용하는 도구 중 하나는 cube control/Kubectl이다.

Kubernetes를 사용하려면 수많은 옵션이 있는데 가장 일반적인 방법 중 하나는 클라우드 공급업체를 통해 Kubernetes를 얻는 것이다. 클라우드 공급업체는 컨테이너를 실행할 Kubernetes를 서비스로 제공한다. 다른 클라우드 서비스와 마찬가지로 Kubernetes 종단점 및 API를 제공하며 로컬 도구를 사용하거나 클라우드 인터페이스에 내장된 GUI를 사용하여 Kubernetes로 제어되는 컨테이너를 배포하고 유지 관리할 수 있다. 인프라 공급업체가 Kubernetes를 패키지로 제공한다. 이를 Kubernetes 배포판(distribution)라고 부른다. Linux 배포 버전의 개념과 유사하다. Linux 세계에서는 모든 다양한 배포판에서 동일한 Linux 커널이 실행된다. 커널은 약간 다르게 구성되거나 다른 버전이지만 기본적으로는 동일하다. Ubuntu, CentOS, Amazon Linux 등 다양한 배포판은 각자 선호하는 도구 집합을 패키지로 제공한다. Kubernetes도 마찬가지다. 클라우드나 온프레미스 데이터 센터용 Kubernetes 배포판 중에서 요구 사항, 기존 공급업체 계약 또는 운영 체제 또는 공급업체 선호도를 기반으로 선택한다.

Kubernetes vs. Swarm

Kubernetes와 Swarm 둘 다 컨테이너 런타임 위에서 실행되는 컨테이너 오케스트레이터이다. Docker 컨테이너 런타임 이외에도 containerd와 CRI-O와 같은 컨테이너 런타임이 존재한다. 두 플랫폼 모두 공급업체 지원이 뒷받침되는 견고한 플랫폼이다.

요약하면, Swarm은 구축하기 쉽고 노드를 추가하기 쉽고 시작하기 쉽고 관리하기 쉽다. 그래서, Swarm에 대해 말할 때 '쉬움'이라는 한 단어로 요약할 수 있다. 하지만 Swarm은 모든 경우에 Kubernetes만큼 다양한 용도로 활용되지는 않는다. Kubernetes는 훨씬 더 다양한 기능과 유연성, 맞춤화 기능을 가지고 있다. 더 많은 문제를 더 다양한 방식으로 해결할 수 있으며 일반적으로 더 많은 곳에서 사용되고 지원된다. 만약 DevOps 커뮤니티에 속해 있고 이 도구를 사용해 비즈니스 문제를 해결하려 한다면 두 플랫폼을 설치하고 애플리케이션을 배포하고 애플리케이션을 배포하는 기본 기능을 알아야 한다.

일반적으로, Swarm은 처음 시작하고 작은 규모로 시작하는 사람들에게 추천하는 툴이며 Kubernetes를 반드시 사용해야 한다는 확신이 없는 한 먼저 Swarm을 추천한다. 하지만 Swarm의 한계에 도달한 것 같고 원하는 기능을 충분히 얻지 못할 것 같다고 느끼면 Kubernetes를 고려한다.

Swarm

• Docker와 함께 제공되는 단일 공급업체에서 지원하는 솔루션이다. 즉, 컨테이너 런타임과 오케스트레이터를 개발한 회사가 동일하다. 복잡성과 실행에 필요한 자원이 상대적으로 작다. Docker 위에서 Swarm을 실행하는데 필요한 자원은 매우 작다.
• 배포하고 관리하기 쉽다. 수백 개에서 수천 개의 노드로 쉽게 확장할 수 있으며, 관리하는 데 큰 팀이 필요하지 않을 수 있다.
• 80/20 규칙을 따른다고 말할 수 있다. Kubernetes의 기능 중 20%를 가지고 있지만, 컨테이너와 오케스트레이션을 위한 80%의 사용 사례를 해결한다. 물론 이는 정확한 과학적 비교가 아니다. Swarm은 대부분의 웹 애플리케이션, 장기 실행 솔루션을 실행하는 데 사용 사례의 다수를 해결하며 클라우드나 데이터 센터, 작은 기기에서도 잘 작동한다.
• Docker가 실행되는 곳이라면 어디에서든 실행된다. Docker 엔진은 어느 툴보다도 더 많은 장소에서 실행된다. 리눅스뿐만 아니라 윈도우에서, 메인프레임에서도 실행된다. 또한, IoT, 라스베리파이와 같은 ARM 디바이스에서도 실행된다.
• 기본적으로 안전하다. Swarm을 만들고 노드를 추가할 때 상호 TLS 인증을 보장한다. 제어판을 암호화하고 데이터베이스를 암호화하여 필요한 경우 비밀을 안전하게 보호한다.  
• Swarm은 요소가 적기 때문에 문제 해결이 더 쉽고 관리해야 할 것이 더 적다. Docker에 기본으로 내장되어 있기 때문에 Docker의 문제 해결 방법을 알고 있다면 아마도 Swarm의 문제 해결 방법도 알 수 있다. 동일한 데몬 로그를 사용하며 애플리케이션에 대해 동일한 Docker 로그 명령을 사용한다. 노드 및 Swarm 자체의 이벤트를 확인하기 위해 동일한 Docker 이벤트 명령을 사용한다.

Kubernetes

• 가장 넓은 클라우드 및 공급업체 지원을 제공한다. 모든 클라우드 공급업체가 Kubernetes을 제공하며 직접 실행하지 않고도 시스템을 시작하고 Kubernetes 배포 파일을 사용하여 애플리케이션을 실행할 수 있다. 
• VMware, Red Hat을 포함한 인프라 공급업체들도 자체 Kubernetes 배포판을 가지고 있다.
• 지원하는 사용 사례 범위가 가장 넓다. 많은 기능과 제삼자 옵션을 가지고 있어서 Swarm보다 더 많은 경우의 수를 다룬다.
• 이미 사용 중인 공급업체가 이미 Docker의 Swarm 제품을 고려하기 전에 Kubernetes를 지원한다. 특히, 산업 전체적으로 Kubernetes를 지원해야 한다는 태도를 취하고 있기 때문에 이미 사용 중인 공급업체들이 Kubernetes를 지원하는 배포판이나 솔루션을 이미 가지고 있을 수 있다. 
• "IBM 제품을 사면 절대로 해고 당하지 않는다." 과거 IBM이 컴퓨팅에서 가장 큰 공급업체였고 하드웨어, 메인프레임, PC를 외주했을 때 인기를 끌었던 시절에 널리 사용되었다. 기술적으로 어떤 공급업체를 선택할지 결정하지 못할 때 안전한 길을 선택하면 IBM을 선택하는 것이었다. 전반적으로, 현재 Kubernetes 플랫폼에 대해서도 그러한 상황이 되었다.

Architecture

다중 마스터 설정에서는 Swarm과 마찬가지로 홀수 개의 마스터가 필요한데 Swarm과 마찬가지로 RAFT 프로토콜을 사용하여 합의를 유지하기 때문이다. 마스터(master)는 제어판이라고도 불리는데 제어판은 클러스터를 관리하는 컨테이너 모음으로 API 서버, 스케줄러, 컨트롤러 매니저, etcd 등을 포함한다. 제어판(control plane)은 마스터 노드가 의사 결정을 내리는 것을 의미한다. Swarm의 일꾼 노드를 Kubernetes에서는 노드(node)라고 한다. 노드도 컨테이너를 실행할 수 있지만 일반적으로 애플리케이션은 노드에 Kubernetes 관리 시스템은 마스터에 유지한다. 노드와 마스터 모두 Docker나 containerd, CRI-O와 같은 다른 컨테이너 런타임 위에서 실행된다.

마스터 내부에서는 시스템을 제어하기 위해 여러 컨테이너를 실행해야 하는데 그 중 하나가 etcd이다. etcd는 키-값 쌍을 위한 분산 저장 시스템이다. Swarm에서 사용되는 RAFT 알고리즘 시스템과 매우 유사하다. etcd는 etcd라는 별도의 제품으로 Kubernetes 없이도 설치할 수 있고 구성 데이터를 저장한다. 또한 동일한 RAFT 프로토콜을 사용하기 때문에 동일한 규칙이 적용된다. 홀수 개수가 필요하다. 한 개로 시작할 수 있지만, 실제 내고장성(fault tolerance)을 위해서는 세 개가 필요한다. 또한, 데이터를 etcd 내부에 저장하고 클러스터를 관리하는 여러 Kubernetes 컨테이너를 실행해야 한다. 

API 서버는 클러스터와 대화하고 클러스터에 명령을 내릴 수 있는 방법이다. 스케줄러(scheduler)는 컨테이너가 노드 상에 포드(pod)라고 불리는 객체 내에서 어디에 어떻게 배치되는지를 제어한다. 

컨트롤러 매니저(controller manager)는 전체 클러스터의 상태와 실행 중인 모든 것을 살펴보고 API를 통해 이를 수행한다. 명령이나 명세를 받아들이고 원하는 작업과 실제로 일어나고 있는 작업 사이의 차이를 결정한다. 기본적으로는 시스템 전체를 살펴보고 현재 일어나고 있는 모든 것을 요청된 작업과 동일하게 만들어내는 루프이다. 

DNS를 제어하기 위한 것이 필요한데 기본적으로 coreDNS가 내장되어 있다. 나중에 네트워크 또는 스토리지와 같은 추가 기능을 얻으면 여기에 더 많은 컨테이너가 실행된다. 모든 노드에서는 에이전트(agent)가 실행되어야 한다. 이는 kubelet이라고 불린다. 또한, 처음에는 네트워크를 제어하기 위해 kube-proxy가 필요하다. 

Docker와 마찬가지로 이 모든 것들은 각각의 역할에 대해 반복된다. 다중 마스터를 사용할 경우 마스터를 동일한 컨테이너들에 모두 설정해야 한다. 워커 노드로 설정한 각 노드도 최소 두 개의 컨테이너(kubelet, kube-proxy)를 갖는다.

update: 2023.12.20