インストールを計画する

このページは、Google Distributed Cloud ソフトウェア（旧称 Google Distributed Cloud Virtual）を使用して、ベアメタル ハードウェア上で GKE クラスタの小規模な概念実証を作成する方法を説明するガイドの最初のパートです。このドキュメントでは、最小限のハードウェア環境を設定し、IP アドレスを計画する方法について説明します。フォローアップの基本クラスタを作成するでは、管理クラスタとユーザー クラスタの作成方法について説明します。

このガイドに従って設定したインフラストラクチャは、実際の本番環境でのニーズやユースケースに適していない可能性があります。本番環境でのインストールの詳細については、デプロイモデルを選択するをご覧ください。

始める前に

  1. Google Distributed Cloud についてを確認します。
  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 アドレス（VIP）、Service と Pod の CIDR 範囲について、IP アドレスを計画します。

  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 は、クラスタの作成と管理に使用できる、Google Distributed Cloud のコマンドライン ツールです。

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

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

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

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

    gsutil cp gs://anthos-baremetal-release/bmctl/1.29.200-gke.243/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 を設定する手順について説明します。

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

非高可用性の管理クラスタとユーザー クラスタが 1 つずつ存在する最小構成では、次のように 3 台のマシンが必要になります。

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

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

ハードウェア要件

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

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

Ubuntu を構成する

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

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

管理ワークステーションは、すべてのクラスタノード マシンにパスワードなしで SSH 接続する必要があります。root として、またはパスワードなしの sudo 権限を持つユーザーとして SSH を設定できます。

Google Distributed Cloud の SSH を設定する手順は次のとおりです。

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

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

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

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

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

Google Distributed Cloud では、管理ワークステーションとクラスタノードがパスワードなしで 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 説明 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 が含まれます。この重複は、デフォルトのバンドルされたロードバランサである 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
ユーザー クラスタの Service 10.96.0.0/20

推奨範囲は次の点が考慮されています。

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

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

  • 通常、クラスタでは Service よりも多くの Pod が必要であるため、Pod には Service よりも広い 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 リソースを確認する

クラスタを作成する前に、Google Distributed Cloud では、関連する Google Cloud プロジェクトで特定の Google API のセットを有効にする必要があります。Google API を使用する場合、Google Distributed Cloud には、関連する 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 Google Distributed Cloud は、このサービス アカウントを使用して 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

次のステップ

基本クラスタを作成する