バージョン 1.7。このバージョンは現在サポートされていません。詳細については、バージョンのサポートポリシーをご覧ください。バージョン 1.8 にアップグレードする方法については、1.8 ドキュメントのベアメタル版 Anthos のアップグレードをご覧ください。

利用可能なサポートされているバージョン: 1.13 | 1.12 | 1.11

ベアメタル版 Anthos クラスタクイックスタート

ベアメタル版 Anthos クラスタを使用すると、次の 4 種類のクラスタを定義できます。

管理 - ユーザークラスタの管理に使用されるクラスタ
ユーザー - ワークロードの実行に使用されるクラスタ
スタンドアロン: 自身を管理でき、ワークロードを実行できるが、他のユーザークラスタの作成または管理はできない単一クラスタ。
ハイブリッド - 管理とワークロード両方のための単一クラスタで、ユーザークラスタを管理することも可能

このクイックスタートでは、ベアメタル版 Anthos クラスタを使用して 2 ノードのハイブリッドクラスタをデプロイします。ここでは、クラスタの作成方法と、クラスタの作成プロセスをモニタリングする方法について説明します。

このクイックスタートは、Kubernetes の基本知識があることを前提としています。

ベアメタル版 Anthos クラスタを準備する

ベアメタル版 Anthos クラスタにクラスタを作成する前に、次のことを行う必要があります。

Google Cloud プロジェクトを作成します。
Google Cloud CLI をインストールします。
Linux 管理ワークステーションを構成する。
bmctl ツールをインストールします。

Google Cloud プロジェクトを作成する

このクイックスタートでは、すべての Google Cloud リソースを整理する新しい Google Cloud プロジェクトを作成します。ベアメタル版 Anthos クラスタにクラスタを作成するには、アカウントに次のいずれかのロールが割り当てられている Google Cloud プロジェクトが必要です。

編集者
オーナー

詳しくは、プロジェクトの作成と管理をご覧ください。

Google Cloud CLI をインストールする

このクイックスタートでは、kubectl ツールと bmctl ツールを使用してクラスタの作成と設定を行います。これらのツールをインストールするには、gcloud と gsutil が必要です。Google Cloud CLI には、gcloud、gsutil、kubectl コマンドラインツールが含まれています。

必要なツールをインストールするには、次の手順を完了します。

管理ワークステーションで、こちらの手順を使用して、Google Cloud CLI をインストールして初期化します。この手順により、gcloud と gsutil がインストールされます。
Google Cloud CLI を更新します。
```
gcloud components update
   
```
サービスとサービスアカウントを管理するために、Google アカウントでログインします。
```
gcloud auth login --update-adc
```
新しいブラウザタブが開き、アカウントの選択を求めるプロンプトが表示されます。
gcloud を使用して kubectl をインストールします。
```
gcloud components install kubectl
```

Linux 管理ワークステーションを構成する

gcloud、gsutil、kubectl をインストールしたら、Linux 管理ワークステーションを構成します。Cloud Shell を管理ワークステーションとして使用しないでください。

Docker バージョン 19.03 以降をインストールします。Docker の構成方法については、ご使用の Linux ディストリビューションに対応するページをご覧ください。
root アクセスを使用するには、管理ワークステーションとリモートクラスタノードマシンの両方で SSH を設定します。最初に、管理ワークステーションから鍵を共有するには、リモートクラスタノードマシンで root の SSH パスワード認証を有効にする必要があります。鍵を設定したら、SSH パスワード認証を無効にできます。
管理ワークステーションで秘密鍵と公開鍵のペアを生成します。鍵のパスフレーズは設定しないでください。管理ワークステーションとクラスタノードマシン間のパスワードなしの安全な接続に SSH を使用するには、鍵が必要です。次のコマンドを実行して鍵を生成します。
```
ssh-keygen -t rsa
```
SSH の設定に、クラスタノードマシンへの SUDO ユーザーアクセスを使用することもできますが、パスワードを使用せず、root ユーザーではない接続の場合は、クラスタ構成ファイルを適切な認証情報で更新する必要があります。詳細については、クラスタ構成ファイルの例の #Node access configuration セクションをご覧ください。
生成された公開鍵をクラスタノードマシンに追加します。デフォルトでは、公開鍵は id_rsa.pub ID ファイルに保存されます。
```
ssh-copy-id -i ~/.ssh/IDENTITY_FILE root@CLUSTER_NODE_IP
```
クラスタノードマシンで SSH パスワード認証を無効にし、管理ワークステーションで次のコマンドを使用して、管理ワークステーションとクラスタノードマシン間の公開鍵認証が機能することを確認します。
```
ssh -o IdentitiesOnly=yes -i IDENTITY_FILE root@CLUSTER_NODE_IP
```

bmctl ツールをダウンロードしてインストールする

ベアメタル版 Anthos クラスタでクラスタを作成するには、bmctl コマンドラインツールを使用します。 bmctl コマンドは、Google サービスアカウントを自動的に設定し、指定したプロジェクトでベアメタル版 Anthos クラスタを使用するために必要な API を有効にします。

独自のサービスアカウントを作成する場合、またはプロジェクトを手動で設定する場合は、bmctl を使用してクラスタを作成する前に、Google サービスとサービスアカウントの有効化をご覧ください。

bmctl ツールをダウンロードしてインストールするには:

bmctl の新しいディレクトリを作成します。
```
cd ~
mkdir baremetal
cd baremetal
```

Cloud Storage バケットから bmctl をダウンロードします。

gsutil cp gs://anthos-baremetal-release/bmctl/1.7.1/linux-amd64/bmctl bmctl
chmod a+x bmctl

ヘルプ情報を表示して、bmctl が正しくインストールされていることを確認します。
```
./bmctl -h
```

クラスタノードを作成する

クラスタのノードとして機能するマシンを 2 つ作成します。

1 つのマシンはコントロールプレーンノードとして機能します。
1 つのマシンはワーカーノードとして機能します。

ハードウェアおよびオペレーティングシステムの要件（Centos、RHEL、Ubuntu）を参照して、クラスタノードの要件を確認してください。

クラスタの作成

クラスタを作成するには、次の手順を行います。

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
---
apiVersion: baremetal.cluster.gke.io/v1
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.7.1
  # 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
    # containerRuntime specifies which container runtime to use for scheduling containers on nodes.
    # containerd and docker are supported.
    containerRuntime: containerd

---
# 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 は適用モードではありません。
Ubuntu の場合、AppArmor と 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>