이 문서에서는 Google Cloud 콘솔에서 베어메탈용 GKE을 관리할 수 있는 방법을 설명합니다. 여기에는 클러스터에 로그인하여 해당 워크로드를 볼 수 있는 것과 같은 기본 관리뿐만 아니라 클러스터를 업그레이드, 업데이트 및 삭제할 수 있도록 클러스터 수명 주기 관리를 사용 설정하는 방법이 포함됩니다.
Fleet 구성원 및 콘솔
모든 베어메탈용 GKE는 여러 클러스터와 해당 워크로드를 보고 관리하는 통합 방법인 Fleet의 구성원이어야 합니다. 각 클러스터 fleet은 fleet 호스트 프로젝트와 연결됩니다.
베어메탈용 GKE에서 사용자 클러스터는 생성 시 Fleet에 등록됩니다.
bmctl을 사용하여 클러스터를 만들 때 클러스터 구성 파일의gkeConnect섹션에서 fleet 호스트 프로젝트를 지정합니다. 베어메탈용 GKE는 해당 정보를 사용하여 클러스터를 지정된 fleet 프로젝트에 등록합니다.콘솔에서 사용자 클러스터를 만들면 클러스터는 자동으로 콘솔에서 선택한 프로젝트의 fleet 구성원이 됩니다.
베어메탈용 GKE와 같은 Google Cloud 외부의 Fleet 구성원은 Google Cloud 기반 GKE와 같은 다른 Fleet 클러스터와 함께 Fleet 호스트 프로젝트의 콘솔에 표시됩니다. 콘솔에서 베어메탈용 GKE를 관리할 수 있는 범위는 다음에 따라 다릅니다.
인증을 설정했으면 클러스터에 로그인하여 해당 워크로드 및 기타 세부정보를 볼 수 있습니다.
클러스터에 대해 클러스터 수명주기 관리를 사용 설정했으면 콘솔을 사용하여 사용자 클러스터를 업그레이드, 업데이트, 삭제할 수도 있습니다. 이렇게 하려면 GKE On-Prem API라고 부르는 서비스로 클러스터를 관리해야 합니다. 콘솔에서 생성된 사용자 클러스터의 경우 클러스터 수명 주기 관리가 클러스터 생성 시 사용 설정되거나 나중에
bmctl을 사용하여 생성된 사용자 클러스터에 대해 이 기능을 사용 설정할 수 있습니다. 이 기능을 사용 설정하지 않으면 관리 워크스테이션에서bmctl을 사용하여 클러스터 수명 주기만 관리할 수 있습니다.
등록된 클러스터 보기
모든 Fleet 클러스터가 콘솔의 GKE 클러스터 페이지에 표시됩니다. 두 가지 모두 전체 Fleet에 대한 개요를 제공하며, 베어메탈용 GKE의 경우 GKE On-Prem API에서 관리되는 클러스터를 확인할 수 있습니다.
Fleet 클러스터를 보려면 다음을 수행하세요.
콘솔에서 Google Kubernetes Engine 클러스터 개요 페이지로 이동합니다.
Google Cloud 프로젝트를 선택합니다.
베어메탈이 유형 열에 표시되면 클러스터가 GKE On-Prem API에서 관리됩니다.
유형 열에 외부가 표시되는 경우 클러스터는 GKE On-Prem API에서 관리되지 않습니다.
클러스터에 대한 세부정보를 보려면 클러스터에 로그인하고 인증해야 합니다. 이렇게 하려면 다음 단계를 수행해야 합니다.
인증 설정
이전에 설명한 대로 모든 Fleet 클러스터는 콘솔의 GKE 클러스터 페이지에 표시됩니다. 하지만 노드 및 워크로드와 같은 세부정보를 추가로 확인하고 (이 기능이 사용 설정된 경우 클러스터 수명 주기 관리 작업을 수행하려면) 사용자가 클러스터에 로그인하고 인증해야 합니다. 이렇게 하려면 다음 인증 방법 중 하나로 등록된 클러스터를 설정해야 합니다.
Google ID: 이 옵션을 사용하면 Google Cloud 계정과 연결된 이메일 주소인 Google Cloud ID를 사용하여 로그인할 수 있습니다. 사용자가 이미 Google ID를 사용하여 Google Cloud에 액세스할 수 있으면 이 옵션을 사용합니다. 콘솔에서 클러스터를 만든 경우 Google ID를 사용하여 클러스터에 로그인할 수 있지만 다른 사용자에 대한 인증을 구성해야 합니다.
Google ID로 로그인은 콘솔에서 인증을 위한 가장 간단한 접근 방식이므로 Google ID 인증 설정에서 이를 설정하는 방법을 자세히 설명합니다.
OpenID Connect(OIDC): 사용자는 이 옵션을 통해 Okta 또는 Microsoft AD FS와 같은 타사 OIDC ID 공급업체의 ID를 사용하여 콘솔에서 클러스터에 로그인할 수 있습니다. 사용자에게 해당 공급자로부터 받은 기존 사용자 이름, 비밀번호, 보안 그룹 멤버십이 있으면 이 옵션을 사용해야 할 수 있습니다. 다음 가이드에서 클러스터에 대해 제3자 OIDC 인증을 설정하는 방법을 알아볼 수 있습니다.
OIDC로 GKE Identity Service용 클러스터 구성: 이 가이드에서는 클러스터별로 OIDC 인증을 설정하는 방법을 설명합니다.
Fleet용 GKE Identity Service 설정: 이 옵션을 사용하면 Fleet 수준에서 OIDC를 설정할 수 있습니다.
Bearer 토큰: 앞선 Google 제공 솔루션이 조직에 적합하지 않으면 Kubernetes 서비스 계정을 사용하여 인증을 설정하고 Bearer 토큰을 사용하여 로그인할 수 있습니다. 자세한 내용은 Bearer 토큰을 사용하여 설정을 참조하세요.
필요한 역할 부여
콘솔 액세스는 Google Cloud IAM으로 제어됩니다. 콘솔에서 클러스터 수명 주기를 관리하려면 프로젝트 소유자 외의 사용자에게 일부 IAM 역할을 부여해야 합니다.
사용자가 콘솔에 액세스할 수 있으려면 최소한 다음 역할을 부여해야 합니다.
roles/container.viewer. 이 역할을 통해 사용자는 콘솔에서 GKE 클러스터 페이지와 기타 컨테이너 리소스를 볼 수 있습니다. 이 역할에 포함된 권한에 대한 자세한 내용이나 읽기 및 쓰기 권한이 있는 역할을 부여하려면 IAM 문서의 Kubernetes Engine 역할을 참조하세요.roles/gkehub.viewer. 이 역할을 통해 사용자는 콘솔에서 Google Cloud 외부에 있는 클러스터를 볼 수 있습니다. 이 역할에 포함된 권한에 대한 자세한 내용이나 읽기 및 쓰기 권한이 있는 역할을 부여하려면 IAM 문서의 GKE 허브 역할을 참조하세요.
사용자가 콘솔에서 클러스터 수명 주기를 관리할 수 있도록 허용하려면
roles/gkeonprem.adminIAM 역할을 부여합니다.roles/gkeonprem.admin역할은 사용자에게 콘솔에서 클러스터 수명 주기를 관리하는 데 사용하는 GKE On-Prem API에 대한 관리 액세스 권한을 제공합니다. 이 역할에 포함된 권한에 대한 자세한 내용은 IAM 문서의 GKE On-Prem 역할 을 참조하세요.
다음 명령어는 콘솔에서 클러스터 수명 주기를 관리하기 위해 필요한 최소 역할을 부여하는 방법을 보여줍니다.
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkehub.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkeonprem.admin
각 항목의 의미는 다음과 같습니다.
PROJECT_ID는 Fleet 호스트 프로젝트입니다.bmctl을 사용하여 생성된 클러스터의 경우 사용자 클러스터 구성 파일의gkeConnect섹션에서 구성한 프로젝트입니다. 콘솔에서 생성된 클러스터의 경우 클러스터가 생성될 때 선택된 프로젝트입니다.MEMBER는user:emailID형식의 사용자 이메일 주소입니다(예:user:alice@example.com).
콘솔에서 클러스터 수명 주기 관리 사용 설정
콘솔에서 생성된 사용자 클러스터는 GKE On-Prem API에서 자동으로 관리되며, 이를 통해 콘솔에서 클러스터 수명주기 관리 태스크를 수행할 수 있습니다. bmctl을 사용하여 만든 사용자 클러스터에 이 기능을 사용 설정하려면 GKE On-Prem API에서 관리할 사용자 클러스터 구성의 단계를 따릅니다.
클러스터 수명 주기 관리가 사용 설정된 경우 콘솔에서 클러스터를 업데이트할 수 있습니다.
- 사용자 클러스터 업데이트
- 사용자 클러스터에서 노드 풀 추가 또는 삭제
- 사용자 클러스터 삭제
Google ID 인증 설정
사용자가 Google ID를 사용하여 클러스터에 로그인할 수 있게 하려면 다음을 구성해야 합니다.
콘솔에서 GKE 클러스터 페이지의 클러스터를 보고 상호작용할 수 있으려면 사용자에게 특정 Identity and Access Management(IAM) 역할이 필요합니다.
Connect 게이트웨이가 Connect Agent를 사용할 때 클러스터의 Kubernetes API 서버에 액세스하는 데 필요한 Kubernetes 역할 기반 액세스 제어(RBAC) 정책에 사용자를 추가해야 합니다.
RBAC 승인 구성
각 클러스터의 Kubernetes API 서버는 콘솔에서 들어오는 요청을 승인할 수 있어야 합니다. 승인을 구성하려면 각 클러스터에서 Kubernetes 역할 기반 액세스 제어(RBAC) 정책을 구성해야 합니다. 콘솔에서 클러스터를 만든 경우 GKE On-Prem API가 사용자 계정을 관리자로 추가하고 클러스터에 대한 전체 관리 액세스 권한을 부여하는 적절한 RBAC 정책을 만듭니다.
gcloud CLI
사용자에게 RBAC 정책을 적용하려면 관리 워크스테이션에서 다음 단계를 수행합니다.
다음 명령어를 실행하여 Google 계정으로 로그인하고 구성요소를 업데이트합니다.
gcloud auth login gcloud components update사용자 및 서비스 계정에 대해 RBAC 정책을 생성하고 클러스터에 적용합니다.
gcloud container fleet memberships generate-gateway-rbac \ --membership=MEMBERSHIP_NAME \ --role=ROLE \ --users=USERS \ --project=PROJECT_ID \ --kubeconfig=KUBECONFIG_PATH \ --context=KUBECONFIG_CONTEXT \ --apply다음을 바꿉니다.
- MEMBERSHIP_NAME: 이 Fleet에서 클러스터를 고유하게 나타내기 위해 사용되는 이름입니다. 베어 메탈용 GKE에서 멤버십 이름과 클러스터 이름은 동일합니다.
- ROLE: 클러스터에서 사용자에게 부여하려는 Kubernetes 역할입니다. 사용자에게 클러스터와 모든 네임스페이스의 모든 리소스에 대한 전체 액세스 권한을 부여하려면
clusterrole/cluster-admin을 지정합니다. 액세스를 제한하려면 커스텀 역할(예:role/mynamespace/namespace-reader)을 만듭니다. 명령어를 실행하기 전에 이미 커스텀 역할이 있어야 합니다. - USERS: 권한을 부여할 사용자(사용자 계정 또는 서비스 계정)의 이메일 주소이며 쉼표로 구분된 목록으로 표시됩니다. 예를 들면
--users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com입니다. - PROJECT_ID: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
- KUBECONFIG_PATH: 클러스터 항목이 포함된 kubeconfig 파일의 로컬 경로입니다.
KUBECONFIG_CONTEXT: kubeconfig 파일에 표시되는 클러스터의 클러스터 컨텍스트입니다.
kubectl config current-context를 실행하여 명령줄에서 현재 컨텍스트를 가져올 수 있습니다. 현재 컨텍스트 사용 여부와 관계없이 다음과 같은 간단한 명령어를 실행하여 클러스터에 액세스할 수 있는지 확인합니다.kubectl get namespaces \ --kubeconfig=KUBECONFIG_PATH \ --context=KUBECONFIG_CONTEXT
gcloud container fleet memberships generate-gateway-rbac를 실행한 후에는 출력의 끝에 다음과 같은 내용이 표시되며 가독성을 위해 잘립니다.Validating input arguments. Specified Cluster Role is: clusterrole/cluster-admin Generated RBAC policy is: -------------------------------------------- ... Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind Writing RBAC policy for user: foo@example.com to cluster. Successfully applied the RBAC policy to cluster.Connect 게이트웨이를 통해 클러스터에 액세스하는 데 사용되는 컨텍스트입니다.
generate-gateway-rbac명령어에 대한 자세한 내용은 gcloud CLI 참조 가이드를 참조하세요.
bmctl
사용자에게 RBAC 정책을 적용하려면 관리 워크스테이션에서 다음 단계를 수행합니다.
clusterSecurity.authorization섹션을 클러스터 구성 파일에 추가합니다. 사용자 이메일 주소와 클러스터를 관리해야 하는 다른 사용자의 이메일 주소를 지정합니다. 예를 들면 다음과 같습니다.... clusterSecurity: authorization: clusterAdmin: gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com] ...클러스터를 업데이트합니다.
bmctl update cluster \ -c CLUSTER_NAME \ --kubeconfig=KUBECONFIG다음과 같이 변경하세요.
- CLUSTER_NAME을 업데이트하려는 클러스터 이름으로 바꿉니다.
- 클러스터가 자체 관리 클러스터(예: 관리자 또는 독립형 클러스터)인 경우 KUBECONFIG를 클러스터의 kubeconfig 파일 경로로 바꿉니다. 클러스터가 사용자 클러스터인 경우 KUBECONFIG를 관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.