Connect 게이트웨이로 등록된 클러스터에 연결

Google Cloud에서 Fleet은 함께 관리될 수 있고 Google Cloud에 클러스터를 등록하여 생성되는 Kubernetes 클러스터 및 기타 리소스에 대한 논리적 그룹입니다. Connect 게이트웨이는 Fleet 성능을 기반으로 빌드되므로 GKE Enterprise 사용자는 클러스터가 Google Cloud, 기타 퍼블릭 클라우드 또는 온프레미스에 있는지에 관계없이 간단하고, 일관되며 안전한 방식으로 Fleet 구성원 클러스터에 연결하고 명령어를 실행하며 모든 클러스터 간에 DevOps 프로세스를 더욱 쉽게 자동화할 수 있습니다.

이 가이드에서는 기본적인 Fleet 개념 및 Fleet에 클러스터 등록에 대해 이미 익숙하다고 가정합니다. 익숙하지 않다면 Fleet 관리 개요, Fleet 만들기 개요, 연결된 가이드에서 자세한 내용을 확인하면 됩니다. 또한 kubectl, client-go(자동화를 위해 게이트웨이를 사용하려는 경우), 역할 기반 액세스 제어(RBAC), 핵심 Kubernetes 리소스를 비롯한 Kubernetes 도구 및 개념에도 익숙해야 합니다.

기본적으로 Connect 게이트웨이는 직원 ID 제휴를 사용하는 타사 ID 공급업체를 지원하고 GKE Identity Service를 통한 그룹 기반 인증을 지원하는 Google ID를 사용하여 클러스터에 인증합니다. GKE Identity Service에 대해 자세히 알아보거나 이를 독립형 서드 파티 인증 옵션으로 사용하려면 GKE Identity Service 소개를 참조하세요.

Connect 게이트웨이를 사용하는 이유는 무엇인가요?

클러스터가 여러 클라우드 및 하이브리드 환경에서 실행될 때는 워크로드를 관리하는 데 많은 어려움이 있습니다. 클러스터가 서로 다른 Virtual Private Cloud(VPC)에서 실행될 수 있고 여러 ID 공급업체가 사용되어 연결, 인증, 승인이 더 복잡해질 수 있습니다. 일부 경우에는 이러한 환경 간에 존재하는 클러스터를 찾는 것도 어려운 일일 수 있습니다.

Connect 게이트웨이로 다음을 쉽게 수행할 수 있습니다.

  • Google Cloud, 다른 퍼블릭 클라우드, 온프레미스에 어떤 클러스터가 존재하고 간단한 쿼리를 통해 Fleet에 어떤 클러스터가 등록되었는지 확인합니다.
  • Google Cloud 콘솔에 등록된 GKE 클러스터를 표시하는 데 사용하는 인프라와 동일한 인프라를 사용하여 원하는 클러스터에 연결합니다.
  • 인증: Google Cloud 서비스에서 사용하는 것과 동일한 ID를 사용하여 인증합니다.
  • 승인: Fleet에 등록된 모든 클러스터에서 일관되게 승인합니다.

게이트웨이는 Google Cloud ID를 인증하고 Connect 서비스를 통해 클러스터의 API 서버에 대한 연결을 제공합니다.

kubectl과 같은 kubeconfig를 허용하는 명령줄 도구를 사용하여 게이트웨이를 통해 직접 클러스터와 상호작용할 수 있습니다. 또한 빌드 파이프라인 및 기타 DevOps 자동화를 사용하여 게이트웨이를 쉽게 활용할 수 있습니다. Cloud Build와 통합 튜토리얼에서 이 방법의 실행 방법 예시를 확인할 수 있습니다.

Connect 서비스를 사용하여 Google Cloud 콘솔의 Google Cloud ID로 Google Cloud 외부에 있는 등록된 클러스터에 연결할 수도 있습니다. 이렇게 하려면 Google Cloud 콘솔에서 클러스터로 작업의 안내를 따르세요.

작동 방식

여기에서는 적절한 인증 및 승인이 구성된 후 CI/CD 파이프라인과 같이 일반적인 사용자 또는 서비스가 Connect 게이트웨이를 사용하기 위해 수행하는 흐름을 보여줍니다. 자세한 내용은 사용 가이드를 참조하세요.

  1. 사용자나 서비스에서 Google Cloud CLI를 사용하여 Fleet 멤버십 리소스를 나열하여 클러스터를 검색합니다.

    gcloud container fleet memberships list

  2. 사용자나 서비스에서 Google Cloud CLI를 사용하여 선택한 클러스터에 연결하는 데 필요한 Connect 게이트웨이 관련 kubeconfig를 가져옵니다.

    gcloud container fleet memberships get-credentials membership-name

    GKE에서 gcloud CLI 사용에 이미 익숙한 경우 이는 Google Cloud 계정을 사용하여 gcloud container clusters get-credentials를 실행하는 것과 비슷하며, 승인된 경우 등록되었고 프로젝트의 Fleet 내에서 연결된 모든 클러스터에 액세스할 수 있게 해줍니다.

  3. 사용자 또는 서비스는 일반적으로 다운로드한 kubeconfig 파일을 사용하여 kubectl 또는 client-go에서 하는 것과 같이 명령어를 실행합니다.

    1. 사용자/서비스는 Connect 게이트웨이에서 인증되며 게이트웨이를 사용할 수 있는 권한이 있는지 확인합니다.
    2. 요청은 Connect 서비스 및 Connect 에이전트를 통해 해당하는 Kubernetes API 서버로 전달됩니다.
    3. Kubernetes API 서버가 요청을 승인하며, 이를 위해서는 Connect 에이전트가 사용자 또는 서비스를 가장하도록 승인되어야 하고, 사용자 또는 서비스가 원하는 요청을 수행하도록 승인되어야 합니다.

Google 그룹 지원

이전 섹션에서 설명한 표준 흐름에서 사용자 요청은 개별 ID를 기준으로 승인됩니다. 하지만 대다수의 경우 Google 그룹스 멤버십을 기준으로 사용자를 승인하는 것이 유용합니다. 그룹 멤버십을 기준으로 승인하면 계정마다 별도의 승인을 설정할 필요가 없으므로 정책을 보다 간단하고 간편하게 관리하고 감사할 수 있습니다. 따라서 예를 들어 사용자가 팀에 가입하거나 탈퇴할 때 클러스터에서 직접 개별 사용자를 추가/삭제할 필요 없이 팀에 클러스터 액세스 권한을 간편하게 공유할 수 있습니다. GKE Identity Service를 사용한 추가 설정을 통해 Connect 게이트웨이에서 사용자에 대한 Google 그룹 멤버십 정보를 가져오도록 구성할 수 있습니다.

이 기능의 작동 방식과 설정 방법은 Google 그룹스를 사용하여 Connect 게이트웨이 설정을 참조하세요.

연결된 클러스터나 다른 GKE Enterprise 환경에서 이 기능을 사용하려면 Cloud Customer Care 또는 Connect 게이트웨이팀에 문의하세요.

서드 파티 ID 지원

Connect 게이트웨이는 Google Workspace 사용자 및 그룹을 지원하는 것 외에도 Azure Active Directory 및 Okta와 같은 타사 ID를 사용한 승인을 지원합니다. 직원 ID 제휴를 사용하면 Identity and Access Management를 통해 외부 ID 공급업체를 사용하여 인력(직원, 파트너, 용역 직원과 같은 사용자 그룹)을 인증하고 승인할 수 있으므로 사용자가 Connect 게이트웨이와 같은 Google Cloud 서비스에 액세스할 수 있습니다. GKE Identity Service를 사용한 추가 설정을 통해 사용자의 타사 그룹 멤버십 정보를 가져오도록 Connect 게이트웨이를 구성할 수 있습니다.

Connect 게이트웨이의 서드 파티 ID 기능은 Anthos(GKE Enterprise) 버전 1.13 이상의 VMware용, 베어메탈용 Google Distributed Cloud 배포에서 지원됩니다. 연결된 클러스터의 경우 Anthos 1.16 이상에서 이 기능을 사용할 수 있습니다.

이 기능의 작동 방식과 설정 방법은 서드 파티 ID를 사용하여 Connect 게이트웨이 설정을 참조하세요.

원하는 경우, 해당 문서의 안내에 따라 GKE Identity Service를 사용하여 전체적으로 타사 인증을 설정할 수 있습니다.

지연 시간

게이트웨이를 통한 요청의 총 지연 시간은 Connect 게이트웨이 서비스에서 Connect 에이전트까지의 RTT(왕복 시간)와 클러스터 내에서 요청 실행 시간으로 구분할 수 있습니다. RTT로 인한 추가 지연 시간은 p95<500밀리초 및 p99<1초입니다. 대부분의 kubectl 명령어는 여러 개의 다양한 요청을 수행하고, 각 요청은 사용자에게 응답을 렌더링하기 전에 왕복 시간이 필요합니다.

다음 단계