ベアメタル版 Anthos クラスタの概要
ベアメタル版 Anthos クラスタを使用すると、次の 4 種類のクラスタを定義できます。
- 管理 - ユーザー クラスタの管理に使用されるクラスタ。
- ユーザー - ワークロードの実行に使用されるクラスタ。
- スタンドアロン - 自身を管理でき、ワークロードを実行できるが、他のユーザー クラスタの作成または管理はできない単一クラスタ。
- ハイブリッド - 管理とワークロード両方のための単一クラスタで、ユーザー クラスタを管理することもできる。
このクイックスタートでは、ベアメタル版 Anthos クラスタを使用して 2 ノードのハイブリッド クラスタをデプロイします。ここでは、クラスタの作成方法と、クラスタの作成プロセスをモニタリングする方法について説明します。
このクイックスタートは、Kubernetes の基本知識があることを前提としています。
ベアメタル版 Anthos クラスタを準備する
ベアメタル版 Anthos クラスタにクラスタを作成する前に、次のことを行う必要があります。
Google Cloud プロジェクトを作成する
このクイックスタートでは、すべての Google Cloud リソースを整理する新しい Google Cloud プロジェクトを作成します。Anthos clusters on bare metal にクラスタを作成するには、アカウントにオーナーのロールがある Google Cloud プロジェクトが必要です。
詳しくは、プロジェクトの作成と管理をご覧ください。
Linux 管理ワークステーションを構成する
このクイックスタートでは、bmctl と kubectl を使用してクラスタを作成し、操作します。このコマンドライン ツールは、Linux 管理ワークステーションで実行されます。管理ワークステーションの設定については、管理ワークステーションの前提条件をご覧ください。
クラスタノードを作成する
クラスタのノードとして機能するマシンを 2 つ作成します。
- 1 つのマシンはコントロール プレーン ノードとして機能します。
- 1 つのマシンはワーカーノードとして機能します。
クラスタノードの要件の詳細については、クラスタノード マシンの前提条件をご覧ください。
クラスタを作成
クラスタを作成するには、次の手順を行います。
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 プロジェクトを作成するで作成したプロジェクトです。
上記のコマンドにより、次のパスで baremetal ディレクトリに構成ファイルが作成されます: bmctl-workspace/cluster1/cluster1.yaml
構成ファイルを編集する
構成ファイルを編集するには、次のようにします。
- エディタで
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 ログに詳細情報を書き込みます。
bmctl、プリフライト チェック、ノード インストール ログは、次のディレクトリにあります: baremetal/bmctl-workspace/CLUSTER_NAME/log
bmctl プリフライトは、行う予定のクラスタのインストールについて、次の条件を確認します。
- Linux ディストリビューションとバージョンがサポートされている。
- SELinux が「enforcing」モードではない。
- Ubuntu では、Uncomplicated Firewall（UFW）がアクティブではありません。
- Google Container Registry に到達可能である。
- VIP が利用可能である。
- クラスタマシンが相互に接続されている。
- ロードバランサ マシンは同じレイヤ 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
Deployment と Service を作成する
Deployment のマニフェストを次に示します。
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 として保存します。
次のコマンドを使用して Deployment を作成します。
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml
Deployment を表示します。
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments
出力には、Deployment で使用可能な 3 つの Pod があることが示されています。
NAME READY UP-TO-DATE AVAILABLE AGE my-deployment 3/3 3 3 16s
次のマニフェストでは、LoadBalancer タイプの Service を定義します。
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: metrics department: sales type: LoadBalancer ports: - port: 80 targetPort: 8080
マニフェストを my-service.yaml として保存します。
次のコマンドを使用して Service を作成します。
kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml
Service を表示します。
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 クラスタは、Service に外部 IP アドレスを付与します。外部 IP アドレスを使用して Service を呼び出します。
curl 172.16.1.21
次のような hello world メッセージが出力されます。
Hello, world! Version: 2.0.0 Hostname: my-deployment-75d45b64f9-6clxj
高可用性のコントロール プレーンを作成する
このクイックスタートでは、単純な 2 ノードのハイブリッド クラスタを作成しました。高可用性コントロール プレーンを作成する場合は、3 つのコントロール プレーン ノードを含むクラスタを 1 つ作成します。
たとえば、構成ファイルを編集し、コントロール プレーンに追加のノードを追加します。
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>