Kubernetes: 오픈 소스와 공급업체별

안녕하세요, 제 이름은 Dmitry Krasnov입니다. 저는 XNUMX년 넘게 Kubernetes 클러스터를 관리하고 복잡한 마이크로서비스 아키텍처를 구축해 왔습니다. 올해 초에는 Containerum을 기반으로 Kubernetes 클러스터를 관리하는 서비스를 출시했습니다. 이번 기회에 Kubernetes가 무엇인지, 벤더와의 통합이 오픈소스와 어떻게 다른지 알려드리겠습니다.

우선, 무엇입니까? Kubernetes. 다수의 호스트에 있는 컨테이너를 관리하기 위한 시스템입니다. 그런데 그리스어에서는 "조종사"또는 "조타수"로 번역됩니다. 원래 Google에서 개발한 후 세계 최고의 개발자, 최종 사용자 및 컨테이너 기술 제공업체를 하나로 모으는 국제 비영리 조직인 Cloud Native Computing Foundation에 기술 기여로 기부했습니다.

다수의 컨테이너 관리

이제 이것이 어떤 종류의 컨테이너인지 알아 보겠습니다. 이것은 전체 환경(주로 프로그램이 의존하는 라이브러리)을 갖춘 애플리케이션입니다. 이 모든 것은 아카이브에 패키지되어 있으며 운영 체제에 관계없이 실행하고 테스트할 수 있는 이미지 형태로 제공됩니다. 그러나 문제가 있습니다. 많은 수의 호스트에서 컨테이너를 관리하는 것은 매우 어렵습니다. 이것이 Kubernetes가 만들어진 이유입니다.

컨테이너 이미지는 애플리케이션과 해당 종속성을 나타냅니다. 애플리케이션, 해당 종속성 및 OS 파일 시스템 이미지는 레이어라고 하는 이미지의 서로 다른 부분에 있습니다. 레이어는 다른 컨테이너에 재사용될 수 있습니다. 예를 들어 회사의 모든 애플리케이션은 Ubuntu 기본 계층을 사용할 수 있습니다. 컨테이너를 실행할 때 호스트에 단일 기본 계층의 여러 복사본을 저장할 필요가 없습니다. 이를 통해 이미지 저장 및 전달을 최적화할 수 있습니다.

컨테이너에서 애플리케이션을 실행하려면 필요한 레이어가 서로 겹쳐지고 오버레이 파일 시스템이 형성됩니다. 기록 레이어는 상단에 배치되며 컨테이너가 중지되면 제거됩니다. 이렇게 하면 컨테이너가 실행될 때 애플리케이션이 항상 변경될 수 없는 동일한 환경을 갖게 됩니다. 이는 다양한 호스트 OS에서 환경의 재현성을 보장합니다. Ubuntu이든 CentOS이든 환경은 항상 동일합니다. 또한 컨테이너는 Linux 커널에 내장된 메커니즘을 사용하여 호스트에서 격리됩니다. 컨테이너의 애플리케이션은 호스트 및 인접 컨테이너의 파일, 프로세스를 볼 수 없습니다. 호스트 OS에서 애플리케이션을 분리하면 추가적인 보안 계층이 제공됩니다.

호스트에서 컨테이너를 관리하는 데 사용할 수 있는 도구가 많이 있습니다. 그 중 가장 인기 있는 것은 Docker입니다. 이를 통해 컨테이너의 전체 수명주기를 제공할 수 있습니다. 그러나 하나의 호스트에서만 작동합니다. 여러 호스트에서 컨테이너를 관리해야 하는 경우 Docker는 엔지니어의 삶을 지옥으로 만들 수 있습니다. 이것이 Kubernetes가 만들어진 이유입니다.

Kubernetes에 대한 수요는 바로 여러 호스트의 컨테이너 그룹을 일종의 단일 엔터티로 관리하는 기능 때문입니다. 시스템의 인기는 Kubernetes가 바로 DevOps의 프로세스를 실행하는 데 사용되는 DevOps 또는 개발 운영을 구축할 수 있는 기회를 제공합니다.

그림 1. Kubernetes 작동 방식의 도식적 표현

완전 자동화

DevOps는 기본적으로 개발 프로세스의 자동화입니다. 대략적으로 말하면 개발자는 저장소에 업로드되는 코드를 작성합니다. 그런 다음 이 코드는 모든 라이브러리가 포함된 컨테이너에 즉시 자동으로 수집되어 테스트되고 다음 단계인 스테이징으로 "롤아웃"된 후 즉시 프로덕션으로 전환될 수 있습니다.

Kubernetes와 함께 DevOps를 사용하면 이 프로세스를 자동화하여 개발자의 참여가 거의 없이 진행되도록 할 수 있습니다. 이로 인해 개발자가 자신의 컴퓨터에서 이 작업을 수행할 필요가 없기 때문에 빌드가 훨씬 더 빨라집니다. 그는 단순히 코드 조각을 작성하고 코드를 저장소에 푸시한 후 프로세스를 포함할 수 있는 파이프라인이 시작됩니다. 구축, 테스트, 출시 과정을 거쳐야 합니다. 그리고 이는 모든 커밋에서 발생하므로 테스트는 지속적으로 발생합니다.

동시에, 컨테이너를 사용하면 이 프로그램의 전체 환경이 테스트된 형식으로 정확하게 프로덕션 환경에 출시될 것임을 확신할 수 있습니다. 즉, "어떤 버전은 테스트에 있었고 다른 버전은 프로덕션에 있었는데 우리가 설치했을 때 모든 것이 떨어졌습니다."와 같은 문제가 없을 것입니다. 그리고 오늘날 우리는 하나의 거대한 애플리케이션 대신 수백 개의 작은 애플리케이션이 있는 마이크로서비스 아키텍처를 지향하는 추세를 보이고 있습니다. 이를 수동으로 관리하려면 엄청난 양의 직원이 필요합니다. 이것이 바로 우리가 Kubernetes를 사용하는 이유입니다.

장점, 장점, 장점

플랫폼으로서의 Kubernetes의 장점에 대해 이야기한다면 마이크로서비스 아키텍처 관리의 관점에서 볼 때 Kubernetes는 상당한 이점을 가지고 있습니다.

• 여러 복제본을 관리합니다. 가장 중요한 것은 여러 호스트에 걸쳐 컨테이너를 관리하는 것입니다. 더 중요한 것은 컨테이너의 여러 애플리케이션 복제본을 단일 엔터티로 관리하는 것입니다. 덕분에 엔지니어는 개별 컨테이너에 대해 걱정할 필요가 없습니다. 컨테이너 중 하나가 충돌하면 Kubernetes는 이를 확인하고 다시 시작합니다.
• 클러스터 네트워크. Kubernetes에는 자체 주소 공간이 있는 소위 클러스터 네트워크도 있습니다. 덕분에 각 포드에는 고유한 주소가 있습니다. 하위 포드는 컨테이너가 직접 실행되는 클러스터의 최소 구조 단위로 이해됩니다. 또한 Kubernetes에는 로드 밸런서와 서비스 검색을 결합하는 기능이 있습니다. 이를 통해 수동 IP 주소 관리를 없애고 이 작업을 Kubernetes에 위임할 수 있습니다. 그리고 자동 상태 확인은 문제를 감지하고 트래픽을 작동 중인 포드로 리디렉션하는 데 도움이 됩니다.
• 구성 관리. 많은 수의 애플리케이션을 관리하는 경우 애플리케이션 구성을 관리하기가 어려워집니다. 이를 위해 Kubernetes에는 특별한 ConfigMap 리소스가 있습니다. 이를 통해 구성을 중앙에서 저장하고 애플리케이션을 실행할 때 이를 포드에 노출할 수 있습니다. 이 메커니즘을 사용하면 최소 XNUMX개 또는 XNUMX개의 애플리케이션 복제본에서 구성의 일관성을 보장할 수 있습니다.
• 영구 볼륨. 컨테이너는 본질적으로 변경할 수 없으며 컨테이너가 중지되면 파일 시스템에 기록된 모든 데이터가 삭제됩니다. 그러나 일부 응용 프로그램은 데이터를 디스크에 직접 저장합니다. 이 문제를 해결하기 위해 Kubernetes에는 디스크 스토리지 관리 기능인 영구 볼륨이 있습니다. 이 메커니즘은 데이터용 외부 저장소를 사용하고 영구 저장소, 블록 또는 파일을 컨테이너로 전송할 수 있습니다. 이 솔루션을 사용하면 작업자와 별도로 데이터를 저장할 수 있으므로 동일한 작업자가 고장나는 경우 데이터를 저장할 수 있습니다.
• 로드 밸런서. Kubernetes에서는 배포, StatefulSet 등과 같은 추상 엔터티를 관리하지만 궁극적으로 컨테이너는 일반 가상 머신이나 하드웨어 서버에서 실행됩니다. 그것들은 완벽하지 않으며 언제든지 떨어질 수 있습니다. Kubernetes는 이를 확인하고 내부 트래픽을 다른 복제본으로 리디렉션합니다. 그런데 외부에서 들어오는 트래픽은 어떻게 해야 할까요? 단순히 작업자 중 한 명에게 트래픽을 보내는 경우 충돌이 발생하면 서비스를 사용할 수 없게 됩니다. 이 문제를 해결하기 위해 Kubernetes에는 Load Balancer와 같은 서비스가 있습니다. 클러스터의 모든 작업자에 대해 외부 클라우드 밸런서를 자동으로 구성하도록 설계되었습니다. 이 외부 밸런서는 외부 트래픽을 작업자에게 전달하고 상태 자체를 모니터링합니다. 한 명 이상의 작업자를 사용할 수 없게 되면 트래픽이 다른 작업자에게 리디렉션됩니다. 이를 통해 Kubernetes를 사용하여 고가용성 서비스를 생성할 수 있습니다.

Kubernetes는 마이크로서비스 아키텍처를 실행할 때 가장 잘 작동합니다. 시스템을 고전적인 아키텍처로 구현하는 것은 가능하지만 의미가 없습니다. 애플리케이션이 여러 복제본에서 실행될 수 없는 경우 Kubernetes에서 또는 그렇지 않은 경우 어떤 차이가 있습니까?

오픈소스 쿠버네티스

오픈 소스 Kubernetes는 훌륭한 기능입니다. 설치했는데 작동합니다. 자체 하드웨어 서버, 자체 인프라에 배포하고 모든 애플리케이션이 실행될 마스터와 작업자를 설치할 수 있습니다. 그리고 가장 중요한 것은 이 모든 것이 무료라는 것입니다. 그러나 뉘앙스가 있습니다.

• 첫 번째는 이 모든 것을 배포하고 지원할 관리자와 엔지니어의 지식과 경험에 대한 수요입니다. 클라이언트는 클러스터에서 완전한 행동의 자유를 누리기 때문에 클러스터의 성능에 대한 책임은 클라이언트 자신에게 있습니다. 그리고 여기서 모든 것을 깨는 것은 매우 쉽습니다.
• 두 번째는 통합이 부족하다는 것입니다. 널리 사용되는 가상화 플랫폼 없이 Kubernetes를 실행하면 프로그램의 모든 이점을 얻을 수 없습니다. 영구 볼륨 및 로드 밸런서 서비스 사용과 같은 것입니다.

그림 2. k8s 아키텍처

공급업체의 Kubernetes

클라우드 공급자와의 통합은 두 가지 옵션을 제공합니다.

• 첫째, “클러스터 생성” 버튼을 클릭하기만 하면 이미 구성되어 사용할 수 있는 클러스터를 얻을 수 있습니다.
• 둘째, 공급업체가 직접 클러스터를 설치하고 클라우드와의 통합을 설정합니다.

여기서 일어나는 일. 클러스터를 시작하는 엔지니어는 필요한 작업자 수와 매개변수(예: 각각 CPU 5개, RAM 10GB, 디스크 16GB를 갖춘 작업자 100명)를 지정합니다. 그 후에는 이미 형성된 클러스터에 액세스할 수 있습니다. 이 경우 로드가 실행되는 작업자는 완전히 클라이언트로 전송되지만 전체 관리 플레인은 공급업체의 책임하에 있습니다(서비스가 관리형 서비스 모델에 따라 제공되는 경우).

그러나 이 계획에는 단점이 있습니다. 관리 플레인이 공급업체에 남아 있기 때문에 공급업체는 클라이언트에 대한 전체 액세스 권한을 부여하지 않으며 이는 Kubernetes 작업의 유연성을 감소시킵니다. 클라이언트가 LDAP를 통한 인증과 같은 일부 특정 기능을 Kubernetes에 추가하려고 하지만 관리 플레인 구성에서 이를 허용하지 않는 경우가 있습니다.

그림 3. 클라우드 제공업체의 Kubernetes 클러스터 예

선택할 것: 오픈 소스 또는 공급업체

그렇다면 Kubernetes 오픈소스 또는 공급업체가 특정합니까? 오픈 소스 Kubernetes를 사용하면 사용자는 원하는 대로 작업을 수행할 수 있습니다. 그러나 발에 총을 쏠 가능성이 높습니다. 벤더의 경우 모든 것이 회사를 위해 고려되고 구성되기 때문에 더 어렵습니다. 오픈소스 Kubernetes의 가장 큰 단점은 전문가가 필요하다는 점입니다. 공급업체 옵션을 사용하면 회사는 이러한 문제에서 벗어날 수 있지만 전문가에게 비용을 지불할지 공급업체에 비용을 지불할지 결정해야 합니다.

글쎄, 장점은 분명하고 단점도 알려져 있습니다. 한 가지는 변함이 없습니다. Kubernetes는 많은 컨테이너의 관리를 자동화하여 많은 문제를 해결합니다. 그리고 오픈 소스 또는 공급업체 중에서 무엇을 선택할 것인지는 모두가 스스로 결정합니다.

이 기사는 #CloudMTS 제공업체의 Containerum 서비스 설계를 주도하는 Dmitry Krasnov가 작성했습니다.

출처 : habr.com