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

Version 1.6 (unsupported)

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

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

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

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

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

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

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

ベアメタル版 Anthos クラスタの準備

ベアメタル版 Anthos クラスタのインストール コマンド（bmctl）は、クラスタの作成を効率化するように設計されています。このコマンドは、ベアメタル版 Anthos クラスタに必要な Google サービス アカウントと API を自動的にセットアップします。このクイックスタートでは、これらの自動化サービスを使用します。

また、必要に応じて、bmctl でクラスタを作成する前に、必要なサービスと API を手動で設定することもできます。必要なコマンドの変更については、このドキュメントに後述します。手動で行う必要がある Google サービスについては、Google サービスとサービス アカウントの有効化をご覧ください。

ベアメタル版 Anthos クラスタを使用してクラスタを作成する前に、以下の点を確認してください。

1. 自分が編集者またはオーナーのロールを持つ Google Cloud プロジェクトを作成します。
2. 下の説明に沿って、bmctl コマンドライン ツールをダウンロードしてインストールします。
3. bmctl を実行するための Linux 管理ワークステーションを構成します。注: 管理ワークステーションとしては Cloud Shell を使用しないでください。
   1. 以下の説明に沿って、gcloud、gsutil、kubectl をインストールします。
   2. Docker バージョン 19.03 以降をインストールします。Docker の構成手順については、Linux OS の構成に関するページ（CentOS の構成、RHEL の構成、Ubuntu の構成をご覧ください）。
   3. root アクセスを使用して、管理ワークステーションとリモート クラスタ ノードマシンの両方で SSH を設定します。最初に、管理ワークステーションから鍵を共有するには、リモート クラスタノードマシンで root の SSH パスワード認証を有効にする必要があります。鍵を設定したら、SSH パスワード認証を無効にできます。
   4. 管理ワークステーションで秘密鍵と公開鍵のペアを生成します（鍵のパスフレーズは設定しないでください）。鍵は、管理ワークステーションとクラスタノードマシン間を、SSH を使用して安全なパスワードを使わない接続を行うために必要です。

      ssh-keygen -t rsa

      クラスタ ノードマシンへの SUDO ユーザー アクセスを使用して SSH を設定することもできますが、パスワードなしで、root ユーザーではない接続の場合は、適切な認証情報で cluster config YAML ファイルを更新する必要があります。詳しくは、サンプル クラスタ構成ファイルの #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

gcloud ユーティリティのインストール

gcloud、gsutil、kubectl ツールは、gcloud CLI に含まれています。

1. 管理マシンで、こちらの手順に沿って gcloud CLI をインストールし、初期化します。この手順により、gcloud と gsutil がインストールされます。
2. gcloud CLI を更新します。

   gcloud components update
   

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

   gcloud auth login --update-adc

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

   この時点で Google Cloud のデフォルト プロジェクトを設定し、他のサービスと Google API を有効にすることができます。これは、ベアメタル クラスタ版 Anthos クラスタを作成する前に行います。デフォルトのプロジェクトを設定すると、サービスを手動で有効にした場合の時間を節約できます。

   ただし、このクイックスタートで示すように、クラスタを作成する際、プロジェクトを指定し、必要な Google サービスを bmctl コマンドで直接設定することもできます。これを行う際、bmctl では、コマンドを発行するときに指定したプロジェクト ID が常に使用されます。

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

   gcloud components install kubectl

bmctl のインストール

ベアメタル版 Anthos クラスタにクラスタを作成するコマンドライン ツールは bmctl です。Cloud Storage バケットから bmctl をダウンロードします。

bmctl をダウンロードする:

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

   cd ~
   mkdir baremetal
   cd baremetal
   

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

   gsutil cp gs://anthos-baremetal-release/bmctl/1.6.2/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 プロジェクトです。

このコマンドは bmctl-workspace/cluster1/cluster1.yaml の baremetal ディレクトリの下に構成ファイルを作成します。

構成ファイルの編集

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

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.6.2
  # 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 VIPs 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 LB 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 VIPs: 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.
    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
---
# 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_IP

プリフライト チェックの実行とクラスタの作成

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 の場合、AppArmor と UFW がアクティブではない。
• CentOS/RHEL の場合、ファイアウォールがアクティブではない。
• Google Container Registry に到達可能である。
• VIP が利用可能である。
• クラスタマシンが相互に接続されている。
• ロードバランサ マシンは同じ L2 サブネット上に存在している。

クラスタの作成が完了するまでに数分かかることがあります。

クラスタに関する情報の取得

クラスタが正常に作成されると、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 に実行中の Pod が 3 つあることが表示されます。

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 クラスタでは、サービスに外部 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>