<div id="readability-page-1" class="page"><div>
				<p>나름 조회수가 잘 나왔던 저의 블로그 글 중 하나인 <a href="https://coffeewhale.com/apiserver">쿠버네티스 API서버는 정말 그냥 API서버라구욧</a>에서 쿠버네티스 API 서버가 일반적인 API 서버와 크게 다르지 않다는 점을 강조한 내용으로 글을 작성하였었습니다. 이와 연관되어 쿠버네티스의 API가 가지는 중요성에 대해 <a href="https://joshgav.github.io/2021/12/16/kubernetes-isnt-about-containers.html">잘 소개한 글</a>이 있어서 번역해 보았습니다.</p>

<hr>

<p>쿠버네티스는 API에 관한 것입니다. 그 이유에 대해 짧게 설명해 보겠습니다.</p>

<h2 id="먼저-컨테이너가-존재하였습니다">먼저 컨테이너가 존재하였습니다.</h2>

<p>도커는 컨테이너를 위해 만들어졌습니다. 2013년, 복잡한 postgres 명령을 간단한 도커 명령으로 쉽게 프로그램을 실행할 수 있는 점은 많은 개발자들에게 혁신과 같은 것이였습니다. 그들이 알지 못했던 에자일 DevOps에 눈을 뜨기 시작한 것이였죠. 그리고 기쁘게도 점점 더 많은 개발자들이 그들의 빌드 &amp; 운영 표준으로 도커를 채택함에 따라 단순히 한 컴퓨터에서만 잘 되는 것이 아니라 여러 클러스터 시스템에서도 똑같이 잘 동작한다는 사실을 깨닫기 시작했습니다. 그리고 이것은 쿠버네티스 아파치 메소스와 같은 제품들이 나오게 만들었죠. 이들 제품에서는 컨테이너가 가장 중요한 부분을 차지하게 되었습니다. 하지만 제목에서 알 수 있듯이 쿠버네티스의 가장 큰 의의로 컨테이너를 잘 실행 시키는 툴이라고 정의할 수는 없습니다.</p>

<p>또한 쿠버네티스를 어떠한 워크로드도 다 잘 실행 시킬 수 있는 general workload 스케줄러라고도 정의할 수 없습니다. 물론 다양한 워크로드를 효율적으로 스케줄링 할 수 있는 능력은 쿠버네티스의 중요한 기능 중 하나이지만 이것 하나만으로는 쿠버네티스의 성공을 말할 수 없습니다.</p>

<h2 id="그리고-api가-그-다음으로-나왔습니다">그리고 API가 그 다음으로 나왔습니다.</h2>

<p>쿠버네티스가 성공할 수 있었던 가장 큰 이유는 소프트웨어 정의 인프라 서비스(workload 포함, 네트워킹, 스토리지 등)들을 이용할 때 표준화된 프로그래밍 인터페이스를 제공했다는 점입니다. 쿠버네티스는 여러가지 모양과 크기의 워크로드들을 동일한 구조와 표현방법(YAML)으로 소프트웨어를 설계하고 구현하고 운영할 수 있게 명세와 구현이 포함된 완벽한 프레임워크를 제공하였습니다. 바로 선언형으로 정의된 리소스와 그것을 관리하는 컨트롤러로 말이죠.</p>

<p>쿠버네티스 이전의 상황을 생각해 보십시오: 각기 다른 클라우드에서 제공하는 다양한 API들과 그것을 표현하는 방법 그리고 사용 패턴들이 전부 달랐습니다. 하나의 클라우드 플랫폼에서 컴퓨팅 엔진, 블록 스토리지, 네트워크와 object 스토리지를 구성하였고 또 다른 클라우드에서 동일한 작업을 다른 방법으로 구성했어야만 했습니다. 그래서 Terraform과 같은 제품이 이러한 차이점을 극복하고자 나오기도 하였습니다. 하지만 여전히 그 구조는 각기 달랐습니다. AWS를 타게팅한 Terraform의 구조는 Azure에서 그대로 사용할 수 없습니다!</p>

<p>이번에는 쿠버네티스가 초창기부터 제공한 가치가 무엇인지를 생각해 봅시다:</p>

<ul>
  <li>Pod라는 객체를 통해 컴퓨팅 자원을 표준화 하였습니다.</li>
  <li>Service와 Ingress를 통해 가상 네트워킹을 표준화 하였습니다.</li>
  <li>Persistent Volume을 통해 스토리지를, Service Account를 통해 실행 주체(Identity)를 표준화 하였습니다.</li>
</ul>

<p>이러한 표현방법과 규약은 다양한 배포판(EKS, AKS, GKE, on-prem 등)에서도 동일하게 동작합니다. 내부적으로는 이러한 표준들을 자기들만의 클라우드 API로 각각 연결하지만 외부적으로는 전부 동일한 표준을 지킵니다.</p>

<p>쿠버네티스는 소프트웨어 정의된 인프라를 표준 인터페이스로 사용할 수 있게 제공합니다. 다시 말해, 클라우드 서비스들의 표준 API가 된 것입니다.</p>

<h2 id="그리고-더-많은-api들이-나오기-시작하였습니다">그리고 더 많은 API들이 나오기 시작하였습니다.</h2>

<p>잘 정의된 표준 API들을 제공한 것이 쿠버네티스 성공의 핵심이 되었습니다. 이것에 끝나지 않고 쿠버네티스는 어떠한 인프라 리소스도 사용할 수 있게 확장해서 만들 수 있습니다. Custom Resource Definitions (CRDs)라는 리소스가 쿠버네티스 1.7 버전에 나왔습니다. 그리고 이것을 통해 사용자 정의 리소스도 쿠버네티스의 프레임워크를 그대로 활용할 수 있게 만들어줬습니다. CRD를 통해 단순히 미리 정의된 API(computing, network, storage 등)만 요청할 수 있을 뿐만 아니라 database, 배치 작업, 메세지 버스, 디지털 인증서 그리고 상상할 수 있는 모든 리소스를 표준화 할 수 있게 만들었습니다.</p>

<p>리소스 제공자들이 쿠버네티스 CRD API를 통해 다양한 서비스들을 제공하려는 움직임이 많아졌기에, Operator Framework와 SIG API Machinery와 관련된 프로젝트들이 최소한의 노력으로 최대한의 결과를 내기 위해 합쳐지게 되었습니다. Crossplane와 같이 쿠버네티스 API와 다양한 리소스들(RDS, SQS 등)을 매핑 시키는 작업을 수행하는 프로젝트도 생겨나기 시작하였습니다. 그리고 Google과 Red Hat과 같은 쿠버네티스 배포판에서는 점점 더 자신들의 리소스를 쿠버네티스 API로 제공하기 시작하였습니다.</p>

<p>이 모든 것은 쿠버네티스 API가 완벽하다는 것을 말할려고 하는 것이 아닙니다. 단지 이미 사실상 표준(de facto standard)이 되었기 때문에 그것과는 상관 없이 많은 곳에서 사용된다는 것입니다. 많은 개발자들이 사용할 줄 알고 많은 툴들이 그것을 지원하며 많은 클라우드 제공자들이 사용합니다. 비록 단점도 존재하지만 이미 많은 곳에서 사용하기에 그 단점을 상쇄시킵니다.</p>

<p>쿠버네티스 리소스 모델이 점점 더 퍼져감에 따라 이미 컴퓨팅 환경을 전부 쿠버네티스 리소스로 표현하는 것이 가능해졌습니다. 간단한 프로그램을 <code>docker run</code>을 통해 손쉽게 실행할 수 있듯이, <code>kubectl apply -f</code>를 이용하여 분산 어플리케이션을 손쉽게 배포할 수 있게 되었습니다. 그리고 많은 클라우드 제공자가 쿠버네티스를 지원하기 때문에 더 많은 곳에서 쿠버네티스 API가 잘 동작하게 될 것입니다.</p>

<p>쿠버네티스는 단순히 컨테이너를 잘 관리하는 툴이 아닙니다. 쿠버네티스는 API에 관한 것입니다.</p>

                
			</div></div>

커피고래의 노트

hongkunyoo

나름 조회수가 잘 나왔던 저의 블로그 글 중 하나인 쿠버네티스 API서버는 정말 그냥 API서버라구욧에서 쿠버네티스 API 서버가 일반적인 API 서버와 크게 다르지 않다는 점을 강조한 내용으로 글을 작성하였었습니다. 이와 연관되어 쿠버네티스의 API가 가지는 중요성에 대해 잘 소개한 글이 있어서 번역해 보았습니다.

[번역]쿠버네티스는 단순히 컨테이너를 관리하는 툴이 아닙니다.

댓글