ハードウェアでの基本的なインストールを計画する

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

このページは、基盤となる技術インフラストラクチャのライフサイクルの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

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

始める前に

  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 以上のストレージ

オペレーティング システムの要件

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

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

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

  • Ubuntu を構成する

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

  • kubectl をインストールする

  • bmctl をインストールする

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

次のコマンドを実行して、ファイアウォールの設定を更新します。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 バイナリ ファイルの最新バージョンをダウンロードし、実行可能にします。

    gcloud storage cp gs://anthos-baremetal-release/bmctl/1.30.300-gke.84/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 にアクセスできる。
  • root またはパスワードなしの sudo 権限を持つユーザーとして、すべてのクラスタノード マシンにパスワードなしで SSH アクセスできる。

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

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

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

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

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

ハードウェア要件

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

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

オペレーティング システムの要件

各ノードマシンは、サポートされているバージョンの Ubuntu を実行する必要があります。

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 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 が含まれます。この重複は、デフォルトのバンドルされたロードバランサである 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 範囲は、複数のクラスタで同じ範囲を指定できます。

  • 通常、クラスタでは 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

次のステップ

基本クラスタを作成する