안녕, 친구들! VMware Tanzu Community Edition은 Managed 및 Unmanaged 두 가지 Kubernetes 클러스터 구성 옵션을 제공합니다. 이 블로그에서는 관리되는 클러스터(Managed Cluster)와 관리되지 않는 클러스터(Unmanaged Cluster), 몇 가지 장점과 단점, 그리고 각 유형이 가장 잘 작동하는 사용 사례를 비교하여 설명합니다.
Back to Basics – Kubernetes 클러스터
우리가 같은 입장이라는 것을 확실히 하기 위해, 저는 쿠버네티스 클러스터를 구성하는 것에 대한 높은 수준의 기본 사항을 다루고자 합니다. 그러나 먼저, 이 경우 클러스터라는 단어가 여러 컴퓨터 또는 가상 시스템을 의미할 필요가 없습니다. 여러 개의 실행 중인 컨테이너가 될 수 있습니다.
쿠버네티스 클러스터의 주요 분할 중 하나는 Control Plan 대 Node(이전에는 Master Node 대 Worker Node)이다. Kubernetes 설명서에서 다음을 참조하십시오.
Node: “Kubernetes 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 일련의 작업자 시스템으로 구성됩니다. 작업자 노드는 애플리케이션 워크로드의 구성 요소인 파드를 호스팅합니다.”
Control Plane: “제어부는 클러스터의 작업자 노드와 포드를 관리합니다.” 일반적으로 제어면은 여러 “기계”에 걸쳐 분산됩니다.
컨트롤 플레인과 노드가 동일한 시스템에 있을 수 있지만 일반적으로 쿠버네티스 클러스터는 하나 이상의 컨트롤 플레인과 하나 이상의 노드로 구성됩니다.
Unmanaged Cluster
Unmanaged Cluster는 단순히 Kubeadm 또는 vRealize Automation과 같은 즐겨 사용하는 툴을 사용하여 구성된 일반 Kubernetes 클러스터입니다. Tanzu Community Edition의 경우 Tanzu CLI에서 단일 명령을 사용할 수 있으며 로컬 시스템에서 Kubernetes-in-Docker(kind) 클러스터를 회전시킵니다. Kind 클러스터에서 Nodes를 포함하여 위에서 설명한 모든 부분은 실제로 로컬 컨테이너 엔진(예: Docker Desktop)에서 실행되는 컨테이너입니다.
Tanzu Community Edition에서 관리되지 않는 클러스터의 몇 가지 이점과 단점을 살펴보고 사용 사례를 살펴보겠습니다.
장점과 단점
관리되지 않는 클러스터의 좋은 기능 중 일부는 다음과 같습니다.
- 컨테이너 한 개에 불과하기 때문에 정말 빠른 시동과 파괴가 가능합니다. 친절한 클러스터는 루트 컨테이너를 시작한 다음 해당 루트 컨테이너 안에 있는 클러스터의 모든 부분을 불러옵니다.
- 단일 “클러스터”와 컨테이너만 불러오기 때문에 리소스 사용량이 상대적으로 적습니다. 컨테이너의 효율적인 특성을 고려할 때, 우리는 컨테이너의 서비스를 실행하는 데 필요한 메모리만 사용할 것입니다.
- 모든 조각은 루트 컨테이너에서 실행되는 컨테이너로, 단일 컨테이너를 삭제하는 것처럼 쉽게 정리할 수 있습니다.
- 컨테이너 이미지가 다운로드되면 모든 작업을 느린 인터넷 연결 또는 낮은 인터넷 연결로 수행할 수 있습니다.
- 클라우드 제공자에게 비용을 지불하지 않아도 됩니다.
이러한 기능을 얻으려면 다음과 같은 몇 가지 절충안을 제시해야 합니다.
- 이러한 클러스터는 수동 단계 또는 자동화 도구를 사용하여 일회성 방식으로 관리해야 합니다.
- 현재 클러스터는 로컬 시스템에서만 실행할 수 있습니다. 컴퓨터에 컨테이너 엔진이 없거나 리소스가 충분하지 않으면 이 작업은 작동하지 않습니다.
- 클러스터에 노드 또는 여러 컨트롤 플레인 서비스 인스턴스를 추가하면 루트 컨테이너에 컨테이너만 추가되므로 진정한 확장 또는 고가용성(HA)을 얻을 수 없습니다. 오류 해결과 같은 작업을 시뮬레이션하고 테스트할 수 있지만 이 오류는 해당 루트 컨테이너 내에서만 발생합니다.
- 관리되지 않는 클러스터는 여러 가지 측면에서 관리 클러스터와 근본적으로 다르므로 관리된 개발, 스테이징 또는 프로덕션 클러스터를 정확하게 나타내지 않습니다.
사용 사례
관리되지 않는 클러스터의 일반적인 사용 사례는 다음과 같습니다.
- 빠른 스핀업 및 해체 속도를 고려할 때 관리되지 않는 클러스터는 Kubernetes와 Tanzu의 기본 사항을 학습하는 데 완벽한 플랫폼입니다. 이 방법을 사용하면 빠르게 시작할 수 있으며 설치를 잘못하면 클러스터를 삭제하고 다시 생성하는 데 많은 비용이 들지 않습니다.
- 클러스터 설정 및 정리의 속도와 용이성을 고려할 때 클라우드 공급자에서 실행되는 클러스터에서 시도하기 전에 관리되지 않는 클러스터에서 로컬 실험을 수행하는 것도 매우 적합합니다.
- 코드를 빨리 보는 것이 중요한 지역 개발도 마찬가지입니다. 모든 것이 당신의 로컬 머신에 있기 때문에 디버거를 첨부하고 파일로 작업하는 것도 더 빠를 것이다.
- 응용 프로그램 컨테이너가 Kubernetes에서 실행되는지 여부와 상태 시도용 YAML을 작성하는 방법을 테스트하려면 관리되지 않는 클러스터가 좋습니다.
- 파이프라인의 비생산 유효성 검사 부분에서 일회용 Tanzu/Kubernetes 인스턴스가 필요한 CI/CD 파이프라인은 관리되지 않는 클러스터에서 잘 처리됩니다. 이 사용 사례는 관리되지 않는 클러스터 아키텍처의 주요 동기 중 하나였습니다.
Managed Cluster
관리형 클러스터(Managed Cluster)는 선언형 인프라, Kubernetes, 사용자 지정 리소스 정의 및 Kubernetes Cluster API를 통해 얻을 수 있는 모든 이점을 활용하므로 Kubernetes 클러스터를 사용하여 클러스터를 관리할 수 있습니다. 기본 아이디어는 하나의 Kubernetes 클러스터(관리 클러스터)를 생성한 다음 이 클러스터를 사용하여 모든 작업을 수행하는 다른 Kubernetes 클러스터(워크로드 클러스터)를 생성하고 관리하는 것입니다.
관리 클러스터는 Kubernetes Cluster API를 사용하여 다른 Kubernetes 클러스터의 전체 수명 주기를 관리합니다. 작업량 클러스터는 모든 응용 프로그램, 데이터베이스 및 기타 컨테이너형을 실행하는 곳입니다. 일반적으로 관리 클러스터는 모든 워크로드 클러스터와 별도의 시스템/인프라스트럭처에 있습니다. 이는 클러스터를 관리하는 작업뿐이기 때문입니다.
워크로드 클러스터가 여러 개인 관리 클러스터는 대부분의 사용 사례에 권장되는 일반적인 패턴입니다.
장점과 단점
이러한 유형의 아키텍처를 사용하면 다음과 같은 많은 이점을 얻을 수 있습니다.
- 제어 영역 및 작업자 노드(관리 및 워크로드 클러스터 모두)는 실제로 여러 인프라 노드에 존재할 수 있습니다. 따라서 진정한 HA 및 확장성을 실현할 수 있습니다.
- 셸 스크립트나 다른 필수 기반 인프라 생성 기법과 달리 클러스터 생성은 선언적으로 수행될 수 있습니다. 워크로드 클러스터에서 사용할 수 있는 리소스를 명시하면 관리 클러스터가 이를 처리합니다.
- 워크로드 클러스터를 생성하는 간단하고 쉬운 명령이 있습니다.
- 관리 클러스터는 노드 업그레이드 또는 확장과 같은 워크로드 클러스터 관리 작업을 단일 명령으로 단순화합니다. 관리 클러스터는 처리해야 하는 모든 부분과 리소스를 파악합니다.
- 관리 클러스터를 사용하여 모든 워크로드 클러스터를 관리하므로 클러스터를 쿼리하고 관리할 수 있는 중앙 집중식 공간이 확보됩니다.
- 관리 클러스터는 워크로드 클러스터를 생성하는 데 필요한 인증 정보를 저장합니다. 최종 사용자에게 해당 관리 클러스터에 대한 액세스 권한을 부여하면 클라우드 제공자 자격 증명이 표시되지 않고 워크로드 클러스터를 스핀업할 수 있습니다.
- 관리 클러스터 또는 관리되지 않는 클러스터를 생성하는 것과 달리 위임된 사용자는 워크로드 클러스터를 생성하는 데 시스템에 Docker가 필요하지 않습니다. 대신 kubectl만 있으면 됩니다.
이러한 이점에는 다음과 같은 단점도 있습니다.
- 관리 클러스터는 인프라의 관리, 지원 및 비용 발생을 위한 또 다른 Kubernetes 클러스터입니다. 물론 관리 클러스터는 일반적으로 상대적으로 작지만 오버헤드는 여전히 존재합니다.
- 관리 클러스터의 중요성을 고려할 때 이 관리 클러스터에서 워크로드를 실행하지 않는 것이 좋습니다. 또한 고가용성을 보장하기 위해 일반적으로 관리 클러스터에 대해 여러 제어부 노드를 실행합니다.
- 특히 관리 클러스터 없이 시작할 때는 관리되지 않는 Tanzu Community Edition 클러스터를 프로비저닝하는 것보다 워크로드 클러스터를 프로비저닝하는 데 시간이 더 오래 걸립니다. 관리 클러스터가 이미 존재하더라도 클라우드 제공자에서 인프라를 프로비저닝해야 하므로 시간이 더 오래 걸립니다. 이는 로컬 시스템에서 컨테이너 회전 속도보다 느립니다.
사용 사례
이러한 일련의 트레이드오프를 통해 이 아키텍처의 이점을 얻을 수 있는 중요한 사용 사례가 있습니다.
- 운영 Tanzu 클러스터는 항상 관리형 클러스터 아키텍처를 사용해야 합니다.
- 프로덕션 클러스터와 일치하도록 개발 클러스터가 필요한 경우 관리 클러스터는 환경 간의 유사성을 더욱 높일 수 있습니다.
- 여러 프로덕션, 스테이징 및 개발 Kubernetes 클러스터(기본적으로 워크로드 클러스터 단위)를 실행하는 것은 모든 클러스터 정보와 방법을 중앙 집중화하여 정보를 쿼리하고 업데이트하기 때문에 주요 사용 사례 중 하나입니다.
- 사용자가 자신의 워크로드 클러스터를 생성할 수 있도록 허용하고 비용을 단일 클라우드 공급자 자격 증명 집합에 묶으면 이 패턴이 유용할 수 있습니다. 중요한 공급자 자격 증명을 사용자에게 노출하지 않아도 되므로 사용자가 클라우드 공급자에서 원하는 모든 작업을 수행할 수 있습니다.
Take Home
본 게시물에서는 많은 내용을 다루었지만, Tanzu와 최신 앱 툴 벨트에 추가할 수 있는 두 가지 주요 툴에 대해 보다 명확하게 이해할 수 있었습니다. 이제 필요에 따라 빠르고 가벼운 관리되지 않는 Tanzu 클러스터를 사용할 수 있습니다. 이 클러스터는 로컬 컴퓨터에서 작업하기에 매우 적합합니다. 또는 로컬 머신에서 즐겨찾는 클라우드 프로바이더에 이르기까지 어디에서나 작동하는 관리형 클러스터 아키텍처에서 운영 중심의 관리 스타일을 선택할 수 있습니다.
Tanzu Community Edition의 이 새로운 도구를 가지고 재미있게 놀고, 여러분의 의견을 꼭 들려주세요!
출처 : https://tanzucommunityedition.io/posts/managed-unmanaged-clusters-tanzu-community-edition/
