쿠베르네테스

Kubernetes
쿠베르네테스
Kubernetes logo without workmark.svg
원저작자구글
개발자클라우드 네이티브 컴퓨팅 기반
초기 릴리즈2014년 6월 7일, 8년 전(2014-06-07)[1]
안정된 릴리스
1.24.2[2]Edit this on Wikidata/ 2022년 6월 15일; 49일 전(2022년 6월 15일)
저장소
기입처가세요
유형클러스터 관리 소프트웨어
면허증.Apache 라이센스 2.0
웹 사이트쿠버네테스이오

Kubernetes(/'k(j)u'b'r'n't's, -'ne't's, -'ne'ti'z, -'n'ti'z/'n[3]'ti'z/')는 소프트웨어 전개, 스케일링 및 [4][5]관리를 자동화하기 위한 오픈소스 컨테이너 오케스트레이션시스템입니다.구글은 원래 Kubernetes를 설계했지만, 현재 Cloud Native Computing Foundation이 프로젝트를 관리하고 있습니다.

Kubernetes는 Docker, Containerd 및 CRI-O와 [6]연계되어 있습니다.원래 독점적으로 그 Docker runtime[7]과"Dockershim"를 통해 하지만, 2016[표창 필요한]4월 2022년에서 50까지 결합시켰습니다, Kubernetes다 사용되지 않은 심을 찬성 직접 심과 컨테이너를 통해 Containerd, 혹은 교체 Docker과 런타임은 컴플라이언스와 컨테이너 런타임 인터페이스(CRI).[8][9][10]2022년 5월에 v1.24가 출시됨에 따라 "Dockershim"은 완전히 [11]제거되었습니다.

Amazon, Google, IBM, Microsoft, Oracle, Red Hat, SUSE, Platform9 및 VMware는 Kubernetes를 [12][13]구현하는 서비스로서의 인프라(IaaS) 기반 플랫폼을 제공합니다.

역사

구글 클라우드 서밋에서 구글 Kubernetes 엔진 토크

Kubernetes(그리스어로 "헬름스맨", "파일럿", "주지사"를 의미하며 사이버네틱스의 [5]어원적 뿌리는 2014년 [14]중반 구글에 의해 발표되었다.이 프로젝트는 Brian Grant와 Tim Hockin을 [14]포함한 다른 구글 엔지니어들과 함께 곧 합류한 Joe Beda, Brendan Burns,[15][16] 그리고 Craig McLuckie에 의해 만들어졌다.

Kubernetes의 설계와 개발은 구글의 Borg 클러스터 매니저의 영향을 받았다.스타 트렉의 전 Borg [17][18]캐릭터인 Seven of[19] Nine의 이름을 따서 Kubernetes "Project 7"이라는 코드명을 붙이고 로고를 7개의 바퀴로 만들었다.C++[17]로 작성된 Borg와 달리 Kubernetes 소스 코드는 Go 언어로 되어 있습니다.

Kubernetes 1.0은 2015년 [20]7월 21일에 출시되었습니다.구글은 Linux Foundation과 협력하여 Cloud Native Computing Foundation(CNCF)[21]을 구성하고 Kubernetes를 시드 테크놀로지로 제공했습니다.2016년 [22]2월에는 Kubernetes의 Helm 패키지 매니저가[23][24] 출시되었습니다.2018년 3월 6일, Kubernetes Project는 GitHub 프로젝트 중 커밋 수에서 9위에 올랐으며, 작성자 및 이슈에서 Linux [25]커널에 이어 2위에 올랐다.

버전 1.18까지 Kubernetes는 N-2 지원 정책을 따랐습니다.즉, 가장 최근의 세 가지 마이너버전은 보안 업데이트와 버그 [26]수정을 받습니다.버전 1.19 이후 Kubernetes는 N-3 지원 [27]정책을 따릅니다.

개념

Kubernetes 아키텍처 다이어그램

Kubernetes는 CPU, 메모리[28] 또는 커스텀 [29]메트릭을 기반으로 애플리케이션을 일괄적으로 도입, 유지보수 및 확장하는 메커니즘을 제공하는 일련의 빌딩 블록("기본")을 정의합니다.Kubernetes는 느슨하게 결합되어 있으며 다양한 워크로드에 대응할 수 있도록 확장 가능합니다.Kubernetes에서 실행되는 내부 컴포넌트와 확장 및 컨테이너는 Kubernetes [30]API에 의존합니다.이 플랫폼은 리소스를 개체로 정의하고 이를 개체로 관리함으로써 컴퓨팅 리소스와 스토리지 리소스를 제어합니다.

Kubernetes는 프라이머리/레플리카 아키텍처를 따릅니다.Kubernetes의 컴포넌트는 개별 노드를 관리하는 컴포넌트와 컨트롤 [30][31]플레인의 일부인 컴포넌트로 나눌 수 있습니다.

컨트롤 플레인

Kubernetes 마스터는 클러스터의 주요 제어 유닛으로 워크로드를 관리하고 시스템 간의 통신을 지시합니다.Kubernetes 컨트롤 플레인은 다양한 컴포넌트(각 프로세스)로 구성되어 있으며, 단일 마스터 노드 또는 고가용성 클러스터를 지원하는 여러 마스터에서 [31]모두 실행할 수 있습니다.Kubernetes 컨트롤 플레인의 다양한 컴포넌트는 다음과 같습니다.

  • etcd는[32] 영속적인 경량 분산형 키밸류 데이터 스토어로 핵심은 다음과 같습니다.OS가 개발되었습니다.클러스터의 구성 데이터를 안정적으로 저장하여 주어진 시점의 전체 클러스터 상태를 나타냅니다.etcd는 네트워크 파티션 발생 시 가용성보다 일관성을 우선합니다(CAP 정리 참조).서비스를 올바르게 스케줄링 및 운영하려면 일관성이 매우 중요합니다.
  • API 서버는 Kubernetes에 [30][33]내부 인터페이스와 외부 인터페이스를 모두 제공하는 JSON over HTTP를 사용하여 Kubernetes API를 제공합니다.API 서버는 REST 요구를 처리 및 검증하고 etcd의 API 오브젝트 상태를 갱신함으로써 클라이언트는 워커 [34]노드 전체에서 워크로드와 컨테이너를 구성할 수 있습니다.API 서버는 etcd의 Watch API를 사용하여 클러스터를 감시하거나 중요한 구성 변경을 롤아웃하거나 배포자가 선언한 클러스터 상태의 차이를 복원합니다.예를 들어 디플로이더는 특정 "Pod"(아래 참조)의 3개의 인스턴스를 실행해야 한다고 지정할 수 있습니다.etcd는 이 사실을 저장합니다.Deployment Controller는 (etcd [35]선언과 경합하는) 인스턴스가 2개만 실행 중인 것을 발견하면 해당 [31]포드의 추가 인스턴스 생성을 스케줄링합니다.
  • 스케줄러는 자원 가용성에 따라 일정되지 않은 포드(스케줄러에 의해 관리되는 기본 엔티티)가 실행되는 노드를 선택하는 확장 가능한 컴포넌트입니다.스케줄러는 각 노드의 리소스 사용량을 추적하여 워크로드가 사용 가능한 리소스를 초과하여 예약되지 않도록 합니다.이를 위해 스케줄러는 리소스 요구 사항, 리소스 가용성 및 서비스 품질, 선호도 대 반선호도 요구 사항 및 데이터 인접성 등의 기타 사용자 제공 제약 조건 또는 정책 지침을 알고 있어야 합니다.스케줄러의 역할은 리소스 "supply"를 워크로드 "demand"[36]와 일치시키는 것입니다.
  • 컨트롤러는 실제 클러스터 상태를 원하는 상태로 유도하여 API 서버와 통신하여 관리하는 리소스(예: 포드 또는 서비스 엔드포인트)[37][33]를 생성, 업데이트 및 삭제하는 조정 루프입니다.컨트롤러의 한 종류는 Replication Controller로, 클러스터 전체에서 지정된 수의 포드 복사본을 실행하여 복제 및 확장을 처리합니다.또한 기본 노드에 [37]장애가 발생할 경우 교체 포드를 생성하는 작업도 처리합니다.핵심 Kubernetes 시스템의 일부인 다른 컨트롤러에는 각 머신(또는 일부 머신의 서브셋)에서 정확히 1개의 팟을 실행하는 DaemonSet 컨트롤러와 완료까지 실행되는 팟을 실행하는 작업 컨트롤러(예: 배치 [38]작업의 일부)가 있습니다.컨트롤러 정의의 일부인 라벨 실렉터는 컨트롤러가 [39]관리하는 포드 세트를 지정합니다.
  • 컨트롤러 매니저는 일련의 핵심 Kubernetes 컨트롤러를 관리하는 프로세스입니다.

노드

노드는 워커 또는 미니언이라고도 하며 컨테이너(워크로드)가 배치되는 기계입니다.클러스터 내의 모든 노드는 Docker와 같은 컨테이너 런타임과 아래 컴포넌트를 실행하여 이들 컨테이너의 네트워크 구성을 위한 프라이머리와의 통신을 실시해야 합니다.

  • Kubelet은 각 노드의 실행 상태를 책임지고 노드 상의 모든 컨테이너가 정상인지 확인합니다.컨트롤 [30][40]플레인의 지시에 따라 팟으로 구성된 애플리케이션 컨테이너의 시작, 중지 및 유지보수를 수행합니다.Kubelet은 포드의 상태를 감시하고 원하는 상태가 아닌 경우 포드는 동일한 노드에 다시 전개됩니다.노드 상태는 하트비트 메시지를 통해 몇 초마다 프라이머리로 릴레이됩니다.프라이머리에서 노드 장애가 검출되면 Replication Controller는 이 상태 변경을 감시하고 다른 [41]정상 노드에서 포드를 실행합니다.
  • Kube-proxy는 네트워크 프록시 및 로드밸런서의 구현으로 다른 네트워크 [30]조작과 함께 서비스 추상화를 지원합니다.착신 요청의 IP 및 포트 번호를 기반으로 트래픽을 적절한 컨테이너로 라우팅합니다.
  • 컨테이너는 팟 안에 있습니다.컨테이너는 실행 중인 응용 프로그램, 라이브러리 및 종속성을 유지하는 마이크로 서비스의 가장 낮은 수준입니다.컨테이너는 외부 IP 주소를 통해 세상에 노출될 수 있습니다.Kubernetes는 첫 번째 버전부터 Docker 컨테이너를 지원했습니다.2016년 7월에 rkt 컨테이너 엔진이 추가되었습니다.[42]

네임스페이스

Kubernetes는 관리하는 리소스를 [43]네임스페이스라고 하는 중복되지 않는 세트로 파티셔닝합니다.여러 팀 또는 프로젝트에 분산된 사용자가 많은 환경 또는 개발, 테스트, 프로덕션과 같은 분리된 환경에서 사용할 수 있도록 설계되었습니다.

팟

Kubernetes의 기본 스케줄링 유닛은 [44]팟으로,[30] 1개 이상의 컨테이너가 같은 노드에 배치되어 있음을 보증합니다.Kubernetes의 각 팟에는 클러스터 내에서 고유한 IP 주소가 할당되어 있어 충돌 [45]위험 없이 애플리케이션을 포트를 사용할 수 있습니다.팟 내에서는 모든 컨테이너가 서로 참조할 수 있습니다.컨테이너는 다른 IP 세그먼트에서도 실행할 수 있습니다.그러나 한 포드의 컨테이너가 다른 포드의 다른 컨테이너에 액세스하려면 포드의 IP 주소를 사용해야 합니다.단, 팟 IP 주소는 일시적이기 때문에 응용 프로그램 개발자는 하드코드된 팟 IP 주소를 사용하지 마십시오.재시작 시 특정 팟이 다른 팟 IP 주소에 할당될 수 있습니다.대신 특정 포드 IP 주소의 타깃팟에 대한 참조를 유지하는 서비스(아래 참조)를 사용해야 합니다.

포드는 로컬 디스크 디렉토리 또는 네트워크 디스크와 같은 볼륨을 정의하고 [46]포드의 컨테이너에 표시할 수 있습니다.포드는 Kubernetes API를 통해 수동으로 관리하거나 컨트롤러에 [30]관리를 위임할 수 있습니다.이러한 볼륨은 ConfigMaps 기능(컨테이너에 표시되는 파일 시스템을 통해 구성에 액세스할 수 있음) 및 Secrets 기능(인정된 컨테이너에만 표시되는 파일 시스템의 자격 정보를 안전하게 액세스하기 위해 필요한 자격 정보에 액세스할 수 있음)의 기반이기도 합니다.

데몬 세트

일반적으로 Kubernetes Scheduler는 포드를 실행할 위치를 결정합니다.그러나 일부 사용 사례에서는 클러스터의 모든 단일 노드에서 포드를 실행해야 할 수 있습니다.이는 로그 수집, 입력 컨트롤러 및 스토리지 서비스와 같은 사용 사례에 유용합니다.DaemonSet은 이러한 종류의 포드 스케줄링을 [47]구현합니다.

복제 세트

ReplicaSet의 목적은 언제든지 실행되는 안정적인 복제 포드 세트를 유지하는 것입니다.따라서 동일한 포드의 [48]특정 개수의 가용성을 보장하기 위해 자주 사용됩니다.

ReplicaSet은[49] Kubernetes가 특정 포드에 대해 선언된 인스턴스 수를 유지할 수 있는 그룹화 메커니즘이라고도 할 수 있습니다.ReplicaSet의 정의는 셀렉터를 사용합니다.셀렉터의 평가는 셀렉터와 관련된 모든 포드를 식별하는 결과를 가져옵니다.

서비스

Kubernetes 클러스터에서 서비스가 포드 네트워킹과 상호 작용하는 방식을 보여 주는 단순화된 보기

Kubernetes 서비스는 다중 계층 애플리케이션의 한 계층과 같이 함께 작동하는 포드 세트입니다.서비스를 구성하는 포드 세트는 라벨 [30]셀렉터에 의해 정의됩니다.Kubernetes 라운드 로빈 방식의 태도 그 IP주소의 깍지 실렉터의 대응 사이에 연결되어(심지어 실패에 꼬투리를 일으키는 네트워크에 서비스 발굴의 두가지 모드, 또는 서비스에 대한 안정된 IP주소와 DNS이름을 할당하여 Kubernetes DNS.[50]서비스 발견을 이용하여 환경 변수를 사용하으며, 부하 균형 교통을 제공한다.호모기계에서 [45]기계로 이동).기본적으로 서비스는 클러스터 내에서 공개되지만(예: 백엔드 포드는 서비스로 그룹화되어 프론트엔드 포드의 요청이 로드 밸런싱될 수 있음), 서비스는 클러스터 외부에서도 공개될 수 있습니다(예: 클라이언트가 프론트엔드 [51]포드에 도달할 수 있음).

볼륨

Kubernetes 컨테이너의 파일 시스템은 기본적으로 사용 후 삭제 스토리지를 제공합니다.즉, 팟을 재시작하면 이러한 컨테이너의 모든 데이터가 삭제되므로, 이러한 형태의 스토리지는 사소한 애플리케이션 이외에는 상당히 제한됩니다.Kubernetes 볼륨은[52] 포드 자체의 수명 동안 지속되는 스토리지를 제공합니다.이 스토리지는 포드 내의 컨테이너를 위한 공유 디스크 공간으로 사용할 수도 있습니다.볼륨은 컨테이너 내의 특정 마운트 지점에 마운트되며, 이 마운트 지점은 포드 구성으로 정의되며 다른 볼륨에 마운트하거나 다른 볼륨에 연결할 수 없습니다.파일 시스템 트리의 다른 지점에 다른 컨테이너에 의해 동일한 볼륨을 마운트할 수 있습니다.

Config Maps 및 비밀 정보

일반적인 애플리케이션 과제는 구성 정보의 저장 및 관리 위치를 결정하는 것입니다.이 중 일부는 기밀 데이터를 포함할 수 있습니다.구성 데이터는 개별 속성이나 전체 구성 파일 또는 JSON/XML 문서와 같은 거친 정보처럼 세분화된 모든 데이터를 사용할 수 있습니다.Kubernetes는 이 요구에 대응하기 위해 configmaps와 secrets라는 밀접하게 관련된 메커니즘을 제공합니다.이러한 메커니즘은 둘 다 애플리케이션을 빌드하지 않고도 구성을 변경할 수 있습니다.configmaps 및 secret의 데이터는 이러한 오브젝트가 전개를 통해 바인드된 어플리케이션의 모든 인스턴스에서 사용할 수 있게 됩니다.시크릿 또는 컨피규레이션맵은 노드상의 팟이 필요로 하는 경우에만 노드에 송신됩니다.Kubernetes가 그 노드의 메모리에 보관합니다.시크릿 또는 컨피규레이션맵에 의존하는 포드가 삭제되면 바인드된 모든 시크릿과 컨피규레이션맵의 인메모리 복사도 삭제됩니다.데이터는 두 가지 방법 중 하나를 통해 팟에 액세스할 수 있습니다. a) 환경 변수(팟이 시작될 때 Kubernetes에 의해 생성됨) 또는 b)는 팟 내에서만 볼 수 있는 컨테이너 파일 시스템에서 사용할 수 있습니다.

데이터 자체는 마스터에 저장되며, 마스터는 아무도 로그인 권한을 갖지 않아야 하는 고도의 보안 시스템입니다.시크릿과 컨피규레이션맵의 가장 큰 차이점은 시크릿의 데이터 내용이 base64로 인코딩되어 있다는 것입니다.Kubernetes의 최신 버전에서는 암호화도 지원되고 있습니다.비밀은 증명서, 패스워드, 풀비밀(이미지 레지스트리를 사용하기 위한 credential), ssh 키 등의 데이터를 저장하기 위해 자주 사용됩니다.

스테이트 풀 세트

상태 비저장 애플리케이션의 확장은 실행 중인 팟을 더 추가하면 됩니다.상태 저장 워크로드는 팟을 다시 시작할 때 상태를 유지해야 하므로 더 어렵습니다.애플리케이션의 스케일 업 또는 스케일 다운의 경우는, 상태를 재배포할 필요가 있습니다.데이터베이스는 상태 저장 워크로드의 한 예입니다.하이 어베이러빌리티 모드로 실행되면 많은 데이터베이스가 프라이머리 인스턴스와 세컨더리 인스턴스의 개념을 가지고 있습니다.이 경우 인스턴스 순서의 개념이 중요합니다.Apache Kafka와 같은 다른 애플리케이션은 브로커에게 데이터를 배포합니다. 따라서 브로커와 브로커는 다릅니다.이 경우 인스턴스 고유성의 개념이 중요합니다.

StatefulSet은[53] 팟 인스턴스 간에 고유성 및 순서 부여 속성을 적용하는 컨트롤러(위 참조)로, 스테이트 풀 애플리케이션을 실행하는 데 사용할 수 있습니다.

레플리케이션 컨트롤러 및 도입

ReplicaSet은 필요한 포드의 인스턴스 수를 선언하고 Replication Controller는 실행 중인 정상 포드의 수가 ReplicaSet에 선언된 포드의 수와 일치하도록 시스템을 관리합니다(실렉터를 평가하여 결정).

배포는 ReplicaSet의 고급 관리 메커니즘입니다.Replication Controller가 ReplicaSet의 규모를 관리하는 동안, 배포는 ReplicaSet에 대한 작업(업데이트의 롤아웃 또는 롤백 여부 등)을 관리합니다.배포가 확대 또는 축소되면 ReplicaSet 선언이 변경되고 선언된 상태의 변경은 Replication Controller에 의해 관리됩니다.

라벨 및 셀렉터

Kubernetes를 통해 클라이언트(사용자 또는 내부 컴포넌트)는 시스템 내의 모든 API 오브젝트(예: 포드나 노드)에 "라벨"이라고 불리는 키를 부가할 수 있습니다.이에 따라 "label selectors"는 일치하는 [30]개체로 확인되는 레이블에 대한 쿼리입니다.서비스가 정의되면 서비스 라우터/로드 밸런서가 트래픽을 라우팅할 포드 인스턴스를 선택하기 위해 사용하는 라벨 실렉터를 정의할 수 있습니다.따라서 포드의 라벨을 변경하거나 서비스의 라벨 셀렉터를 변경하는 것만으로 트래픽을 수신하는 포드와 수신하지 않는 포드를 제어할 수 있습니다.이 포드는 청록색 배치 또는 A-B 테스트와 같은 다양한 전개 패턴을 지원하는 데 사용할 수 있습니다.서비스가 리소스를 구현하는 방법을 동적으로 제어하는 이 기능은 인프라 내에서 느슨한 결합을 제공합니다.

예를 들어 응용 프로그램의 포드에 시스템 라벨이 있는 경우tier(예를 들어 다음과 같은 가치로)frontend,backend(예를 들어) 및release_track(예를 들어 다음과 같은 가치로)canary,production(예를 들어) 다음으로 모든 동작에 대해backend그리고.canary노드에서는 다음과 [39]같은 라벨 셀렉터를 사용할 수 있습니다.

tier=backend AND release_track=canary

라벨과 마찬가지로 필드 셀렉터에서도 Kubernetes 리소스를 선택할 수 있습니다.레이블과 달리 선택 항목은 사용자 정의 분류가 아니라 선택한 리소스에 고유한 속성 값을 기반으로 합니다. metadata.name그리고.metadata.namespace는 모든 Kubernetes 객체에 존재하는 필드 셀렉터입니다.사용할 수 있는 다른 선택기는 개체/리소스 유형에 따라 달라집니다.

애드온

애드온은 클러스터 내에서 실행되는 다른 애플리케이션과 동일하게 동작합니다. 애드온은 팟과 서비스를 통해 구현되며 Kubernetes 클러스터의 기능을 구현한다는 점만 다릅니다.포드는 Deployments, Replication Controller 등에 의해 관리될 수 있습니다.많은 애드온들이 있고, 그 목록들은 점점 늘어나고 있다.그 중 중요한 것은 다음과 같습니다.

  • DNS: 모든 Kubernetes 클러스터에는 클러스터 DNS가 필요합니다.이것은 필수 기능입니다.클러스터 DNS는 사용자 환경의 다른 DNS 서버와 더불어 Kubernetes 서비스의 DNS 레코드를 제공하는 DNS 서버입니다.Kubernetes에 의해 시작된 컨테이너는 자동으로 이 DNS 서버를 DNS 검색에 포함합니다.
  • 웹 UI: Kubernetes 클러스터를 위한 범용 웹 기반 UI입니다.사용자는 클러스터 자체뿐만 아니라 클러스터에서 실행 중인 애플리케이션을 관리하고 문제를 해결할 수 있습니다.
  • 컨테이너 자원 감시: 신뢰성 높은 애플리케이션 런타임 제공 및 워크로드에 따라 스케일업 또는 스케일다운이 가능하기 때문에 워크로드 퍼포먼스를 지속적이고 효과적으로 감시할 수 있습니다.컨테이너 리소스 모니터링은 컨테이너에 대한 메트릭을 중앙 데이터베이스에 기록하여 이 기능을 제공하고 해당 데이터를 찾아보기 위한 UI를 제공합니다.cAdvisor는 제한된 메트릭 모니터링 기능을 제공하는 슬레이브 노드의 컴포넌트입니다.Prometheus와 같은 전체 메트릭 파이프라인도 있어 대부분의 모니터링 요구를 충족할 수 있습니다.
  • 클러스터 레벨 로깅: 로그는 노드, 포드 또는 컨테이너에 의존하지 않는 개별 스토리지와 라이프 사이클을 가져야 합니다.그렇지 않으면 노드 또는 포드 장애로 인해 이벤트 데이터가 손실될 수 있습니다.이를 클러스터 수준 로깅이라고 하며 이러한 메커니즘은 검색/브라우징 인터페이스를 사용하여 컨테이너 로그를 중앙 로그 저장소에 저장하는 역할을 합니다.Kubernetes는 로그 데이터를 위한 네이티브 스토리지를 제공하지 않지만 기존의 많은 로깅 솔루션을 Kubernetes 클러스터에 통합할 수 있습니다.

보관소

컨테이너는 소프트웨어를 휴대할 수 있는 방법으로 등장했다.컨테이너에는 서비스를 실행하는 데 필요한 모든 패키지가 들어 있습니다.제공된 파일 시스템은 컨테이너를 매우 휴대성이 뛰어나고 개발 시 사용하기 쉽게 만듭니다.컨테이너는 구성을 변경하지 않거나 비교적 적게 변경하지 않고 개발에서 테스트 또는 프로덕션으로 이동할 수 있습니다.

역사적으로 Kubernetes는 상태 비저장 서비스에만 적합했습니다.그러나 많은 애플리케이션에는 데이터베이스가 있어 지속성이 필요하며, 이로 인해 Kubernetes용 영구 스토리지가 생성됩니다.컨테이너용 영구 스토리지를 구현하는 것은 Kubernetes 관리자, DevOps 및 클라우드 엔지니어의 가장 큰 과제 중 하나입니다.컨테이너는 일시적일 수 있지만, 데이터의 대부분은 그렇지 않기 때문에 컨테이너 종료나 하드웨어 장애 시에도 데이터의 존속을 보장할 필요가 있습니다.Kubernetes 또는 컨테이너형 애플리케이션을 사용하여 컨테이너를 구축할 때 기업은 영구 스토리지가 필요하다는 것을 깨닫는 경우가 많습니다.컨테이너에서 사용되는 데이터베이스, 루트 이미지 및 기타 데이터를 위한 빠르고 안정적인 스토리지를 제공해야 합니다.

Cloud Native Computing Foundation(CNCF)은 Kubernetes Persistent Storage에 대한 기타 정보(컨테이너 접속 스토리지 패턴의 정의를 지원하는 블로그 등)를 공개하고 있습니다.이 패턴은 Kubernetes 자체를 스토리지 시스템 또는 [54]서비스의 구성 요소로 사용하는 패턴이라고 생각할 수 있습니다.

CNCF의 랜드스케이프 조사에서도 이러한 접근법의 상대적 인기에 대한 자세한 내용은 2019년 [55]가을 현재 평가 대상이 될 가능성이 가장 높은 프로젝트인 MayaData와 Rook의 OpenEBS를 확인할 수 있습니다.

컨테이너 어태치드 스토리지는 Kubernetes가 두각을 나타내면서 등장한 데이터 스토리지의 일종이다.컨테이너 연결 스토리지 접근 방식 또는 패턴은 Kubernetes에서 실행되는 워크로드에 주로 블록, 파일, 객체 및 인터페이스를 제공하면서 특정 기능을 Kubernetes [56]자체에 의존합니다.

컨테이너 연결 스토리지의 일반적인 특성으로는 커스텀 리소스 정의와 같은 Kubernetes에 대한 확장 기능 사용, 스토리지 또는 데이터 관리를 위해 별도로 개발 및 배포되는 기능에 Kubernetes 자체를 사용하는 것이 있습니다.커스텀 리소스 정의 또는 Kubernetes 자체에서 제공하는 재시도 논리, 일반적으로 커스텀 리소스 [57][58]정의를 통해 제공되는 사용 가능한 스토리지 미디어 및 볼륨의 인벤토리 생성 및 유지보수가 있습니다.

API

Kubernetes 컨트롤 플레인의 주요 컴포넌트는 API 서버입니다.이 서버는 클러스터의 다른 부분과 최종 사용자 및 외부 컴포넌트에서 호출할 수 있는HTTP API를 제공합니다.이 API는 REST API로 선언형입니다.API 리소스에는 두 가지 종류가 있습니다.Kubernetes API의 API 리소스는 대부분 객체입니다.이는 포드 또는 네임스페이스와 같은 클러스터에 있는 개념의 구체적인 인스턴스를 나타냅니다.소수의 API 리소스 유형이 "가상"입니다.이는 "subject accessreviews" 리소스를 사용하는 개체(예: 사용 권한 검사)가 아니라 작업을 나타냅니다.개체에 해당하는 API 리소스는 개체에 대한 고유한 식별자로 클러스터에 표시됩니다.가상 리소스에는 고유한 식별자가 없습니다.

연산자

커스텀 리소스를 사용하여 Kubernetes를 확장할 수 있습니다.이러한 API 리소스는 표준 Kubernetes 제품의 일부가 아닌 개체를 나타냅니다.이러한 리소스는 동적 등록을 통해 실행 중인 클러스터에 나타나거나 사라질 수 있습니다.클러스터 관리자는 클러스터와 독립적으로 사용자 지정 리소스를 업데이트할 수 있습니다.

커스텀 컨트롤러도 확장 메커니즘입니다.이들은 Custom Resources와 상호 작용하며 Kubernetes 자체의 설계 방식에 맞춰 Custom Resource의 라이프사이클 관리를 가능하게 하는 진정한 선언형 API를 제공합니다.커스텀 리소스와 커스텀컨트롤러의 조합을 (Kubernetes) 오퍼레이터라고 부릅니다.Operators의 주요 활용 사례는 서비스 또는 서비스 세트를 관리하는 사람의 목적을 포착하고 자동화와 이 자동화를 지원하는 선언형 API를 사용하여 이를 구현하는 것입니다.특정 애플리케이션과 서비스를 관리하는 휴먼 오퍼레이터는 시스템의 동작 방법, 도입 방법 및 문제가 발생했을 경우의 대응 방법에 대해 깊은 지식을 가지고 있습니다.오퍼레이터가 해결한 문제의 예로는 응용 프로그램 상태 백업 및 복원, 데이터베이스 스키마 또는 추가 구성 설정 등의 관련 변경과 함께 응용 프로그램 코드 업그레이드 처리 등이 있습니다.

클러스터 API

Kubernetes 클러스터를 프로그래밍 방식으로 생성, 구성 및 관리하기 위한 API를 정의하는 데 동일한 API 설계 원칙이 사용되었습니다.이를 클러스터 [59]API라고 합니다.API에 구현된 주요 개념은 소프트웨어로서의 인프라스트럭처를 사용하는 것입니다.또는 Kubernetes 클러스터 인프라스트럭처 자체가 다른 Kubernetes 리소스와 마찬가지로 관리할 수 있는 자원/개체라는 개념입니다.마찬가지로 클러스터를 구성하는 머신도 Kubernetes 리소스로 취급됩니다.API에는 핵심 API와 공급자 구현이라는 두 가지 요소가 있습니다.프로바이더 구현은 Kubernetes가 클라우드 프로바이더의 서비스 및 리소스와 잘 통합된 방식으로 클러스터 API를 제공할 수 있는 클라우드 프로바이더별 기능으로 구성됩니다.

사용하다

Kubernetes는 일반적으로 마이크로 서비스 기반 구현을 호스팅하는 방법으로 사용됩니다. Kubernetes는 마이크로 서비스 아키텍처의 주요 문제를 해결하는 데 필요한 모든 기능을 제공하기 때문입니다.오픈소스, 커머셜, 매니지드 3가지 형태로 제공됩니다.오픈 소스 배포에는 오리지널 Kubernetes, Amazon EKS-D, Red Hat OpenShift, VMware Tanzu, Mirantis Kubernetes Engine 및 D2iQ Kubernetes 플랫폼이 포함됩니다.관리 대상 제품에는 GKE, Oracle Container Engine for Kubernetes, Amazon Elastic Kubernetes Service, IBM Kubernetes Service [60]및 Platform 9 Managed Kubernetes가 포함됩니다.

릴리즈 스케줄

릴리즈 스케줄
버전 발매일 판매[61] 종료일 메모들
이전 버전, 더 이상 유지 보수되지 않음 2015년 7월 10일 오리지널 릴리즈
이전 버전, 유지 보수 불필요: 1.1 2015년 11월 9일 https://kubernetes.io/blog/2015/11/kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
이전 버전, 유지 보수 불필요: 1.2 2016년 3월 16일 2016년 10월 23일 https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
이전 버전, 유지 보수 불필요: 1.3 2016년 7월 1일 2016년 11월 1일 https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads
이전 버전, 더 이상 유지 보수되지 않음 2016년 9월 26일 2017년 4월 21일 https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere
이전 버전, 더 이상 유지 보수되지 않음 2016년 12월 12일 2017년 10월 1일 https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads
이전 버전, 더 이상 유지 보수되지 않음 2017년 3월 28일 2017년 11월 23일 https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale
이전 버전, 유지 보수 불필요: 1.7 2017년 6월 30일 2018년 4월 4일 https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates
이전 버전, 유지 보수 불필요: 1.8 2017년 8월 28일 2018년 7월 12일 https://kubernetes.io/blog/2017/09/kubernetes-18-security-workloads-and
이전 버전, 더 이상 유지 보수되지 않음: 2017년 12월 15일 2018년 9월 29일 https://kubernetes.io/blog/2017/12/kubernetes-19-workloads-expanded-ecosystem
이전 버전, 유지 보수 불필요: 1.10 2018년 3월 28일 2019년 2월 13일 https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking
이전 버전, 더 이상 유지 보수되지 않음: 1.11 2018년 7월 3일 2019년 5월 1일 https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement
이전 버전, 유지 보수 불필요: 1.12 2018년 9월 27일 2019년 7월 8일 https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability
이전 버전, 유지 보수 불필요: 1.13 2018년 12월 3일 2019년 10월 15일 https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement
이전 버전, 유지 보수 불필요: 1.14 2019년 3월 25일 2019년 12월 11일 https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement
이전 버전, 유지 보수 불필요: 1.15 2019년 6월 20일 2020년 5월 6일 https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement
이전 버전, 유지 보수 불필요: 1.16 2019년 10월 22일 2020년 9월 2일 https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement
이전 버전, 유지 보수 불필요: 1.17 2019년 12월 9일 2021년 1월 13일 https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement
이전 버전, 유지 보수 불필요: 1.18 2020년 3월 25일 2021년 6월 18일 https://kubernetes.io/blog/2020/03/25/kubernetes-1-18-release-announcement
이전 버전, 유지 보수 불필요: 1.19 2020년 8월[62] 26일 2021년 10월 28일 Kubernetes 버전 1.19부터 지원 기간이 1년, 유지 보수 모드 기간이 [27]2개월로 연장되었습니다.
https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive
이전 버전, 유지 보수 불필요: 1.20 2020년 12월 8일 2022년 2월 28일 https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/
이전 버전, 유지 보수 불필요: 1.21 2021년 4월 8일 2022년 6월 28일 https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/
이전 버전이지만 유지 보수: 1.22 2021년 8월 4일 2022년 10월 28일 https://kubernetes.io/blog/2021/08/04/kubernetes-1-22-release-announcement/
이전 버전, 아직 유지 보수: 1.23 2021년 12월 7일 2023년 2월 28일 https://kubernetes.io/blog/2021/12/07/kubernetes-1-23-release-announcement/
현재 안정적인 버전: 1.24 2022년 5월 3일 2023년 9월 29일 https://kubernetes.io/blog/2022/05/03/kubernetes-1-24-release-announcement/
범례:
구버전
이전 버전, 아직 유지 관리됨
최신 버전
최신 프리뷰 버전
향후 출시

지원창

아래 표는 각 릴리스가 지원되는 기간을 나타내고[61] 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "First GitHub commit for Kubernetes". github.com. 2014-06-07. Archived from the original on 2017-03-01.
  2. ^ "Release Kubernetes v1.24.2".
  3. ^ "Kubernetes GitHub Repository". GitHub. January 22, 2021.
  4. ^ "kubernetes/kubernetes". GitHub. Archived from the original on 2017-04-21. Retrieved 2017-03-28.
  5. ^ a b "What is Kubernetes?". Kubernetes. Retrieved 2017-03-31.
  6. ^ "Container runtimes". Kubernetes. Retrieved 2021-11-14.
  7. ^ "Kubernetes v1.12: Introducing RuntimeClass". kubernetes.io. 10 October 2018.
  8. ^ "Don't Panic: Kubernetes and Docker". Kubernetes Blog. 2 December 2020. Retrieved 2020-12-22.
  9. ^ "Introducing Container Runtime Interface (CRI) in Kubernetes". Kubernetes. 2016-12-19. Retrieved 2021-05-16.
  10. ^ "kubernetes/community". GitHub. Retrieved 2021-05-16.
  11. ^ 갱신일 : Dockershim 제거 FAQ Kubernetes 블로그
  12. ^ "The 7 Most Popular Kubernetes Distributions". Retrieved 2021-12-28.
  13. ^ MSV, Janakiram. "Why Kubernetes Developer Ecosystem Needs A PaaS". Forbes. Retrieved 2021-05-16.
  14. ^ a b Metz, Cade. "Google Open Sources Its Secret Weapon in Cloud Computing". Wired. Archived from the original on 10 September 2015. Retrieved 24 September 2015.
  15. ^ Metz, Cade. "Google Made Its Secret Blueprint Public to Boost Its Cloud". Wired. Archived from the original on 2016-07-01. Retrieved 2016-06-27.
  16. ^ Burns, Brendan (July 20, 2018), The History of Kubernetes & the Community Behind It, archived from the original on 2022-02-27
  17. ^ a b Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (April 21–24, 2015). "Large-scale cluster management at Google with Borg". Proceedings of the European Conference on Computer Systems (EuroSys). Archived from the original on 2017-07-27.
  18. ^ "Borg, Omega, and Kubernetes - ACM Queue". queue.acm.org. Archived from the original on 2016-07-09. Retrieved 2016-06-27.
  19. ^ "Early Stage Startup Heptio Aims to Make Kubernetes Friendly". Retrieved 2016-12-06.
  20. ^ "As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation". TechCrunch. Archived from the original on 23 September 2015. Retrieved 24 September 2015.
  21. ^ "Cloud Native Computing Foundation". Archived from the original on 2017-07-03.
  22. ^ "Release v1.0: Merge pull request #277 from jackgr/master · helm/helm". GitHub. Retrieved 2021-05-16.
  23. ^ "Helm (package manager) - wikieduonline". www.wikieduonline.com. Retrieved 2021-05-16.
  24. ^ "Helm". helm.sh. Retrieved 2021-05-16.
  25. ^ Conway, Sarah (6 March 2018). "Kubernetes Is First CNCF Project To Graduate" (html). Cloud Native Computing Foundation. Archived from the original on 29 October 2018. Retrieved 3 December 2018. Compared to the 1.5 million projects on GitHub, Kubernetes is No. 9 for commits and No. 2 for authors/issues, second only to Linux.
  26. ^ "Kubernetes version and version skew support policy". Kubernetes. Retrieved 2020-03-03.
  27. ^ a b "Kubernetes 1.19 Release Announcement > Increase Kubernetes support window to one year". Kubernetes. 26 August 2020. Retrieved 2020-08-28.
  28. ^ Sharma, Priyanka (13 April 2017). "Autoscaling based on CPU/Memory in Kubernetes—Part II". Powerupcloud Tech Blog. Medium. Retrieved 27 December 2018.
  29. ^ "Configure Kubernetes Autoscaling With Custom Metrics". Bitnami. BitRock. 15 November 2018. Retrieved 27 December 2018.
  30. ^ a b c d e f g h i "An Introduction to Kubernetes". DigitalOcean. Archived from the original on 1 October 2015. Retrieved 24 September 2015.
  31. ^ a b c "Kubernetes Infrastructure". OpenShift Community Documentation. OpenShift. Archived from the original on 6 July 2015. Retrieved 24 September 2015.
  32. ^ 코어별 컨테이너 LinuxOS: 클러스터 인프라스트럭처
  33. ^ a b Marhubi, Kamal (2015-09-26). "Kubernetes from the ground up: API server". kamalmarhubi.com. Archived from the original on 2015-10-29. Retrieved 2015-11-02.
  34. ^ Ellingwood, Justin (2 May 2018). "An Introduction to Kubernetes". DigitalOcean. Archived from the original on 5 July 2018. Retrieved 20 July 2018. One of the most important primary services is an API server. This is the main management point of the entire cluster as it allows a user to configure Kubernetes' workloads and organizational units. It is also responsible for making sure that the etcd store and the service details of deployed containers are in agreement. It acts as the bridge between various components to maintain cluster health and disseminate information and commands.
  35. ^ "Deployments". Kubernetes. Retrieved 2022-02-27.
  36. ^ "The Three Pillars of Kubernetes Container Orchestration - Rancher Labs". rancher.com. 18 May 2017. Archived from the original on 24 June 2017. Retrieved 22 May 2017.
  37. ^ a b "Overview of a Replication Controller". Documentation. CoreOS. Archived from the original on 2015-09-22. Retrieved 2015-11-02.
  38. ^ Sanders, Jake (2015-10-02). "Kubernetes: Exciting Experimental Features". Livewyer. Archived from the original on 2015-10-20. Retrieved 2015-11-02.
  39. ^ a b "Intro: Docker and Kubernetes training - Day 2". Red Hat. 2015-10-20. Archived from the original on 2015-10-29. Retrieved 2015-11-02.
  40. ^ Marhubi, Kamal (2015-08-27). "What [..] is a Kubelet?". kamalmarhubi.com. Archived from the original on 2015-11-13. Retrieved 2015-11-02.
  41. ^ "Kubernetes Security Issues and Best Practices Snyk". snyk.io. 26 July 2020. Retrieved 2021-05-16.
  42. ^ "rktnetes brings rkt container engine to Kubernetes". kubernetes.io. 11 July 2016.
  43. ^ "Namespaces". kubernetes.io.
  44. ^ "Pods". kubernetes.io.
  45. ^ a b Langemak, Jon (2015-02-11). "Kubernetes 101 – Networking". Das Blinken Lichten. Archived from the original on 2015-10-25. Retrieved 2015-11-02.
  46. ^ Strachan, James (2015-05-21). "Kubernetes for Developers". Medium (publishing platform). Archived from the original on 2015-09-07. Retrieved 2015-11-02.
  47. ^ "DaemonSet". kubernetes.io.
  48. ^ "ReplicaSet". kubernetes.io. Retrieved 2020-03-03.
  49. ^ "Deployments, ReplicaSets, and pods". IBM.
  50. ^ "Service". kubernetes.io.
  51. ^ Langemak, Jon (2015-02-15). "Kubernetes 101 – External Access Into The Cluster". Das Blinken Lichten. Archived from the original on 2015-10-26. Retrieved 2015-11-02.
  52. ^ "Volumes". kubernetes.io.
  53. ^ "StatefulSets". kubernetes.io.
  54. ^ "Container Attached Storage: A primer". Cloud Native Computing Foundation. 2018-04-19. Retrieved 2021-05-16.
  55. ^ "CNCF SURVEY 2019" (PDF). cncf.io.{{cite web}}: CS1 maint :url-status (링크)
  56. ^ "Container Attached Storage: A primer". Cloud Native Computing Foundation. 2018-04-19. Retrieved 2020-10-09.
  57. ^ "Container Attached Storage SNIA". www.snia.org. Retrieved 2020-10-09.
  58. ^ "Cloud Native Application Checklist: Cloud Native Storage". www.replex.io. Retrieved 2020-10-09.
  59. ^ "Introduction - The Cluster API Book".
  60. ^ "5 Cloud Native Trends to Watch out for in 2022". The New Stack. 2022-01-03. Retrieved 2022-02-03.
  61. ^ a b "Kubernetes Patch Releases". GitHub. 4 May 2022. Retrieved 2022-05-09.
  62. ^ "Kubernetes 1.19 Release Announcement". Kubernetes. 26 August 2020. Retrieved 2020-08-28.

외부 링크