상위 질문
타임라인
채팅
관점

쿠버네티스

컨테이너화된 애플리케이션의 자동 디플로이, 스케일링 등을 제공하는 관리시스템 위키백과, 무료 백과사전

Remove ads

쿠버네티스(Kubernetes, 쿠베르네테스, "K8s"[3])는 오픈 소스 컨테이너 오케스트레이션 시스템으로, 소프트웨어 전개, 확장 및 관리를 자동화한다.[4][3] 구글에서 처음 설계했으며, 현재는 전 세계 기여자 커뮤니티에서 유지보수하며, 상표는 클라우드 네이티브 컴퓨팅 재단이 소유한다.

간략 정보 원저자, 개발자 ...

쿠버네티스라는 이름은 그리스어의 κυβερνήτης (kubernḗtēs)에서 유래했으며, '지사', '키잡이' 또는 '파일럿'을 의미한다. 쿠버네티스는 K와 s 사이의 여덟 글자를 세어 K8s로 종종 약칭한다 (누메로님).[5]

쿠버네티스는 하나 이상의 컴퓨터(가상 머신 또는 베어 머신)를 클러스터로 묶어 컨테이너에서 워크로드를 실행할 수 있게 한다. 이는 containerd 및 CRI-O와 같은 다양한 컨테이너 런타임과 함께 작동한다.[6] 모든 크기와 스타일의 워크로드를 실행하고 관리하는 데 적합하여 클라우드 및 데이터 센터에서 널리 채택되었다. 이 플랫폼은 독립 소프트웨어 공급업체(ISV)와 모든 주요 공용 클라우드 공급업체의 호스팅 클라우드 서비스 형태로 여러 배포판이 존재한다.[7]

이 소프트웨어는 컨트롤 플레인과 실제 애플리케이션이 실행되는 노드로 구성된다. 또한 REST 기반 API와 상호 작용하는 데 사용할 수 있는 kubeadm 및 kubectl과 같은 도구를 포함한다.[8]

Remove ads

역사

요약
관점
Thumb
2017년 구글 클라우드 서밋에서 구글 쿠버네티스 엔진 강연

쿠버네티스는 2014년 6월 6일 구글에 의해 발표되었다.[9] 이 프로젝트는 구글 직원인 조 베다, 브렌던 번스, 크레이그 맥클러키에 의해 구상되고 만들어졌다. 곧 빌 아익스, 던 첸, 브라이언 그랜트, 팀 호킨, 다니엘 스미스를 포함한 다른 구글 직원들도 프로젝트 구축을 도왔다.[10][11] 레드햇과 CoreOS와 같은 다른 회사들도 곧 클레이튼 콜먼과 켈시 하이타워와 같은 저명한 기여자들과 함께 이 노력에 동참했다.[9]

쿠버네티스의 설계 및 개발은 구글의 보그 클러스터 관리자에서 영감을 받았으며 프라미스 이론을 기반으로 한다.[12][13] 많은 최고 기여자들이 이전에 보그에서 일했으며,[14][15] 그들은 스타 트렉의 전 보그 캐릭터인 세븐 오브 나인[16]의 이름을 따서 쿠버네티스를 "프로젝트 7"이라고 불렀고, 로고에 7개의 바퀴살을 가진 선박의 바퀴를 넣었다 (팀 호킨이 디자인). C++[14]로 작성된 보그와 달리 쿠버네티스는 Go 언어로 작성되었다.

쿠버네티스는 2014년 6월에 발표되었고, 1.0 버전은 2015년 7월 21일에 출시되었다.[17] 구글은 리눅스 재단과 협력하여 클라우드 네이티브 컴퓨팅 재단 (CNCF)[18]을 설립하고 쿠버네티스를 시드 기술로 제공했다.

구글은 이미 관리형 쿠버네티스 서비스인 GKE를 제공하고 있었고, 레드햇은 2014년 쿠버네티스 프로젝트 시작부터 오픈시프트의 일부로 쿠버네티스를 지원하고 있었다.[19] 2017년, 주요 경쟁사들은 쿠버네티스를 중심으로 모여들었고, 이에 대한 기본 지원을 추가한다고 발표했다.

2018년 3월 6일, 쿠버네티스 프로젝트는 깃허브 프로젝트 중 커밋 수에서 9위, 작성자 및 이슈 수에서 리눅스 커널에 이어 2위를 차지했다.[26]

버전 1.18까지 쿠버네티스는 N-2 지원 정책을 따랐는데, 이는 가장 최근의 세 가지 마이너 버전이 보안 업데이트 및 버그 수정을 받는다는 의미이다.[27] 버전 1.19부터 쿠버네티스는 N-3 지원 정책을 따른다.[28]

Remove ads

개념

요약
관점
Thumb
쿠버네티스 아키텍처 다이어그램

쿠버네티스는 CPU, 메모리[29] 또는 사용자 지정 메트릭에 기반한 애플리케이션을 배포, 유지보수 및 확장하는 메커니즘을 집합적으로 제공하는 일련의 빌딩 블록("프리미티브")을 정의한다.[30] 쿠버네티스는 다양한 워크로드의 요구 사항을 충족하도록 느슨하게 결합되어 있으며 확장 가능하다. 내부 구성 요소뿐만 아니라 쿠버네티스에서 실행되는 확장 및 컨테이너는 쿠버네티스 API에 의존한다.[31][32]

플랫폼은 컴퓨팅 및 스토리지 리소스를 객체로 정의하여 제어하며, 이러한 객체를 관리할 수 있다.

쿠버네티스는 마스터-슬레이브 아키텍처를 따른다. 쿠버네티스 구성 요소는 개별 노드를 관리하는 부분과 컨트롤 플레인의 일부인 부분으로 나눌 수 있다.[31][33]

컨트롤 플레인

쿠버네티스 마스터 노드는 클러스터의 쿠버네티스 컨트롤 플레인을 처리하며, 워크로드를 관리하고 시스템 전체의 통신을 지시한다. 쿠버네티스 컨트롤 플레인은 TLS 암호화, RBAC, 강력한 인증 방법, 네트워크 분리와 같은 다양한 구성 요소로 이루어져 있으며, 각 구성 요소는 자체 프로세스로 단일 마스터 노드 또는 여러 마스터에서 실행되어 고가용성 클러스터를 지원할 수 있다.[33] 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 다음과 같다.[34]

Etcd

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

API 서버

API 서버는 HTTP를 통해 JSON을 사용하여 쿠버네티스 API를 제공하며, 이는 쿠버네티스에 대한 내부 및 외부 인터페이스를 모두 제공한다.[31][36] API 서버는 REST 요청을 처리하고 유효성을 검사하며, etcd에 있는 API 객체의 상태를 업데이트하여 클라이언트가 워크로드와 컨테이너를 워커 노드에 걸쳐 구성할 수 있도록 한다.[37] API 서버는 etcd의 워치 API를 사용하여 클러스터를 모니터링하고, 중요한 구성 변경 사항을 롤아웃하거나, 클러스터 상태의 불일치를 etcd에 선언된 원하는 상태로 되돌린다.

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

스케줄러

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

쿠버네티스는 단일 클러스터 내에서 여러 스케줄러를 실행할 수 있도록 한다. 따라서 스케줄러 플러그인은 쿠버네티스 스케줄링 프레임워크를 준수하는 한 별도의 스케줄러로 실행하여 기본 바닐라 스케줄러의 인-프로세스 확장으로 개발 및 설치될 수 있다.[40] 이를 통해 클러스터 관리자는 필요에 따라 기본 쿠버네티스 스케줄러의 동작을 확장하거나 수정할 수 있다.

컨트롤러

컨트롤러는 API 서버와 통신하여 관리하는 리소스(예: 파드 또는 서비스 엔드포인트)를 생성, 업데이트 및 삭제함으로써 실제 클러스터 상태를 원하는 상태로 이끄는 조정 루프이다.[41][36]

컨트롤러의 예로는 ReplicaSet 컨트롤러가 있는데, 이는 클러스터 전반에 걸쳐 지정된 수의 파드 복사본을 실행하여 복제 및 확장을 처리한다. 이 컨트롤러는 또한 기본 노드가 실패할 경우 대체 파드를 생성하는 것을 처리한다.[41] 코어 쿠버네티스 시스템의 일부인 다른 컨트롤러로는 모든 머신(또는 머신의 일부 하위 집합)에 정확히 하나의 파드를 실행하는 DaemonSet 컨트롤러, 그리고 완료될 때까지 실행되는 파드(예: 배치 작업의 일부)를 실행하는 Job 컨트롤러가 있다.[42] 레이블 선택기는 컨트롤러가 관리하는 파드 집합을 지정하는 컨트롤러 정의의 일부를 형성하는 경우가 많다.[43]

컨트롤러 매니저는 여러 코어 쿠버네티스 컨트롤러(위에서 설명한 예시 포함)를 관리하고, 표준 쿠버네티스 설치의 일부로 배포되며, 노드 손실에 대응하는 단일 프로세스이다.[34]

클러스터에는 사용자 정의 컨트롤러를 설치할 수도 있으며, 이를 통해 사용자 정의 리소스(사용자 정의 리소스, 컨트롤러 및 오퍼레이터 아래 참조)와 함께 사용될 때 쿠버네티스의 동작 및 API를 더욱 확장할 수 있다.

노드

노드 또는 워커, 미니언으로 알려진 것은 컨테이너(워크로드)가 배포되는 머신이다. 클러스터의 모든 노드는 기본 네트워크 구성을 위해 아래 언급된 구성 요소뿐만 아니라 컨테이너 런타임을 실행해야 한다.

kubelet

kubelet은 각 노드의 실행 상태를 담당하며, 노드의 모든 컨테이너가 정상 상태인지 확인한다. 컨트롤 플레인의 지시에 따라 파드로 구성된 애플리케이션 컨테이너를 시작, 중지 및 유지 관리한다.[31][44] kubelet은 파드의 상태를 모니터링하며, 원하는 상태가 아니면 해당 파드를 동일한 노드에 재배포한다. 노드 상태는 하트비트 메시지를 통해 몇 초마다 API 서버로 전달된다. 컨트롤 플레인이 노드 실패를 감지하면, 상위 수준 컨트롤러가 이 상태 변화를 감지하고 다른 정상 노드에 파드를 실행할 것으로 예상된다.[45]

컨테이너 런타임

컨테이너 런타임은 컨테이너의 시작, 조정 및 종료를 포함하여 컨테이너의 수명 주기를 담당한다. kubelet은 컨테이너 런타임 인터페이스(CRI)를 통해 컨테이너 런타임과 상호 작용하며,[46][47] 이는 코어 쿠버네티스 유지 관리를 실제 CRI 구현과 분리시킨다.

원래 kubelet은 "dockershim"을 통해 도커 런타임과만 연동되었다.[48] 그러나 2020년 11월[49]부터 2022년 4월까지 쿠버네티스는 컨테이너 런타임 인터페이스(CRI)를 준수하는 런타임으로 shim을 직접 컨테이너를 통해 또는 도커를 대체하는 런타임으로 교체하는 것을 선호하여 더 이상 지원하지 않는다.[50][46][51] 2022년 5월 v1.24가 출시되면서 "dockershim"은 완전히 제거되었다.[52]

kubelet과 호환되는 인기 있는 컨테이너 런타임의 예로는 containerd(처음에는 Docker를 통해 지원됨)와 CRI-O가 있다.

kube-proxy

kube-proxy는 네트워크 프록시 및 로드 밸런서의 구현이며, 다른 네트워킹 작업과 함께 서비스 추상화를 지원한다.[31] 이는 들어오는 요청의 IP 및 포트 번호를 기반으로 적절한 컨테이너로 트래픽을 라우팅하는 역할을 한다.

네임스페이스

쿠버네티스에서 네임스페이스는 관리하는 리소스를 서로 다른 비겹치는 컬렉션으로 분리하는 데 사용된다.[53] 이는 여러 팀, 프로젝트, 또는 개발, 테스트, 프로덕션과 같은 환경을 분리해야 하는 많은 사용자가 있는 환경에서 사용하도록 고안되었다.

파드

쿠버네티스의 기본 스케줄링 단위는 파드이다.[54] 파드는 동일한 노드에 함께 위치하도록 보장되는 하나 이상의 컨테이너로 구성된다.[31] 쿠버네티스의 각 파드에는 클러스터 내에서 고유한 IP 주소가 할당되어, 애플리케이션이 충돌 위험 없이 포트를 사용할 수 있도록 한다.[55] 파드 내의 모든 컨테이너는 서로를 참조할 수 있다.

컨테이너는 파드 내부에 존재한다. 컨테이너는 실행 중인 애플리케이션, 라이브러리 및 해당 종속성을 포함하는 마이크로 서비스의 최하위 계층이다.

워크로드

쿠버네티스는 단순 파드보다 더 높은 수준의 여러 워크로드 추상화를 지원한다. 이를 통해 사용자는 개별 파드를 직접 관리할 필요 없이 이러한 고수준 추상화를 선언적으로 정의하고 관리할 수 있다. 쿠버네티스의 표준 설치에서 지원되는 이러한 추상화 중 일부는 아래에 설명되어 있다.

ReplicaSet, ReplicationController 및 Deployment

ReplicaSet의 목적은 언제든지 안정적인 복제 파드 집합을 유지하는 것이다. 따라서 이는 지정된 수의 동일한 파드 가용성을 보장하는 데 자주 사용된다.[56] ReplicaSet은 또한 쿠버네티스가 주어진 파드에 대해 선언된 인스턴스 수를 유지하도록 하는 그룹화 메커니즘이라고도 할 수 있다. ReplicaSet의 정의는 선택기를 사용하며, 이 선택기 평가는 이와 관련된 모든 파드를 식별하는 결과를 가져온다.

ReplicationController는 ReplicaSet과 유사하게 동일한 목적을 가지며, ReplicaSet과 유사하게 동작하여 항상 지정된 수의 파드 복제본이 원하는 대로 존재하도록 보장한다. ReplicationController 워크로드는 ReplicaSet의 선행자였지만, 집합 기반 레이블 선택기를 사용하기 위해 결국 ReplicaSet을 선호하여 더 이상 사용되지 않게 되었다.[56]

배포(Deployments)는 ReplicaSet을 위한 상위 수준 관리 메커니즘이다. ReplicaSet 컨트롤러가 ReplicaSet의 규모를 관리하는 반면, 배포 컨트롤러는 ReplicaSet에 일어나는 일, 즉 업데이트가 롤아웃되어야 하는지, 롤백되어야 하는지 등을 관리한다. 배포가 스케일 업 또는 스케일 다운될 때, 이는 ReplicaSet의 선언 변경을 초래하며, 이 선언된 상태의 변경은 ReplicaSet 컨트롤러에 의해 관리된다.[38]

StatefulSet

StatefulSet은 파드 인스턴스 간의 고유성과 순서 속성을 강제하는 컨트롤러로, 상태 저장 애플리케이션을 실행하는 데 사용할 수 있다.[57] 무상태 애플리케이션을 확장하는 것은 단순히 실행 중인 파드를 추가하는 문제이지만, 상태 저장 워크로드의 경우 파드가 다시 시작될 때 상태를 보존해야 하므로 더 어렵다. 애플리케이션이 스케일 업 또는 다운되면 상태를 재분배해야 할 수 있다.

데이터베이스는 상태 저장 워크로드의 한 예이다. 고가용성 모드로 실행될 때, 많은 데이터베이스는 주 인스턴스와 보조 인스턴스의 개념을 포함한다. 이 경우 인스턴스 순서의 개념이 중요하다. 아파치 카프카와 같은 다른 애플리케이션은 데이터를 브로커 간에 분산시키므로, 한 브로커가 다른 브로커와 동일하지 않다. 이 경우 인스턴스 고유성의 개념이 중요하다.

DaemonSet

DaemonSet은 클러스터의 모든 단일 노드에 파드가 생성되도록 보장하는 역할을 한다.[58] 일반적으로 대부분의 워크로드는 애플리케이션이 필요로 하는 가용성 및 성능 요구 사항에 따라 원하는 복제본 수에 반응하여 확장된다. 그러나 다른 시나리오에서는 클러스터의 모든 단일 노드에 파드를 배포해야 할 수도 있으며, 노드가 추가될 때 총 파드 수가 늘어나고 노드가 제거될 때 쓰레기 수집된다. 이는 로그 수집, 인그레스 컨트롤러 및 스토리지 서비스와 같이 워크로드가 실제 노드 또는 호스트 머신에 대한 종속성을 갖는 사용 사례에 특히 유용하다.

서비스

Thumb
쿠버네티스 클러스터에서 서비스가 파드 네트워킹과 상호 작용하는 방식을 보여주는 간략화된 보기

쿠버네티스 서비스는 다층 애플리케이션의 한 계층처럼 함께 작동하는 파드 집합이다. 서비스를 구성하는 파드 집합은 레이블 선택기로 정의된다.[31] 쿠버네티스는 환경 변수 또는 쿠버네티스 DNS를 사용하여 두 가지 서비스 검색 모드를 제공한다.[59] 서비스 검색은 서비스에 안정적인 IP 주소와 DNS 이름을 할당하고, 해당 IP 주소의 네트워크 연결에 대한 트래픽을 선택기와 일치하는 파드들 간에 라운드 로빈 방식으로 로드 밸런싱한다(심지어 실패로 인해 파드가 머신 간에 이동하더라도).[55] 기본적으로 서비스는 클러스터 내부에 노출된다(예: 백엔드 파드는 서비스로 그룹화될 수 있으며, 프론트엔드 파드의 요청은 이들 사이에 로드 밸런싱된다). 하지만 서비스는 클러스터 외부에도 노출될 수 있다(예: 클라이언트가 프론트엔드 파드에 접근할 수 있도록).[60]

볼륨

쿠버네티스 컨테이너의 파일 시스템은 기본적으로 임시 스토리지를 제공한다. 이는 파드가 재시작되면 해당 컨테이너의 모든 데이터가 사라지므로, 사소한 애플리케이션을 제외하고는 이러한 형태의 스토리지는 상당히 제한적이라는 의미이다. 쿠버네티스 볼륨[61]은 파드 자체의 수명 동안 존재하는 영구 스토리지를 제공한다. 이 스토리지는 파드 내 컨테이너를 위한 공유 디스크 공간으로도 사용될 수 있다. 볼륨은 컨테이너 내의 특정 마운트 지점에 마운트되며, 이는 파드 구성에 의해 정의되고 다른 볼륨에 마운트되거나 다른 볼륨과 연결될 수 없다. 동일한 볼륨은 다른 컨테이너에 의해 파일 시스템 트리의 다른 지점에 마운트될 수 있다.

ConfigMap 및 Secret

일반적인 애플리케이션 과제는 구성 정보를 저장하고 관리하는 방법을 결정하는 것인데, 이 중 일부는 민감한 데이터를 포함할 수 있다. 구성 데이터는 개별 속성과 같은 세밀한 정보부터 전체 JSON 또는 XML 문서와 같은 일반적인 구성 파일까지 다양할 수 있다. 쿠버네티스는 이러한 필요를 해결하기 위해 ConfigMap 및 Secret으로 알려진 밀접하게 관련된 두 가지 메커니즘을 제공하며, 둘 다 애플리케이션을 재구축하지 않고도 구성 변경을 수행할 수 있도록 한다.

ConfigMap과 Secret의 데이터는 이 객체들이 Deployment를 통해 바인딩된 애플리케이션의 모든 인스턴스에 제공된다. Secret 및 ConfigMap은 해당 노드의 파드가 필요로 할 경우에만 해당 노드로 전송되며, 이 데이터는 노드의 메모리에만 저장된다. Secret 또는 ConfigMap에 의존하는 파드가 삭제되면, 바인딩된 모든 Secret 및 ConfigMap의 메모리 내 복사본도 삭제된다.

ConfigMap 또는 Secret의 데이터는 다음 방법 중 하나를 통해 파드에 접근할 수 있다.[62]

  1. 컨테이너가 시작될 때 kubelet이 ConfigMap에서 사용할 환경 변수로;
  2. 컨테이너의 파일 시스템 내에서 접근 가능한 볼륨 내부에 마운트되며, 컨테이너를 다시 시작하지 않고도 자동 새로 고침을 지원한다.

Secret과 ConfigMap의 가장 큰 차이점은 Secret이 안전하고 기밀 데이터를 포함하도록 특별히 설계되었다는 점이다. 비록 기본적으로 정지 상태에서 암호화되지 않으며, 클러스터 내에서 Secret의 사용을 완전히 보호하기 위해서는 추가 설정이 필요하다.[63] Secret은 종종 인증서, 이미지 레지스트리 작업 자격 증명, 암호 및 SSH 키와 같은 기밀 또는 민감한 데이터를 저장하는 데 사용된다.

레이블 및 선택기

쿠버네티스는 클라이언트(사용자 또는 내부 구성 요소)가 파드 및 노드와 같은 시스템의 모든 API 객체에 레이블이라는 키를 첨부할 수 있도록 한다. 이에 따라 레이블 선택기는 일치하는 객체로 해석되는 레이블에 대한 쿼리이다.[31] 서비스가 정의될 때, 서비스 라우터/로드 밸런서가 트래픽이 라우팅될 파드 인스턴스를 선택하는 데 사용될 레이블 선택기를 정의할 수 있다. 따라서 단순히 파드의 레이블을 변경하거나 서비스의 레이블 선택기를 변경함으로써 어떤 파드가 트래픽을 받고 어떤 파드가 받지 않는지 제어할 수 있으며, 이는 블루-그린 배포 또는 A/B 테스트와 같은 다양한 배포 패턴을 지원하는 데 사용될 수 있다. 서비스가 구현 리소스를 동적으로 활용하는 이 기능은 인프라 내에서 느슨한 결합을 제공한다.

예를 들어, 애플리케이션의 파드에 시스템 tier (예: frontend, backend 등의 값) 및 release_track (예: canary, production 등의 값)에 대한 레이블이 있는 경우, 모든 backend 및 canary 노드에 대한 작업은 다음과 같은 레이블 선택기를 사용할 수 있다.[43]

tier=backend AND release_track=canary

레이블과 마찬가지로 필드 선택기도 쿠버네티스 리소스를 선택할 수 있게 한다. 레이블과 달리 선택은 사용자 정의 분류가 아닌 선택되는 리소스에 내재된 속성 값에 기반한다. metadata.name 및 metadata.namespace는 모든 쿠버네티스 객체에 존재하는 필드 선택기이다. 사용할 수 있는 다른 선택기는 객체/리소스 유형에 따라 달라진다.

애드온

애드온은 쿠버네티스 클러스터 내에서 애플리케이션으로 실행되는 추가 기능이다. 파드는 배포, ReplicationController 등에 의해 관리될 수 있다. 많은 애드온이 있으며, 그 중 몇 가지 중요한 것은 다음과 같다.

DNS
클러스터 DNS는 환경의 다른 DNS 서버 외에 쿠버네티스 서비스를 위한 DNS 레코드를 제공하는 DNS 서버이다. 쿠버네티스에 의해 시작된 컨테이너는 자동으로 이 DNS 서버를 DNS 검색에 포함한다.
웹 UI
이는 쿠버네티스 클러스터를 위한 범용 웹 기반 UI이다. 관리자가 클러스터에서 실행되는 애플리케이션뿐만 아니라 클러스터 자체를 관리하고 문제를 해결할 수 있도록 한다.
리소스 모니터링
컨테이너 리소스 모니터링은 컨테이너에 대한 메트릭을 중앙 데이터베이스에 기록하고, 해당 데이터를 탐색하기 위한 UI를 제공한다.
비용 모니터링
쿠버네티스 비용 모니터링 애플리케이션은 파드, 노드, 네임스페이스 및 레이블별로 비용을 세분화할 수 있도록 한다.
클러스터 수준 로깅
노드 또는 파드 실패 시 이벤트 데이터 손실을 방지하기 위해 컨테이너 로그를 검색/탐색 인터페이스가 있는 중앙 로그 저장소에 저장할 수 있다. 쿠버네티스는 로그 데이터에 대한 기본 스토리지를 제공하지 않지만, 많은 기존 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다.

스토리지

컨테이너는 소프트웨어 이식성을 위한 방법으로 등장했다. 컨테이너는 서비스를 실행하는 데 필요한 모든 패키지를 포함한다. 제공되는 파일 시스템은 컨테이너를 매우 이식성 있게 만들고 개발에서 사용하기 쉽게 한다. 컨테이너는 사소한 구성 변경만으로 또는 전혀 변경 없이 개발에서 테스트 또는 프로덕션으로 이동할 수 있다.

역사적으로 쿠버네티스는 무상태 서비스에만 적합했다. 그러나 많은 애플리케이션에는 영속성이 필요한 데이터베이스가 포함되어 있어 쿠버네티스를 위한 영구 스토리지가 생성되었다. 컨테이너를 위한 영구 스토리지를 구현하는 것은 쿠버네티스 관리자, DevOps 및 클라우드 엔지니어에게 가장 큰 과제 중 하나이다. 컨테이너는 일시적일 수 있지만, 그 데이터는 점점 더 일시적이지 않으므로 컨테이너 종료 또는 하드웨어 장애 발생 시 데이터의 생존을 보장해야 한다. 쿠버네티스 또는 컨테이너화된 애플리케이션으로 컨테이너를 배포할 때, 조직은 영구 스토리지가 필요하다는 것을 종종 깨닫는다. 그들은 데이터베이스, 루트 이미지 및 컨테이너가 사용하는 기타 데이터에 빠르고 안정적인 스토리지를 제공해야 한다.

이러한 상황 외에도 클라우드 네이티브 컴퓨팅 재단 (CNCF)은 쿠버네티스 영구 스토리지에 대한 추가 정보, 특히 컨테이너 연결 스토리지 패턴을 정의하는 데 도움이 되는 블로그를 발행했다. 이 패턴은 쿠버네티스 자체를 스토리지 시스템 또는 서비스의 구성 요소로 사용하는 것으로 생각할 수 있다.[64]

이러한 접근 방식 및 기타 접근 방식의 상대적 인기에 대한 더 많은 정보는 CNCF의 환경 조사를 통해서도 찾을 수 있다. 2019년 가을 현재 OpenEBS (Datacore Software[65]의 Stateful Persistent Storage 플랫폼) 및 Rook (스토리지 오케스트레이션 프로젝트)이 평가 중일 가능성이 가장 높은 두 프로젝트로 나타났다.[66]

컨테이너 연결 스토리지(Container Attached Storage)는 쿠버네티스가 부상하면서 등장한 데이터 스토리지 유형이다. 컨테이너 연결 스토리지 접근 방식 또는 패턴은 특정 기능에 대해 쿠버네티스 자체에 의존하면서, 주로 쿠버네티스에서 실행되는 워크로드에 블록, 파일, 객체 및 인터페이스를 제공한다.[67]

컨테이너 연결 스토리지의 일반적인 속성에는 사용자 정의 리소스 정의와 같은 쿠버네티스 확장 기능 사용, 그리고 스토리지 또는 데이터 관리를 위해 별도로 개발 및 배포되었을 기능에 쿠버네티스 자체를 사용하는 것이 포함된다. 사용자 정의 리소스 정의 또는 쿠버네티스 자체에 의해 제공되는 기능의 예로는 쿠버네티스 자체에 의해 제공되는 재시도 로직, 그리고 일반적으로 사용자 정의 리소스 정의를 통해 제공되는 사용 가능한 스토리지 미디어 및 볼륨 인벤토리 생성 및 유지가 있다.[68][69]

컨테이너 스토리지 인터페이스 (CSI)

쿠버네티스 버전 1.9에서 컨테이너 스토리지 인터페이스(CSI)의 초기 알파 버전이 도입되었다.[70] 이전에는 스토리지 볼륨 플러그인이 쿠버네티스 배포에 포함되어 있었다. 표준화된 CSI를 생성함으로써 외부 스토리지 시스템과 인터페이스하는 데 필요한 코드가 핵심 쿠버네티스 코드베이스에서 분리되었다. 불과 1년 후, CSI 기능은 쿠버네티스에서 일반 가용(GA) 상태가 되었다.[71]

Remove ads

API

요약
관점

쿠버네티스 컨트롤 플레인의 핵심 구성 요소는 API 서버이며, 이 서버는 클러스터의 다른 부분뿐만 아니라 최종 사용자 및 외부 구성 요소에서도 호출할 수 있는 HTTP API를 노출한다. 이 API는 REST API이며 본질적으로 선언적이며, 컨트롤 플레인에 노출되는 것과 동일한 API이다.[72] API 서버는 모든 레코드를 영구적으로 저장하기 위해 etcd를 사용한다.[73]

API 객체

쿠버네티스에서 모든 객체는 클러스터 상태의 "의도 기록" 역할을 하며, 객체를 작성하는 사람이 클러스터가 되기를 원하는 원하는 상태를 정의할 수 있다.[74] 따라서 대부분의 쿠버네티스 객체는 다음과 같은 동일한 중첩 필드 집합을 가진다.

  • spec: 리소스의 원하는 상태를 설명하며, 최종 사용자 또는 다른 상위 수준 컨트롤러에 의해 제어될 수 있다.
  • status: 리소스의 현재 상태를 설명하며, 리소스의 컨트롤러에 의해 적극적으로 업데이트된다.

쿠버네티스의 모든 객체는 동일한 API 규칙을 따른다. 그 중 일부는 다음과 같다.

  • 중첩 객체 필드 metadata 아래에 다음 메타데이터가 있어야 한다.[75]
    • namespace: 객체가 세분화되는 레이블
    • name: 정의된 네임스페이스 내에서 객체를 고유하게 식별하는 문자열
    • uid: 공간과 시간(동일한 이름으로 삭제 및 재생성된 경우에도)을 넘어 동일한 이름을 가진 객체들을 구별할 수 있는 고유한 문자열.
  • metadata.ownerReferences 필드에 정의된 다른 컨트롤러에 의해 관리될 수 있다.[76]
    • 제어 대상 객체의 관리 컨트롤러는 controller 필드에 정의된 대로 최대 하나만 존재한다.
  • 소유자가 삭제되면 가비지 컬렉션될 수 있다.[77]
    • 객체가 삭제되면 모든 종속 객체도 종속적으로 삭제될 수 있다.

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

쿠버네티스 API는 사용자 정의 리소스(Custom Resources)를 사용하여 확장될 수 있으며, 이는 표준 쿠버네티스 설치의 일부가 아닌 객체를 나타낸다. 이러한 사용자 정의 리소스는 사용자 정의 리소스 정의(CRD)를 사용하여 선언된다. CRD는 현재 실행 중인 클러스터를 종료하거나 다시 시작할 필요 없이 동적으로 등록 및 등록 해제될 수 있는 리소스 유형이다.[78]

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

사용자 정의 리소스와 사용자 정의 컨트롤러의 조합은 종종 쿠버네티스 오퍼레이터라고 불린다.[79] 오퍼레이터의 주요 사용 사례는 서비스 또는 서비스 집합을 관리하는 인간 오퍼레이터의 목표를 캡처하고, 자동화를 사용하여 이를 구현하며, 이 자동화를 지원하는 선언적 API를 사용하는 것이다. 특정 애플리케이션 및 서비스를 관리하는 인간 오퍼레이터는 시스템이 어떻게 동작해야 하는지, 어떻게 배포해야 하는지, 문제가 발생할 경우 어떻게 대응해야 하는지에 대한 깊은 지식을 가지고 있다.

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

API 보안

쿠버네티스는 API 접근을 제어하기 위해 다음 전략을 정의한다.[81]

전송 보안

쿠버네티스 API 서버는 전송 계층 보안(TLS)을 CA 인증서를 사용하여 적용하기 위해 TCP 포트에서 HTTPS 트래픽을 수신한다.[34]

쿠버네티스의 이전 버전에서는 API 서버가 HTTP 및 HTTPS 포트에서 모두 수신하는 것을 지원했다(HTTP 포트는 전송 보안이 전혀 없음). 이는 v1.10에서 더 이상 사용되지 않게 되었고, 결국 쿠버네티스 v1.20에서는 지원이 중단되었다.[82]

인증

쿠버네티스 API 서버에 대한 모든 요청은 인증되어야 하며, 다음을 포함한 여러 인증 전략을 지원한다.[83]

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

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

권한 부여

쿠버네티스 API는 다음 권한 부여 모드를 지원한다.[85]

  1. 노드 권한 부여 모드: kubelet이 제대로 작동하기 위해 수행할 수 있는 API 요청 작업의 고정 목록을 부여한다.
  2. 속성 기반 접근 제어(ABAC) 모드: 정의된 접근 제어 정책을 사용하여 속성을 결합함으로써 사용자에게 접근 권한을 부여한다.
  3. 역할 기반 접근 제어(RBAC) 모드: 사용자에게 부여된 역할에 따라 접근 권한을 부여하며, 각 역할은 허용되는 작업 목록을 정의한다.
  4. 웹훅 모드: 사용자가 주어진 작업을 수행할 권한이 있는지 확인하기 위해 REST API 서비스에 쿼리한다.[34]

API 클라이언트

쿠버네티스는 여러 공식 API 클라이언트를 지원한다.

클러스터 API

동일한 API 설계 원칙을 사용하여 쿠버네티스 클러스터를 생성, 구성 및 관리하기 위한 API를 프로그램으로 활용하도록 정의했다. 이를 클러스터 API라고 한다.[88] API에 구현된 핵심 개념은 코드형 인프라스트럭처 또는 쿠버네티스 클러스터 인프라 자체가 다른 쿠버네티스 리소스처럼 관리될 수 있는 리소스/객체라는 개념이다. 유사하게, 클러스터를 구성하는 머신도 쿠버네티스 리소스로 취급된다. API는 핵심 API와 공급자 구현의 두 부분으로 구성된다. 공급자 구현은 쿠버네티스가 클라우드 공급자의 서비스 및 리소스와 잘 통합되는 방식으로 클러스터 API를 제공할 수 있도록 하는 클라우드 공급자별 기능을 포함한다.[34]

Remove ads

용도

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

비판

쿠버네티스에 대한 일반적인 비판은 너무 복잡하다는 점이다. 구글도 이를 인정했다.[89]

배포판

다양한 공급업체는 쿠버네티스 기반 플랫폼 또는 IaaS를 제공하여 쿠버네티스를 배포한다.[90][91]

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

오픈 소스 배포판

  • 아마존 EKS-D
  • k0s
  • k3s
  • SUSE Rancher Kubernetes Engine (RKE)
  • OKD.IO 레드햇 오픈시프트를 지원하는 쿠버네티스 커뮤니티 배포판

상업용 배포판

  • D2iQ Kubernetes 플랫폼
  • Mirantis Kubernetes Engine (구 Docker Enterprise)
  • 레드햇 오픈시프트
  • VM웨어 탄주
  • SUSE Rancher (k3s 및 RKE2 쿠버네티스 배포 옵션 제공)

관리형 배포판

Remove ads

출시 타임라인

요약
관점
자세한 정보 버전, 출시일 ...

지원 기간

아래 차트는 각 릴리스가 지원되는 기간을 시각적으로 보여준다.[93]

Remove ads

같이 보기

각주

외부 링크

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads