이 문서에서는 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 클러스터가 VM과 비교해 갖는 근본적인 차이점입니다. VM은 프로젝트의 하위 리소스인 반면 Kubernetes 클러스터는 조직의 하위 리소스로 작동하므로 여러 프로젝트에 연결할 수 있습니다.
Kubernetes 클러스터 내의 포드 예약의 경우 GDC는 예약, 선점, 제거에 관한 일반적인 Kubernetes 개념을 채택합니다. 클러스터 내에서 포드를 예약하는 권장사항은 워크로드의 요구사항에 따라 다릅니다.
Kubernetes 클러스터에 대한 자세한 내용은 Kubernetes 클러스터 개요를 참고하세요. Kubernetes 클러스터에서 컨테이너를 관리하는 방법에 관한 자세한 내용은 GDC의 컨테이너 워크로드를 참고하세요.
Kubernetes 클러스터 설계 권장사항
이 섹션에서는 Kubernetes 클러스터 설계에 관한 권장사항을 소개합니다.
각 권장사항을 고려하여 컨테이너 워크로드 수명 주기에 복원력이 있는 클러스터 설계를 설계하세요.
소프트웨어 개발 환경별로 별도의 클러스터 만들기
소프트웨어 개발 환경별 별도의 프로젝트 외에도 소프트웨어 개발 환경별로 별도의 Kubernetes 클러스터를 설계하는 것이 좋습니다. 소프트웨어 개발 환경은 지정된 수명 주기 단계에 해당하는 모든 작업을 위해 GDC 유니버스 내에 있는 영역입니다. 예를 들어 조직에 development 및 production라는 두 개의 소프트웨어 개발 환경이 있는 경우 각 환경에 대해 별도의 Kubernetes 클러스터 집합을 만들고 필요에 따라 각 클러스터에 프로젝트를 연결할 수 있습니다. 사전 프로덕션 및 프로덕션 수명 주기에 있는 Kubernetes 클러스터에 여러 프로젝트를 연결하는 것이 좋습니다.
각 소프트웨어 개발 환경에 대해 정의된 클러스터는 소프트웨어 개발 환경 내의 워크로드가 클러스터를 공유할 수 있다고 가정합니다. 그런 다음 적절한 환경의 Kubernetes 클러스터에 프로젝트를 할당합니다. Kubernetes 클러스터는 여러 노드 풀로 더 세분화되거나 워크로드 격리를 위해 taint를 사용할 수 있습니다.
소프트웨어 개발 환경별로 Kubernetes 클러스터를 분리하면 프로덕션 워크로드와 비프로덕션 워크로드 간에 리소스 소비, 액세스 정책, 유지관리 이벤트, 클러스터 수준 구성 변경사항을 격리할 수 있습니다.
다음 다이어그램은 프로젝트, 클러스터, 소프트웨어 개발 환경, 머신 클래스에 걸쳐 있는 여러 워크로드의 샘플 Kubernetes 클러스터 설계를 보여줍니다.
이 샘플 아키텍처에서는 프로덕션 및 개발 소프트웨어 개발 환경 내의 워크로드가 클러스터를 공유할 수 있다고 가정합니다. 각 환경에는 별도의 Kubernetes 클러스터가 있으며, 이는 다양한 머신 클래스 요구사항에 따라 여러 노드 풀로 세분화됩니다.
또는 다음과 같은 시나리오와 같은 컨테이너 작업에 여러 Kubernetes 클러스터를 설계하는 것이 유용합니다.
- 특정 Kubernetes 버전에 고정된 워크로드가 있으므로 서로 다른 버전의 클러스터를 유지합니다.
- 백업 정책과 같은 다양한 클러스터 구성이 필요한 워크로드가 있어 구성이 다른 여러 클러스터를 만듭니다.
- 중단이 발생하는 버전 업그레이드 또는 블루-그린 배포 전략을 용이하게 하기 위해 클러스터의 복사본을 병렬로 실행합니다.
- API 서버 또는 클러스터 내 다른 단일 장애점을 제한할 위험이 있는 실험적 워크로드를 빌드하므로 기존 워크로드와 격리합니다.
다음 다이어그램은 이전 섹션에 설명된 컨테이너 작업과 같은 요구사항으로 인해 소프트웨어 개발 환경별로 여러 클러스터가 구성된 예를 보여줍니다.
클러스터 수를 줄입니다.
효율적인 리소스 사용을 위해 소프트웨어 개발 환경과 컨테이너 작업을 분리하는 요구사항을 충족하는 최소한의 Kubernetes 클러스터를 설계하는 것이 좋습니다. 클러스터가 추가될 때마다 필요한 추가 제어 영역 노드와 같은 추가 오버헤드 리소스 소비가 발생합니다. 따라서 워크로드가 많은 대규모 클러스터는 소규모 클러스터가 여러 개인 경우보다 기본 컴퓨팅 리소스를 더 효율적으로 활용합니다.
구성 유사한 클러스터가 여러 개 있으면 클러스터 용량을 모니터링하고 클러스터 간 종속 항목을 계획하는 데 추가 유지관리 오버헤드가 발생합니다.
클러스터가 용량에 가까워지면 새 클러스터를 만드는 대신 클러스터에 노드를 추가하는 것이 좋습니다.
클러스터 내에서 노드 풀을 더 적게 만들기
효율적인 리소스 사용을 위해 Kubernetes 클러스터 내에 더 적은 수의 더 큰 노드 풀을 설계하는 것이 좋습니다.
여러 노드 풀을 구성하는 것은 다른 머신 클래스가 필요한 포드를 예약해야 할 때 유용합니다. 워크로드에 필요한 각 머신 클래스에 대해 노드 풀을 만들고 컴퓨팅 리소스를 효율적으로 사용할 수 있도록 노드 용량을 자동 확장으로 설정합니다.