베어메탈용 Anthos 클러스터 소개
베어메탈용 Anthos 클러스터를 사용하면 다음 네 가지 유형의 클러스터를 정의할 수 있습니다.
- 관리자 - 사용자 클러스터를 관리하는 데 사용되는 클러스터입니다.
- 사용자 - 워크로드를 실행하는 데 사용되는 클러스터입니다.
- 독립형 - 사용자가 직접 관리할 수 있으며 워크로드를 실행할 수 있지만 다른 사용자 클러스터를 만들거나 관리할 수 없는 단일 클러스터입니다.
- 하이브리드 - 사용자 클러스터도 관리할 수 있는 관리자와 워크로드에 대한 단일 클러스터입니다.
이 빠른 시작에서는 베어메탈용 Anthos 클러스터를 사용하여 2노드 하이브리드 클러스터를 배포합니다. 클러스터를 만드는 방법과 클러스터 생성 프로세스를 모니터링하는 방법을 알아봅니다.
이 빠른 시작에서는 사용자가 Kubernetes를 기본적으로 이해하고 있다고 가정합니다.
베어메탈용 Anthos 클러스터 준비
베어메탈용 Anthos 클러스터에 클러스터를 만들기 전에 다음을 수행해야 합니다.
Google Cloud 프로젝트 만들기
이 빠른 시작에서는 모든 Google Cloud 리소스를 구성하는 새 Google Cloud 프로젝트를 만듭니다. 베어메탈용 Anthos 클러스터에 클러스터를 만들려면 계정에 소유자 역할이 있는 Google Cloud 프로젝트가 필요합니다.
자세한 내용은 프로젝트 만들기 및 관리를 참조하세요.
Linux 관리자 워크스테이션 구성
이 빠른 시작에서는 bmctl
및 kubectl
을 사용하여 클러스터를 만들고 사용합니다.
이 명령줄 도구는 Linux 관리자 워크스테이션에서 실행됩니다. 관리자 워크스테이션 설정은 관리자 워크스테이션 기본 요건을 참조하세요.
클러스터 노드 만들기
클러스터의 노드로 사용될 두 머신을 만듭니다.
- 머신 한 개는 제어 영역 노드로 작동합니다.
- 머신 한 개는 워커 노드로 작동합니다.
클러스터 노드의 요구사항에 대해 자세히 알아보려면 클러스터 노드 머신 기본 요건으로 이동하세요.
클러스터 만들기
클러스터를 만들려면 다음 안내를 따르세요.
bmctl
를 사용하여 구성 파일을 만듭니다.- 구성 파일을 수정하여 클러스터 및 네트워크에 맞게 사용자 설정 하세요.
bmctl
을 사용하여 구성 파일에서 클러스터를 만듭니다.
구성 파일 만들기
구성 파일을 만들고 서비스 계정과 API를 자동으로 사용 설정하려면 baremetal
디렉터리에 있는지 확인하고 다음 플래그를 사용하여 bmctl
명령어를 실행합니다.
./bmctl create config -c CLUSTER_NAME \ --enable-apis --create-service-accounts --project-id=PROJECT_ID
CLUSTER_NAME은 클러스터 이름입니다. PROJECT_ID은 Google Cloud 프로젝트 만들기에서 만든 프로젝트입니다.
위 명령어는 다음 bmctl-workspace/cluster1/cluster1.yaml
경로의 baremetal
디렉터리에 구성 파일을 만듭니다.
구성 파일 수정
구성 파일을 수정하려면 다음 안내를 따르세요.
- 편집기에서
bmctl-workspace/cluster1/cluster1.yaml
구성 파일을 엽니다. - 특정 노드 및 네트워크 요구사항에 따라 파일을 수정합니다. 아래의 샘플 구성 파일을 참고용으로 사용하세요. 이 빠른 시작은 OpenID Connect(OIDC)에 대한 정보를 사용하거나 포함하지 않습니다.
# gcrKeyPath: < to GCR service account key>
gcrKeyPath: baremetal/gcr.json
# sshPrivateKeyPath: < to SSH private key, used for node access>
sshPrivateKeyPath: .ssh/id_rsa
# gkeConnectAgentServiceAccountKeyPath: < to Connect agent service account key>
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
# gkeConnectRegisterServiceAccountKeyPath: < to Hub registration service account key>
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
# cloudOperationsServiceAccountKeyPath: < to Cloud Operations service account key>
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
name: cluster-cluster1
---
# Cluster configuration. Note that some of these fields are immutable once the cluster is created.
# For more info, see https://cloud.google.com/anthos/clusters/docs/bare-metal/1.13/reference/cluster-config-ref#cluster_configuration_fields
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
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: hybrid
# Anthos cluster version.
anthosBareMetalVersion: 1.13.0
# GKE connect configuration
gkeConnect:
projectID: 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: CONTROL_PLANE_NODE_IP
# 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:
- 172.26.232.0/24
# 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: CONTROL_PLANE_VIP
# 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: INGRESS_VIP
# 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).
# - LOAD_BALANCER_ADDRESS_POOL-
# A load balancer nodepool 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: LOAD_BALANCER_NODE_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: 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 the maximum number of pods allowed on a single node.
maxPodsPerNode: 250
---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
name: node-pool-1
namespace: cluster-cluster1
spec:
clusterName: cluster1
nodes:
- address: WORKER_NODE_1_IP
- address: WORKER_NODE_2_IP
실행 전 검사 실행 및 클러스터 만들기
bmctl
명령어는 클러스터를 만들기 전에 클러스터 구성 파일에서 실행 전 검사를 실행합니다. 확인에 성공하면 bmctl
이 클러스터를 만듭니다.
실행 전 확인을 실행하고 클러스터를 만들려면 다음 안내를 따르세요.
- 현재 위치가
baremetal
디렉터리인지 확인합니다. - 다음 명령어를 사용하여 클러스터를 만듭니다.
./bmctl create cluster -c CLUSTER_NAME
./bmctl create cluster -c cluster1
bmctl
명령어는 실행 전 확인과 클러스터 생성을 모니터링한 후 출력을 화면에 표시하고 자세한 정보를 bmctl
로그에 기록합니다.
다음 디렉터리 baremetal/bmctl-workspace/CLUSTER_NAME/log
에서 bmctl
, 실행 전 검사 및 노드 설치 로그를 찾을 수 있습니다.
bmctl
실행 전 검사는 제안된 클러스터 설치를 다음과 같은 조건으로 확인합니다.
- Linux 배포판 및 버전이 지원됩니다.
- SELinux는 '시행' 모드가 아닙니다.
- Ubuntu에서 Unflicated Firewall(UFW)은 활성화되지 않습니다.
- Google Container Registry에 연결할 수 있습니다.
- VIP를 사용할 수 있습니다.
- 클러스터 머신은 서로 연결성을 가지고 있습니다.
- 부하 분산기 머신은 동일한 Layer 2 서브넷에 있습니다.
클러스터를 만드는 데 몇 분 정도 걸릴 수 있습니다.
클러스터 정보 가져오기
클러스터가 성공적으로 생성되면 kubectl
명령어를 사용하여 새 클러스터에 대한 정보를 표시합니다. 클러스터 생성 중에 bmctl
명령어는 kubectl
로 쿼리할 수 있는 클러스터의 kubeconfig 파일을 작성합니다. kubeconfig 파일은 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig
에 기록됩니다.
예를 들면 다음과 같습니다.
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get nodes
이 명령어는 다음을 반환합니다.
NAME STATUS ROLES AGE VERSION node-01 Ready master 16h v1.17.8-gke.16 node-02 Ready <none> 16h v1.17.8-gke.16
클러스터 생성이 실행 전 검사에서 실패하면 실행 전 검사 로그에 오류가 있는지 확인하고 클러스터 구성 파일에서 오류를 수정합니다. 실행 전 검사 로그는 /log
디렉터리에 있습니다.
~/baremetal/bmctl-workspace/CLUSTER_NAME/log
클러스터의 각 머신에 대한 실행 전 검사 로그는 CLUSTER_NAME 디렉터리에 있으며 IP 주소로 구성됩니다. 예를 들면 다음과 같습니다.
bmctl-workspace/cluster1/log └── preflight-20201007-034844 ├── 172.17.0.3 ├── 172.17.0.4 ├── 172.17.0.5 ├── 172.17.0.6 ├── 172.17.0.7 └── node-network
실행 전 검사 오류 무시
실행 전 확인 후 클러스터 만들기가 실패하면 bmctl
명령어에서 --force
플래그를 사용하여 클러스터를 다시 설치할 수 있습니다.
--force
플래그는 기존 클러스터를 통해 설치되지만 이미 할당된 서버 포트로 인해 실행 전 검사 실패의 결과는 무시합니다.
- 현재 위치가
baremetal
디렉터리인지 확인합니다. - 다음 명령어를
--force
플래그와 함께 사용하여 클러스터를 다시 만듭니다.
./bmctl create cluster -c CLUSTER_NAME --force
./bmctl create cluster -c cluster1 -force
배포 및 서비스 만들기
배포의 매니페스트는 다음과 같습니다.
apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: selector: matchLabels: app: metrics department: sales replicas: 3 template: metadata: labels: app: metrics department: sales spec: containers: - name: hello image: "gcr.io/google-samples/hello-app:2.0"
매니페스트를 my-deployment.yaml
로 저장합니다.
다음 명령어를 사용하여 배포를 만듭니다.
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml
배포를 확인합니다.
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments
출력은 배포에 사용 가능하고 준비된 포드가 3개 있음을 보여줍니다.
NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 16s
다음 매니페스트는 LoadBalancer 유형의 서비스를 정의합니다.
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: metrics department: sales type: LoadBalancer ports: - port: 80 targetPort: 8080
매니페스트를 my-service.yaml
로 저장합니다.
다음 명령어를 사용하여 서비스를 만듭니다.
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml
서비스를 확인합니다.
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get service my-service
출력:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S my-service LoadBalancer 172.26.232.2 172.16.1.21 80:30060/TCP
베어메탈용 Anthos 클러스터 서비스에 외부 IP 주소를 제공합니다. 외부 IP 주소를 사용하여 서비스를 호출합니다.
curl 172.16.1.21
출력은 다음과 같은 hello world 메시지입니다.
Hello, world! Version: 2.0.0 Hostname: my-deployment-75d45b64f9-6clxj
고가용성 제어 영역 만들기
이 빠른 시작에서는 단순한 2-노드 하이브리드 클러스터를 만들었습니다. 고가용성 제어 영역을 만들려면 제어 영역 노드가 3개인 클러스터를 만듭니다.
예를 들어 구성 파일을 수정하여 제어 영역에 2개의 노드를 추가합니다.
controlPlane: nodePoolSpec: clusterName: cluster1 nodes: # Control Plane node pools. Typically, this is either a single machine # or 3 machines if using a high availability deployment. - address: <Machine 1 IP> - address: <Machine 2 IP> - address: <Machine 3 IP>
자체 노드 풀에서 부하 분산기 실행
이 빠른 시작에서는 단순한 2-노드 하이브리드 클러스터를 만들었습니다. 따라서 부하 분산기는 제어 영역을 실행하는 동일한 노드에서 실행됩니다.
부하 분산기를 자체 노드 풀에서 실행하려면 구성 파일의 loadBalancer
섹션에 있는 nodePoolSpec
값을 수정합니다.
loadBalancer: nodePoolSpec: clusterName: "cluster1" nodes: - address: <LB Machine 1 IP> - address: <LB Machine 2 IP>