Fleet 기능 계획

Fleet 계획에서 중요한 부분은 사용할 Fleet 지원 기능을 결정하는 것입니다. 특히 기존 클러스터와 프로덕션 워크로드를 사용하는 경우 즉시 채택 가능하며 기존 애플리케이션에 최소한의 불편이나 위험을 끼치는 Fleet 기능을 파악하고 더 점진적이거나 신중한 채택이 필요한 다른 기능을 계획하는 것이 좋습니다. 이 가이드에서는 Fleet과 해당 요구사항을 사용하여 사용 설정된 다양한 유형의 기능을 설명하고 기능 채택에 대한 실용적인 안내를 제공합니다.

이 가이드에 설명된 많은 기능은 오직 GKE Enterprise의 일부로 사용할 수 있습니다. 자세한 내용은 GKE Enterprise 배포 옵션을 참조하세요.

이 가이드는 조직에서 Fleet를 시작하려는 클라우드 설계자를 대상으로 합니다. 이 가이드를 읽기 전에 Fleet에 새 클러스터 또는 기존 클러스터를 구성하는 방법을 설명하는 Fleet 관리 개요 및 Fleet 리소스 계획을 숙지해야 합니다.

기능 채택 권장사항

모든 Fleet 기능(기본 Fleet 관측 가능성 제외)을 선택 가능하며 이를 사용하도록 지정해야 합니다. 기존 클러스터를 Fleet에 추가해도 구성은 변경되지 않습니다. Fleet 기능을 사용하기로 결정한 경우 일부 기능은 최소한의 위험으로 즉시 사용 설정할 수 있지만 일부 기능은 더 신중하게 접근해야 할 수 있습니다. 이 섹션에서는 기능 채택에 관한 몇 가지 안내를 제공합니다.

특히 기존 클러스터 및 워크로드에서는 기능이 동일성을 사용하는 경우 특히 주의해야 합니다. 이는 서로 다른 클러스터에서 동일한 이름을 가진 네임스페이스, 서비스 또는 ID를 기능에서 동일한 것으로 가정하는 Fleet 개념입니다. 동일성의 원리와 이를 사용하는 기능에 대한 자세한 내용은 Fleet 작동 방식을 참고하세요.

위험도가 낮은 기능 온보딩

다음 '주변' 기능은 어떤 유형의 동일성도 가정하지 않으며 어떤 방식으로도 클러스터에 영향을 주지 않습니다. 기존 워크로드 및 클러스터에서도 모두 안전하게 사용할 수 있으므로 Fleet 전반에서 향상된 관측 가능성 및 보안 통계를 즉시 활용할 수 있을 뿐만 아니라 Fleet 멤버십에 따라 클러스터 업그레이드 순서를 관리할 수 있습니다.

다음 기능은 개별 클러스터에 설치됩니다. 이 기능은 동일성을 가정할 수 있지만 여러 클러스터에서 리소스를 구성하거나 지정하는 경우에만 해당됩니다. 즉, 기존 워크로드가 있는 클러스터에서 이러한 기능을 안전하게 사용 설정할 수 있으며 이러한 선택적 선택기를 사용하는 구성을 만들거나 사용할 때 동일성만 고려하면 됩니다.

고급 멀티 클러스터 기능 온보딩

다음과 같은 강력한 기능을 사용하면 여러 클러스터를 관리하는 데 따른 운영 오버헤드를 줄일 수 있습니다. 하지만 이러한 기능은 모두 하나 이상의 동일성 유형이 작동한다고 가정해야 하기 때문에 이러한 기능을 사용 설정하거나 사용 중지하면 여러 클러스터 및 해당 워크로드에 영향을 줄 수 있으므로 주의해야 합니다.

예를 들어 서로 다른 클러스터 및 애플리케이션(기본 네임스페이스 포함)에 동일한 이름의 기존 Kubernetes 네임스페이스가 있는 경우 이러한 가정을 하는 기능을 사용 설정하기 전에 동일한 네임스페이스로 취급할지 확인해야 합니다. 마찬가지로 Cloud Service Mesh를 사용하려면 클러스터 간에 병합되는 서비스 엔드포인트를 파악하고 원하는 동작인지 확인해야 합니다.

네임스페이스 동일성 감사

애플리케이션을 잘 알고 있다면 '다른' 두 애플리케이션이 동일한 네임스페이스를 사용하지 않는지 확인하는 것만으로 네임스페이스를 감사할 수 있습니다. 특히 기본 네임스페이스의 임시 사용에 주의하세요. 예를 들어 한 클러스터에 default라는 네임스페이스가 있고 다른 클러스터에도 default이라는 네임스페이스가 있지만 둘이 다른 목적으로 사용되는 경우 이 중 하나의 이름을 변경해야 합니다.

더 엄격한 접근 방식을 사용하려면 다음을 시도해 보세요. Fleet의 여러 클러스터에서 이름이 같은 네임스페이스의 각 집합에 대해 다음을 확인합니다.

  • 모든 클러스터에서 동일한 RBAC 규칙이 클러스터에 있고 주 구성원의 네임스페이스가 이 네임스페이스에 액세스하도록 허용됩니다.
  • 포드에서 사용하는 이미지 집합(해시/태그 제외)이 동일합니다.
  • 포드에서 사용하는 보안 비밀 집합이 동일합니다.

위의 모든 사항에 해당한다면 네임스페이스가 '동일'한 것으로 취급될 만큼 충분히 유사합니다.

네임스페이스가 충분히 유사하지 않은 경우 앱을 새 네임스페이스로 이전할 수 있습니다. 네임스페이스 동일성을 가정해도 괜찮다고 판단되면 이를 사용하는 기능을 사용 설정하면 됩니다.

서비스 동일성 감사

Cloud Service Mesh를 채택하여 마이크로서비스 기반 애플리케이션을 관리하려는 경우 고려해야 할 또 다른 문제는 서비스 동일성입니다. 즉, 네임스페이스와 서비스 이름의 조합에 관계없이 Cloud Service Mesh는 이를 다음과 같은 측면에서 동일한 논리적 서비스로 간주합니다.

  • ID(특히 Cloud Service Mesh 보안용): namespace1/service1이 작업을 수행하도록 승인되면 모든 클러스터에서 해당 ID를 사용하는 워크로드가 승인됩니다.
  • 트래픽 관리: 기본적으로 트래픽은 모든 클러스터의 namespace1/service1 서비스 간에 부하 분산됩니다.
  • 관측 가능성: 모든 클러스터의 namespace1/service1에 대한 측정항목이 함께 집계됩니다.

새 클러스터 및 애플리케이션에서 Cloud Service Mesh를 사용 설정하는 경우 전체 메시에서 고유한 네임스페이스/서비스 이름 조합을 예약하는 것이 좋습니다. 기존 애플리케이션의 경우 서비스를 감사하여 클러스터 전체에서 네임스페이스와 이름이 동일한 서비스를 ID, 트래픽 관리, 관측 가능성 면에서 동일한 서비스로 취급할 것인지 확인합니다.

특히 결제 계정 API와 결제 트랜잭션 API와 같이 논리적으로 다른 서비스에서 동일한 [네임스페이스, 이름] 쌍(예: payments/api)을 사용하지 않아야 합니다. 그렇지 않으면 서비스 메시에서 이를 동일한 서비스로 취급합니다. 이 개념 조인은 리전 경계에서도 마찬가지로 발생합니다. 또한 서비스의 기능에 영향을 줄 수 있습니다.

클러스터 외부에 노출된 서비스만 해당하지만 여러 클러스터의 서비스로 트래픽을 전달할 때 멀티 클러스터 인그레스 및 멀티 클러스터 게이트웨이에서도 서비스 네임스페이스/이름 동일성이 가정됩니다.

워크로드 아이덴티티 고려

강력한 Fleet 기능은 Fleet 전체 워크로드 아이덴티티 제휴입니다. 이는 GKE용 워크로드 아이덴티티 제휴에서 제공하는 기능을 확장하여 Google Cloud 서비스 계정 키를 다운로드하고 수동으로 순환하고 일반적으로 관리하지 않아도 클러스터의 워크로드를 Google에 인증할 수 있게 해줍니다. 대신 클러스터에서 생성된 단기 토큰을 사용하여 워크로드가 인증되며, 각 클러스터가 특수 워크로드 아이덴티티 풀에 ID 공급업체로 추가됩니다. 특정 네임스페이스에서 실행되는 워크로드는 클러스터 간에 동일한 Identity and Access Management ID를 공유할 수 있습니다.

GKE용 일반 워크로드 아이덴티티 제휴는 프로젝트 전체의 ID 풀을 사용하는 반면, Fleet 전체 워크로드 아이덴티티 제휴는 클러스터가 서로 다른 프로젝트에 속하더라도 전체 Fleet의 워크로드 아이덴티티 풀을 사용합니다. 이때 Fleet 전체의 ID와 네임스페이스, 서비스의 동일성이 암시적으로 적용됩니다. 이렇게 하면 프로젝트 전체의 애플리케이션에 대한 인증을 더 간단하게 설정할 수 있지만 멀티 프로젝트 Fleet에서 사용하려는 경우, 특히 Fleet 호스트 프로젝트에 Fleet 및 비Fleet 클러스터가 혼합된 경우 액세스 제어 고려사항이 GKE용 일반 워크로드 아이덴티티 제휴보다 늘어날 수 있습니다.

Fleet 워크로드 아이덴티티 제휴와 이를 사용하여 Google Cloud 서비스에 액세스하는 방법에 관한 자세한 내용은 Fleet 워크로드 아이덴티티 사용을 참고하세요. 몇 가지 예시와 함께 Fleet 워크로드 아이덴티티 제휴로 위험을 최소화하는 방법은 Fleet 워크로드 아이덴티티 사용 권장사항을 참조하세요.

Fleet 수준 기본값

GKE Enterprise에서는 Cloud Service Mesh, 구성 동기화, 정책 컨트롤러를 포함하여 특정 엔터프라이즈 기능에 대해 Fleet 수준 기본값을 설정할 수 있습니다. 이렇게 하면 각 클러스터를 개별적으로 구성할 필요 없이 이러한 기능을 사용하도록 클러스터를 설정할 수 있습니다. 예를 들어 관리자는 Fleet에 정책 컨트롤러를 사용 설정하고 Fleet 수준에서 기본 정책을 설정할 수 있습니다. 이렇게 하면 새 Fleet 구성원 클러스터에 필수 에이전트가 설치되고 기본 정책이 적용됩니다.

그러나 이러한 기본값은 클러스터 생성 시 Fleet에 추가하는 새 클러스터에만 자동으로 적용됩니다. 기존 클러스터와 워크로드는 이미 Fleet에 추가했거나 기능 기본값을 설정한 후 클러스터를 추가하더라도 영향을 받지 않습니다. 즉, 준비되지 않은 클러스터에서 기능을 사용 설정하거나 구성할 위험 없이 Fleet 수준 기본값을 안전하게 설정할 수 있습니다. 나중에 언제든지 기존 클러스터에 기본 설정을 적용할 수 있습니다.

기능 요구사항

조직에서 사용하려는 Fleet 기능을 기반으로 Fleet을 구현할 때는 몇 가지 고려할 제한사항이 있습니다. 예를 들어 일부 기능은 Fleet 호스트 프로젝트에 없는 클러스터를 사용한 작업을 지원하지 않지만 Google Cloud 외부의 클러스터에서는 지원되지 않는 기능도 있습니다.

다음 표에서는 각 구성요소의 현재 요구사항 및 제한사항을 보여주며 구체적인 가이드라인은 다음 섹션에서 다룹니다.

기능
 클러스터 유형
 프로젝트 요구사항
 VPC 요구사항
구성 동기화 모든 GKE Enterprise 지원 클러스터 없음 없음
정책 컨트롤러 모든 GKE Enterprise 지원 클러스터 없음 없음
Cloud Service Mesh 제한사항을 참고하세요. Cloud Service Mesh에서 사용되며 동일한 프로젝트에 있는 모든 클러스터는 동일한 Fleet에 등록해야 합니다. 자세한 내용은 Cloud Service Mesh Fleet 요구사항을 참조하세요. GKE 클러스터는 동일한 VPC 네트워크에 있어야 합니다.
멀티 클러스터 서비스(MCS) Google Cloud 기반 GKE 없음 공유 VPC의 MCS를 참고하세요.
멀티 클러스터 인그레스 및 멀티 클러스터 게이트웨이 Google Cloud 기반 GKE 인그레스/게이트웨이 리소스, GKE 클러스터, Fleet이 동일한 프로젝트에 있어야 합니다. 인그레스/게이트웨이 리소스와 GKE 클러스터가 동일한 VPC 네트워크에 있어야 합니다.
워크로드 아이덴티티 풀 Google Cloud 기반 GKE 및 VMware용 Google Distributed Cloud에 최적화되었습니다. 다른 Kubernetes 클러스터도 지원되지만 추가 설정 작업이 필요합니다. 없음 없음
Binary Authorization Google Cloud 기반 GKE, VMware용 Google Distributed Cloud, 베어메탈용 Google Distributed Cloud 없음 없음
Advanced Vulnerability Insights Google Cloud 기반 GKE 없음 없음
보안 상황 Google Cloud 기반 GKE 없음 없음
규정 준수 상태 Google Cloud 기반 GKE 없음 없음
Fleet 리소스 사용률 측정항목 Google Cloud 기반 GKE 없음 없음
Fleet 로깅 전체 없음 없음
Connect 게이트웨이 전체 없음 없음
Fleet팀 관리 전체 없음 없음
포드 FQDN 네트워크 정책 Google Cloud 기반 GKE 없음 없음
노드 간 투명한 암호화 Google Cloud 기반 GKE 없음 없음
구성 컨트롤러 해당 사항 없음 없음 없음
출시 시퀀싱 Google Cloud 기반 GKE 없음 없음

가상 프라이빗 클라우드 요구사항 고려

이전 표와 같이 클러스터가 단일 가상 프라이빗 클라우드(VPC) 네트워크에 있어야 하는 Cloud Service Mesh와 같은 기능을 사용하려는 경우 각 VPC의 Fleet을 만들어야 합니다. 이러한 기능을 사용할 계획이 없으면 하나의 Fleet에 여러 VPC를 배치할 수 있습니다.

예를 들어 한 가지 일반적인 패턴은 조직에 각각 자체 기본 VPC가 있는 여러 프로젝트가 있는 것입니다. 프로젝트 간에 기존 피어링 연결이 있을 수 있습니다. 단일 VPC 요구사항이 있는 기능을 사용하지 않는 경우 모두 단일 Fleet에 배치할 수 있습니다. 또 다른 일반적인 패턴은 여러 VPC를 사용하는 '허브 및 스포크' 토폴로지를 따릅니다. 단일 VPC 요구사항이 있는 기능을 사용하지 않는 경우 모든 VPC의 클러스터를 단일 Fleet에 배치할 수 있습니다. 경우에 따라 이 가이드라인을 따르면 클러스터가 하나만 있는 Fleet이 발생할 수 있습니다. 이 경우 VPC 제한사항이 있는 기능을 사용하지 않고 다중 프로젝트 Fleet을 만들거나 아키텍처를 다시 고려하고 워크로드를 적절하게 이동해야 할 수 있습니다.

멀티 클러스터 네트워킹 요구사항

트래픽 관리에 멀티 클러스터 인그레스 또는 멀티 클러스터 게이트웨이를 사용하려면 두 경우 모두 게이트웨이 컨트롤러가 프로젝트에 걸쳐 적용될 수 없다는 점에 유의하세요. 즉, 이러한 기능과 함께 사용하려는 모든 클러스터가 동일한 프로젝트 및 동일한 Fleet에 있어야 합니다. 여러 프로젝트의 클러스터를 포함하는 Fleet을 만들어야 하는 경우 단일 클러스터 게이트웨이를 대신 사용하고 DNS를 사용하는 등의 다른 방법으로 트래픽을 올바른 게이트웨이로 전달할 수 있습니다. 이러한 기능을 사용하는 클러스터도 동일한 VPC 네트워크에 있어야 합니다.

다음 단계