이 페이지에서는 일부 Fleet 용어와 개념을 포함하여 Fleet이 멀티 클러스터 배포를 관리하는 데 어떻게 도움이 되는지 자세히 설명합니다. Fleet은 클러스터와 기타 리소스를 논리적으로 구성하기 위한 Google Cloud 개념으로, 이를 사용하면 멀티 클러스터 기능을 사용 및 관리하고 시스템 전체에 일관된 정책을 적용할 수 있습니다. Fleet은 Google Cloud에서 엔터프라이즈 멀티 클러스터 기능 작동 방식의 중요한 부분을 차지합니다.
이 가이드는 시스템 설계자, 플랫폼 운영자, 서비스 운영자 등 여러 클러스터 및 관련 인프라를 활용하려는 기술 리더를 대상으로 작성되었습니다. 이러한 개념은 조직에서 Google Cloud, 여러 클라우드 제공업체, 온프레미스에서 여러 클러스터를 실행할 때 유용합니다.
클러스터와 네임스페이스와 같은 기본 Kubernetes 개념을 잘 알고 있어야 합니다. 이러한 개념을 모른다면 Kubernetes 기본사항, GKE 문서, Cloud Service Mesh용 애플리케이션 준비를 참조하세요.
GKE Enterprise 플랫폼 및 Fleet을 사용하는 구성요소에 대한 자세한 내용은 GKE Enterprise 기술 개요 및 GKE Enterprise 살펴보기 튜토리얼을 참조하세요. 하지만 GKE Enterprise에 대해 잘 몰라도 이 가이드를 진행할 수 있습니다.
용어
Fleet에 대해 설명할 때 사용하는 중요 용어는 다음과 같습니다.
Fleet 인식 리소스
Fleet 인식 리소스는 논리적으로 Fleet으로 그룹화되고 관리될 수 있는 Google Cloud 프로젝트 리소스입니다. 현재 Kubernetes 클러스터만 Fleet 구성원이 될 수 있습니다.
Fleet 호스트 프로젝트
다른 많은 Google Cloud 리소스와 같이 Fleet 구현은 Fleet 호스트 프로젝트라고 부르는 Google Cloud 프로젝트를 기반으로 합니다. 지정된 Google Cloud 프로젝트는 연관된 단일 Fleet만 포함할 수 있습니다(또는 Fleet 없음). 이 제한사항은 Google Cloud 프로젝트를 사용하여 함께 적용되지 않거나 함께 소비되지 않는 리소스 간에 더욱 강력한 격리 조치를 적용합니다.
인프라 그룹화
Fleet의 첫 번째 중요한 개념은 그룹화 개념입니다. 즉, Fleet의 일부가 될 관련 Fleet 인식 리소스를 선택하는 것입니다. 그룹화할 항목을 결정하려면 다음 질문에 답해야 합니다.
- 리소스가 서로 관련되어 있나요?
- 서비스 간 통신이 많은 리소스는 Fleet에서 함께 관리할 경우 가장 효과적입니다.
- 동일한 배포 환경(예: 프로덕션 환경)의 리소스는 Fleet에서 함께 관리되어야 합니다.
- 리소스를 누가 관리하나요?
- Fleet의 무결성을 보장하려면 리소스를 통합(또는 최소한 상호 신뢰) 제어하는 것이 중요합니다.
이러한 점을 설명하기 위해 여러 비즈니스 계열(LOB)이 있는 조직을 고려해 보세요. 이 경우 서비스는 LOB 경계 간에 통신하는 경우가 거의 없고, 다른 LOB의 서비스는 관리 방식이 다르며(예: 업그레이드 주기는 LOB마다 다름), LOB마다 관리자가 다를 수 있습니다. 이 경우 LOB당 Fleet을 갖는 것이 더 나을 수 있습니다. 또한 각 LOB는 프로덕션 서비스와 비프로덕션 서비스를 구분하기 위해 여러 Fleet을 도입할 가능성이 높습니다.
다음 섹션에서는 다른 Fleet 개념을 살펴보고 특정 조직 요구를 고려하여 여러 Fleet을 만들어야 할 다른 이유를 찾을 수 있습니다.
동일성
Fleet에서 중요한 개념은 동일성 개념입니다. 즉, 특정 Fleet 지원 기능을 사용할 때 서로 다른 클러스터에서 이름이 동일한 네임스페이스와 같은 일부 Kubernetes 객체는 동일한 것으로 취급됩니다. 이 정규화를 수행하여 Fleet 리소스를 보다 쉽게 관리할 수 있습니다. 동일성을 활용하는 기능을 사용하는 경우 이러한 동일성 가정은 네임스페이스, 서비스, ID를 설정하는 방법에 관한 강한 지침을 제공합니다. 하지만 대부분의 조직이 이미 자체적으로 구현하고 있는 것을 따릅니다.
다음 표와 같이 동일성 유형에 따라 이점이 다릅니다.
| 동일성 속성 | 이점 |
|---|---|
| 네임스페이스가 여러 클러스터에서 동일한 것으로 간주됩니다. |
|
| 네임스페이스와 서비스 이름의 조합이 여러 클러스터에서 동일한 것으로 간주됩니다. 동일한 네임스페이스에 있는 이름이 같은 서비스가 동일한 라벨 선택기를 사용합니다. |
|
| 네임스페이스와 서비스 계정(ID)의 조합이 여러 클러스터에서 동일한 것으로 간주됩니다. |
|
즉, Fleet 기능마다 서로 다른 유형의 동일성에 의존합니다. 소수의 기능은 동일성을 전혀 사용하지 않습니다. 동일성을 사용하는 기능에서 Fleet 전체의 동일성을 고려하지 않고 사용할 수 있는 기능과 더 신중하게 계획해야 하는 기능 등을 자세히 알아보세요.
네임스페이스 동일성
Fleet 동일성의 기본 예시는 네임스페이스 동일성입니다. 여러 클러스터에 있는 이름이 동일한 네임스페이스는 여러 Fleet 기능에서 동일한 것으로 간주됩니다. 이 속성에 대해 고려할 또 다른 방법은 네임스페이스의 인스턴스화가 Fleet 리소스의 하위 집합에만 있는 경우에도 네임스페이스가 전체 Fleet에서 논리적으로 정의됩니다.
다음 backend 네임스페이스 예시를 살펴보세요. 네임스페이스는 클러스터 A와 B에서만 인스턴스화되지만 클러스터 C에 암시적으로 예약됩니다(필요한 경우 backend 네임스페이스의 서비스도 클러스터 C에 예약될 수 있음).
즉, 네임스페이스는 클러스터별로 할당되는 것이 아니라 전체 Fleet에 할당됩니다. 따라서 네임스페이스 동일성을 위해 전체 Fleet에서 일관된 네임스페이스 소유권이 필요합니다.
서비스 동일성
Cloud Service Mesh 및 멀티 클러스터 인그레스는 네임스페이스 내에서 서비스 동일성 개념을 사용합니다. 네임스페이스 동일성과 마찬가지로 네임스페이스와 서비스 이름이 동일한 서비스는 동일한 서비스로 간주됩니다.
Cloud Service Mesh의 경우 서비스 엔드포인트를 메시 간에 병합할 수 있습니다. 멀티 클러스터 인그레스에서는 MultiClusterService(MCS) 리소스를 통해 엔드포인트가 더 명시적으로 병합됩니다. 하지만 이름 지정과 관련하여 유사한 권장사항을 따르는 것이 좋습니다. 이로 인해 동일한 네임스페이스 내에서 이름이 같은 서비스가 실제로 같은 서비스인지 확인하는 것이 중요합니다.
다음 예시에서 인터넷 트래픽은 클러스터 B와 C 모두에 있는 frontend 네임스페이스에서 동일한 이름의 서비스에 부하 분산됩니다. 마찬가지로, Fleet 내 서비스 메시 속성을 사용하여 frontend 네임스페이스의 서비스가 클러스터 A 및 C에 있는 auth 네임스페이스에서 이름이 같은 서비스에 연결될 수 있습니다.
외부 리소스에 액세스할 때 ID 동일성
Fleet 워크로드 아이덴티티 제휴를 사용하면 Fleet 내의 서비스에서 Google Cloud 서비스, 객체 스토어 등의 외부 리소스에 액세스하기 위해 이그레스할 때 공통 ID를 활용할 수 있습니다. 이 공통 ID를 사용하면 Fleet 내에서 서비스가 클러스터 단위가 아니라 한번만 외부 리소스에 액세스할 수 있습니다.
이 점을 더 자세히 설명하기 위해 다음 예시를 살펴보세요. 클러스터 A, B, C는 Fleet 내에서 공통 ID로 등록됩니다. backend 네임스페이스의 서비스가 Google Cloud 리소스에 액세스하면 해당 ID는 back이라는 일반적인 Google Cloud 서비스 계정에 매핑됩니다. Google Cloud 서비스 계정(back)은 Cloud Storage부터 Cloud SQL까지 모든 관리형 서비스에 대해 승인을 받을 수 있습니다. 클러스터와 같은 새로운 Fleet 리소스가 backend 네임스페이스에 추가되면 워크로드 아이덴티티의 동일성 속성을 자동으로 상속합니다.
ID 동일성으로 인해 Fleet의 모든 리소스를 신뢰할 수 있고 잘 관리하는 것이 중요합니다. 이전 예시를 다시 보면, 클러스터 C를 별도의 신뢰할 수 없는 팀에서 소유한 경우 backend 네임스페이스를 만들고 클러스터 A 또는 B의 backend처럼 관리형 서비스에 액세스할 수 있습니다.
Fleet 내부의 ID 동일성
Fleet 내에서 ID는 앞서 언급한 외부 ID 동일성과 유사하게 사용됩니다. Fleet 서비스는 외부 서비스에 대해 한 번 승인되는 것처럼 내부적으로도 승인될 수 있습니다.
다음 예시에서는 Cloud Service Mesh를 사용하여 frontend에서 backend에 액세스할 수 있는 멀티 클러스터 서비스 메시를 만듭니다.
Cloud Service Mesh 및 Fleet을 사용하면 클러스터 B 및 C의 frontend가 클러스터 A 및 B의 backend에 액세스할 수 있도록 지정할 필요가 없습니다. 대신 Fleet의 frontend가 Fleet의 backend에 액세스할 수 있도록 지정합니다. 이 속성은 승인을 단순화할 뿐만 아니라 리소스 경계의 유연성을 높여줍니다. 이제 승인 방식에 영향을 주지 않으면서 워크로드를 클러스터 간에 쉽게 이동할 수 있습니다. 워크로드 아이덴티티 동일성과 마찬가지로 서비스 간 통신의 무결성을 보장하려면 Fleet 리소스에 대한 거버넌스가 중요합니다.
동일성을 사용하는 기능
많은 Fleet 기능은 동일성에 전혀 의존하지 않으므로 Fleet에서 어떤 형태의 동일성을 가정할지 여부를 고려할 필요 없이 사용 설정하고 사용할 수 있습니다. 다른 기능(구성 동기화 및 정책 컨트롤러 포함)에서 동일성을 사용(예를 들어 단일 정보 소스에서 구성을 위해 여러 Fleet 구성원 클러스터에서 네임스페이스를 선택하려는 경우)할 수 있지만 모든 사용 사례에 필요하지는 않습니다. 마지막으로, 멀티 클러스터 인그레스 및 Fleet 전체의 워크로드 아이덴티티 제휴와 같이 클러스터 전반에서 항상 어떤 형태로든 동일성을 가정하는 기능이 있으며, 이러한 기능은 필요와 기존 워크로드에 따라 신중하게 채택해야 할 수 있습니다.
일부 Fleet 기능(예: Fleet 워크로드 아이덴티티 제휴)을 사용하려면 전체 Fleet가 동일성 가정을 사용할 준비가 되어 있어야 합니다. 팀 관리와 같은 다른 기능을 사용하면 네임스페이스 또는 팀 범위 수준에서 점진적으로 동일성을 선택할 수 있습니다.
다음 표에서는 이 섹션에 설명된 동일성 개념 중 하나 이상이 필요한 기능을 보여줍니다.
| 기능 | 점진적 동일성 채택 지원 | 네임스페이스 동일성에 따라 다름 | 서비스 동일성에 따라 다름 | ID 동일성에 따라 다름 |
|---|---|---|---|---|
| Fleet | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| Binary Authorization | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 노드 간 투명한 암호화 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 정규화된 도메인 이름 기반 네트워크 정책 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| Connect 게이트웨이 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 구성 동기화 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 정책 컨트롤러 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| GKE Security Posture | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| Advanced Vulnerability Insights | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 규정 준수 상태 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 출시 시퀀싱 | 해당 사항 없음 | 아니요 | 아니요 | 아니요 |
| 팀 관리 | 예 | 예 | 예 | 아니요 |
| 멀티 클러스터 인그레스 | 예 | 예 | 예 | 예 |
| 멀티 클러스터 서비스 | 예 | 예 | 예 | 예 |
| Fleet 워크로드 아이덴티티 제휴 | 아니요 | 예 | 예 | 예 |
| Cloud Service Mesh | 아니요 | 예 | 예 | 예 |
독점성
Fleet-인식 리소스는 특정 시점에 단일 Fleet의 구성원만 될 수 있으며 이는 Google Cloud 도구 및 구성요소에 의해 적용되는 제한사항입니다. 이 제한사항으로 인해 클러스터를 관리하는 정보 소스가 하나만 있습니다. 독점성 없이는 가장 단순한 구성 요소도 사용하기가 복잡해지므로 조직은 여러 Fleet의 여러 구성요소가 상호작용하는 방식을 추론하고 구성해야 합니다.
높은 신뢰도
서비스 동일성, 워크로드 아이덴티티 동일성, 메시 ID 동일성은 Fleet 구성원 간의 높은 신뢰도 원칙에 따라 빌드됩니다. 이 신뢰도를 사용하면 이러한 리소스를 리소스 단위(즉, Kubernetes 리소스의 클러스터 단위)로 관리하는 대신 Fleet으로 관리 수준을 높일 수 있고 궁극적으로 클러스터 경계가 덜 중요합니다.
다시 말해 Fleet 내에서 클러스터는 영향 범위, 가용성(제어 영역과 기본 인프라 모두), 트래픽 많은 이웃 등으로부터 보호합니다. 그러나 Fleet에 있는 모든 구성원의 관리자가 Fleet의 다른 구성원에서 서비스 운영에 영향을 미칠 수 있으므로 정책 및 거버넌스에 대한 강력한 격리 경계가 아닙니다.
이러한 이유로 Fleet 관리자는 격리 상태를 유지하기 위해 신뢰하지 않는 클러스터를 자체 Fleet에 배치하는 것이 좋습니다. 그런 다음 필요에 따라 개별 서비스를 Fleet 경계에서 승인할 수 있습니다.
팀 범위
팀 범위는 Fleet를 클러스터 그룹으로 더 세분화하여 특정 애플리케이션팀에 할당된 Fleet 인식 리소스를 정의할 수 있는 메커니즘입니다. 사용 사례에 따라 개별 Fleet 구성원 클러스터를 팀과 연결하지 않거나 한 팀 또는 여러 팀과 연결할 수 있으므로 여러 팀에서 클러스터를 공유할 수 있습니다. 또한 팀 범위를 사용하여 Fleet 간에 클러스터 업그레이드 출시를 시퀀싱할 수 있지만 이 경우 각 클러스터를 단일 팀에만 연결해야 합니다.
팀 범위에는 명시적으로 정의된 Fleet 네임스페이스가 연결되어 있을 수 있으며, 여기서 네임스페이스는 범위 전체에서 동일하다고 간주됩니다. 그러면 Fleet에서만 제공하는 기본 네임스페이스 동일성보다 네임스페이스를 더 세밀하게 제어할 수 있습니다.
Fleet 지원 구성요소
다음 GKE Enterprise 및 GKE 구성요소는 모두 네임스페이스 및 ID 동일성과 같은 Fleet 개념을 활용하여 클러스터 및 서비스로 작업할 수 있는 더욱 단순화된 방법을 제공합니다. 각 구성요소와 함께 Fleet 사용에 대한 현재의 요구사항 또는 제한사항은 구성요소 요구사항을 참조하세요.
워크로드 아이덴티티 풀
Fleet은 서비스 메시 내에서 워크로드를 균일하게 인증하고 승인하는 데 사용할 수 있는 일반적인 워크로드 아이덴티티 풀을 외부 서비스에 제공합니다.Cloud Service Mesh
Cloud Service Mesh는 Google Cloud, 온프레미스, 기타 지원되는 환경에서 안정적인 서비스 메시를 모니터링하고 관리하는 데 도움이 되는 도구 모음입니다. 같은 Fleet에 속하는 클러스터 전체에서 서비스 메시를 구성할 수 있습니다.구성 동기화
구성 동기화를 사용하면 네임스페이스, 라벨, 주석 등 핵심 Kubernetes 개념을 활용하여 Git 저장소와 같이 중앙의 단일 정보 소스에 저장된 시스템의 선언적 구성 패키지를 배포하고 모니터링할 수 있습니다. 구성 동기화를 사용하면 구성이 Fleet 간에 정의되지만 각 구성원 리소스에서 로컬로 적용되고 시행됩니다.정책 컨트롤러
정책 컨트롤러를 사용하면 Kubernetes 클러스터에 선언적 정책을 적용하고 시행할 수 있습니다. 이러한 정책은 가드레일 역할을 하며 클러스터와 Fleet의 권장사항, 보안, 규정 준수 관리에 도움이 됩니다.멀티 클러스터 인그레스
멀티 클러스터 인그레스는 Fleet을 사용하여 트래픽 부하가 분산될 수 있는 클러스터 및 서비스 엔드포인트 집합을 정의하므로 지연 시간이 짧은 고가용성 서비스를 사용 설정할 수 있습니다.Knative serving
Knative serving은 기본 인프라의 복잡성을 추상화하여 Fleet의 클러스터에서 앱과 서비스를 쉽게 빌드, 배포, 관리할 수 있게 해주는 Google에서 관리하고 지원하는 Knative 개발자 플랫폼입니다.
다음 단계
- 멀티 클러스터 사용 사례에서 기술 및 비즈니스 요구사항을 충족하기 위해 여러 클러스터를 사용해야 하는 경우에 대해 자세히 알아보세요.
- 이러한 개념을 자체 시스템에 적용할 준비가 되셨나요? Fleet 리소스 계획을 참조하세요.