ベアメタル版 Anthos を実際に体験
Google Cloud Japan Team
※この投稿は米国時間 2021 年 1 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。
本ブログ投稿では、自宅ラボにベアメタル版 Anthos（ABM）をインストールした方法をご紹介します。ベアメタル版 Anthos をデプロイするメリット、デプロイに必要な前提条件、インストール プロセス、Google Cloud Operations 機能を使用した、デプロイされたクラスタのヘルスチェックについてご案内します。このブログは、ベアメタル版 Anthos のインストールに関する詳細なガイドではありません。こちらのコミュニティ サイトに投稿したチュートリアルで重要なポイントを紹介していますので、ご参考になさってください。
Anthos の紹介と Anthos をベアメタルで実行する理由について
Google はこのほど、ベアメタル版 Anthos の一般提供を開始したことを発表しました。この発表の詳細は紹介いたしませんが、ご利用のシステムで Anthos を実行した場合、特に次のようなメリットがあります。
ハイパーバイザ上の依存関係を削除することで、アプリケーションを低コストで簡単に実行できます。
サーバーでワークロードを直接実行した場合、多くのユースケースでパフォーマンス上のメリットが得られます。
お客様に近い場所でワークロードをデプロイできる柔軟性を備えているため、レイテンシが低下し、アプリケーションの応答性が向上することで、新たなユースケースの発掘につながります。
環境の概要
私の自宅ラボには、Intel Next Unit of Computing（NUC）のマシンが 2 台あります。それぞれ、i7 プロセッサ、32 GB の RAM、1 台の 250 GB SSD で構成されています。ベアメタル版 Anthos には、32 GB の RAM と少なくとも 128 GB の空きディスク容量が必要です。
どちらのマシンも、ベアメタル版 Anthos に対応したディストリビューションの一つである Ubuntu Server 20.04 LTS が稼働しています。それ以外のマシンでは Red Hat Enterprise Linux 8.1 と CentOS 8.1 が稼働しています。
1 台のマシンが Kubernetes コントロール プレーンとして動作し、それ以外はワーカーノードとなります。さらに、ワーカーノードを使用して bmctl を実行し、ベアメタル版 Anthos のコマンドライン ユーティリティでベアメタル版 Anthos Kubernetes クラスタのプロビジョニングと管理を行います。
Ubuntu マシンでは、Apparmor と UFW の双方を無効にする必要があります。加えて、ワーカーノードを使用して bmctl を実行するために、gcloud、gsutils、Docker 19.03 以降がすべてインストールされている必要があります。
Google Cloud で、自分にオーナーのロールと編集者のロールがあるプロジェクトを作成しておく必要があります。ベアメタル版 Anthos は、3 つのサービス アカウントも利用します。また、複数の API を必要とします。サービス アカウントを作成して API を自分で有効にしなくても、bmctl でこの操作を行えます。
ベアメタル版 Anthos が作成する Cloud Operations ダッシュボードに目を通すので、Cloud Monitoring Workspace をプロビジョニングする必要があります。
インストールを bmctl によって行う場合、bmctl ではターゲット ノードでコマンドを実行するために SSH を使用します。このためにはワーカーノードとコントロール プレーン ノードの間で、パスワードなしで SSH 接続できるよう構成されている必要があります。複数のノードを使用していた場合、bmctl を実行するノードと、すべてのターゲット ノードの間に接続が確立されている必要があります。
前提条件をすべてクリアすると、bmctl のダウンロードとクラスタのセットアップの準備が整います。
クラスタのデプロイ
クラスタを実際にデプロイする手順の概要は次のとおりです。
bmctl をインストールする
ネットワークの設定を確認する
クラスタ構成ファイルを作成する
クラスタ構成ファイルを編集する
bmctl とカスタマイズしたクラスタ構成ファイルを使用してクラスタをデプロイする
bmctl のインストールは非常に簡単です。gsutil を使用して、これを Google Cloud ストレージ バケットからワーカーマシンにコピーし、実行ビットを設定します。
ベアメタル版 Anthos のネットワーク設定
ベアメタル版 Anthos を構成する場合、異なる 3 つの IP サブネットが必要になります。
2 つのサブネットは、ポッド ネットワークとサービス ネットワークという Kubernetes 標準のものです。
第 3 のサブネットは上り（内向き）と負荷分散に使用されます。このネットワークに関連する IP は、負荷分散ノードと同じ（私の場合、コントロール プレーン ノードと同じ）ローカル L2 ネットワーク上に存在する必要があります。ロードバランサ用に IP を 1 つ指定し、さらに上り（内向き）用に 1 つ、続いてクラスタの外部にサービスを公開する場合に選択するロードバランサの範囲を指定します。上り（内向き）VIP は、ロードバランサ用に指定した範囲内のものにする必要がありますが、ロードバランサの IP は指定範囲外の場合もあります。
私のローカル ネットワークの CIDR 範囲は 192.168.86.0/24 です。さらに、すべての Intel NUC を同じスイッチに接続しているので、これらはすべて同じ L2 ネットワーク上に存在しています。
注意点としては、デフォルトのポッド ネットワーク（192.168.0.0/16）が自宅のネットワークと重複しています。この競合が起きないようにするため、自分のポッド ネットワークを 172.16.0.0/16 を使用するように設定しました。これで競合がなくなったので、自分のサービス ネットワークはデフォルト（10.96.0.0/12）を使用しています。選択したローカル ネットワークが bmctl のデフォルトと競合していないか確認することが重要です。
この構成では、コントロール プレーン VIP は 192.168.86.99 に設定されています。上り（内向き）VIP は、ロードバランサ プール用に指定した範囲に含まれる必要があります。ここでは 192.168.86.100 です。さらに、自分のロードバランサ用のアドレスのプールを 192.168.86.100～192.168.86.150 に設定しました。
IP 範囲に加えて、コントロール プレーン ノードとワーカーノードの IP アドレスも指定する必要があります。私の場合、コントロール プレーンは 192.168.86.51、ワーカーノード IP は 192.168.86.52 です。
クラスタ構成ファイルの作成
クラスタ構成ファイルを作成するため、SSH 経由でワーカーノードに接続します。接続後、Google Cloud で認証を行います。
以下のコマンドで、demo cluster という名前の新しいクラスタ用にクラスタ構成ファイルが作成されます。--enable-apis フラグと --create-service-accounts フラグを使用していることに注意してください。このフラグは、bmctl に対して必要なサービス アカウントを作成し、適切な API を有効にすることを要求するものです。
クラスタ構成ファイルの編集
bmctl create config コマンドからの出力は、クラスタの構築方法を定義する YAML ファイルです。ターゲット ノードへの接続に使用する SSH 認証鍵の場所、デプロイするクラスタの種類など、上述のネットワークの詳細を指定するため、このファイルを編集する必要があります。
ベアメタル版 Anthos では、次のようにスタンドアロン デプロイとマルチクラスタ デプロイを作成できます。
スタンドアロン: このデプロイモデルには、ユーザー クラスタと管理クラスタとして機能する単一のクラスタがあります。
マルチクラスタ: 複数のクラスタの管理に使用され、管理クラスタとユーザー クラスタの両方が含まれます。
デプロイするクラスタは 1 つだけなので、スタンドアロンを選択します。
クラスタ構成ファイルに加えた変更は次のとおりです。
ファイルの先頭にあるアクセスキー一覧の下:
sshPrivateKeyPath 変数に、SSH 秘密鍵のパスを指定
クラスタ定義の下:
タイプをスタンドアロンに変更
コントロール プレーン ノードの IP アドレスを設定
ポッド ネットワークの CIDR 範囲を調整
コントロール プレーン VIP を指定
上り（内向き）VIP のコメントを解除して VIP を指定
addressPools セクションのコメントを解除（実際のコメントを除外）してロードバランサのアドレスプールを指定
NodePool 定義の下:
ワーカーノードの IP アドレスを指定
クラスタ定義の yaml 用に GitLab スニペットを作成しましたので参考にしてください（簡潔にするためコメントは削除しています）。
クラスタの作成
構成ファイルの編集が完了すると、次のように bmctl の create cluster コマンドを使用してクラスタをデプロイできます。
./bmctl create cluster -c demo-cluster
bmctl で一連のプリフライト チェックを実行してからクラスタを作成します。チェックで問題があった場合、出力で指定したログファイルを調べます。
インストールが完了すると、kubeconfig ファイルが /bmctl-workspace/demo-cluster/demo-cluster-kubeconfig に書き込まれます。
この kubeconfig ファイルを使用して、他の Kubernetes クラスタと同様に、作成されたクラスタに対してコマンドを実行できます。
ロギングとモニタリングについて
ベアメタル版 Anthos は、クラスタがプロビジョニングされるとき、ノードのステータス、ポッドのステータス、コントロール プレーンのステータスという 3 つの Google Cloud Operations（旧称 Stackdriver）のロギング ダッシュボードとモニタリング ダッシュボードを自動的に作成します。これらのダッシュボードによって、クラスタの状態を迅速に可視化できます。この 3 つのダッシュボードに加えて、Google Cloud Operations Metrics Explorer でさまざまなパフォーマンス データポイント向けにカスタムクエリを作成できます。
ダッシュボードを表示するには、Google Cloud Console に戻り、[Operations] セクションに移動して、[Monitoring and Dashboards] を選択します。
画面中央のリストに 3 つのダッシュボードが表示されます。3 つのダッシュボードそれぞれについて、利用可能なグラフを調べます。
まとめ
これで完了です。ベアメタル版 Anthos を使用すると、数個のコマンドの実行で、一元管理される Kubernetes クラスタを作成できます。デプロイされたクラスタは Google Cloud Console に表示され、他の GKE クラスタを使用した場合と同様にアプリケーションがデプロイされます。利用可能なハードウェアを入手したら、私の実践的なチュートリアルをひととおり実行することをおすすめします。
-Cloud デベロッパー アドボケイト Mike Coleman
