Kubernetes 란 무엇입니까? 다음 애플리케이션 플랫폼

Kubernetes는 컨테이너 오케스트레이션을 위한 인기있는 오픈 소스 플랫폼입니다. 즉, 컨테이너라고하는 여러 개의 독립적 인 런타임으로 구축 된 애플리케이션 관리를위한 것입니다 . 컨테이너는 2013 년 Docker 컨테이너화 프로젝트가 시작된 이후로 점점 인기를 얻었지만, 대규모 분산 컨테이너화 애플리케이션은 조정하기가 점점 더 어려워 질 수 있습니다. 컨테이너화 된 애플리케이션을 대규모로 훨씬 쉽게 관리 할 수있게함으로써 Kubernetes는 컨테이너 혁명의 핵심 부분이되었습니다.

컨테이너 오케스트레이션이란 무엇입니까?

컨테이너는 VM과 같은 문제 분리를 지원하지만 오버 헤드는 훨씬 적고 유연성은 훨씬 더 높습니다. 그 결과 컨테이너는 사람들이 소프트웨어 개발, 배포 및 유지 관리에 대해 생각하는 방식을 재편했습니다. 컨테이너화 된 아키텍처에서 애플리케이션을 구성하는 다양한 서비스는 별도의 컨테이너로 패키징되고 물리적 또는 가상 머신의 클러스터에 배포됩니다. 그러나 이로 인해 컨테이너 기반 애플리케이션의 배포, 관리, 확장, 네트워킹 및 가용성을 자동화하는 도구 인 컨테이너 오케스트레이션 이 필요 합니다.

Kubernetes 란 무엇입니까?

Kubernetes는 가장 인기있는 컨테이너 오케스트레이션 도구 중 하나가 된 오픈 소스 프로젝트입니다. 이를 통해 대규모 다중 컨테이너 애플리케이션을 배포하고 관리 할 수 ​​있습니다. 실제로 Kubernetes는 가장 널리 사용되는 컨테이너화 플랫폼 인 Docker와 함께 가장 자주 사용되지만 컨테이너 이미지 형식 및 런타임에 대한 OCI (Open Container Initiative) 표준을 준수하는 모든 컨테이너 시스템에서도 작동 할 수 있습니다. 또한 Kubernetes는 오픈 소스이므로 사용 방법에 대한 제한이 비교적 적기 때문에 컨테이너를 실행하려는 모든 사람, 온 프레미스, 퍼블릭 클라우드 또는 둘 다에서 컨테이너를 실행하려는 모든 곳에서 자유롭게 사용할 수 있습니다. .

Google 및 Kubernetes

Kubernetes는 Google 내 프로젝트로 시작되었습니다. Google이 내부적으로 사용한 이전 컨테이너 관리 도구 인 Google Borg의 직계 후손은 아니지만 후속 제품입니다. 2014 년 Google은 Kubernetes가 지원하는 분산 마이크로 서비스 아키텍처를 통해 클라우드에서 애플리케이션을 쉽게 실행할 수 있기 때문에 2014 년에 오픈 소스 Kubernetes를 사용했습니다. Google은 컨테이너, 마이크로 서비스 및 Kubernetes의 채택을 잠재적으로 고객을 클라우드 서비스로 유도하는 것으로보고 있습니다 (Kubernetes는 확실히 Azure 및 AWS에서도 작동하지만). Kubernetes는 현재 Linux Foundation의 산하에있는 Cloud Native Computing Foundation에서 관리합니다.

Kubernetes 대 Docker 및 Kubernetes 대 Docker Swarm

Kubernetes는 Docker를 대체하지 않지만 확장합니다. 그러나 Kubernetes Docker를 중심으로 등장한 일부 고급 기술을 대체합니다.

이러한 기술 중 하나는 Docker와 함께 번들로 제공되는 오케 스트레이터 인 Docker Swarm입니다. 여전히 Kubernetes 대신 Docker Swarm을 사용할 수 있지만 Docker Inc.는 앞으로 Kubernetes를 Docker Community 및 Docker Enterprise 에디션의 일부로 만들기로 선택했습니다.

Kubernetes가 Docker Swarm의 드롭 인 대체품은 아닙니다. Kubernetes는 Swarm보다 훨씬 더 복잡하며 배포하는 데 더 많은 작업이 필요합니다. 그러나이 작업은 장기적으로는 더 관리하기 쉽고 탄력적 인 애플리케이션 인프라라는 큰 성과를 제공하기위한 것입니다. 개발 작업 및 소규모 컨테이너 클러스터의 경우 Docker Swarm은 더 간단한 선택을 제공합니다. 

Kubernetes와 Mesos

Kubernetes의 경쟁자로서 들어 보셨을 또 다른 프로젝트는 Mesos입니다. Mesos는 원래 Twitter의 개발자로부터 나온 Apache 프로젝트입니다. 실제로 Google Borg 프로젝트에 대한 답변으로 간주되었습니다.

Mesos는 실제로 컨테이너 오케스트레이션 서비스를 제공하지만 그 목표는 그 이상입니다. 즉, 컨테이너화 된 구성 요소와 컨테이너화되지 않은 구성 요소를 모두 조정할 수있는 일종의 클라우드 운영 체제를 목표로합니다. 이를 위해 Kubernetes 자체를 포함하여 Mesos 내에서 다양한 플랫폼을 실행할 수 있습니다.

Kubernetes 아키텍처 : Kubernetes 작동 방식

Kubernetes의 아키텍처는 다양한 개념과 추상화를 사용합니다. 이들 중 일부는 기존의 익숙한 개념에 대한 변형이지만 다른 일부는 Kubernetes에만 해당됩니다.

Kubernetes 클러스터

가장 높은 수준의 Kubernetes 추상화 인 cluster 는 Kubernetes (그 자체가 클러스터 된 애플리케이션)를 실행하는 머신 그룹과 여기에서 관리되는 컨테이너를 나타냅니다. Kubernetes 클러스터에는 클러스터 의 다른 모든 Kubernetes 머신을 명령하고 제어하는 ​​시스템 인 마스터 가 있어야 합니다. 고 가용성 Kubernetes 클러스터는 여러 머신에 걸쳐 마스터의 시설을 복제합니다. 그러나 한 번에 하나의 마스터 만 작업 스케줄러와 컨트롤러 관리자를 실행합니다.

Kubernetes 노드 및 포드

각 클러스터에는 Kubernetes 노드 가 포함되어 있습니다 . 노드는 물리적 시스템 또는 VM 일 수 있습니다. 다시 말하지만, 아이디어는 추상화입니다. 앱이 실행되는 것이 무엇이든 Kubernetes는 해당 기판에서 배포를 처리합니다. Kubernetes를 사용하면 특정 컨테이너가 VM 또는 베어 메탈에서만 실행되도록 할 수도 있습니다.

노드 는 생성 또는 관리 할 수있는 가장 기본적인 Kubernetes 객체 인 pod를 실행 합니다. 각 포드는 애플리케이션의 단일 인스턴스 또는 Kubernetes에서 실행중인 프로세스를 나타내며 하나 이상의 컨테이너로 구성됩니다. Kubernetes는 포드의 모든 컨테이너를 그룹으로 시작, 중지 및 복제합니다. 포드는 컨테이너 자체가 아니라 애플리케이션에 사용자의주의를 집중시킵니다. 포드 상태부터 Kubernetes를 구성해야하는 방법에 대한 세부 정보 는 분산 키-값 저장소 인 Etcd 에 보관됩니다.

포드는 포드 정의에서 사용자가 지정한 원하는 상태를 따르기 위해 필요에 따라 노드에서 생성 및 삭제됩니다. Kubernetes는 팟 (Pod)이 스핀 업, 롤아웃 및 스핀 다운되는 방식의 물류를 처리하기 위해 컨트롤러 라는 추상화를 제공합니다 . 컨트롤러는 관리되는 애플리케이션의 종류에 따라 몇 가지 다른 형태로 제공됩니다. 예를 들어 최근에 도입 된 "StatefulSet"컨트롤러는 지속적인 상태가 필요한 응용 프로그램을 처리하는 데 사용됩니다. 또 다른 종류의 컨트롤러 인 deployment 는 앱을 확장하거나 축소하고, 앱을 새 버전으로 업데이트하거나, 문제가있는 경우 앱을 알려진 정상 버전으로 롤백하는 데 사용됩니다.

Kubernetes 서비스

포드는 필요에 따라 살고 죽기 때문에 애플리케이션 수명주기를 처리하기 위해 다른 추상화가 필요합니다. 애플리케이션을 구성하는 컨테이너를 실행하는 포드가 자체적으로 지속되지 않는 경우에도 애플리케이션은 영구 엔티티 여야합니다. 이를 위해 Kubernetes는 서비스 라는 추상화를 제공합니다.

Kubernetes의 서비스는 네트워크를 통해 주어진 포드 그룹 (또는 기타 Kubernetes 객체)에 액세스 할 수있는 방법을 설명합니다. Kubernetes 문서에 나와 있듯이 애플리케이션의 백엔드를 구성하는 포드가 변경 될 수 있지만 프런트 엔드는 이에 대해 알거나 추적 할 필요가 없습니다. 서비스가이를 가능하게합니다.

쿠 버네 티스 내부의 몇 가지 더 많은 부분이 그림을 완성합니다. 스케줄러 가 자원을 통해 균형있는 및 배포 응용 프로그램 정의의 요구 사항을 충족 그래서 있도록 노드에 워크로드 밖으로 소포. 컨트롤러 관리 시스템 - 애플리케이션 워크로드의 상태 등-일치 원하는 상태가 Etcd의 구성 설정에 정의 된 것을 보장한다.

Docker 자체와 같이 컨테이너에서 사용하는 저수준 메커니즘 은 Kubernetes 로 대체 되지 않는다는 점을 기억하는 것이 중요합니다 . 오히려 Kubernetes는 앱을 대규모로 실행하기 위해 이러한 메커니즘을 사용하기위한 더 큰 추상화 집합을 제공합니다.

Kubernetes 인 그레스

Kubernetes 서비스는 클러스터 에서 실행 되는 것으로 간주됩니다 . 그러나 외부 세계에서 이러한 서비스에 액세스 할 수 있기를 원할 것입니다. Kubernetes에는 NodePort 및 LoadBalancer를 포함하여 다양한 수준의 단순성과 견고성으로이를 용이하게하는 여러 구성 요소가 있지만 가장 유연성이있는 구성 요소는 Ingress입니다. Ingress는 일반적으로 HTTP를 통해 클러스터 서비스에 대한 외부 액세스를 관리하는 API입니다.

Ingress를 올바르게 설정하려면 약간의 구성이 필요합니다. Kubernetes 개발에 관한 책을 쓴 Matthew Palmer가 웹 사이트에서 프로세스를 안내합니다.

Kubernetes 대시 보드

이러한 다른 모든 구성 요소를 유지하는 데 도움이되는 Kubernetes 구성 요소 중 하나는 앱을 배포하고 문제를 해결하고 클러스터 리소스를 관리 할 수있는 웹 기반 UI 인 Dashboard입니다. Dashboard는 기본적으로 설치되지 않지만 추가하는 것은 그리 큰 문제가 아닙니다.

관련 비디오 : Kubernetes 란 무엇입니까?

90 초 분량의이 동영상에서는 기술 발명가 중 한 명인 Heptio의 창립자이자 CTO 인 Joe Beda로부터 컨테이너 식 애플리케이션 자동화를위한 오픈 소스 시스템 인 Kubernetes에 대해 알아 봅니다.

Kubernetes의 장점

Kubernetes는 새로운 추상화와 개념을 도입하고 Kubernetes에 대한 학습 곡선이 높기 때문에 Kubernetes 사용에 대한 장기적 보상이 무엇인지 묻는 것은 정상일뿐입니다. 다음은 Kubernetes 내에서 앱을 실행하는 것이 더 쉬워지는 특정 방법에 대한 요약입니다.

Kubernetes는 앱 상태, 복제, 부하 분산 및 하드웨어 리소스 할당을 관리합니다.

Kubernetes가 수행하는 가장 기본적인 의무 중 하나는 애플리케이션을 계속 실행하고 사용자 요구에 응답하는 바쁜 작업입니다. "비정상"상태가되거나 설명하는 건강 정의를 준수하지 않는 앱은 자동으로 치료 될 수 있습니다.

Kubernetes가 제공하는 또 다른 이점은 메모리, 스토리지 I / O 및 네트워크 대역폭을 포함한 하드웨어 리소스의 사용을 극대화하는 것입니다. 애플리케이션은 리소스 사용량에 대해 소프트 및 하드 제한을 설정할 수 있습니다. 최소한의 리소스를 사용하는 많은 앱을 동일한 하드웨어에 함께 묶을 수 있습니다. 확장해야하는 앱은 확장 할 여지가있는 시스템에 배치 할 수 있습니다. 또한 클러스터 전체에서 업데이트를 롤아웃하거나 업데이트가 중단 된 경우 롤백을 자동화 할 수 있습니다.

Kubernetes는 Helm 차트를 사용하여 사전 구성된 애플리케이션의 배치를 용이하게합니다.

Debian Linux의 APT 및 Python의 Pip과 같은 패키지 관리자는 사용자가 애플리케이션을 수동으로 설치하고 구성하는 수고를 덜어줍니다. 이것은 응용 프로그램에 여러 외부 종속성이있을 때 특히 편리합니다.

Helm은 기본적으로 Kubernetes의 패키지 관리자입니다. 많은 인기있는 소프트웨어 애플리케이션은 Kubernetes에서 상호 의존적 인 컨테이너 그룹으로 실행되어야합니다. Helm은 애플리케이션 또는 서비스가 Kubernetes 내에서 컨테이너 그룹으로 실행되는 방법을 설명하는 정의 메커니즘 인 '차트'를 제공합니다.

고유 한 Helm 차트를 처음부터 만들 수 있으며 내부적으로 배포 할 사용자 지정 앱을 빌드하는 경우 필요할 수 있습니다. 그러나 공통 배포 패턴이있는 인기있는 애플리케이션을 사용하는 경우 누군가 이미 Helm 차트를 작성하여 공식 Helm 차트 저장소에 게시했을 가능성이 있습니다. 공식 Helm 차트를 찾을 수있는 또 다른 곳은 Kubeapps.com 디렉토리입니다.

Kubernetes는 스토리지, 비밀 및 기타 애플리케이션 관련 리소스의 관리를 단순화합니다.

컨테이너는 변경 불가능합니다. 당신이 그들에 넣는 것은 무엇이든 변경되어서는 안됩니다. 그러나 애플리케이션에는 상태가 필요하므로 외부 스토리지 볼륨을 처리 할 수있는 안정적인 방법이 필요합니다. 이는 컨테이너가 앱의 수명 동안 살아 나고, 죽고, 다시 태어나는 방식으로 인해 더욱 복잡해졌습니다.

Kubernetes는 컨테이너와 앱이 다른 리소스와 동일한 분리 된 방식으로 스토리지를 처리 ​​할 수 ​​있도록 추상화를 제공합니다. Amazon EBS 볼륨에서 일반 오래된 NFS 공유에 이르기까지 많은 일반적인 종류의 스토리지는 볼륨이라고하는 Kubernetes 스토리지 드라이버를 통해 액세스 할 수 있습니다. 일반적으로 볼륨은 특정 포드에 바인딩되지만 "영구 볼륨"이라는 볼륨 하위 유형은 포드와 독립적으로 유지해야하는 데이터에 사용할 수 있습니다.

컨테이너는 종종 "비밀"(컨테이너에 하드 코딩하거나 디스크 볼륨에 공개적으로 저장하고 싶지 않은 API 키 또는 서비스 암호와 같은 자격 증명)을 사용하여 작업해야합니다. 이를 위해 Docker 비밀 및 HashiCorp Vault와 같은 타사 솔루션을 사용할 수 있지만 Kubernetes에는 신중하게 구성해야하지만 기본적으로 비밀을 처리하는 자체 메커니즘이 있습니다. 예를 들어 Etcd는 일반 텍스트가 아닌 노드간에 비밀을 보낼 때 SSL / TLS를 사용하도록 구성되어야합니다. 

Kubernetes 애플리케이션은 하이브리드 및 다중 클라우드 환경에서 실행할 수 있습니다.

클라우드 컴퓨팅의 오랜 꿈 중 하나는 모든 클라우드 또는 공용 또는 사설 클라우드의 혼합에서 모든 앱을 실행할 수 있다는 것입니다. 이는 공급 업체 종속을 피하는 것뿐만 아니라 개별 클라우드에 특정한 기능을 활용하기위한 것이기도합니다.

Kubernetes는 여러 지역 및 클라우드에서 여러 클러스터를 서로 동기화 상태로 유지하기 위해 집합 적으로 연합이라고하는 기본 집합을 제공합니다. 예를 들어 특정 앱 배포는 여러 클러스터간에 일관되게 유지 될 수 있으며 다른 클러스터는 서비스 검색을 공유하여 모든 클러스터에서 백엔드 리소스에 액세스 할 수 있습니다. 페더레이션은 여러 클라우드 환경에 걸쳐 있는지 여부에 관계없이 고 가용성 또는 내결함성 Kubernetes 배포를 만드는 데 사용할 수도 있습니다.

페더레이션은 여전히 ​​Kubernetes에 비교적 새로운 기능입니다. 모든 API 리소스가 페더레이션 된 인스턴스에서 아직 지원되는 것은 아니며 업그레이드에는 아직 자동 테스트 인프라가 없습니다. 그러나 이러한 단점은 향후 Kubernetes 버전에서 해결 될 예정입니다.

Kubernetes를 얻을 수있는 곳