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

Version 1.12 

• 最新
• バージョン 1.16
• 以前のバージョン（サポート対象外）

ベアメタル版 Anthos クラスタの概要

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

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

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

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

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

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

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

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

このクイックスタートでは、すべての Google Cloud リソースを整理する新しい Google Cloud プロジェクトを作成します。Anthos clusters on bare metal にクラスタを作成するには、アカウントにオーナーのロールがある Google Cloud プロジェクトが必要です。

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

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

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

注: Google Cloud CLI の設定では、gcloud コマンドを実行するためのデフォルトのプロジェクトを指定することもできます。ただし、このクイックスタートでは、bmctl コマンドを使用し、gcloud のデフォルトではなく bmctl に指定されたプロジェクトを使用して、ベアメタル版 Anthos クラスタの設定手順（サービス アカウントの作成や API の有効化など）を自動化します。

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

1. 管理ワークステーションで、こちらの手順を使用して、Google Cloud CLI をインストールして初期化します。この手順により、gcloud と gsutil がインストールされます。
2. Google Cloud CLI を更新します。

   gcloud components update
   

3. サービスとサービス アカウントを管理するために、Google アカウントでログインします。

   gcloud auth login --update-adc

   新しいブラウザタブが開き、アカウントの選択を求めるプロンプトが表示されます。

4. gcloud を使用して kubectl をインストールします。

   gcloud components install kubectl

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

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

1. 前のセクションで説明したように、gcloud、gsutil、kubectl をインストールします。
2. Docker バージョン 19.03 以降をインストールします。Docker の構成方法については、ご使用の Linux ディストリビューションに対応するページをご覧ください。
   • CentOS を構成する
   • RHEL を構成する
   • Ubuntu を構成する
3. root アクセスを使用するには、管理ワークステーションとリモート クラスタ ノードマシンの両方で SSH を設定します。最初に、管理ワークステーションから鍵を共有するには、リモート クラスタ ノードマシンで root の SSH パスワード認証を有効にする必要があります。鍵を設定したら、SSH パスワード認証を無効にできます。
4. 管理ワークステーションで秘密鍵と公開鍵のペアを生成します。鍵のパスフレーズは設定しないでください。管理ワークステーションとクラスタノード マシン間のパスワードなしの安全な接続に SSH を使用するには、鍵が必要です。次のコマンドを実行して鍵を生成します。

   ssh-keygen -t rsa

   SSH の設定に、クラスタノード マシンへの SUDO ユーザー アクセスを使用することもできますが、パスワードを使用せず、root ユーザーではない接続の場合は、クラスタ構成ファイルを適切な認証情報で更新する必要があります。詳細については、クラスタ構成ファイルの例の #Node access configuration セクションをご覧ください。

5. 生成された公開鍵をクラスタ ノードマシンに追加します。デフォルトでは、公開鍵は id_rsa.pub ID ファイルに保存されます。

   ssh-copy-id -i ~/.ssh/identity_file root@cluster_node_ip

6. クラスタノード マシンで SSH パスワード認証を無効にし、管理ワークステーションで次のコマンドを使用して、管理ワークステーションとクラスタノード マシン間の公開鍵認証が機能することを確認します。

   ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip

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

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

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

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

1. bmctl の新しいディレクトリを作成します。

   cd ~
   mkdir baremetal
   cd baremetal
   

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

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

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

   ./bmctl -h

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

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

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

注: 管理ワークステーションは、これらのノードに ssh 接続して、コントロール プレーン VIP にアクセスできる必要があります。

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

クラスタの作成

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

1. bmctl を使用して構成ファイルを作成します。
2. 構成ファイルを編集して、クラスタとネットワークに合わせてカスタマイズします。
3. 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

構成ファイルを編集する

構成ファイルを編集するには、次のようにします。

1. エディタで bmctl-workspace/cluster1/cluster1.yaml 構成ファイルを開きます。
2. 特定のノードおよびネットワーク要件を使用してファイルを編集します。参考のため、以下のサンプル構成ファイルを使用します。このクイックスタートでは、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.12.9
  # 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 によってクラスタが作成されます。

プリフライト チェックを実行してクラスタを作成するには、次のようにします。

1. baremetal ディレクトリにいることを確認します。
2. 次のコマンドを使用してクラスタを作成します。

./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 フラグにより、既存のクラスタにインストールされますが、すでに割り当てられているサーバーポートが原因でプリフライト チェックに失敗した場合の結果は無視されます。

1. baremetal ディレクトリにいることを確認します。
2. 次のコマンドで --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>