インストールを計画する

このページは、GDCV for Bare Metal の小規模な概念実証のインストールについて説明するガイドの最初のページです。このドキュメントでは、最小限のハードウェア環境を設定し、IP アドレスを計画する方法について説明します。フォローアップの基本クラスタを作成するでは、管理クラスタとユーザー クラスタを作成する方法について説明します。このガイドに沿って設定したインフラストラクチャは、実際の本番環境でのニーズやユースケースに適していない可能性があります。本番環境のインストールの詳細については、デプロイモデルを選択するをご覧ください。

準備

  1. GKE on Bare Metal についてを読む。
  2. プロジェクト、IAM 権限、サービス アカウントなど、Google Cloud の基本的なコンセプトについて十分に理解します。
  3. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. 後で必要になるので、Google Cloud プロジェクト ID はメモしておいてください。

手順の概要

インフラストラクチャの最小設定は、次の主なステップで構成されます。

  1. 管理ワークステーションを設定する。オンプレミスの管理タスク用に Linux 管理ワークステーションを設定します。複数のクラスタを管理可能な既存のマシンまたは専用のマシンを使用できます。

  2. クラスタノード マシンを設定する。ノード用に少なくとも 3 つのマシンを設定します（管理クラスタノード、ユーザー クラスタ コントロール プレーン ノード、ユーザー クラスタ ワーカーノード用にそれぞれ 1 つ）。

  3. ネットワーキングを計画する。ノードマシンの IP アドレス、仮想 IP アドレス（VIP）、Service と Pod の CIDR 範囲を計画します。

  4. 必要な Google Cloud リソースを確認する。クラスタを作成するには、Google Cloud プロジェクトに特定の Google API とサービス アカウントが必要です。

1. 管理ワークステーションを設定する

管理ワークステーションは、クラスタを作成して操作するためのツールと構成ファイルをホストします。

ハードウェア要件

管理ワークステーションでは、ツールを実行して、クラスタの作成と管理に関連するリソースを保存するために、大量のコンピューティング能力、メモリ、ストレージを必要とします。

管理ワークステーションが、次のハードウェア要件を満たしていることを確認します。

  • 2 つ以上の CPU コア
  • 4 GiB 以上の RAM
  • 128 GiB 以上のストレージ

オペレーティング システムとソフトウェアを構成する

管理ワークステーションに、次のものをインストールして構成します。

  • Ubuntu を構成する

  • gcloud CLI をインストールする

  • kubectl をインストールする

  • bmctl をインストールする

オペレーティング システムを構成する

bmctl を実行してクラスタを作成するために、管理ワークステーションにはノードと同じオペレーティング システム（OS）の要件があります。各マシンでは、サポートされているバージョンの Ubuntu（Ubuntu 20.04 など）を実行する必要があります。

次のコマンドを実行して、ファイアウォール設定を更新して Docker をインストールして構成し、各マシンで時刻が同期されるようにします。

  1. Uncomplicated Firewall（UFW）を無効にして、そのステータスを確認します。

    sudo ufw disable
sudo ufw status

  2. 以前の Docker バージョンを削除してパッケージ管理システムを更新し、Docker の最新バージョンをインストールします。

    sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg-agent \
  software-properties-common \
  docker.io

  3. Docker のバージョン 19.03 以降を実行していることを確認します。

    sudo docker version

    次のサンプル レスポンスに示すように、クライアントとサーバーの両方のバージョンを 19.03 以降にする必要があります。

    Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 ...

Server:
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.1
  ...

  4. docker グループを作成します。

    sudo groupadd docker

  5. 自分自身を Docker グループに追加します。

    sudo usermod -aG docker $USER

  6. 次のコマンドを実行して、グループの変更を有効にします。

    newgrp docker

  7. 次のコマンドを実行して、システム クロックが同期していることを確認します。

    timedatectl

    timedatectl の出力には次のステータスが含まれます。

    System clock synchronized: yes

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

Ubuntu に Google Cloud CLI をインストールするには、こちらのインストール ガイドの手順を実施します。

管理ワークステーションで次の手順を実施して、gcloud CLI を構成します。

  1. ログインして gcloud CLI の account プロパティを設定します。

    gcloud auth login

  2. gcloud CLI の project プロパティを設定します。

    gcloud config set project PROJECT_ID

    PROJECT_ID は、Google Cloud プロジェクトの ID に置き換えます。

  3. account と project のプロパティが正しく設定されていることを確認します。

    gcloud config list

    出力には、account と project プロパティの値が表示されます。次に例を示します。

    [core]
account = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

kubectl をインストールする

kubectl をインストールするには:

  1. 管理ワークステーションで次のコマンドを実行します。

    gcloud components install kubectl

bmctl をインストールします。

bmctl は、クラスタの作成と管理に使用できる、GKE on Bare Metal が所有するコマンドライン ツールです。

管理ワークステーションに bmctl をインストールするには:

  1. baremetal ディレクトリを作成し、パスに追加します。ホーム ディレクトリにいる場合は、次のコマンドを実行します。

    mkdir baremetal
export PATH="$HOME/baremetal:$PATH"

  2. 次のコマンドを実行して、最新バージョンの bmctl バイナリ ファイルをダウンロードして実行可能にします。

    gsutil cp gs://anthos-baremetal-release/bmctl/1.16.8/linux-amd64/bmctl .
chmod +x ./bmctl

  3. bmctl がインストールされ、実行可能であることを確認します。

    bmctl version

    次のようなレスポンスが表示されます。

    [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023

接続

管理ワークステーションは、Google Cloud とすべてのクラスタノードにアクセスする必要があります。

Google Cloud へのアクセス

管理ワークステーションは、Google Cloud にアクセスして、ツールとイメージのダウンロードとインストール、認可リクエストの処理、サービス アカウントの作成、ロギングとモニタリングの管理などを行います。Google Cloud にアクセスできないと、クラスタを作成できません。

管理ワークステーションからのアクセス

管理ワークステーションからクラスタを作成して管理するには、ノードマシンに対する次のアクセス権が必要です。

  • すべてのクラスタノード マシンへのレイヤ 3 接続。
  • コントロール プレーン VIP にアクセスできる。
  • SSH を使用したすべてのクラスタノード マシンへのパスワードなしの root アクセス。直接または sudo による SSH アクセス。

次のセクションでは、管理ワークステーションとノードマシンで SSH を設定する手順について説明します。

2. クラスタノード マシンを設定する

1 つの非高可用性管理クラスタと 1 つの非高可用性ユーザー クラスタの最小インストールでは、3 台のマシンが必要です。

  • 1 つのコントロール プレーン ノードを持つ管理クラスタのマシン。

  • 1 つのコントロール プレーン ノードと 1 つのワーカーノードがある 2 台のマシン。

ハードウェア要件

各ノードマシンは、次のハードウェア要件を満たす必要があります。

  • 2 つ以上の CPU コア
  • 4 GiB 以上の RAM
  • 128 GiB 以上のストレージ

Ubuntu を構成する

管理ワークステーションで使用した手順と同じ手順に沿って、各ノードで Ubuntu を構成します。

ノードへの SSH アクセスを設定する

管理ワークステーションでは、SSH を使用したすべてのクラスタノード マシンへのパスワードなしの root アクセスが必要です。root アクセスは直接または sudo によるものになります。

GKE on Bare Metal の SSH を設定する手順の概要は次のとおりです。

  1. すべてのマシンに SSH をインストールして構成する

  2. SSH 認証鍵を作成し、各ノードマシンに公開鍵をコピーする

  3. ノードマシンでパスワード認証を無効にする

  4. 管理ワークステーションとノードマシン間の SSH アクセスを確認する

すべてのマシンに SSH をインストールして構成する

GKE on Bare Metal では、管理ワークステーションとクラスタノード間のパスワードなしの SSH 通信が必要です。次の手順は、管理ワークステーションと各ノードマシンで行う必要があります。

Ubuntu を実行しているマシンで SSH を構成するには:

  1. SSH サーバーがまだ実行されていない場合は、ここでインストールします。

    sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh

  2. /etc/ssh/sshd_config ファイルで PermitRootLogin と PasswordAuthentication の行をコメント解除するか追加し、値を yes に設定して、root の SSH パスワード認証を有効にします。

    # Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
...
PasswordAuthentication yes

  3. root のパスワードを設定します。

    sudo passwd root

  4. SSH 構成の変更を適用するには、SSH サービスを再起動します。

    sudo systemctl restart ssh.service

  5. パソコンを再起動します。

  6. 別のマシンから SSH 接続を確立して、SSH が動作していることを確認します。

SSH 認証鍵を作成し、各ノードマシンに公開鍵をコピーする

管理ワークステーションとノード間のパスワードなしの安全な接続のために、管理ワークステーションで SSH 認証鍵を作成し、公開鍵をノードと共有します。

  1. 管理ワークステーションで、秘密鍵と公開鍵のペアを生成します。鍵のパスフレーズは設定しないでください。

    ssh-keygen -t rsa

  2. 管理ワークステーションで、生成された公開鍵を各ノードマシンにコピーします。

    ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP

    以下を置き換えます。

    • PUBLIC_KEY: SSH 公開鍵を含むファイルのパス。デフォルトでは、パスは /home/USERNAME/.ssh/id_rsa.pub です。
    • CLUSTER_NODE_IP: ノードマシンの IP アドレス
ノードマシンでパスワード認証を無効にする

この時点で、パスワード認証を有効にする必要はありません。

各ノードマシン:

  1. /etc/ssh/sshd_config を開き、PasswordAuthentication を no に設定してファイルを保存します。

  2. SSH サービスを再起動します。

    sudo systemctl restart ssh.service
管理ワークステーションとノードマシン間の SSH アクセスを確認する

SSH が正しく構成されると、パスワードなしで管理ワークステーション（root として）からノードマシンへの SSH 接続を確立できます。

管理ワークステーションとクラスタノードの間で公開鍵認証が機能することを確認する

  1. 管理ワークステーションで、ノードマシンごとに次のコマンドを実行します。

    ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP

    以下を置き換えます。

    • PRIVATE_KEY: SSH 公開鍵を含むファイルのパス。デフォルトでは、パスは /home/USERNAME/.ssh/id_rsa です。
    • CLUSTER_NODE_IP: ノードマシンの IP アドレス

3. ネットワーキングを計画する

クラスタをインストールする場合は、アドレスの競合が発生しないように、IP アドレスを計画することが重要です。この単純なインストールの場合でも、適切なアドレスを見つけるにはネットワーク管理者の協力が必要になる場合があります。Pod と Service の CIDR をカウントしない場合は、最小の管理クラスタとユーザー クラスタのインストールに、少なくとも 15 個の一意の IP アドレスが必要です。

次のクラスタ コンポーネントの IP アドレスを計画して指定します。

  • クラスタノード: 各ノードマシンの IP アドレスが必要です。
  • 仮想 IP アドレス（VIP）: Kubernetes API サーバー、Ingress プロキシ、LoadBalancer タイプの Service にアクセスするには VIP が必要です。
  • Pod と Service: クラスタで実行されているすべての Pod と Service に対応する CIDR アドレス範囲が必要です。

このセクションの残りの部分では、この架空のネットワークで機能する値の具体例を紹介します。ユーザーの値とは異なります。

この小規模なインストールでは、管理ワークステーション、管理クラスタノード、ユーザー クラスタノードを同じレイヤ 2 ドメインに配置します。たとえば、172.16.20.0/24 の範囲内のすべての IP アドレスが特定のレイヤ 2 ドメインにルーティングされるとします。また、ネットワーク管理者は、ノードマシンのアドレスに 172.16.20.10 ～ 172.16.20.12、VIP に 172.16.0.13 ～ 172.16.20.24 を使用できると説明しているとします。

次の図は、管理ワークステーション、管理クラスタ、ユーザー クラスタがあるレイヤ 2 ドメインを示しています。

管理クラスタとユーザー クラスタの IP アドレス。
管理クラスタとユーザー クラスタの IP アドレス（クリックして拡大）

クラスタノードの IP アドレスの例

次の表は、クラスタノードで IP アドレスを使用する例を示しています。

マシン 説明 IP アドレス
管理クラスタのコントロール プレーン ノード 管理クラスタのコントロール プレーン ノードとして機能する物理マシン 172.16.20.10
ユーザー クラスタのコントロール プレーン ノード ユーザー クラスタのコントロール プレーン ノードとして機能する物理マシン 172.16.20.11
ユーザー クラスタのワーカーノード ユーザー ワークロードを実行する物理マシン 172.16.20.12

仮想 IP アドレス（VIP）の例

次の表に、クラスタの VIP を指定する方法の例を示します。

VIP Description IP アドレス
管理クラスタ コントロール プレーンの VIP アドレス 管理クラスタ コントロール プレーンの VIP アドレス（管理クラスタの Kubernetes API サーバー） 172.16.20.13
ユーザー クラスタ コントロール プレーンの VIP アドレス ユーザー クラスタ コントロール プレーンの VIP アドレス（ユーザー クラスタの Kubernetes API サーバー） 172.16.20.14
上り（内向き）VIP アドレス 上り（内向き）VIP（MetaLB アドレスプール範囲に含まれる） 172.16.20.15
サービス VIP アドレス LoadBalancer タイプの Service の外部 IP アドレスとして使用する 10 個のアドレス。アドレスは、必要に応じてユーザー クラスタノードに割り当てられます。

この範囲には上り（内向き）VIP が含まれます。この IP アドレスの重複は、デフォルトのバンドル ロードバランサである MetalLB の要件です。

 172.16.20.15 - 172.16.20.24

Pod と Service の IP アドレス

クラスタノードと VIP 用に指定した IP アドレスに加えて、Pod と Service のアドレスを指定する必要があります。Pod IP アドレスに使用する CIDR 範囲と、Kubernetes Services の ClusterIP アドレスに使用される別の CIDR 範囲を指定します。RFC 1918 で説明されているように、プライベート アドレス空間で IP アドレスを使用します。このガイドの次の部分で説明するように、これらのアドレスはクラスタ構成の一部として指定されます。

IP 計画の一環として、Pod と Service に使用する CIDR 範囲を決定します。特に理由がない限り、次の推奨範囲を使用してください。

目的 事前入力された CIDR 範囲
管理クラスタ Pod 192.168.0.0/16
管理クラスタ Service 10.96.0.0/20
ユーザー クラスタ Pod 192.168.0.0/16
ユーザー クラスタ サービス 10.96.0.0/20

推奨される範囲は次のポイントを示しています。

  • Pod の CIDR 範囲は、デフォルトのアイランド モードのネットワーク モデルの複数のクラスタで同じになります。

  • Service の CIDR 範囲は、複数のクラスタで同じ範囲を指定できます。

  • 通常、1 つのクラスタ内の Service よりも多くの Pod が必要であるため、Service CIDR 範囲よりも広い Pod CIDR 範囲が必要になる場合があります。たとえば、ユーザー クラスタの推奨 Pod 範囲は 2(32-16) = 216 アドレスですが、推奨される Service 範囲はユーザー クラスタには 2(32-20) = 212 アドレスのみが存在します。

重複を回避する

ネットワークで到達可能な IP アドレスと重複しないように、前述の推奨事項とは異なる CIDR 範囲の使用が必要になる場合があります。 Service と Pod の範囲は、クラスタ内から到達可能にする必要があるクラスタ外のアドレスと重複しないようにしてください。

たとえば、Service の範囲が 10.96.232.0/24、Pod の範囲が 192.168.0.0/16 であるとします。Pod からこれらの範囲のいずれかのアドレスに送信されたトラフィックは、クラスタ内として扱われ、クラスタ外の宛先に到達できません。

特に、Service と Pod の範囲が次の対象と重複しないようにする必要があります。

  • 任意のクラスタ内に存在するノードの IP アドレス

  • ロードバランサ マシンで使用される IP アドレス

  • コントロール プレーン ノードとロードバランサで使用される VIP

  • DNS サーバーまたは NTP サーバーの IP アドレス

4. 必要な Google Cloud リソースを確認する

クラスタを作成する前に、GKE on Bare Metal では、関連する Google Cloud プロジェクトで特定の Google API のセットを有効にする必要があります。Google API を使用するには、GKE on Bare Metal に、関連する Google Cloud プロジェクトで特定の IAM ロールが構成されたサービス アカウントが必要です。

このガイドの次のパート（基本クラスタを作成する）でクラスタを作成するプロセスでは、API が有効になり、サービス アカウントが自動的に作成されます。

自動的に有効になる Google API は次のとおりです。

  • anthos.googleapis.com
  • anthosaudit.googleapis.com
  • anthosgke.googleapis.com
  • cloudresourcemanager.googleapis.com
  • connectgateway.googleapis.com
  • container.googleapis.com
  • gkeconnect.googleapis.com
  • gkehub.googleapis.com
  • gkeonprem.googleapis.com
  • iam.googleapis.com
  • logging.googleapis.com
  • monitoring.googleapis.com
  • opsconfigmonitoring.googleapis.com
  • serviceusage.googleapis.com
  • stackdriver.googleapis.com
  • storage.googleapis.com

次の表に、自動的に作成されるサービス アカウントを示します。

サービス アカウント 目的 ロール
anthos-baremetal-gcr GDCV for Bare Metal は、このサービス アカウントを使用して Container Registry からコンテナ イメージをダウンロードします。 なし
anthos-baremetal-connect Connect Agent は、このサービス アカウントを使用して、クラスタと Google Cloud 間の接続を維持しますこれにより、クラスタと、Google Cloud コンソールや Connect Gateway などのワークロード管理機能にアクセスして、クラスタを操作できます。 roles/gkehub.connect
anthos-baremetal-register Connect Agent はこのサービス アカウントを使用して、フリートにクラスタを登録します。 roles/gkehub.admin
anthos-baremetal-cloud-ops Stackdriver Agent は、このサービス アカウントを使用して、クラスタから Cloud Logging と Cloud Monitoring にログと指標をエクスポートします。 roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

次のステップ

基本クラスタを作成する