이 가이드는 조직에서 Fleet을 구현하기 위한 모범 사례, 실용적인 고려사항 및 권장사항을 제공합니다.
이 가이드를 읽기 전에 Fleet 작동 방식의 개념을 숙지해야 합니다. 예시를 살펴보기 전에 이 가이드를 읽어보는 것이 좋습니다.
구성요소 요구사항
조직에서 사용하려는 Fleet 인식 GKE Enterprise 및 Google Cloud 구성요소를 기반으로 Fleet을 구현할 때는 몇 가지 고려할 제한사항이 있습니다. 예를 들어 Fleet 호스트 프로젝트에 없는 클러스터로는 일부 구성요소가 아직 지원되지 않을 수 있습니다.
다음 표에서는 각 구성요소의 현재 요구사항 및 제한사항을 보여줍니다.
| 구성요소 |
클러스터 유형 |
프로젝트 요구사항 |
VPC 요구사항 |
|---|---|---|---|
| 구성 동기화 | 모든 GKE Enterprise 지원 클러스터 | 없음 | 없음 |
| 정책 컨트롤러 | 모든 GKE Enterprise 지원 클러스터 | 없음 | 없음 |
| Anthos Service Mesh | 지원되는 플랫폼을 참조하세요. | 클러스터를 한 Fleet에 등록해야 하며 동일한 프로젝트에 있는 모든 클러스터는 동일한 Fleet에 등록해야 합니다. 자세한 내용은 Anthos Service Mesh Fleet 요구사항을 참조하세요. | GKE 클러스터는 동일한 VPC 네트워크에 있어야 합니다. |
| 멀티 클러스터 인그레스 | Google Cloud 기반 GKE 클러스터 | 인그레스 리소스, GKE 클러스터, Fleet은 동일한 프로젝트를 공유해야 합니다. | 인그레스 리소스 및 GKE 클러스터가 동일한 VPC 네트워크에 있어야 합니다. |
| 워크로드 아이덴티티 풀 | GKE Enterprise, Google Cloud 기반 GKE, VMware용 GKE에 최적화되었습니다. GKE Enterprise에서는 다른 Kubernetes 클러스터가 지원되지만 수동 설정 작업이 필요합니다. | 없음 | 없음 |
Fleet용 프로젝트 및 VPC 네트워크 구성
Fleet을 설계할 때는 Google Cloud 프로젝트 및 Virtual Private Cloud(VPC) 네트워크의 두 가지 기본 리소스를 고려해야 합니다.
Fleet 작동 방식에 설명된 대로 각 Fleet은 단일 프로젝트 내에 생성됩니다. 하지만(이전 표에 설명된 제한사항과 같이) Fleet은 Fleet 호스트 프로젝트, 다른 Google Cloud 프로젝트, 다른 클라우드 제공업체, 온프레미스의 Fleet 인식 리소스와 작동하도록 의도되었습니다.
대부분의 경우 명시적으로 금지되지는 않지만 동일한 프로젝트의 Fleet 인식 리소스를 동일한 Fleet에 추가하는 것이 좋습니다. 여러 Fleet 간에 분할되면 안 됩니다. 동일한 프로젝트에서 Fleet 간에 리소스를 분할하는 것은 프로젝트 경계가 정책 및 거버넌스 목적으로 더 강력한 보호 기능을 제공하기 때문에 안티패턴으로 고려됩니다.
여러 프로젝트에 Fleet 인식 리소스를 배치하는 방법을 결정할 때는 많은 조직들이 서로 다른 테넌시 요구사항을 가질 것으로 예상됩니다. 다음 두 가지 극단적인 경우를 고려하세요.
- 일부 조직은 중앙 제어가 적용되는 일부 프로젝트에 모든 Fleet 리소스를 배치하여 팀에 네임스페이스를 할당합니다.
- 다른 조직에서는 팀의 자체 프로젝트 내에서 팀에 자체적인 전용 클러스터를 제공할 수 있습니다.
첫 번째 극단적인 상황의 경우 리소스에 대한 중앙화된 거버넌스를 유지하는 것이 더 쉽지만, 원하는 격리를 얻기 위해서는 추가 작업이 필요할 수 있습니다. 두 번째 극단적인 상황의 경우 이러한 애로사항이 역전됩니다. 일부 복잡한 경우 조직에는 공유 인프라 리소스와 전용 리소스가 혼합되어 별도의 프로젝트에 격리되어 있을 수 있습니다. 어떤 상황이든 상관없이, 신뢰도가 높은 섹션에서 설명한 바와 같이, Fleet에 등록된 리소스에 대한 상호 신뢰를 유지하는 것은 Fleet의 무결성을 유지하는 데 중요합니다.
프로젝트 조직과 밀접한 관련이 있는 것은 네트워크 조직입니다. 구성요소 요구사항 표에 명시된 것처럼 여러 Fleet 구성요소와 Fleet에 등록된 리소스 간에 구체적인 연결이 필요합니다. 시간 경과에 따라 이러한 요구사항 중 일부는 완화될 수 있습니다. 하지만 예를 들어 오늘날 멀티 클러스터 인그레스는 pod가 동일한 VPC 네트워크에 있어야 하고, 클러스터 자체가 Fleet과 동일한 프로젝트에 있어야 합니다.
구성요소가 이러한 초기 프로젝트와 VPC 네트워크 요구사항을 완화할 수 있는 경우, Google에서는 여러 프로젝트가 필요할 때마다 공유 VPC 모델을 채택하는 것이 권장사항이 될 것으로 예상합니다. 이러한 모델의 경우 VPC 네트워크의 서비스 호스트 프로젝트에서 각 Fleet 프로젝트에 등록된 리소스를 사용하여 Environ을 인스턴스화할 수 있습니다. 공유 VPC에 여러 Fleet이 필요한 경우 프로젝트를 Fleet 호스트 프로젝트로 지정할 수 있습니다.
Fleet 리소스 추가/삭제(클러스터)
기존 Fleet 인식 리소스를 Fleet에 추가할 수 있지만, 이러한 추가 작업의 결과로 서비스가 중단되지 않도록 특별히 주의해야 합니다. 특히 Fleet에 리소스를 추가하기 전 동일성 및 신뢰 속성이 고려되는지 확인해야 합니다. Fleet 관리자는 활성 Fleet 구성요소에 동일성이 사용되는 방법에 특히 주의해야 합니다. 일관된 이름 지정 방식으로 마이그레이션하거나, 리소스의 거버넌스를 설정하거나, 다른 Fleet에 리소스를 추가하기 전에 다른 작업을 수행해야 할 수도 있습니다.
Fleet에서 리소스를 삭제하려면 추가 주의가 필요합니다. 예를 들어 활성 상태로 서비스 메시의 일부를 이루거나 멀티 클러스터 부하 분산기의 일부로 타겟팅된 리소스는 영향을 받습니다. 리소스 삭제를 준비하려면 Fleet에서 사용 설정한 각 구성요소를 검토하고 활성 서비스 메시 트래픽 또는 외부 트래픽을 드레이닝하는 데 필요한 단계를 수행하는 것이 좋습니다.
Fleet의 발전에 따라 Fleet 리소스 추가 및 삭제 시 더 많은 대역 내 지침이 제공될 것입니다.
Fleet 구성요소 사용 설정 또는 재구성
Fleet을 사용하는 Google Cloud 또는 GKE Enterprise 구성요소를 사용 설정하거나 재구성하려면 특별한 주의가 필요합니다. 새 구성요소를 사용 설정하는 경우, 모든 클러스터에서 구성요소를 사용 설정할 때의 잠재적인 부작용을 고려합니다. 예를 들어 Anthos Service Mesh를 사용 설정하기 전에 어떤 서비스 엔드포인트가 리소스 간에 병합되는지를 파악하고, 원하는 결과인지 확인합니다.
Fleet 개념의 발전에 따라 Fleet 지원 구성요소 구성 시 추가적인 대역 내 지침이 제공될 것입니다.
다음 단계
- 이 가이드에 설명된 고려사항을 보여주는 일부 가상 시나리오는 Fleet 예시를 참조하세요.