쿠버네티스

1. 개요

쿠버네티스는 그리스어로 '키잡이'를 뜻하며, 구글에서 개발한 컨테이너 오케스트레이션 시스템이다. 2014년 처음 발표되었으며, 2015년 7월 v1.0 버전이 출시되었다. 클라우드 네이티브 컴퓨팅 재단(CNCF)의 시드 기술로 제공되었으며, 현재 다양한 버전과 지원 정책을 따른다. 쿠버네티스는 마이크로서비스 기반 애플리케이션 호스팅에 주로 사용되며, 컨트롤 플레인과 노드로 구성된 아키텍처를 가진다. 주요 개념으로는 파드, 서비스, 볼륨, 네임스페이스 등이 있으며, API를 통해 확장 가능하다. 다양한 배포판이 존재하며, 국내에서도 금융, 통신, e-커머스 등 다양한 분야에서 활발하게 도입되고 있다.

2. 역사

쿠버네티스(κυβερνήτης^{고대 그리스어})는 그리스어로 키잡이를 뜻하며, 조 베다(Joe Beda), 브렌던 번스(Brendan Burns), 크레이그 맥러키(Craig McLuckie)가 설립했고, 브라이언 그랜트(Brian Grant), 팀 호킨(Tim Hockin) 등 다른 구글 엔지니어들이 빠르게 개발에 동참했다. 2014년 중순에 구글이 처음 발표했다. 쿠버네티스의 개발과 설계는 구글의 보그(Borg) 시스템의 영향을 크게 받았으며, 이전 보그 프로젝트의 주요 기여자 다수가 개발에 참여했다. 구글 내 쿠버네티스의 원래 코드명은 프로젝트 세븐이었는데, 이는 스타 트렉의 보그 캐릭터를 참조한 것이다.

2015년 7월 21일, 쿠버네티스 v1.0이 출시되었다. 같은 날 구글은 리눅스 재단과 협력하여 클라우드 네이티브 컴퓨팅 재단(CNCF)을 설립하고, 쿠버네티스를 시드 기술(seed technology)로 제공했다. 2018년 3월 6일, 쿠버네티스 프로젝트는 깃허브에서 커밋 순위 9위를 기록했으며, 개발자와 이슈 수에서는 리눅스 커널에 이어 2위를 차지했다.

쿠버네티스는 v1.18까지 N-2 지원 정책(최근 3개 마이너 버전 지원)을 따랐고, v1.19부터 N-3 지원 정책(최근 4개 마이너 버전 지원)을 따른다.

2.1. 개발 배경

쿠버네티스(κυβερνήτης^{고대 그리스어})는 2014년 구글의 조 베다(Joe Beda), 브렌던 번스(Brendan Burns), 크레이그 맥러키(Craig McLuckie)가 개발을 시작했으며, 브라이언 그랜트(Brian Grant), 팀 호킨(Tim Hockin) 등 다른 구글 엔지니어들도 빠르게 개발에 동참하였다.

쿠버네티스의 개발과 설계는 구글의 Borg 시스템의 영향을 크게 받았으며, Borg 프로젝트에 참여했던 다수의 엔지니어들이 쿠버네티스 개발에 기여했다. 구글 내부에서 쿠버네티스의 코드명은 '프로젝트 세븐'이었는데, 이는 스타 트렉의 등장인물인 '세븐 오브 나인'에서 유래했다. 쿠버네티스 로고의 바퀴살이 7개인 것도 이 코드명과 관련이 있다.

2015년 7월 21일, 쿠버네티스 1.0 버전이 출시되었다.

2.2. 클라우드 네이티브 컴퓨팅 재단 (CNCF)

2015년 7월 21일 쿠버네티스 1.0 출시와 함께, 구글은 리눅스 재단과 협력하여 클라우드 네이티브 컴퓨팅 재단(CNCF)을 설립하고 쿠버네티스를 시드 기술로 제공했다.

2.3. 주요 버전 및 지원

쿠버네티스는 초기에 N-2 지원 정책(최근 3개 마이너 버전 지원)을 따랐으나, v1.19부터 N-3 지원 정책(최근 4개 마이너 버전 지원)으로 변경되었다.

아래 차트는 각 릴리스가 지원되는 기간을 시각화한 것이다.


ImageSize = width:1000 height:auto barincrement:35
PlotArea = left:100 right:50 bottom:30 top:10

DateFormat = dd/mm/yyyy
Period = from:01/12/2018 till:28/10/2025
TimeAxis = orientation:horizontal
ScaleMajor = unit:year increment:1 start:2019
ScaleMinor = unit:month increment:1 start:01/01/2019

Define $dx = 25 # shift text to right side of bar

Colors =
id:out_of_support value:rgb(0.992,0.702,0.671) legend:Out_of_support
id:in-support value:rgb(0.996,0.973,0.776) legend:In_support
id:latest value:rgb(0.831,0.957,0.706) legend:Latest_stable_version
id:prerelease value:rgb(0.996,0.82,0.627) legend:Preview_version

PlotData=
mark:(line,black)
fontsize:S
bar:1.31.x from:13/08/2024 till:28/10/2025 text:1.31.x color:latest
bar:1.30.x from:17/04/2024 till:28/06/2025 text:1.30.x color:in-support
bar:1.29.x from:13/12/2023 till:28/02/2025 text:1.29.x color:in-support
bar:1.28.x from:15/08/2023 till:28/10/2024 text:1.28.x color:in-support
bar:1.27.x from:11/04/2023 till:30/05/2024 text:1.27.x color:out_of_support
bar:1.26.x from:09/12/2022 till:24/02/2024 text:1.26.x color:out_of_support
bar:1.25.x from:23/08/2022 till:27/10/2023 text:1.25.x color:out_of_support
bar:1.24.x from:03/05/2022 till:28/07/2023 text:1.24.x color:out_of_support
bar:1.23.x from:07/12/2021 till:28/02/2023 text:1.23.x color:out_of_support
bar:1.22.x from:04/08/2021 till:28/10/2022 text:1.22.x color:out_of_support
bar:1.21.x from:08/04/2021 till:28/06/2022 text:1.21.x color:out_of_support
bar:1.20.x from:08/12/2020 till:28/02/2022 text:1.20.x color:out_of_support
bar:1.19.x from:26/08/2020 till:28/10/2021 text:1.19.x color:out_of_support
bar:1.18.x from:25/03/2020 till:30/04/2021 text:1.18.x color:out_of_support
bar:1.17.x from:09/12/2019 till:30/01/2021 text:1.17.x color:out_of_support
bar:1.16.x from:18/09/2019 till:25/08/2020 text:1.16.x color:out_of_support
bar:1.15.x from:19/06/2019 till:23/03/2020 text:1.15.x color:out_of_support
bar:1.14.x from:25/03/2019 till:09/12/2019 text:1.14.x color:out_of_support
bar:1.13.x from:03/12/2018 till:18/09/2019 text:1.13.x color:out_of_support

3. 개념

쿠버네티스는 CPU, 메모리 또는 사용자 정의 지표를 기반으로 애플리케이션을 배포, 유지 관리 및 확장하는 메커니즘을 제공한다. 쿠버네티스는 느슨하게 결합되어 있으며 다양한 워크로드의 요구 사항을 충족하도록 확장 가능하다. 쿠버네티스에서 실행되는 내부 구성 요소, 확장 및 컨테이너는 쿠버네티스 API에 의존한다. 이 플랫폼은 리소스를 객체로 정의하여 컴퓨팅 및 스토리지 리소스에 대한 제어력을 행사하며, 이후 해당 객체로 관리할 수 있다.

3.1. 기본 구성 요소

쿠버네티스는 프라이머리/레플리카 구조를 따른다. 쿠버네티스의 구성 요소는 개별 노드를 관리하는 구성 요소들과 컨트롤 플레인(control plane)의 일부인 구성 요소들로 나눌 수 있다.

쿠버네티스는 주/복제 아키텍처를 따르며, 다음과 같은 구성 요소로 이루어져 있다.

* 컨트롤 플레인(Control Plane): 클러스터 전체를 관리하고 제어하는 핵심 구성 요소이다.
* etcd
* API 서버
* 스케줄러
* 컨트롤러
* 컨트롤러 매니저
* 노드(Node): 실제 컨테이너가 실행되는 서버이다. 워커(worker) 또는 미니언(minion)이라고도 한다.
* kubelet
* 컨테이너 런타임
* kube-proxy

== 컨트롤 플레인 ==
쿠버네티스 마스터 노드는 클러스터의 쿠버네티스 컨트롤 플레인을 처리하여 워크로드를 관리하고 시스템 전체의 통신을 지시한다. 쿠버네티스 컨트롤 플레인은 TLS 암호화, RBAC, 강력한 인증 방법, 네트워크 분리 등 각자 고유한 프로세스를 가진 다양한 구성 요소로 구성되며, 단일 마스터 노드 또는 여러 마스터에서 고가용성 클러스터를 지원하도록 실행될 수 있다.

=== etcd ===
etcd는 영속적이고 가벼우며 분산된 키-값 데이터 저장소이다. (원래 Container Linux를 위해 개발되었다). 클러스터의 구성 데이터를 안정적으로 저장하며, 특정 시점의 클러스터 전체 상태를 나타낸다. etcd는 네트워크 분할(CAP 정리 참조) 발생 시 가용성보다 일관성을 선호한다. 이 일관성은 서비스를 올바르게 스케줄링하고 운영하는 데 매우 중요하다.

=== API 서버 ===
API 서버는 쿠버네티스 API를 HTTP를 통한 JSON을 사용하여 제공하며, 이는 쿠버네티스에 대한 내부 및 외부 인터페이스를 모두 제공한다. API 서버는 REST 요청을 처리하고, 검증하며, etcd에서 API 객체의 상태를 업데이트하여 클라이언트가 작업 부하 및 컨테이너를 워커 노드 전체에서 구성할 수 있도록 한다. API 서버는 etcd의 watch API를 사용하여 클러스터를 모니터링하고, 중요한 구성 변경 사항을 롤아웃하거나, etcd에 선언된 대로 클러스터 상태의 모든 발산을 원하는 상태로 복원한다.

예를 들어, 운영자는 특정 "파드"(아래 참조)의 세 개의 인스턴스가 실행되어야 한다고 지정할 수 있으며, etcd는 이 사실을 저장한다. 만약 배포 컨트롤러가 단 두 개의 인스턴스만 실행 중임을 발견하면(etcd 선언과 충돌), 해당 파드의 추가 인스턴스 생성을 예약한다.

=== 스케줄러 ===
스케줄러는 스케줄링되지 않은 파드(스케줄링될 워크로드의 기본 단위)가 실행될 노드를 자원 가용성 및 기타 제약 조건에 따라 선택하는 확장 가능한 구성 요소이다. 스케줄러는 각 노드의 자원 할당을 추적하여 워크로드가 사용 가능한 자원을 초과하여 스케줄링되지 않도록 한다. 이를 위해 스케줄러는 자원 요구 사항, 자원 가용성 및 서비스 품질, 선호도/반선호도 요구 사항, 데이터 지역성과 같은 사용자가 제공한 기타 제약 조건 또는 정책 지시 사항을 알아야 한다. 스케줄러의 역할은 자원 "공급"을 워크로드 "수요"에 일치시키는 것이다.

쿠버네티스는 단일 클러스터 내에서 여러 스케줄러를 실행할 수 있다. 따라서 스케줄러 플러그인은 쿠버네티스 스케줄링 프레임워크를 준수하는 한, 별도의 스케줄러로 실행하여 기본 스케줄러에 대한 인 프로세스 확장으로 개발 및 설치할 수 있다.

=== 컨트롤러 ===
컨트롤러는 실제 클러스터 상태를 원하는 상태로 유지하는 조정 루프이며, 관리하는 리소스(예: 파드 또는 서비스 엔드포인트)를 생성, 업데이트 및 삭제하기 위해 API 서버와 통신한다.

예시로, 레플리카셋(ReplicaSet) 컨트롤러는 클러스터 전체에서 지정된 수의 파드 복제본을 실행하여 복제 및 스케일링을 처리한다. 이 컨트롤러는 또한 기본 노드에 장애가 발생할 경우 대체 파드를 생성하는 역할도 한다. 핵심 쿠버네티스 시스템의 다른 컨트롤러로는 모든 머신(또는 일부 머신)에서 정확히 하나의 파드를 실행하기 위한 데몬셋(DaemonSet) 컨트롤러와 완료될 때까지 실행되는 파드(예: 배치 작업의 일부)를 실행하기 위한 잡(Job) 컨트롤러가 있다. 레이블 선택기는 컨트롤러가 관리하는 파드 집합을 지정하는 컨트롤러 정의의 일부를 형성하는 경우가 많다.

=== 컨트롤러 매니저 ===
컨트롤러 매니저는 여러 핵심 쿠버네티스 컨트롤러(위에 설명된 예제 포함)를 관리하는 단일 프로세스이며, 표준 쿠버네티스 설치의 일부로 배포되며 노드 손실에 대응한다. 사용자 정의 컨트롤러도 클러스터에 설치하여 사용자 정의 리소스와 함께 사용될 때 쿠버네티스의 동작 및 API를 더욱 확장할 수 있다.

== 노드 ==
노드는 컨테이너(워크로드)가 배치되는 머신으로, 워커 또는 미니언이라고도 한다. 클러스터의 모든 노드는 컨테이너 런타임 시스템을 실행해야 하며, 이러한 컨테이너의 기본 네트워크 구성을 위한 통신을 위해 아래 언급된 구성 요소를 실행해야 한다.

=== Kubelet ===
Kubelet은 각 노드의 실행 상태를 책임지며, 노드 내의 모든 컨테이너가 정상적인 상태임을 보장한다. 컨트롤 플레인의 지시에 따라 애플리케이션 컨테이너 그룹을 시작, 중지, 관리하고, 파드로 구성한다.

Kubelet은 파드의 상태를 모니터링하고, 지정된 상태에서 벗어난 것을 감지하면, 파드를 동일한 노드에 자동으로 재배포한다. 노드의 상태는 몇 초마다 하트비트 메시지로 마스터에게 전송된다. 마스터가 노드의 장애를 감지하면 즉시, Replication Controller가 이 상태를 확인하고, 다른 정상 상태의 노드에서 파드를 새로 시작한다.

=== 컨테이너 ===
컨테이너는 파드 안에 위치한다. 컨테이너는 가장 낮은 수준의 마이크로서비스로, 실행 중인 애플리케이션, 라이브러리 및 해당 종속성을 저장한다. 컨테이너는 외부 IP 주소를 할당하여 외부에 공개할 수도 있다. 쿠버네티스는 최초 버전부터 도커 컨테이너를 지원해 왔으며, 2016년 7월에는 rkt 컨테이너 엔진이 추가되었다.

=== Kube-proxy ===
Kube-proxy는 네트워크 프록시 및 로드 밸런서의 구현체이며, 서비스 추상화 및 기타 네트워크 작업을 지원한다. 트래픽 라우팅을 담당하며, 수신된 요청의 IP 주소와 포트 번호를 기반으로 적절한 컨테이너로 라우팅한다.

3.2. 핵심 개념

쿠버네티스는 배포, 유지 관리, 확장을 위한 기본 단위("프리미티브")들을 정의한다. 이러한 프리미티브는 CPU, 메모리, 사용자 정의 지표 등을 기반으로 애플리케이션을 관리한다. 쿠버네티스는 느슨하게 결합되어 다양한 워크로드를 지원하며, 쿠버네티스 API를 통해 확장 가능하다. 리소스는 "오브젝트"로 정의되어 관리된다.

* 파드 (Pod): 쿠버네티스에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 포함한다. 같은 파드 내 컨테이너는 리소스를 공유하며, 동일한 호스트 머신에 배포된다. 각 파드는 고유한 IP 주소를 가지지만, 파드 IP 주소는 일시적이므로 직접 참조해서는 안 되며, 대신 서비스를 통해 접근해야 한다.
* 서비스 (Service): 여러 파드 집합에 대한 단일 접근 지점을 제공한다. 서비스는 레이블 셀렉터로 정의되며, 안정적인 IP 주소와 DNS 이름을 할당받는다. 서비스는 라운드 로빈 방식으로 트래픽을 로드 밸런싱하며, 클러스터 내부 또는 외부에 노출될 수 있다.
* 볼륨 (Volume): 파드 내 컨테이너에 영구 저장 공간을 제공한다. 파드가 재시작되어도 데이터는 유지되며, 컨테이너 간 공유 디스크 공간으로 사용될 수 있다. 볼륨은 다른 볼륨에 마운트되거나 연결될 수 없지만, 동일한 볼륨은 다른 컨테이너에서 다른 위치에 마운트할 수 있다.
* 네임스페이스 (Namespace): 클러스터 내 리소스를 논리적으로 분리하는 데 사용된다. 여러 팀이나 프로젝트에서 사용하거나 개발, 테스트, 프로덕션 환경을 분리하는 데 사용될 수 있다.
* ConfigMaps 및 Secrets: 구성 정보와 민감한 정보를 관리하는 데 사용된다. ConfigMaps는 일반적인 구성 정보를, Secrets는 비밀번호, 인증서 등과 같은 기밀 데이터를 저장하는 데 사용된다. 이 데이터는 환경 변수나 볼륨을 통해 파드에서 접근할 수 있다.
* 레이블 (Label) 및 셀렉터 (Selector): 리소스를 분류하고 선택하는 데 사용된다. 레이블은 키-값 쌍으로, 파드, 노드 등 모든 API 객체에 부착할 수 있다. 레이블 셀렉터는 레이블에 대한 쿼리를 통해 일치하는 객체를 찾는다. 이를 통해 블루-그린 배포나 A/B 테스트와 같은 배포 패턴을 지원할 수 있다. 필드 셀렉터는 리소스의 속성 값을 기반으로 리소스를 선택할 수 있게 해준다.

3.3. 워크로드 관리

쿠버네티스는 파드 외에도 다양한 워크로드 관리 추상화를 제공한다. 이를 통해 사용자는 개별 파드를 직접 관리하는 대신, 이러한 상위 수준의 추상화를 선언적으로 정의하고 관리할 수 있다.

* ReplicaSet은 주어진 시점에 실행 중인 안정적인 레플리카(replica) 파드 집합을 유지한다. 지정된 수의 동일한 파드의 가용성을 보장하는 데 사용된다. ReplicaSet은 쿠버네티스가 주어진 파드에 대해 선언된 인스턴스 수를 유지하도록 하는 그룹화 메커니즘이라고 할 수 있다.
* ReplicationController는 ReplicaSet과 유사하게 항상 원하는 수의 파드 레플리카가 있도록 보장한다. ReplicationController는 ReplicaSet의 이전 버전이었지만, 집합 기반 레이블 셀렉터를 사용하기 위해 결국 ReplicaSet으로 대체되었다.
* Deployment는 ReplicaSet을 위한 상위 수준의 관리 메커니즘이다. ReplicaSet 컨트롤러가 ReplicaSet의 크기를 관리하는 반면, Deployment 컨트롤러는 ReplicaSet에 발생하는 업데이트 롤아웃, 롤백 등을 관리한다.
* StatefulSet은 파드의 인스턴스 간의 고유성과 순서를 적용하는 컨트롤러이며, 상태 저장 애플리케이션(예: 데이터베이스)을 실행하는 데 사용될 수 있다. 상태 비저장 애플리케이션의 확장은 실행 중인 파드를 추가하는 문제일 뿐이지만, 상태 저장 워크로드를 확장하는 것은 더 어렵다. 파드가 다시 시작될 경우 상태를 보존해야 하기 때문이다. 아파치 카프카(Apache Kafka)와 같은 애플리케이션은 브로커 간에 데이터를 분산하므로 인스턴스 고유성이 중요하다.

4. API

쿠버네티스 컨트롤 플레인의 핵심은 API 서버이다. API 서버는 HTTP 상의 JSON을 활용하는 쿠버네티스 API 서버로, 쿠버네티스에 대한 내부 및 외부 인터페이스를 모두 제공한다. API 서버는 REST 요청을 처리하고 검증하며, etcd에 저장된 API 객체의 상태를 업데이트한다. 이를 통해 클라이언트는 워커 노드 전체에 걸쳐 워크로드와 컨테이너를 설정할 수 있다.

동일한 API 설계 원칙을 사용하여 쿠버네티스 클러스터를 생성, 구성 및 관리하기 위한 프로그램을 활용하는 API를 정의했는데, 이를 클러스터 API라고 한다.

4.1. API 객체

쿠버네티스에서 API 객체는 시스템의 '의도 기록' 역할을 한다. 모든 객체는 원하는 상태를 나타내는 `spec` 필드와 현재 상태를 나타내는 `status` 필드를 갖는다.

4.2. 사용자 정의 리소스, 컨트롤러 및 오퍼레이터

쿠버네티스 API는 사용자 정의 리소스를 사용하여 확장할 수 있는데, 이는 표준 쿠버네티스 설치에 포함되지 않은 객체를 나타낸다. 이러한 사용자 정의 리소스는 사용자 정의 리소스 정의(CRD)를 통해 선언되며, 현재 실행 중인 클러스터를 종료하거나 다시 시작하지 않고도 동적으로 등록 및 등록 해제할 수 있다.

사용자 정의 컨트롤러는 쿠버네티스 API와 상호 작용하는 또 다른 확장 메커니즘이다. 이는 표준으로 사전 설치된 쿠버네티스 컨트롤러 관리자의 기본 컨트롤러와 유사하게 작동한다. 사용자 정의 컨트롤러는 사용자 정의 리소스와 상호 작용하여 선언적 API를 제공한다. 사용자는 사용자 정의 리소스를 통해 시스템의 원하는 상태를 선언하고, 사용자 정의 컨트롤러는 변경 사항을 관찰하고 조정한다.

사용자 정의 리소스와 사용자 정의 컨트롤러의 조합을 쿠버네티스 오퍼레이터라고 한다. 오퍼레이터는 서비스 또는 서비스 집합을 관리하는 사람의 목표를 캡처하고 자동화를 통해 구현하며, 이러한 자동화를 지원하는 선언적 API를 사용한다. 특정 애플리케이션 및 서비스를 관리하는 사람들은 시스템 작동 방식, 배포 방식, 문제 발생 시 대응 방식에 대한 깊은 지식을 가지고 있다.

오퍼레이터가 해결하는 문제의 예로는 애플리케이션 상태 백업 및 복원, 데이터베이스 스키마 또는 추가 구성 설정과 같은 관련 변경 사항과 함께 애플리케이션 코드 업그레이드 처리가 있다. 클라우드 네이티브 컴퓨팅 재단의 인큐베이션 프로그램에 속한 아르고(Argo), 오픈 정책 에이전트(Open Policy Agent), 이스티오(Istio) 등의 프로젝트는 오퍼레이터 패턴을 따라 쿠버네티스를 확장한다.

4.3. API 보안

쿠버네티스는 API 접근 제어를 위해 다양한 전략을 사용한다. API 서버는 TCP 포트에서 HTTPS 트래픽을 수신하고 CA 인증서를 사용하여 TLS 보안을 적용한다.

쿠버네티스 API 서버는 여러 인증 방식을 지원한다.

* X.509 클라이언트 인증서
* 베어러 토큰
* 서비스 계정 토큰 (프로그램 방식 API 접근용)

일반적으로 사용자는 kubeconfig 파일에 클러스터 URL 정보와 필요한 자격 증명을 명시하고 정의해야 한다. 이 파일은 kubectl 및 공식 쿠버네티스 클라이언트 라이브러리와 같은 다른 쿠버네티스 도구에서 기본적으로 지원된다.

쿠버네티스 API는 다음과 같은 인증 방식도 지원한다.

* 노드 인증 방식: 쿠버네티스가 정상 작동하기 위해 필요한 API 요청의 고정된 작업 목록을 부여한다.
* ABAC 방식: 속성을 결합하는 접근 제어 정책을 정의하여 사용자에게 접근 권한을 부여한다.
* RBAC 방식: 사용자에게 부여된 역할에 따라 접근 권한을 부여하며, 각 역할은 허용되는 작업 목록을 정의한다.
* 웹훅 방식: REST API 서비스에 쿼리를 보내 사용자가 특정 작업을 수행할 권한이 있는지 확인한다.

5. 활용 및 배포판

쿠버네티스는 마이크로서비스 기반 구현을 호스팅하는 방법으로 흔히 사용된다. 쿠버네티스와 관련 도구 생태계가 마이크로서비스 아키텍처의 주요 관심사를 해결하는 데 필요한 모든 기능을 제공하기 때문이다.

다양한 벤더들이 쿠버네티스를 배포하는 쿠버네티스 기반 플랫폼 또는 서비스형 인프라(IaaS)를 제공한다. 이들은 일반적으로 오픈 소스, 상업용 또는 관리형 배포판으로 분류된다. 주요 배포판은 다음과 같다:

5.1. 활용

쿠버네티스는 마이크로서비스 기반 구현을 호스팅하는 방법으로 흔히 사용된다. 쿠버네티스와 관련 도구 생태계가 마이크로서비스 아키텍처의 주요 관심사를 해결하는 데 필요한 모든 기능을 제공하기 때문이다.

5.2. 배포판

다양한 벤더들이 쿠버네티스를 배포하는 쿠버네티스 기반 플랫폼 또는 서비스형 인프라(IaaS)를 제공한다.

이들은 일반적으로 오픈 소스, 상업용 또는 관리형 배포판으로 분류된다. 몇 가지 주요 배포판은 다음과 같다:

* 아마존 EKS-D
* [https://k0sproject.io/ k0s]
* [https://k3s.io/ k3s]
* SUSE Rancher Kubernetes Engine(RKE)
* [https://www.okd.io/ OKD.IO] 레드햇 오픈시프트를 지원하는 쿠버네티스 커뮤니티 배포판
* D2iQ 쿠버네티스 플랫폼
* 미란티스 쿠버네티스 엔진 (구 도커 엔터프라이즈)
* 레드햇 오픈시프트
* VMware 탄주
* 알리바바 클라우드 ACK (알리바바 클라우드 쿠버네티스 컨테이너 서비스)
* 아마존 EKS (탄력적 쿠버네티스 서비스)
* 캐노니컬 MicroK8s 및 Charmed Kubernetes
* 디지털오션 관리형 쿠버네티스 서비스
* 구글 GKE (구글 쿠버네티스 엔진)
* 화웨이 CCE (화웨이 클라우드 컨테이너 엔진)
* IBM 클라우드 쿠버네티스 서비스
* 마이크로소프트 AKS (애저 쿠버네티스 서비스)
* 미란티스 쿠버네티스 엔진, OpsCare Plus 관리 서비스 포함
* 오라클 컨테이너 엔진 for 쿠버네티스
* Platform9 관리형 쿠버네티스
* 윈드리버 시스템즈 윈드리버 스튜디오