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