이 문서에서는 Google Distributed Cloud (GDC) 에어 갭의 워크로드 관리에 대한 개요를 제공합니다. 여기서 다루는 주제는 다음과 같습니다.
일부 워크로드 배포 설계가 권장되지만, 규정된 대로 정확하게 따를 필요는 없습니다. 각 GDC 유니버스에는 사례별로 충족해야 하는 고유한 요구사항과 고려사항이 있습니다.
이 문서는 조직 내에서 리소스 관리를 담당하는 플랫폼 관리자 그룹의 IT 관리자와 GDC 유니버스에서 애플리케이션 개발 및 유지보수를 담당하는 애플리케이션 운영자 그룹의 애플리케이션 개발자를 대상으로 합니다.
자세한 내용은 GDC 에어 갭 문서의 잠재고객을 참조하세요.
워크로드 배포 위치
GDC 플랫폼에서 가상 머신 (VM) 워크로드와 컨테이너 워크로드를 배포하는 작업은 서로 다릅니다. 다음 다이어그램은 조직의 데이터 영역 레이어 내에서 워크로드 분리를 보여줍니다.
VM 기반 워크로드는 VM 내에서 작동합니다. 반대로 컨테이너 워크로드는 Kubernetes 클러스터 내에서 작동합니다. VM과 Kubernetes 클러스터 간의 근본적인 분리는 VM 워크로드와 컨테이너 워크로드 간에 격리 경계를 제공합니다. 자세한 내용은 리소스 계층 구조를 참조하세요.
다음 섹션에서는 각 워크로드 유형과 배포 수명 주기의 차이점을 소개합니다.
VM 기반 워크로드
VM을 만들어 VM 기반 워크로드를 호스팅할 수 있습니다. VM 기반 워크로드 요구사항을 가장 잘 충족할 수 있도록 VM의 형태와 크기에 대한 다양한 구성 옵션이 있습니다. VM 워크로드가 여러 개 있을 수 있는 프로젝트에서 VM을 만들어야 합니다. VM은 프로젝트의 하위 리소스입니다. 자세한 내용은 VM 개요를 참조하세요.
VM 기반 워크로드만 포함하는 프로젝트에는 Kubernetes 클러스터가 필요하지 않습니다. 따라서 VM 기반 워크로드에 Kubernetes 클러스터를 프로비저닝할 필요가 없습니다.
컨테이너 기반 워크로드
컨테이너 기반 워크로드를 Kubernetes 클러스터의 포드에 배포할 수 있습니다. Kubernetes 클러스터는 다음 노드 유형으로 구성됩니다.
제어 영역 노드: 예약, etcd, API 서버와 같은 관리 서비스를 실행합니다.
작업자 노드: 포드 및 컨테이너 애플리케이션을 실행합니다.
Kubernetes 클러스터에는 두 가지 구성 유형이 있습니다.
- 공유 클러스터: 여러 프로젝트에 걸쳐 있을 수 있고 단일 프로젝트에서 관리하지 않지만 프로젝트에 연결되는 조직 범위의 Kubernetes 클러스터입니다.
- 표준 클러스터: 프로젝트 내에서 클러스터 리소스를 관리하고 여러 프로젝트에 걸쳐 있을 수 없는 프로젝트 범위의 Kubernetes 클러스터입니다.
자세한 내용은 Kubernetes 클러스터 구성을 참조하세요.
공유 클러스터는 조직 범위이고 표준 클러스터는 프로젝트 범위이므로 Kubernetes 클러스터는 다양한 리소스 계층 구조 옵션을 제공합니다. 이는 Kubernetes 클러스터가 VM과 비교하여 갖는 근본적인 차이점입니다. VM은 프로젝트의 하위 리소스이며 프로젝트 외부에서 작동하도록 구성할 수 없습니다. Kubernetes 클러스터 인프라를 설계하는 방법에 대한 자세한 내용은 Kubernetes 클러스터 설계 권장사항을 참조하세요.
Kubernetes 클러스터 내의 포드 예약의 경우 GDC는 예약, 선점, 제거의 일반적인 Kubernetes 개념을 채택합니다. 클러스터 내에서 포드를 예약하는 권장사항은 워크로드의 요구사항에 따라 다릅니다.
Kubernetes 클러스터에 대한 자세한 내용은 Kubernetes 클러스터 개요를 참조하세요. Kubernetes 클러스터에서 컨테이너를 관리하는 방법에 대한 자세한 내용은 GDC의 컨테이너 워크로드를 참조하세요.
Kubernetes 클러스터 설계 권장사항
이 섹션에서는 Kubernetes 클러스터 설계 권장사항을 소개합니다.
각 권장사항을 고려하여 컨테이너 워크로드 수명 주기를 위한 복원력 있는 클러스터 설계를 만드세요.
소프트웨어 개발 환경별로 별도의 클러스터 만들기
소프트웨어 개발 환경별로 별도의 프로젝트를 만드는 것 외에도
소프트웨어 개발 환경별로 별도의 Kubernetes 클러스터를 설계하는 것이 좋습니다. 소프트웨어 개발 환경 은 지정된 수명 주기 단계에 해당하는 모든 작업을 위한 GDC 유니버스 내의 영역입니다. 예를 들어 조직에 development, staging, production이라는 세 개의 소프트웨어 개발 환경이 있는 경우 각 환경에 대해 별도의 Kubernetes 클러스터 집합을 만들고 필요에 따라 각 클러스터에 프로젝트를 연결할 수 있습니다.
단일 프로젝트 범위의 사전 프로덕션 수명 주기에서는 표준 클러스터를 사용하는 것이 좋습니다. 이렇게 하면 테스트와 관련된 파괴적인 프로세스를 프로덕션 프로젝트에서 격리할 수 있습니다. 공유 클러스터는 여러 프로젝트에 걸쳐 있을 수 있는 프로덕션 환경에 적합합니다. 여러 프로젝트에 걸쳐 있는 프로덕션 워크로드를 호스팅하는 공유 클러스터는 단일 프로젝트 범위의 표준 클러스터가 워크로드를 프로덕션 환경으로 직접 승격할 수 있는 공유 배포 영역을 제공합니다.
각 소프트웨어 개발 환경에 대해 정의된 표준 클러스터는 소프트웨어 개발 환경 내의 사전 프로덕션 워크로드가 해당 클러스터로 제한된다고 가정합니다. Kubernetes 클러스터는 여러 노드 풀로 더 세분화되거나 워크로드 격리를 위해 테인트를 사용할 수 있습니다.
소프트웨어 개발 환경별로 Kubernetes 클러스터를 분리하면 프로덕션 워크로드와 비프로덕션 워크로드 간에 리소스 소비, 액세스 정책, 유지보수 이벤트, 클러스터 수준 구성 변경사항을 격리할 수 있습니다.
다음 다이어그램은 프로젝트, 클러스터, 소프트웨어 개발 환경, 서로 다른 노드 풀에서 제공하는 머신 클래스에 걸쳐 있는 여러 워크로드의 샘플 Kubernetes 클러스터 설계를 보여줍니다.
이 샘플 아키텍처는 개발, 스테이징, 프로덕션 소프트웨어 개발 환경 내의 워크로드가 클러스터를 공유할 수 있다고 가정합니다. 각 환경에는 별도의 표준 클러스터가 있으며, 이는 서로 다른 머신 클래스 요구사항을 충족하기 위해 여러 노드 풀로 더 세분화됩니다. 공유 클러스터는 모든 소프트웨어 개발 환경에 걸쳐 있으며 모든 환경에 공통 배포 영역을 제공합니다.
또는 소프트웨어 개발 환경별로 여러 표준 클러스터를 설계하는 것은 다음과 같은 시나리오와 같은 컨테이너 작업에 유용합니다.
- 특정 Kubernetes 버전에 고정된 워크로드가 있으므로 서로 다른 버전의 여러 클러스터를 유지합니다.
- 백업 정책과 같이 서로 다른 클러스터 구성 요구사항이 있는 워크로드가 있으므로 서로 다른 구성으로 여러 클러스터를 만듭니다.
- 파괴적인 버전 업그레이드 또는 블루-그린 배포 전략을 용이하게 하기 위해 클러스터의 사본을 병렬로 실행합니다.
- 클러스터 내에서 API 서버 또는 기타 단일 장애 지점을 제한할 위험이 있는 실험적 워크로드를 빌드하므로 기존 워크로드와 격리합니다.
컨테이너 작업에서 설정한 요구사항에 맞게 소프트웨어 개발 환경을 조정해야 합니다.
더 적은 수의 클러스터 만들기
효율적인 리소스 사용을 위해 소프트웨어 개발 환경과 컨테이너 작업을 분리하기 위한 요구사항을 충족하는 최소한의 Kubernetes 클러스터를 설계하는 것이 좋습니다. 각 추가 클러스터에는 필요한 추가 제어 영역 노드와 같은 추가 오버헤드 리소스 소비가 발생합니다. 따라서 워크로드가 많은 더 큰 클러스터는 작은 클러스터가 많은 것보다 기본 컴퓨팅 리소스를 더 효율적으로 사용합니다.
구성이 비슷한 클러스터가 여러 개 있으면 클러스터 용량을 모니터링하고 클러스터 간 종속 항목을 계획하는 데 추가 유지보수 오버헤드가 발생합니다.
클러스터가 용량에 가까워지면 새 클러스터를 만드는 대신 클러스터에 노드를 추가하는 것이 좋습니다.
클러스터 내에서 더 적은 수의 노드 풀 만들기
효율적인 리소스 사용을 위해 Kubernetes 클러스터 내에서 더 적은 수의 더 큰 노드 풀을 설계하는 것이 좋습니다.
여러 노드 풀을 구성하는 것은 다른 노드 풀과 다른 머신 클래스가 필요한 포드를 예약해야 할 때 유용합니다. 워크로드에 필요한 각 머신 클래스에 대해 노드 풀을 만들고 노드 용량을 자동 확장으로 설정하여 컴퓨팅 리소스를 효율적으로 사용할 수 있도록 합니다.