베어메탈용 Anthos 클러스터의 경우 다른 클러스터를 안전하게 관리하도록 관리자 클러스터를 설정합니다. 관리자 클러스터에서 사용자 클러스터를 생성, 업데이트, 업그레이드, 삭제할 수 있습니다. 사용자 클러스터는 관리와 별도로 워크로드를 실행하므로 민감한 정보가 보호됩니다.
멀티 클러스터 워크로드를 관리하는 관리자 클러스터는 고가용성(HA) 안정성을 제공할 수 있습니다. HA 클러스터에서 하나의 제어 영역 노드에 장애가 발생해도 다른 노드는 계속 작동합니다.
멀티 클러스터 환경의 관리자 클러스터는 최상의 기본 보안을 제공합니다. 관리 데이터에 대한 액세스는 워크로드와 분리되므로 사용자 워크로드에 액세스하는 사용자는 SSH 키 및 서비스 계정 데이터와 같은 민감한 관리 데이터에 액세스할 수 없습니다. 따라서 별도의 관리자 클러스터가 있다는 것은 관리 및 워크로드를 위한 전용 리소스가 필요하다는 것을 의미하므로 보안과 필요한 리소스 사이에서 약간의 절충이 필요합니다.
bmctl
명령어를 사용하여 관리자 클러스터를 만듭니다. 관리자 클러스터를 만든 후에는 워크로드를 실행할 사용자 클러스터를 만듭니다.
기본 요건:
- Cloud Storage에서 최신
bmctl
을 다운로드했습니다(gs://anthos-baremetal-release/bmctl/1.8.9/linux-amd64/bmctl
). bmctl
을 실행하는 워크스테이션은 대상 사용자 클러스터의 모든 노드에 네트워크로 연결되어 있습니다.bmctl
을 실행하는 워크스테이션은 클러스터 API 서버(제어 영역 VIP)에 네트워크로 연결되어 있습니다.- 관리자 클러스터를 만드는 데 사용된 SSH 키는 루트에서 사용할 수 있거나, 대상 관리자 클러스터의 모든 노드에 대한 SUDO 사용자 액세스 권한이 있습니다.
- Connect-register 서비스 계정은 Connect에 사용하도록 구성됩니다.
하이브리드 클러스터를 만드는 방법에 대한 확장된 단계별 안내는 베어메탈용 Anthos 클러스터 빠른 시작을 참조하세요. 관리자 클러스터 만들기는 관리자 클러스터에서 워크로드를 실행하지 않는 것을 제외하면 하이브리드 클러스터 만들기와 방법이 비슷합니다.
SELinux 사용 설정
컨테이너를 보호하도록 SELinux를 사용 설정하려면 베어메탈용 Anthos 클러스터를 설치하기 전 Enforced
모드 호스트 머신에 SELinux가 사용 설정되었는지 확인해야 합니다. SELinux는 기본적으로 RHEL 및 CentOS 시스템에서 사용 설정됩니다. SELinux가 클러스터에 사용 중지되어 있거나 확실하지 않으면 SELinux를 사용하여 컨테이너 보안에서 이를 사용 설정하는 방법에 대한 안내를 참조하세요.
베어메탈용 Anthos 클러스터는 RHEL 및 CentOS 시스템에서만 SELinux를 지원합니다.
gcloud CLI에 로그인 및 관리자 클러스터 구성 파일 만들기
다음 명령어를 사용하여 베어메탈용 Anthos 클러스터에서 클러스터를 만드는 데 사용할 수 있는 기본 사용자 인증 정보를 설정합니다.
gcloud auth application-default login
이 페이지에서 자동 API 사용 설정 및 서비스 계정 만들기 기능을 사용하려면 해당 주 구성원에게 프로젝트 소유자 역할을 부여합니다. 주 구성원에게 프로젝트 소유자 역할이 없으면 다음 단계를 완료하세요.
프로젝트 소유자 역할을 부여하지 않고도 클러스터 생성이 성공할 수 있도록 하려면 주 구성원에게 다음 IAM 역할을 추가합니다.
- 서비스 계정 관리자
- 서비스 계정 키 관리자
- 프로젝트 IAM 관리자
- Compute 뷰어
- 서비스 사용량 관리자
주 구성원이 해당 역할이 있는 서비스 계정인 경우 다음을 실행할 수 있습니다.
export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
JSON_KEY_FILE
을 서비스 계정의 JSON 키 파일 경로로 바꿉니다.클러스터 생성에 사용할 Google Cloud 프로젝트의 ID를 가져오고 환경 변수에 저장합니다.
export CLOUD_PROJECT_ID=$(gcloud config get-value project)
bmctl
을 사용하여 관리자 클러스터 구성 만들기
gcloud에 로그인하여 프로젝트를 설정하면 bmctl
명령어를 사용하여 클러스터 구성 파일을 만들 수 있습니다.
다음 예시에서는 모든 서비스 계정이 bmctl create config
명령어로 자동으로 생성됩니다.
bmctl create config -c ADMIN_CLUSTER_NAME --enable-apis \
--create-service-accounts --project-id=CLOUD_PROJECT_ID
다음을 바꿉니다.
- ADMIN_CLUSTER_NAME: 새 클러스터의 이름입니다.
- CLOUD_PROJECT_ID: Google Cloud 프로젝트 ID 또는
$CLOUD_PROJECT_ID
환경 변수입니다.
다음은 프로젝트 ID my-gcp-project
와 연결된 admin1
이라는 관리자 클러스터의 구성 파일을 만드는 예시입니다.
bmctl create config -c admin1 --create-service-accounts --enable-apis --project-id=my-gcp-project
파일은 bmctl-workspace/admin1/admin1.yaml.
에 기록됩니다.
자동으로 API를 사용 설정하고 서비스 계정을 만드는 대신 적절한 IAM 권한이 있는 기존 서비스 계정을 제공할 수도 있습니다. 즉, bmctl
명령어의 이전 예시에서 자동 서비스 계정 생성을 건너뛸 수 있습니다.
bmctl create config -c admin1
클러스터 구성 파일 수정
이제 클러스터 구성 파일이 있으므로 수정하여 다음과 같이 변경합니다.
관리자 클러스터 노드에 액세스할 SSH 비공개 키를 제공합니다.
# bmctl configuration variables. Because this section is valid YAML but not a valid Kubernetes # resource, this section can only be included when using bmctl to # create the initial admin/admin cluster. Afterwards, when creating user clusters by directly # applying the cluster and node pool resources to the existing cluster, you must remove this # section. gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json sshPrivateKeyPath: /path/to/your/ssh_private_key gkeConnectAgentServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json gkeConnectRegisterServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json cloudOperationsServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json
1.7.0 이상 버전에서는 Connect를 사용하여 프로젝트 환경에 클러스터를 등록해야 합니다.
- 자동 API 사용 설정 및 서비스 계정 생성 기능을 사용하여 구성 파일을 만든 경우 이 단계를 건너뛸 수 있습니다.
- 자동 API 사용 설정 및 서비스 계정 생성 기능을 사용하지 않고 구성 파일을 만든 경우 클러스터 구성 파일의 해당
gkeConnectAgentServiceAccountKeyPath
및gkeConnectRegisterServiceAccountKeyPath
필드에서 다운로드한 서비스 계정 JSON 키를 참조하세요.
구성이
admin
의 클러스터 유형(기본값)을 지정하는지 확인합니다.spec: # Cluster type. This can be: # 1) admin: to create an admin cluster. This can later be used to create user clusters. # 2) user: to create a user cluster. Requires an existing admin cluster. # 3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads. # 4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters. type: admin
멀티 노드, 고가용성, 제어 영역을 지정하기 위해 구성 파일을 변경합니다. 비정상적인 노드 수를 지정하여 HA용 대부분의 쿼럼을 확보합니다.
# Control plane configuration controlPlane: nodePoolSpec: nodes: # Control plane node pools. Typically, this is either a single machine # or 3 machines if using a high availability deployment. - address: 10.200.0.4 - address: 10.200.0.5 - address: 10.200.0.6
클러스터 노드 및 컨테이너 런타임의 포드 밀도를 지정합니다.
.... # NodeConfig specifies the configuration that applies to all nodes in the cluster. nodeConfig: # podDensity specifies the pod density configuration. podDensity: # maxPodsPerNode specifies at most how many pods can be run on a single node. maxPodsPerNode: 250 # containerRuntime specifies which container runtime to use for scheduling containers on nodes. # containerd and docker are supported. containerRuntime: containerd ....
관리자 클러스터의 경우
maxPodsPerNode
에 허용되는 값은 HA 클러스터의 경우32-250
, 비 HA 클러스터의 경우64-250
입니다. 지정되지 않은 경우 기본값은110
입니다. 클러스터가 생성된 후에는 이 값을 업데이트할 수 없습니다.또한 포드 밀도는 클러스터의 사용 가능한 IP 리소스에 따라서도 제한됩니다. 자세한 내용은 포드 네트워킹을 참조하세요.
클러스터 구성으로 관리자 클러스터 만들기
bmctl
명령어를 사용하여 클러스터를 배포합니다.
bmctl create cluster -c ADMIN_CLUSTER_NAME
ADMIN_CLUSTER_NAME은 이전 섹션에서 만든 클러스터 이름을 지정합니다.
다음은 admin1
이라는 클러스터를 만드는 명령어의 예시입니다.
bmctl create cluster -c admin1
샘플 전체 관리자 클러스터 구성
다음은 bmctl
명령어로 만든 샘플 관리자 클러스터 구성 파일입니다.
이 샘플 구성에는 자리표시자 클러스터 이름, VIP, 주소가 사용되었습니다. 사용 중인 네트워크에서 작동하지 않을 수 있습니다.
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /bmctl/bmctl-workspace/.ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
gkeConnectRegisterServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
cloudOperationsServiceAccountKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: admin1
namespace: cluster-admin1
spec:
# Cluster type. This can be:
# 1) admin: to create an admin cluster. This can later be used to create user clusters.
# 2) user: to create a user cluster. Requires an existing admin cluster.
# 3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
# 4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
type: admin
# Anthos cluster version.
anthosBareMetalVersion: 1.8.9
# GKE connect configuration
gkeConnect:
projectID: $GOOGLE_PROJECT_ID
# Control plane configuration
controlPlane:
nodePoolSpec:
nodes:
# Control plane node pools. Typically, this is either a single machine
# or 3 machines if using a high availability deployment.
- address: 10.200.0.4
- address: 10.200.0.5
- address: 10.200.0.6
# Cluster networking configuration
clusterNetwork:
# Pods specify the IP ranges from which pod networks are allocated.
pods:
cidrBlocks:
- 192.168.0.0/16
# Services specify the network ranges from which service virtual IPs are allocated.
# This can be any RFC 1918 range that does not conflict with any other IP range
# in the cluster and node pool resources.
services:
cidrBlocks:
- 10.96.0.0/20
# Load balancer configuration
loadBalancer:
# Load balancer mode can be either 'bundled' or 'manual'.
# In 'bundled' mode a load balancer will be installed on load balancer nodes during cluster creation.
# In 'manual' mode the cluster relies on a manually-configured external load balancer.
mode: bundled
# Load balancer port configuration
ports:
# Specifies the port the load balancer serves the Kubernetes control plane on.
# In 'manual' mode the external load balancer must be listening on this port.
controlPlaneLBPort: 443
# There are two load balancer virtual IP (VIP) addresses: one for the control plane
# and one for the L7 Ingress service. The VIPs must be in the same subnet as the load balancer nodes.
# These IP addresses do not correspond to physical network interfaces.
vips:
# ControlPlaneVIP specifies the VIP to connect to the Kubernetes API server.
# This address must not be in the address pools below.
controlPlaneVIP: 10.200.0.71
# IngressVIP specifies the VIP shared by all services for ingress traffic.
# Allowed only in non-admin clusters.
# This address must be in the address pools below.
# ingressVIP: 10.0.0.2
# AddressPools is a list of non-overlapping IP ranges for the data plane load balancer.
# All addresses must be in the same subnet as the load balancer nodes.
# Address pool configuration is only valid for 'bundled' LB mode in non-admin clusters.
# addressPools:
# - name: pool1
# addresses:
# # Each address must be either in the CIDR form (1.2.3.0/24)
# # or range form (1.2.3.1-1.2.3.5).
# - 10.0.0.1-10.0.0.4
# A load balancer node pool can be configured to specify nodes used for load balancing.
# These nodes are part of the Kubernetes cluster and run regular workloads as well as load balancers.
# If the node pool config is absent then the control plane nodes are used.
# Node pool configuration is only valid for 'bundled' LB mode.
# nodePoolSpec:
# nodes:
# - address: <Machine 1 IP>
# Proxy configuration
# proxy:
# url: http://[username:password@]domain
# # A list of IPs, hostnames or domains that should not be proxied.
# noProxy:
# - 127.0.0.1
# - localhost
# Logging and Monitoring
clusterOperations:
# Cloud project for logs and metrics.
projectID: $GOOGLE_PROJECT_ID
# Cloud location for logs and metrics.
location: us-central1
# Whether collection of application logs/metrics should be enabled (in addition to
# collection of system logs/metrics which correspond to system components such as
# Kubernetes control plane or cluster management agents).
# enableApplication: false
# Storage configuration
storage:
# lvpNodeMounts specifies the config for local PersistentVolumes backed by mounted disks.
# These disks need to be formatted and mounted by the user, which can be done before or after
# cluster creation.
lvpNodeMounts:
# path specifies the host machine path where mounted disks will be discovered and a local PV
# will be created for each mount.
path: /mnt/localpv-disk
# storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
# is created during cluster creation.
storageClassName: local-disks
# lvpShare specifies the config for local PersistentVolumes backed by subdirectories in a shared filesystem.
# These subdirectories are automatically created during cluster creation.
lvpShare:
# path specifies the host machine path where subdirectories will be created on each host. A local PV
# will be created for each subdirectory.
path: /mnt/localpv-share
# storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
# is created during cluster creation.
storageClassName: local-shared
# numPVUnderSharedPath specifies the number of subdirectories to create under path.
numPVUnderSharedPath: 5
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
# podDensity specifies the pod density configuration.
podDensity:
# maxPodsPerNode specifies at most how many pods can be run on a single node.
maxPodsPerNode: 250
# containerRuntime specifies which container runtime to use for scheduling containers on nodes.
# containerd and docker are supported.
containerRuntime: containerd
# KubeVirt configuration, uncomment this section if you want to install kubevirt to the cluster
# kubevirt:
# # if useEmulation is enabled, hardware accelerator (i.e relies on cpu feature like vmx or svm)
# # will not be attempted. QEMU will be used for software emulation.
# # useEmulation must be specified for KubeVirt installation
# useEmulation: false
# Authentication; uncomment this section if you wish to enable authentication to the cluster with OpenID Connect.
# authentication:
# oidc:
# # issuerURL specifies the URL of your OpenID provider, such as "https://accounts.google.com". The Kubernetes API
# # server uses this URL to discover public keys for verifying tokens. Must use HTTPS.
# issuerURL: <URL for OIDC Provider; required>
# # clientID specifies the ID for the client application that makes authentication requests to the OpenID
# # provider.
# clientID: <ID for OIDC client application; required>
# # clientSecret specifies the secret for the client application.
# clientSecret: <Secret for OIDC client application; optional>
# # kubectlRedirectURL specifies the redirect URL (required) for the gcloud CLI, such as
# # "http://localhost:[PORT]/callback".
# kubectlRedirectURL: <Redirect URL for the gcloud CLI; optional, default is "http://kubectl.redirect.invalid">
# # username specifies the JWT claim to use as the username. The default is "sub", which is expected to be a
# # unique identifier of the end user.
# username: <JWT claim to use as the username; optional, default is "sub">
# # usernamePrefix specifies the prefix prepended to username claims to prevent clashes with existing names.
# usernamePrefix: <Prefix prepended to username claims; optional>
# # group specifies the JWT claim that the provider will use to return your security groups.
# group: <JWT claim to use as the group name; optional>
# # groupPrefix specifies the prefix prepended to group claims to prevent clashes with existing names.
# groupPrefix: <Prefix prepended to group claims; optional>
# # scopes specifies additional scopes to send to the OpenID provider as a comma-delimited list.
# scopes: <Additional scopes to send to OIDC provider as a comma-separated list; optional>
# # extraParams specifies additional key-value parameters to send to the OpenID provider as a comma-delimited
# # list.
# extraParams: <Additional key-value parameters to send to OIDC provider as a comma-separated list; optional>
# # proxy specifies the proxy server to use for the cluster to connect to your OIDC provider, if applicable.
# # Example: https://user:password@10.10.10.10:8888. If left blank, this defaults to no proxy.
# proxy: <Proxy server to use for the cluster to connect to your OIDC provider; optional, default is no proxy>
# # deployCloudConsoleProxy specifies whether to deploy a reverse proxy in the cluster to allow Google Cloud
# # Console access to the on-premises OIDC provider for authenticating users. If your identity provider is not
# # reachable over the public internet, and you wish to authenticate using Google Cloud console, then this field
# # must be set to true. If left blank, this field defaults to false.
# deployCloudConsoleProxy: <Whether to deploy a reverse proxy for Google Cloud console authentication; optional>
# # certificateAuthorityData specifies a Base64 PEM-encoded certificate authority certificate of your identity
# # provider. It's not needed if your identity provider's certificate was issued by a well-known public CA.
# # However, if deployCloudConsoleProxy is true, then this value must be provided, even for a well-known public
# # CA.
# certificateAuthorityData: <Base64 PEM-encoded certificate authority certificate of your OIDC provider; optional>
# Node access configuration; uncomment this section if you wish to use a non-root user
# with passwordless sudo capability for machine login.
# nodeAccess:
# loginUser: <login user name>