Fleet 리소스 계획

Fleet 관리 개요에서 배운 것처럼 Fleet는 대규모로 Kubernetes 클러스터를 관리, 구성, 보호하는 그룹화 메커니즘입니다. Fleet은 멀티 클러스터 환경에서 반복 작업을 수행할 필요가 없고 대규모 클러스터 그룹에 대해 일관되고 포괄적인 관측 가능성을 제공하는 강력한 도구입니다. 여러 GKE Enterprise 기능은 Fleet를 통해서만 사용 가능합니다.

Fleet을 만드는 데 사용하는 그룹화 전략은 조직의 기술 및 비즈니스 니즈에 따라 다를 수 있습니다. 예를 들어 한 조직에서 실행되는 애플리케이션 유형에 따라 클러스터를 그룹화하는 반면, 다른 조직에서는 리전, 환경 또는 기타 관련 요소별로 클러스터를 그룹화할 수 있습니다. 모든 조건이 동일하다면 조직 내에서 Fleet를 필요한 만큼 적게 포함하는 것이 편리합니다.

이 가이드는 조직에서 Fleet를 시작하려는 클라우드 설계자를 대상으로 합니다. 클러스터를 Fleet으로 구성하는 방법에 대한 다음과 같은 실용적인 안내를 제공합니다.

• 완전히 새로운 클러스터를 만들려는 경우
• 기존 클러스터로 Fleet을 만들려는 경우

여기에 설명된 패턴은 많은 조직에 적합하지만 이것이 Fleet를 계획하는 유일한 방법은 아닙니다. Fleet은 유연하며 클러스터에 다른 그룹화 패턴을 사용할 수도 있습니다.

이 가이드를 읽기 전에 Fleet 관리 개요에 설명된 개념을 숙지해야 합니다. 또한 이 가이드에서는 사용자가 기본 Kubernetes 개념과 Google Cloud 리소스 계층 구조에 익숙하다고 가정합니다.

Fleet 및 리소스 제한사항

Fleet을 만들 때 다음과 같은 일반적인 제한사항이 적용됩니다.

• 지정된 Google Cloud 프로젝트에는 연결된 Fleet 하나만 있을 수 있습니다(또는 Fleet 없음). 단, 해당 Fleet에는 여러 프로젝트의 클러스터가 포함될 수 있습니다. Fleet과 연결된 프로젝트를 Fleet의 Fleet 호스트 프로젝트라고 합니다.
• 클러스터는 한 번에 Fleet 하나에만 속할 수 있습니다.
• Fleet의 클러스터 수에 대한 기본 한도는 250개이지만 필요한 경우 한도 상향을 요청할 수 있습니다.

여러 가지 이유로 같은 프로젝트에 클러스터를 여러 개 배치하는 것이 편리할 수 있습니다. 하지만 프로젝트에 구성할 클러스터를 계획할 때는 다음 한도를 고려하세요.

• 단일 프로젝트에서는 VM 32,000개를 초과할 수 없습니다. 이보다 많은 VM이 필요할 것으로 예상되면 프로젝트를 더 많이 사용하는 것이 좋습니다.
• Virtual Private Cloud(VPC) 네트워크에는 비공개 클러스터 75개를 초과할 수 없습니다.
• 멀티 클러스터 인그레스 또는 멀티 클러스터 게이트웨이를 사용하려면 프로젝트의 MultiClusterIngress 및 MultiClusterService 리소스 한도를 고려하세요.

일반 원칙

다음은 Fleet에서 클러스터를 그룹화할지 여부를 결정할 때 자문해야 하는 일반적인 질문입니다. 다음 섹션에서는 이러한 내용이 적용되는 방식을 자세히 살펴봅니다.

• 리소스가 서로 관련되어 있나요?
  • 서비스 간 통신이 많은 리소스는 Fleet에서 함께 관리할 경우에 가장 효과적입니다.
  • 같은 배포 환경(예: 프로덕션 환경)의 리소스는 Fleet에서 함께 관리되어야 합니다.
• 리소스를 누가 관리하나요?
  • Fleet의 무결성을 보장하려면 리소스를 통합(또는 최소한 상호 신뢰) 제어하는 것이 중요합니다.

새 클러스터의 Fleet 계획

이 섹션에서는 애플리케이션 집합이 알고 있을 때 Fleet을 계획하는 방법을 설명하지만 해당 애플리케이션을 배포할 위치를 유연하게 선택할 수 있습니다. 이는 아직 해당 애플리케이션을 개발하지 않았거나 다른 컨테이너 플랫폼에서 마이그레이션하기 때문일 수 있습니다. 또는 이미 기존 클러스터에서 애플리케이션이 실행되고 있지만 원하는 아키텍처를 달성하기 위해 애플리케이션을 새 클러스터로 이동할 수 있습니다.

Fleet가 식별되면 Fleet별로 새 프로젝트를 만들고 각 프로젝트에서 Fleet를 만들고 원하는 Fleet에 클러스터를 만들고 등록할 수 있습니다.

워크로드 감사

배포하려는 모든 Kubernetes 워크로드(예: 배포) 목록으로 시작합니다. 리터럴 목록일 필요는 없습니다. 필요한 워크로드만 파악하면 됩니다. 그런 다음 이 섹션의 나머지 단계를 수행하여 필요한 최소 그룹 집합이 될 때까지 애플리케이션 집합을 점진적으로 하위 집합으로 나눕니다. 이렇게 하면 필요한 Fleet과 클러스터가 정의됩니다.

비즈니스 단위 고려

조직에 제휴 IT 구조가 있을 수 있습니다. 이 경우 조직에 중앙 IT팀 하나가 있고 비즈니스 단위마다 별도의 IT팀이 있습니다. 이 경우 각 제휴 IT팀에서 자체 Fleet을 관리하려고 할 수 있습니다. 두 비즈니스 단위의 워크로드(예: 은행 감사 및 거래)가 규제상의 이유로 서로 통신할 수 없으면 별도의 Fleet을 사용합니다.

환경별로 워크로드 분리

많은 조직에서 사용하는 일반적인 패턴은 클러스터를 환경별로 그룹화하는 것입니다. 일반적인 구성은 개발, 비프로덕션(또는 스테이징), 프로덕션 등 세 가지 기본 환경이 있는 것입니다. 애플리케이션 변경사항은 일반적으로 목록의 각 환경에 점진적으로 배포(또는 프로모션)됩니다. 따라서 동일한 기본 컨테이너 이미지 이름과 같이 동일한 기본 애플리케이션의 환경마다 별도의 배포가 있습니다. 조직에서 환경을 만드는 방법의 예시는 엔터프라이즈 기반 청사진을 참조하세요.

Fleet에는 환경 하나의 클러스터만 포함되어야 합니다. 환경마다 Fleet이 하나씩 있는 환경 3개가 많은 조직에 충분할 수 있습니다. 환경마다 Fleet이 하나 있는 예시와 애플리케이션을 점진적으로 배포하는 방법은 엔터프라이즈 애플리케이션 청사진을 참조하세요.

중복 워크로드 인스턴스 결합

애플리케이션에 고가용성이 필요한 경우 한 가지 패턴은 리전 2개 이상에서 애플리케이션을 실행하는 것입니다. 여기에는 매우 유사하게 구성된 배포를 실행하고 단위로 관리되는 클러스터가 2개 이상 포함됩니다. 모든 클러스터의 애플리케이션 인스턴스에 걸쳐 부하 분산기가 있거나 DNS 부하 분산을 사용하는 경우가 많습니다.

이러한 시나리오에서는 모든 클러스터를 같은 Fleet에 배치합니다. 다른 리전의 클러스터는 규제 기관이나 다른 이유로 필요한 경우가 아니라면 일반적으로 별도의 Fleet에 있을 필요가 없습니다.

기존 클러스터로 Fleet 계획

이 섹션에서는 워크로드가 기존 클러스터에서 실행되고 있으며 워크로드를 재배치할 계획이 없을 때 Fleet을 계획하는 방법을 설명합니다. 이러한 클러스터는 Google Cloud 내부 또는 외부에 있을 수 있습니다. 이 시나리오에서는 조직 내에 일련의 Fleet을 만들고 기존 클러스터를 Fleet에 할당하는 것이 목표입니다.

Fleet가 식별되면 Fleet별로 새 프로젝트를 만들고 각 프로젝트에서 Fleet를 만들고 원하는 Fleet에 클러스터를 등록할 수 있습니다.

클러스터 감사

조직의 모든 Kubernetes 클러스터 목록부터 시작합니다. Cloud 애셋 인벤토리는 조직에서 Kubernetes 클러스터 리소스를 검색하는 한 가지 방법입니다.

그런 다음 이 섹션의 나머지 단계를 수행하여 필요한 최소 그룹 집합이 될 때까지 애플리케이션 집합을 점진적으로 하위 집합으로 나눌 수 있습니다. 이렇게 하면 필요한 Fleet이 정의됩니다.

비즈니스 단위 고려

조직에 제휴 IT 구조가 있을 수 있습니다. 이 경우 조직에 중앙 IT팀 하나가 있고 비즈니스 단위마다 별도의 IT팀이 있습니다. 이러한 비즈니스 단위별 IT팀에서 기존 클러스터를 만들었을 수 있습니다. 일반적으로 이 경우 비즈니스 단위별로 클러스터 집합을 파티셔닝합니다. 예를 들어 특정 비즈니스 단위의 워크로드(예: 은행의 감사 및 거래)가 규제상의 이유로 서로 통신할 수 없는 경우가 있습니다.

비즈니스 단위가 단지 원가 계산 목적으로만 존재하지만 공통 IT팀을 사용하는 경우, 특히 비즈니스 단위 간에 상당한 서비스 간 종속 항목이 있으면 해당 클러스터를 단일 Fleet으로 결합하는 것이 좋습니다.

환경별로 클러스터 그룹화

조직에서 사용되는 환경을 식별합니다. 일반적인 환경 이름은 dev, non-production(또는 staging), prod입니다.

각 클러스터가 환경 하나씩에 있는 것이 명확하면 클러스터 목록을 환경별로 구분합니다. 그러나 일부 클러스터에 논리적으로 다른 환경에 속하는 워크로드가 포함된 경우 애플리케이션을 단일 논리적 환경에 속하는 애플리케이션만 포함된 클러스터에 재배포하는 것이 좋습니다.

클러스터 소유자 수 최소화

기존 프로젝트를 Fleet으로 결합할 때 IAM 정책(container.admin)과 RBAC(관리자 ClusterRoleBinding)를 모두 고려하여 이러한 클러스터에서 관리자 역할을 수행할 수 있는 권한이 있는 다양한 사용자 집합이 있을 수 있습니다. 동일성이 필요한 기능을 사용하려는 경우 모든 클러스터에 같은 관리자 집합을 지정하고 Fleet에 대한 소규모 관리자 집합을 만드는 것이 목표입니다. 클러스터에 다양한 관리자가 있어야 하고 동일성이 필요한 기능을 사용하는 것이 목표인 경우에는 같은 Fleet에 속하지 않을 수 있습니다.

예를 들어 클러스터 C1과 C2에 서로 신뢰하지 않는 다양한 관리자가 있고 Fleet을 관리하는 중앙 플랫폼팀과 관리자 권한을 공유하지 않을 경우 Fleet으로 그룹화해서는 안 됩니다.

Fleet 작동 방식에서 동일성과 이를 필요로 하는 기능에 대해 자세히 알아보세요.

Fleet 기능 고려

새 클러스터 또는 기존 클러스터를 사용하는지 여부에 관계없이 선택하는 Fleet 기능이 최적의 Fleet 구성에 영향을 줄 수 있습니다. 예를 들어 Fleet 전체 워크로드 아이덴티티 제휴를 사용하는 경우 Fleet 전체 워크로드 인증을 설정할 때 위험이 최소화되는 방식으로 Fleet을 구성할 수 있습니다. 또는 Cloud Service Mesh를 사용하려면 특정 클러스터가 같은 Fleet에 있어야 할 수 있습니다. Virtual Private Cloud(VPC)를 사용하는 경우 일부 기능을 사용하려면 Fleet당 단일 VPC를 사용해야 합니다.

Fleet 기능 채택 및 요구사항과 제한사항에 대한 자세한 내용은 이 시리즈의 다음 가이드인 Fleet 기능 계획을 참조하세요.

VPC 경계 고려

새로운 클러스터와 기존 클러스터 모두에서 고려해야 하는 또 다른 문제는 Google Cloud에서 Virtual Private Cloud(VPC)를 사용하여 자체 비공개 네트워크를 만들었거나 만들려는 경우입니다. VPC 경계 내에 있는 클러스터(예: VPC 서비스 제어가 있는 공유 VPC)는 함께 Fleet 하나에 있을 수 있습니다. 제한된 공유 VPC와 제한되지 않은 공유 VPC 모두 있는 경우 별도의 Fleet에 배치하는 것이 좋습니다.

VPC 서비스 제어 경계를 사용하려는 경우 일반적으로 일부 워크로드는 경계에 있고 일부는 경계 외부에 있습니다. 환경(또는 최소한 프로덕션 및 프로덕션 직전 환경)마다 각 Fleet의 VPC 서비스 제어 버전과 비VPC 서비스 제어 버전이 있는 것이 좋습니다.

VPC를 사용하는 Fleet을 계획할 때는 일부 Fleet 기능에 특정 VPC 요구사항(예: Fleet을 사용하는 모든 클러스터가 같은 VPC 네트워크 내에 있어야 함)이 있다는 점에 유의하세요.

다음 단계

• Fleet 기능 계획에서 기능을 Fleet에 추가하기 위한 권장사항 확인하기
• Fleet 작동 방식에서 Fleet 작동 방식 자세히 알아보기
• Fleet 만들기 개요에 따라 Fleet 만들기